Re: [Cerowrt-devel] [Cake] [Bloat] heisenbug: dslreports 16 flow test vs cablemodems

[Alan Jenkins <alan.christopher.jenkins@gmail.com>]

On 15/05/15 09:55, Sebastian Moeller wrote:
> Hi Lars,
>
>
> On May 15, 2015, at 10:18 , Eggert, Lars <lars@netapp.com> wrote:
>
>> On 2015-5-15, at 06:44, Aaron Wood <woody77@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
>