On Fri, 2006-23-06 at 22:37 +1000, Russell Stuart wrote: > Sorry for the digest like reply :(
;-> I know this discussion has gone in a few directions already and i am sure as you kept responding to the emails it became obvious. Let me just jump to one point so we dont repeat a lot of the same things over and over.. You can actually stop reading here if you have gathered the view at this point that i am not objecting to the simple approach Patrick is going with... > On Tue, 2006-06-20 at 10:06 -0400, jamal wrote: > But you can measure the bandwidth you are > getting from your ISP and plug that into the tc command > line. The web page I sent to you describes how to do this > for ADSL lines. > Indeed and i referred to it in the exchanges. And yes, I was arguing that the tc scheme you describe would not be so bad either if the cost of making a generic change is expensive. To reiterate the scheduler "owns the resources" of the link i.e link level bandwidth - aka throughput; however, teaching the scheduler as in your description in that page about effective throughput aka "goodput" is also within reason if you knew _it was consistent_ . The diagram i drew was: |Linux| --ethernet-- |Modem| --DSL-- |DSLAM| --ATM-- |BRAS| As can be seen from above, Linux has direct ownership of the ethernet link resources (within limits of fixed bandwidth no AN etc). Just like a disk quota scheduler owns the disk resources or CPU scheduler owns the CPU cycles etc. Likewise, the DSLAM downstream owns scheduling of the ATM link resources. if you have knowledge that ATM runs between DSLAM and BRAS and that the effective throughput is in-fact lower than the advertised one at that point in the end2end path, then i admit it is fine to do as you described in your web-page. Given the ubiquity of ADSL it is also ok to have simple tweak knobs for the scheduler in Linux to allow for it to be able to compensate for the ATM fragmentation 3 hops down. There are a lot of link layer issues that you may end up knowing of (other than the ATM fragmentation overhead) in regards to something downstream and you keep adding knobs is just adding more bloat. Example: If that 3rd hop was wireless that happened to be doing CDMA RLP with a lot of retransmits, or wireless that varied its throughput from 1-3Mbps at any point in time or it was a satellite link that had a lot of latency etc etc. You could always have some way to tweak these via the kernel. In-fact people have written schedulers specifically for these sorts of link layer problems (I think even some of the IEEE 802.11 or wimax folks have standardized specific schedulers). You basically have to draw a line somewhere. My line was "can it be done via user space? yes - do it there". Patrick seems to have a simple way to compensate generically for link layer fragmentation, so i will not argue the practically; hopefully that settles it? ;-> cheers, jamal - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
