:i haven't seen the beginning of the thread but surely both altq
:and dummynet can help, with the CBQ/WFQ support.
:
:In the case of dummynet, you can pace incoming traffic as well,
:at your endpoint. This means you act after the bottleneck,
:but the effect is that this way
:you will delay acks, and so slow down the connection eating a lot of
:bandwidth, and in the steady state this keeps the queue very
:short even before the bottleneck.
:Much like what products like packeteer do.
:
: cheers
: luigi
I don't know much about CBQ (Class Based Queuing) and WFQ (Weighted
Fair Queueing), but my impression is that these protocols would only
effect the transmit side (like the patch I posted) and would also have
to be implemented at the router nodes rather then simply at the
end points. Of course, for a modem your end point *is* a router node
so that would probably work ok.
The patch I posted, implementing bandwidth delay product adjustments
to the transmit window, should work extremely well with a modem or
DSL line (where the bandwidth restriction occurs near the end points
rather then in the middle of the network), but again it only effects
outgoing data. I'm looking at Julian's algorithms to see if there
is a receive side solution I can implement that wouldn't conflict
with the transmit side solution.
-Matt
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
