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...
> > 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. > > 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. > > > 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, 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 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 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? In any case, when your modem's queue is full, which is the case we are talking about here, reordering is 100% useless. 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. 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) 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. Jussi Peltola
