* Christopher Zimmermann <madro...@zakweb.de> [2011-11-24 12:28]: > On 11/23/11 20:58, Henning Brauer wrote: > > * Jussi Peltola <pe...@pelzi.net> [2011-11-20 04:09]: > >> On Sat, Nov 19, 2011 at 08:58:46PM -0500, quartz wrote: > >>> is there a way to set up altq+priq on an internet connection with highly > >>> variable/unknown bandwidth? > >>> I'd like to create a simple one layer queue system that prioritizes empty > >>> ACKs over anything else (always, all the time, no matter the load or > >>> congestion). it looks like priq is the way to do this, but all the > >>> documentation I can find seems to say you have to type in a hard number, > >>> which won't work for my case. > >> This is usually impossible. The packets get re-queued in the modem or > >> whatever device is next to the choke point, and any prioritization you > >> configure becomes useless. Typically the only way around it is to send > >> at a rate slightly lower than the choke point bandwidth, so the buffer > >> of the modem never starts to get utilized. If the bandwidth is variable, > >> you're screwed. > > this is not true for simple priority queueing. it just reorders the > > packets. the modem is not supposed to, so your higher priority packets > > still go out before the later sent lower priority ones. > This works only as long as the modem doesn't start to drop packets > because its queue is full.
that changes the order how exactly? the only valid point is that the modem drops packets regardless of their priority while we would drop low prio first. > If the modem ist not queueing packets, why do you do priorization? that sentence doesn't make any sense at all. > Most people use priority queueing because they want short delay on some > connections like ssh, VoIP... They don't want the modem to buffer > packets at all because that would add delay. > This means you can priorize packets only on the bottleneck. sigh. what part in "simple priority queueing just reorders packets" didn't you understand? > > however and admittedly: > > the effect of simple priority queueing isn't all that drastic since > > your machine only reorders within the packets it has in flight at the > > given moment (few less even). > > the combo of the extra buffer and the lower bandwidth link further > > down the road minimizes the effects - foremost when there is congestion > > on that slower link. > as soon as the modem starts queueing your deley rises (my modem buffers > up to 2500ms - try doing VoIP over such a connection). > as soon as the modem starts dropping packets (because it has a small > buffer or because it gets fed with 100MBit) your priorization won't > work anymore, too. wrong. the priorization works just fine. the priorized packets go out before the unpriorized ones. you don't get your desired effect, but that is a whole different story. > You cannot do any kind of bandwidth shaping, priorization or fair > queueing on any link but the bottleneck. that is plain bullshit. it is most effective at the bottleneck, but especially priority queueing - how often do I have to stress this, which just REORDERS PACKETS - has its effects and value no matter where. it does not suffice to guarantee low delay for voip or the like, but that has never been promised. -- Henning Brauer, h...@bsws.de, henn...@openbsd.org BS Web Services, http://bsws.de, Full-Service ISP Secure Hosting, Mail and DNS Services. Dedicated Servers, Root to Fully Managed Henning Brauer Consulting, http://henningbrauer.com/
