Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Weaver]

I’m having nightmare problems with Zoom at the moment and I can see really bad packet loss and horrible latency with line 1. Have talked to AA - they’re stumped so I’ve asked that it be escalated.

Here are the stats for modem 1:

Code: [Select]

xdslctl: ADSL driver and PHY status
Status: Showtime
Last Retrain Reason: 8000
Last initialization procedure status: 0
Max: Upstream rate = 767 Kbps, Downstream rate = 2708 Kbps
Bearer: 0, Upstream rate = 767 Kbps, Downstream rate = 2656 Kbps

Link Power State: L0
Mode: ADSL2 Annex A
TPS-TC: ATM Mode(0x0)
Trellis: U:ON /D:ON
Line Status: No Defect
Training Status: Showtime
Down Up
SNR (dB): 3.1 5.8
Attn(dB): 65.0 40.7
Pwr(dBm): 17.8 12.4

ADSL2 framing
Bearer 0
MSGc: 59 11
B: 83 23
M: 1 1
T: 1 4
R: 0 0
S: 1.0000 0.9897
L: 672 194
D: 1 1

Counters
Bearer 0
SF: 2651262 566718
SFErr: 161 498
RS: 0 2324050
RSCorr: 0 0
RSUnCorr: 0 0

Bearer 0
HEC: 274 335
OCD: 0 0
LCD: 0 0
Total Cells: 269878285 78023508
Data Cells: 16551616 6577526
Drop Cells: 0
Bit Errors: 12095 29452

ES: 4192 7934
SES: 425 18
UAS: 14261 13841
AS: 43090

Bearer 0
INP: 0.00 0.00
INPRein: 0.00 0.00
delay: 0 0
PER: 16.25 16.82
OR: 32.00 8.08
AgR: 2677.54 772.98

Bitswap: 4129/4129 27/27

Total time = 56 days 23 hours 35 min 39 sec
FEC: 52709 323872
CRC: 19799 11168
ES: 4192 7934
SES: 425 18
UAS: 14261 13841
LOS: 67 0
LOF: 334 0
LOM: 4 0
Latest 15 minutes time = 5 min 39 sec
FEC: 0 0
CRC: 1 1
ES: 1 1
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Previous 15 minutes time = 15 min 0 sec
FEC: 0 0
CRC: 1 1
ES: 1 1
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Latest 1 day time = 23 hours 35 min 39 sec
FEC: 0 0
CRC: 210 777
ES: 197 616
SES: 0 0
UAS: 58 58
LOS: 0 0
LOF: 0 0
LOM: 0 0
Previous 1 day time = 24 hours 0 sec
FEC: 0 0
CRC: 252 726
ES: 233 654
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Since Link time = 11 hours 58 min 9 sec
FEC: 0 0
CRC: 161 498
ES: 148 337
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0

NTR: mipsCntAtNtr=0 ncoCntAtNtr=0

I keep trying to raise the SNRM, both downstream and upstream, but they keep dropping back down again, for reasons unknown. Was mentioned in an earlier thread.

Here is the CQM graph from clueless.aa.net.uk :  (scroll horizontally for descriptions)



(Note: In the graphs for tx and rx, a horizontal grey line near the top represents the max downstream line rate.)

As you see in the graph, there is no packet loss (scarlet) if there’s no user data only PPP LCP echo request packets for CQM, don’t know why though.

The data rate downstream is not maxed out, so that doesn’t suggest that AA is overloading the line downstream.

Only line 1 is misbehaving like this, and it’s the slowest line downstream by a long way. (But the fastest upstream, by a huge amount, for some weird reason.)

Any suggestions as to how I might fix this?

[burakkucat]

Unfortunately, I do not have a suggestion nor an answer for you. 

[Weaver]

I have tried a number of things. I’ve increased the downstream SNRM on each line from 3dB to 6dB and the line 1 upstream to 9dB, others 6dB. Not that that will last long!    That’s a just in case, as the error rates were not that high before. I’ve also lowered the AA downstream tx rates to 95% of flat-out (were at 98%). Trying to fix the latency but I don’t know why that would work if indeed it does turn out to be a successful measure.

On the CQM graph shown above, is there a max-rate upstream tx at 11:00 ? (red-brown trace, labelled ‘Rx’) I’m wondering if that’s why everything went bad, because of simultaneous downstream and upstream, or because of downstream and simultaneous upstream @100%. If so, then I’m not testing it properly, not with a sufficient load.

CQM graph from a bidirectional test that aims to give a much more testing scenario the packet and a (more than) realistic load. The testmy.net upload 100 MB test was run while simultaneously performing several 100MB downloads on another machine. This is a worse test than the original Zoom case because with Zoom the download is not at 100%.



It does show the packet loss on line 1 (only) just like the Zoom scenario. So I have successfully reproduced it! I’m assuming that line 1 exhibits the problem because it has the slowest downstream sync speed so is the limiting factor for TCP in this test. But I can’t see how that’s relevant for Zoom, seeing as we presume there’s no TCP and it isn’t flat out downstream, so it won’t know anything about line 1 being any performance-limiting link.

Speeds now, after the changes are as follows. SNRM 6 dB / 6 dB, apart from line 1 which is now 9 dB upstream. When line 1 was at 6dB upstream, its sync rate was an amazing 200k higher ! Live sync rates:
  #1: downstream 2378 kbps, upstream 566 kbps
  #2: downstream 2503 kbps, upstream 525 kbps
  #4: downstream 2719 kbps, upstream 563 kbps

[Moderator edited to merge four successive posts into one.]

[Weaver]

