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

[Dave Taht <dave.taht@gmail.com>]

On Thu, May 14, 2015 at 7:48 PM, Greg White <g.white@cablelabs.com> wrote:
> I don't have any ideas, but I can try to cross some of yours off the
> list...  :)
>
> "* always on media access reducing grant latency"
> During download test, you are receiving 95 Mbps, that works out to what,
> an upstream ACK every 0.25ms?  The CM will get an opportunity to send a
> piggybacked request approx every 2ms.  It seems like it will always be
> piggybacking in order to send the 8 new ACKs that have arrived in the last
> 2ms interval.  I can't see how adding a ping packet every 10ms would
> influence the behavior.
>
> "* ack prioritization on the modem"
> ACK prioritization would mean that the modem would potentially delay the
> pings (yours and dlsreports') in order to service the ACKs.  Not sure why
> this wouldn't delay dslreports' ACKs when yours are present.
>
> "* hitting packet limits on the CMTS..."
> I'd have to see the paper, but I don't see a significant difference in DS
> throughput between the two tests.  Are you thinking that there are just
> enough packet drops happening to reduce bufferbloat, but not affect
> throughput?  T'would be lucky.

http://www.i-teletraffic.org/fileadmin/ITCBibDatabase/2014/braud2014tcp.pdf

was that paper.

My thinking was possibly CMTS's also use GRO equivalents and a limit
on the number of packets. So we end up with some big flows having 15k
or more "packets" queued up counting as 1 packet. So accumulating 20
ping packets can push out a GRO "packet" in that tail drop system.

too bad I don't know any CMTS experts.... ;)

I guess I will go fiddle with the math. Lord knows offloads have
caused us and continue to cause us major headaches on linux. It would
not surprise me if they were elsewhere.

(I like that slow start behaviors have become more analyzed of late)


So some small
>
>
>
> On 5/14/15, 1:13 PM, "Dave Taht" <dave.taht@gmail.com> wrote:
>
>>One thing I find remarkable is that my isochronous 10ms ping flow test
>>(trying to measure the accuracy of the dslreports test) totally
>>heisenbugs the cable 16 (used to be 24) flow dslreports test.
>>
>>Without, using cake as the inbound and outbound shaper, I get a grade
>>of C to F, due to inbound latencies measured in the seconds.
>>
>>http://www.dslreports.com/speedtest/479096
>>
>>With that measurement flow, I do so much better, (max observed latency
>>of 210ms or so) with grades ranging from B to A...
>>
>>http://www.dslreports.com/speedtest/478950
>>
>>I am only sending and receiving an extra ~10000 bytes/sec (100 ping
>>packets/sec) to get this difference between results. The uplink is
>>11Mbits, downlink 110 (configured for 100)
>>
>>Only things I can think of are:
>>
>>* ack prioritization on the modem
>>* hitting packet limits on the CMTS forcing drops upstream (there was
>>a paper on this idea, can't remember the name (?) )
>>* always on media access reducing grant latency
>>* cake misbehavior (it is well understood codel does not react fast
>>enough here)
>>* cake goodness (fq of the ping making for less ack prioritization?)
>>* ????
>>
>>I am pretty sure the cable makers would not approve of someone
>>continuously pinging their stuff in order to get lower latency on
>>downloads (but it would certainly be one way to add continuous tuning
>>of the real rate to cake!)
>>
>>Ideas?
>>
>>The simple test:
>># you need to be root to ping on a 10ms interval
>># and please pick your own server!
>>
>>$ sudo fping -c 10000 -i 10 -p 10 snapon.lab.bufferbloat.net  >
>>vscabletest_cable.out
>>
>>start a dslreports "cable" test in your browser
>>
>>abort the (CNTRL-C) ping when done. Post processing of fping's format
>>
>>$ cat vscabletest_cable.out | cut -f3- -d, |  awk '{ print $1 }' >
>>vscabletest-cable.txt
>>
>>import into your favorite spreadsheet and plot.
>



-- 
Dave Täht
Open Networking needs **Open Source Hardware**

https://plus.google.com/u/0/+EricRaymond/posts/JqxCe2pFr67