[Cake] [Cerowrt-devel] [Bloat] heisenbug: dslreports 16 flow test vs cablemodems
Alan Jenkins
alan.christopher.jenkins at gmail.com
Fri May 15 07:10:30 EDT 2015
On 15/05/15 09:55, Sebastian Moeller wrote:
> Hi Lars,
>
>
> On May 15, 2015, at 10:18 , Eggert, Lars <lars at netapp.com> wrote:
>
>> On 2015-5-15, at 06:44, Aaron Wood <woody77 at 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
>
More information about the Cake
mailing list