On 15/05/15 09:55, Sebastian Moeller wrote:
Hi Lars,
On May 15, 2015, at 10:18 , Eggert, Lars <l...@netapp.com> wrote:
On 2015-5-15, at 06:44, Aaron Wood <wood...@gmail.com> wrote:
ICMP prioritization over TCP?
Probably.
Interesting so far I often heard ICMP echo requests are bad as they are
often rate-limited and/or processed in a slow path in routers...
Yes, if you ping an ISP router itself. You can avoid that by pinging an
end-host. Then you'll reveal silly QoS implementations at the edge of
the network which prioritize ping. Or hit one like SQM (simple.qos)
that de-prioritises it. So you can get biased results in either
direction :). Need to test very carefully.
I like that rrul includes udp probes as well.
The betterspeedtest and netperfrunner.sh scripts let you ping a router
if you want, which is what I started off my testing with. You can get a
nice low minimum but I don't really trust that now. By default they ping
a local google IP, which might give more consistent results.
Ping in parallel to TCP is a hacky way to measure latencies; not only because
of prioritization, but also because you don't measure TCP send/receive buffer
latencies (and they can be large, auto-tuning is not so great.)
I guess the concurrent ICMP echo requests are a better measure for flow
separation and sparse-flow-boostiing than inter-flow latency. TCP embedded
timestamps would be a jacky way to measure those ;) .
+1
You really need to embed timestamps in the TCP bytestream and echo them back.
See the recent netperf patch I sent.
I hope this makes into the main netperf branch…
Best Regards
Sebastian
_______________________________________________
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel
