Dripping blood in clueless

I have three DSL lines bonded. Last night I was doing a flat-out download and one (only) of the three lines was showing fairly serious dripping blood in clueless. It was the line that is the fastest of the three by a small amount (<10% faster than the slowest). Is this normal?

No dripping blood anywhere at other times. That line is set to 99% rate in clueless.

I rarely seem to max out my line, but when I do I see this

My Broadband Ping

My line is set at 95%, I think. (VoIP setting)

Edited by bet_here (Fri 03-Mar-17 21:23:34)

Any thanks. Although you are using ICMP echo request response pings, not the graphs in AA's clueless which show PPP LCP echo request responses, not the usual kind of 'pings', a completely different protocol. But loss is loss.

https://control.aa.net.uk/graphimg.cgi/2017-02-05/37...

It was easier whilst browsing TBB to link to one of their graphs.

Simon.

Edited by bet_here (Sat 04-Mar-17 12:25:38)

Simon, it may be then that what I am seeing is just normality. I don't know why responses to LCP pings are not being seen coming back. I also don't know why this is only happening on one out of my set of three bonded lines. (The one with the highest sync speed, by a small amount.)

Does everyone get this all the time? On flat-out downloads only?

What are you expecting if a line is running flat out download wise?

Without any traffic prioritisation the pings will be delayed by virtue of being swamped by the download traffic.

At a guess, I've not looked, it may need the speed setting adjusted in your FireBrick PPP config - perhaps it's set to a speed higher than the line upload speed and is therefore sending too much traffic up it.

Agree with Mr Saffron. But that is the entire point. Firebricks don't have proper QoS unfortunately but they are supposed to make do with a general heuristic that prioritises small packets. So surely PPP LCP pings ought to qualify? Then they should go first and queue-jump, no? So it would seem that the queuing must have been elsewhere? This would definitely have been the case before for flat-out @100% upstream.

I took Andrew from AA's advice. I recently did some extensive detailed timing measurements involving uploads on three lines and a lot of slog in a spreadsheet to examine RTT in different scenarios and compare near-zero load RTT with the case of a flat-out upload with MTU-sized packets. From this I think/hope I managed to work out the queuing delay, either in the modems or else in the Firebrick, as the FB�s rate-limiters' settings are varied and it throttles upstream packets before they get into the modem. The conclusions were that the modem seems to have a buffer with 16 slots, each of 1536-bytes, best guess, which comes to 24kiB exactly. When you get to 16 packets in the queue (each being full MTU size in this particular test case), that's when the packet loss really kicks in, as you would expect. Btw, 1536 is an interesting number, the worst-case AAL5 payload size excluding CPCS for PPPoEoA.

By cutting the rates down to 97.5% instead of 100% of the theoretical protocol efficiency for PPPoEoA with 1532 byte ATM payload (that is incl AAL5 CPCS trailer and all overheads of higher protocols), I brought the queuing delay right down, so that the RTT was around 150ms on a flat-out upload. (I calculate the protocol efficiency as roughly 0.884434 * sync rate, from the number of whole ATM cell payloads required to take 1532 bytes * 48 / 53 for ATM inefficiency)

Anyone who is interested can have the spreadsheet. It's from the Apple iOS "Numbers" app, but that app, does claim iirc to be able to write Excel files.