"Paul E. McKenney" writes: > I am using these two in a new "Effectiveness of FQ-CoDel" section. > Chrome can display .svg, and if it becomes a problem, I am sure that > they can be converted. Please let me know if some other data would > make the point better. If you are just trying to show the "ideal" effectiveness of fq_codel, two attached graphs are from some old tests we did at the UDS showing a simple ethernet link between two laptops with a single stream going in each direction. This is of course by no means a real-world test, but on the other hand they show a very visible factor ~4 improvement in latency. These are the same graphs Dave used in his slides, but also in a 100mbit version. > Also, I know what ICMP is, but the UDP variants are new to me. Could > you please expand the "EF", "BK", "BE", and "CSS" acronyms? The UDP ping times are simply roundtrips/second (as measured by netperf) converted to ping times. The acronyms are diffserv markings, i.e. EF=expedited forwarding, BK=bulk (CS1 marking), BE=best effort (no marking). The UDP ping tests tend to not work so well on a loaded link, however, since netperf stops sending packets after detecting (excessive(?)) loss. Which is why you see only see the UDP ping times on the first part of the graph. The markings are also used on the TCP flows, as seen in the legend for the up/downloads. > All sessions were started at T+5, then? The pings start right away, the transfers start at T+5 seconds. Looks like the first ~five seconds of transfer is being cut off on those graphs. I think what happens is that one of the streams (the turquoise one) starts up faster than the other ones, consuming all the bandwidth for the first couple of seconds until they adjust to the same level. These initial values are then scaled off the graph as outlier values. If you zoom in on the beginning of the graph you can see the turquoise line coming down from far off the scale in one direction, while the rest come From off the bottom. > Please see attached for update including .git directory. I got a little lost in all the lists of SFQ, but other than that I found it quite readable. The diagrams of the queuing algorithms are a tad big, though, I think. :) When is the article going to be published? -Toke -- Toke Høiland-Jørgensen toke@toke.dk