* Jussi Peltola <[email protected]> [2011-11-24 15:18]: > On Thu, Nov 24, 2011 at 02:21:57PM +0100, Henning Brauer wrote: > > 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. > There won't be an appreciable queue on a router that is not next to the > choke point. It will just pass the packets toward the modem at whatever > rate they come, unless you configure the queue bandwidth lower than > the choke point's, invalidating the assumption that the router is not next > to the choke point...
you are once again missing the point. the packets arrive reordered at the modem, priority queueing has done its job. > > > If the modem ist not queueing packets, why do you do priorization? > > that sentence doesn't make any sense at all. > It makes perfect sense. You control what the modem does with the packets > in its queue with marking, assuming the modem actually honors that. I don't have "modems" in the path to begin with, but that's a whole different story. your unfounded claims are just that and parts plain don't make any sense. like this. the reordering has already happened at that point. is that really so hard to understand? > > > 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? > It does not reorder much at all if the rate is less than the max. wrong. > > > > 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. > Since there is not much queue on the machine where you are prioritizing, sigh. you speak as if you knew internals, but your assumptions are off. i just rewrote prio queueing for openbsd, i naturally know the internals - I wrote them. > the packets go out immediately. The prioritized traffic is not any more > likely to get delivered, or getting any less delay. It may get ahead of > a few packets in case of a burst, but the majority of the queue is in > the modem and not affected, and neither is the risk of the packet > getting dropped. you once again miss the point big time. priorization doesn't have much to do with a fifo queue in some shaby modem. > > 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. > reordering packets implies that you hold some in a queue, i.e. delay hey, news: every packet going thru (or originating at) an OpenBSD machine is in queue at at least one point. another of your basic assumptions which is plain wrong. it's not 1990 any more. you don't PIO-grab a packet at a time off a NIC and process it to completion (i. e. has left the system thru the outgoing NIC). > some packets less and some packets more. when does this happen when the > actual rate of packets is lower than the queue's max rate? your basic misunderstanding is the wrong assumption that no queueing goes on unless you run an interface at line rate. > In any case, when your modem's queue is full, which is the case we are > talking about here, sigh. it is what YOU are talking about, based on wrong assumptions. > reordering is 100% useless. another unfounded and 100% wrong claim. > The modem randomly drops > packets and delaying some packets less than other packets will not make > it any less likely that the modem will drop them. network devices typically have a simple fifo queue. they don't change packet order. note the "typically". there are exceptions. which are exactly that - exceptions. > The original poster's objective was > > 1) Utilize the full link bandwidth > 2) Prioritize some packets (affecting their risk of getting dropped, and > their delay) no priorization can ever influence the risk of dropping for certain packets on other devices, at least for not trivially short pathes. not without a priority marker being passed thru the entire path AND all devices honouring it. which doesn't happen in reality. not as soon as your packet leaves your own controlled network. you do influence the delay. the more the closer you are to the bottleneck, of course, but you still do anywhere in the path. an openbsd machine having only one packet "in flight" at a time? very very very unlikely in practice. and those in flight - anywhere between in ipintrq and the dequeueing from the outbound interface's queue - get reordered. > This is impossible to do if you do not have feedback about the modem's > queue, or knowledge of the speed of the link. 2) is possible without 1), > assuming that some lower bound of the link speed is known. 1) is > obviously possible without any prioritization at all. modem modem modem modem modem boredom. i dunno what is so hard to understand about packet reordering based on priority. prio queueing is best effort, no guarantees. with more effort (towards low delay) for higher priorized traffic. no more, no less. -- Henning Brauer, [email protected], [email protected] 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/
