On 2008/01/13 12:16, Darrin Chandler wrote:
> On Sun, Jan 13, 2008 at 12:53:38PM -0600, Max Hayden Chiz wrote:
> > Because several people have asked, my Internet connection is a
> > business class cable connection with guaranteed 512Kbps up and 7Mbps
> > down. I do get those speeds and can sustain them essentially
> > indefinitely.
> >
> > On Jan 12, 2008 9:01 PM, Max Hayden Chiz <[EMAIL PROTECTED]> wrote:
> > >
> > > altq on $ext_if priq bandwidth 512Kb queue{ack, main, others, bt}
>
> On my home assymetric connection I noticed that I had to adjust the
> bandwidth down just a little before the ackpriq method worked well. Yes,
> I measured upload speed and tried *that* number, but I still had to set
> it a bit lower. This is purely anecdotal, and I didn't do in-depth
> measurements. However, it's easy to try. :)
it looks like cable modems normally use time-division multiple access
for the upstream, the cable modem requests a timeslot and the CMTS has
to grant access to it. this doesn't fit too well with altq, which can't
know when it has access to send (the CMTS decides how to split time
between the various subscribers contending for access to the channel).
when transmitting a larger block of data, the access requests are
piggybacked onto transmitted data where possible, otherwise they go in
a separate contention timeslot; if the cable modem doesn't know it has
more to send (which I suspect might happen if rate-limiting takes place
prior to the cable modem) it won't be able to piggyback.
it also comes to mind that if access to the upstream is bursty, you
probably want to have the packets queued on the cable modem so it can
send them when it has a timeslot, so I wonder if sending them to the
CM at 512Kb/s might hurt this too.
there is also an optimisation to avoid sending some TCP acks described
at http://www.cedmagazine.com/docsis-per-sub-throughput-optimization.aspx
which might also be interfered with.
I think the upshot is you might well be better off to let the cable
modem handle all this stuff, so do some measurements and find out...
ADSL is different, normally upstream isn't affected by contention, but
the packets are encapsulated in various layers, one of which is fixed-
size ATM cells, so the overhead varies depending on the exact size
of a packet - with PPPoE(overATM AAL5), if my sums are right, a TCP
packet with 1-15 bytes of data takes 1 cell, 16-63 bytes data takes
2 cells, so you can see that a TCP packet with 63 bytes of data has
47 bytes less overhead than one with 16 bytes, and normal altq
doesn't understand this. the best you can do is to back off from
the real bandwidth, but this doesn't give accurate information about
how much bandwidth is really available, so the scheduler's decisions
on packet ordering and rate aren't optimal.
I really must dust off the diff for making this work better, I have
to rework the config interface, so I get an exciting chance to learn
more about yacc too. excellent...