@jelv Thanks for the tip, will Google it. This isn’t anything to do with the lines, as modems show no errors much and tests have been run on line 1.

Here for comparison are pictures of the other lines



So the question, why line 1 and not the others ?

[Ixel]

Apologies if this sounds like a silly question, or if you've already tried this, but have you tried swapping the modems around to see if the issue persists either on the same line or instead has moved to another line? My thinking is that this would completely eliminate a dodgy modem despite what the DSL statistics say.

[Weaver]

@Ixel No, I haven’t - that’s a good point. I can soon swap the modem out as I have plenty of spares.

There are so many things that I don’t understand;

1. why only line 1 ? - answers could be a bad modem 1; could be that line #1 is always a sacred number, something to do with treatment by my Firebrick or AA’s Firebricks giving the first slot special treatment.

2. More difficult: why does it come and go ?

[Ixel]

@Ixel No, I haven’t - that’s a good point. I can soon swap the modem out as I have plenty of spares.

There are so many things that I don’t understand;

1. why only line 1 ? - answers could be a bad modem 1; could be that line #1 is always a sacred number, something to do with treatment by my Firebrick or AA’s Firebricks giving the first slot special treatment.

2. More difficult: why does it come and go ?

If swapping the modem doesn't yield any worthwhile result then another idea I have is possibly forcing line 1 to go to AAISP's test LNS. I assume this is possible even with bonded lines, although I suspect the bonding will be temporarily broken until you log back into the usual LNS.

If I recall, I read somewhere you just prefix the username with 'test-' (without the quotes) to force a specific login to go to their test LNS.

[Weaver]

I talked to AA again and they asked me to retest after they had made some temporary changes to the Firebrick config. AA added in the traditional explicit "speed=<value>" attributes in the FB config for each PPP i/f object to presumably override the new "auto-percent" speed attributes that I have been using and set the speeds to calculated values equal to 88% of each upstream sync rate (for ADSL overheads). I had been using auto-percent set to 88% * 95% (not * 100%) so I was driving the upstream 5% slower.

Unfortunately this didn’t seem to change things. It’s good that there does not seem to be any bug in the FB2900’s handling of the new auto-percent facility though. (Or the delivery of info concerning sync rates to the Firebrick, since getting the delivered sync rate wrong would cause badness without any FB bug.)

Hi Ixel, thanks for the tip - what made you think of that ?

[Moderator edited to merge two successive posts into one.]

[Ixel]

Hi Ixel, thanks for the tip - what made you think of that ?

Not sure, just an idea that occurred to me as a process of elimination.

[Weaver]

Zoom is a far more testing scenario if there is as I suspect no TCP to cover up any weirdness. And there doesn’t seem to be any evidence that DSL is to blame for the packet loss and latency increases, so the finger seems to be pointing at the scheduling in the Firebrick being either unfair or fair, limits being unreasonable or reasonable.

There is a rumour that Tarskavaig (a few miles to the south of us, in the Sléibhte peninsula) might get FTTP, but that could well be wishful thinking. I’ve asked Janet to try and get some political pressure for us.

It will be excellent if some alternative network operators make BT begin to feel insecure.

Coming back to the current problem, the upstream speeds are pretty much closely equal at the moment, something that has not been the case for a long time. Line 3 (RIP) was always 30% slower than the other modems, but now we don’t have that inequality. Some short while ago, I forget when, line 1 was much faster upstream than the other lines, for reasons unknown, at 750kbps u/s @6dB, a completely new development which is very weird. Putting the u/s SNRM up to 9dB in order to reduce error rates has reduced the u/s sync rate to something roughly the same as the others. Having sync rates be near identical is of course very desirable.

[jelv]

There is a rumour that Tarskavaig (a few miles to the south of us, in the Sléibhte peninsula) might get FTTP, but that could well be wishful thinking. I’ve asked Janet to try and get some political pressure for us.

That will be because under the Scottish 4G infill programme a new mast has gone up there and 4G services are available from EE. See https://www.gov.scot/publications/scottish-4g-infill-programme-progress-update/#Progress%20updates%20on%20mast%20sites

The EE coverage checker is saying you should get good 4G coverage outdoors - have you tried it?

[Weaver]

Have had 4G from the base station across the valley, not near Tarskavaig, for many years now. Direct line of site, but in my bedroom the stone wall of the house casts a shadow so my iPad often decides to switch down to 3G depending on exactly where it is.

[Weaver]

Zoom session at 1700 UTC this evening (Ancient Greek class at citylit.ac.uk in London) was 100% fine. So have I really fixed the problem with the many changes I have made, or is it just (pseudo-)random?

All three lines together covering class starting at at 17:00 BST. Live sync rates:
  #1: downstream 2378 kbps, upstream 566 kbps
  #2: downstream 2503 kbps, upstream 525 kbps
  #4: downstream 2719 kbps, upstream 563 kbps




Just line 1 only, broken down, in detail:



Not sure why the packet-loss spikes are there, one at ~17:30 BST before the start of the class, also a lesser one later at around 18:50 BST.

[burakkucat]

It looks quite usable. 

I was hoping you would be able to explain those two spikes and associated "blood-drips".

[Weaver]

The bright green spikes must have been some simultaneous uploads+downloads that Janet did, I think. At 17:30 BST I was waking up and drinking coffee getting ready for my class and at 18:50 BST I was in my class, so deep in Zoom. I don’t know why there are are the drips of blood nor why they are associated with L1 more than the other lines. The L1 downstream sync rate is lowest and perhaps the graph doesn’t show it because of limited res, but perhaps there is a very short duration d/s spike to hit max sync rate.