User comments on ISPs
  >> AAISP


Register (or login) on our website and you will not see this ad.


  Print Thread
Standard User CecilWard
(newbie) Fri 03-Mar-17 19:59:16
Print Post

Dripping blood in clueless


[link to this post]
 
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.
Standard User bet_here
(member) Fri 03-Mar-17 21:22:06
Print Post

Re: Dripping blood in clueless


[re: CecilWard] [link to this post]
 
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)

Standard User CecilWard
(newbie) Sat 04-Mar-17 00:22:28
Print Post

Re: Dripping blood in clueless


[re: bet_here] [link to this post]
 
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.


Register (or login) on our website and you will not see this ad.

Standard User bet_here
(member) Sat 04-Mar-17 02:15:11
Print Post

Re: Dripping blood in clueless


[re: CecilWard] [link to this post]
 
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)

Standard User CecilWard
(newbie) Sun 05-Mar-17 05:25:58
Print Post

Re: Dripping blood in clueless


[re: bet_here] [link to this post]
 
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?
Administrator MrSaffron
(staff) Sun 05-Mar-17 09:52:17
Print Post

Re: Dripping blood in clueless


[re: CecilWard] [link to this post]
 
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.

The author of the above post is a thinkbroadband staff member. It may not constitute an official statement on behalf of thinkbroadband.
ISP Representative andrewhearn
(isp) Mon 06-Mar-17 14:41:51
Print Post

Re: Dripping blood in clueless


[re: CecilWard] [link to this post]
 
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.

Andrew Hearn
AAISP
aa.net.uk support@aa.net.uk 033 33 400 999
The above post has been made by an ISP REPRESENTATIVE (although not necessarily the ISP being discussed in the post).
Standard User CecilWard
(newbie) Sun 30-Jul-17 08:21:37
Print Post

Re: Dripping blood in clueless


[re: MrSaffron] [link to this post]
 
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 FBs 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.
  Print Thread

Jump to