* Eric Dumazet | 2011-12-29 10:12:02 [+0100]: >> Also, the whole tfifo idea is only to support the wierd idea that >> if doing random delay that packets should get reordered based on the >> results of the random value; it was an behavior some users wanted >> because that is what NISTnet did. > >tfifo supports a time ordered queuing, wich mimics some jitter in the >network. This seems quite useful. > >I see what you suggest : adding 'time_to_send' in the generic qdisc cb. > >But it makes no sense if we attach a reordering qdisc, like SFQ : >A 'high prio' packet will block the whole netem because we'll have to >throttle since this packet time_to_send will be in the future, while >many other elligible packets are in queue. In other words netem jitter and a qdisc !tfifo will not work. Correct? The rate extension also peak the last packet to get the reference time (assuming a strict ordering): [...] now = netem_skb_cb(skb_peek_tail(list))->time_to_send; [...] We should avoid a different (unseeable) behavior depending on the queue (tfifo, SFQ). Another point: operate netem and qdisc on the same computer can lead to timing abnormalities. In our test setups we operate qdisc/tcp/whatever setups and netem on more then on computer. Hagen -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html