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

[Greg White]

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.




On 5/14/15, 1:13 PM, "Dave Taht" <dave.taht at 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.