> On 19 Apr, 2015, at 21:30, Toke Høiland-Jørgensen <t...@toke.dk> wrote: > >>> Why not? They can be a quite useful measure of how competing traffic >>> performs when bulk flows congest the link. Which for many >>> applications is more important then the latency experienced by the >>> bulk flow itself. >> >> One clear objection is that ICMP is often prioritised when UDP is not. >> So measuring with UDP gives a better indication in those cases. >> Measuring with a separate TCP flow, such as HTTPing, is better still >> by some measures, but most truly latency-sensitive traffic does use >> UDP. > > Sure, well I tend to do both. Can't recall ever actually seeing any > performance difference between the UDP and ICMP latency measurements, > though...
On a LAN, I usually see that ICMP gets a small bonus from being returned by the kernel rather than needing to wake up a userspace process. That might matter less when the target host is multicore; I’ve often been using an old Thinkpad as a target. In any case, it’s a constant factor without much dependence on network load. The one ISP I know of on this side of the pond which does any prioritisation - there are many I don’t know about - prioritises small packets in general, though I don’t know where they set their threshold, specifically to help VoIP and gaming traffic. I don’t think they treat ICMP specially beyond that. But they’re a clueful one; there are many others less clueful. Meanwhile, I’m presently (briefly) in a very rural part of Finland, where old 2G equipment (which I assume was redundant from early populated-area deployments) was relocated to improve coverage. Twenty miles from any decent-sized town, fifteen miles from the nearest 3G tower, and about 7.5 miles from any worthwhile shops (ie. that sell food). That means the local coverage is GPRS - not even EDGE. And I brought some of the more portable components of my lab with me. This should be fun… - Jonathan Morton _______________________________________________ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat
