Print

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

[Weaver]

During the last three days or so, my line #1 (only) has started resyncing a few times per day, 1 - 2 times very approximately. The link comes back up in the usual ~80 secs. On the modem’s SNRM vs time graph for the last day or so, the instantaneous downstream SNRM drops from the assigned 3 dB target down to say -2 dB and the modem then drops the link. This is in fact not a practical problem at all since I have multiple bonded lines, and while one is down, the traffic just goes to the other links and there is no noticeable failure of the overall service. So it isn’t a priority to fix the problem by raising the downstream target SNRM and / or increasing the downstream interleave depth. Mind you, the system(s) (?) seem to ignore me these days even if I try to set the link to a high downstream interleave depth using AA’s clueless.aa.net.uk control panel, and sometimes when I set the downstream target SNRM to be higher using clueless, the real downstream SNRM just eventually goes back down to 3dB again. Don’t understand why.

So I have no desire to fix the problem by increasing the downstream target SNRM, although clearly at the moment line #1 can’t quite handle a 3 dB downstream target SNRM. For the last seven years the links have been able to hold sync fine all the time with a downstream 3 dB target SNRM, and with the current ZyXEL VMG 1312-B10A modems that I have been using for several years now, the modems have also been able hold the link with a very low or indeed long-term zero downstream error rate, thanks to the availability of Broadcom’s PhyR L2 retransmission-based error correction. In 2015, I was advised by AA that a 3dB target downstream might prove untenable and I told them that I would bear this in mind, keep a close eye on things and be ready to give up and return to a 6dB downstream SNRM target. Before I started using the current ZyXEL modems, I didn’t have a way of measuring the error rate, and when TCP was being used, TCP’s retransmissions would cover up packet corruption, so underlying problems with the modems would not be easy to see unless things got very bad or TCP practical throughput downstream deteriorated enough to be measureably lower. During the years that I have had the benefit of the ZyXELs’ enhanced DSL analog hardware, the high-performance PhyR L2 protocol compared to the DLink modems I was using before, and the fantastic reporting capabilities of our Kitizen Johnson’s custom ZyXEL firmware, I have been able to keep a very careful eye on exactly what’s going on, in detail. So I know now that much of the time there truly are no uncorrected packet corruption errors at all even with a 3 dB downstream SNRM target, and I know that I’m not either losing packets where non-TCP protocols (eg UDP) or losing effective performance as a result of TCP’s L4 retransmissions and in some cases TCP speed recovery after packet loss.

It seems then that as I said earlier, there’s absolutely no point in ‘fixing’ the problem then by going up to 6dB downstream target SNRM since that would simply reduce the downstream sync rate by quite a lot in order to deal with a transient problem that only happens a couple of times per day. If the number of resync events per day gets worse then I would have to think again but in such a case I would more likely try and get a fault fixed.

I’m assuming there is sometimes a short noise burst that affects downstream only. Referring back to eg. https://forum.kitz.co.uk/index.php/topic,26768.msg448911.html#msg448911 - I am thinking about water ingress into a joint. The whole of this month of May has been incredibly wet: normally it’s beautiful, sunny and very dry, in fact five-week long droughts have been very common, droughts so bad that by June neighbours have lost their water supply where they are relying on streams. The last few days have been no wetter than the preceding weeks, so I can’t blame very recent wet weather, thinking in ‘why now?’ and ‘what has changed?’ terms.

I can’t see any point in reporting this to AA apart from a ‘could you keep an eye on it’ request; it’s nowhere even remotely at the performance level to qualify as an OR fault given that they would quite rightly just say that I can’t expect it to work with a downstream target SNRM below 6dB (OR having never heard of PhyR, and not being used to long lines being this quiet, which is due to the lack of human habitation along most of the run)

So my questions:

• Water ingress? on one line only and the others are 100% fine. Is that a plausible diagnosis?
• What should I be looking at to keep an eye on it? (In detailed stats.)
• Assuming for the moment that it is water ingress, is that something that an engineer could diagnose/measure/locate even now?

I have an idea: perhaps I should ask my wife to plug a telephone into the line and listen to see if there is any noise? Do we have to listen for 24 hours until we might hear a noise event? If there is any noise then that would be brilliant as AA could report this to OR as a ‘voice fault’ and we do not mention internet access at all.

Detailed stats follow:

Code: [Select]

xdslctl: ADSL driver and PHY status
Status: Showtime
Last Retrain Reason: 8000
Last initialization procedure status: 0
Max: Upstream rate = 624 Kbps, Downstream rate = 3088 Kbps
Bearer: 0, Upstream rate = 669 Kbps, Downstream rate = 2748 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.9
Attn(dB): 65.0 40.9
Pwr(dBm): 18.2 12.4

ADSL2 framing
Bearer 0
MSGc: 53 12
B: 18 78
M: 8 1
T: 5 1
R: 16 16
S: 1.7409 3.7255
L: 772 204
D: 1 8

Counters
Bearer 0
SF: 2026228 951239
SFErr: 217 42
RS: 74717180 750558
RSCorr: 16910 22258
RSUnCorr: 266 0

ReXmt: 8971 0
ReXmtCorr: 8930 0
ReXmtUnCorr: 266 0

Bearer 0
HEC: 296 83
OCD: 1 0
LCD: 1 0
Total Cells: 212027330 51692442
Data Cells: 53334577 8420282
Drop Cells: 0
Bit Errors: 7825 10929

ES: 1126 1688
SES: 135 6
UAS: 1324 1207
AS: 32723

Bearer 0
INP: 29.00 2.50
INPRein: 0.00 0.00
delay: 8 7
PER: 16.04 16.76
OR: 29.40 8.58
AgR: 2764.72 675.92

Bitswap: 6958/6959 22/22

Total time = 29 days 17 hours 46 min 28 sec
FEC: 1951162 1969788
CRC: 7829 2526
ES: 1126 1688
SES: 135 6
UAS: 1324 1207
LOS: 6 0
LOF: 53 0
LOM: 0 0
Latest 15 minutes time = 1 min 28 sec
FEC: 6 47
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Previous 15 minutes time = 15 min 0 sec
FEC: 61 519
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Latest 1 day time = 17 hours 46 min 28 sec
FEC: 40754 76495
CRC: 3139 90
ES: 237 65
SES: 61 6
UAS: 206 147
LOS: 3 0
LOF: 27 0
LOM: 0 0
Previous 1 day time = 24 hours 0 sec
FEC: 60778 47297
CRC: 2738 105
ES: 303 75
SES: 60 0
UAS: 146 99
LOS: 2 0
LOF: 17 0
LOM: 0 0
Since Link time = 9 hours 5 min 21 sec
FEC: 16910 22258
CRC: 217 42
ES: 66 32
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
NTR: mipsCntAtNtr=0 ncoCntAtNtr=0


Here’s the SNRM history around a resynch event. Dark blue is downstream, green is upstream.



[Moderator edit: Formatting fix.]

[burakkucat]

I very much doubt it is due to water ingress (into a joint). Perhaps it is an occasional burst of SHINE?

Looking at the plot, there is nothing of any great significance as the horizontal, x-axis, is so compressed. If you could expand the plot to just cover a period of around one hour before and one hour after the event, that would be helpful. (I.e. 1100 to 1300 hours on May 25th.)

[Weaver]

Damn, lost that section now; time has moved on and the modem only keeps a certain window of data, doesn’t go back far enough. I’ll be watching out for another such event. All good recently.

[Weaver]

No events today (Friday). Maybe the bad thing has mysteriously gone away, touch wood.

Burakkucat’s suggestion about SHINE makes a lot of sense. Questions below, and I hope kitizens might knock them off the list for me with answers

• If it were water ingress, would it not be the case that the symptoms start and then never go away?
• However, if SHINE, why does only one line pick it up?
• How long might such noise bursts be, typically? (how long is a piece of string?) Maybe let’s say worst case seen in practice for SHINE. Kitz talks about classifying noise bursts by duration; < 1 ms, 1-10 ms, > 10ms; I see that SHINE fits into the > 10ms minimum duration band.
• Would it help having a huge interleaving depth?
• Can the maximum interleaving depth be long enough to cope with SHINE length?
• Is 10ms 40 symbols? (At the 4kHz symbol rate, no?)
• And why can’t I get downstream interleaving at all?
• I wonder if it’s something to do with the modem refusing to do downstream interleave because it has downstream (only) PhyR? Maybe it thinks there’s no need and that there’s some downside involved in interleaving. There’s no upstream PhyR, unfortunately, for some reason, so that could be why I get interleaving depth=8 for upstream. I recently found out thanks to Burakkucat that I can turn downstream PhyR off in the modem’s settings, so that might be a worthwhile experiment.
• I wonder if having PhyR is no use if you have such bad SHINE that it knocks the SNRM down to < 0 ? Maybe the reasoning is that PhyR is useless when communication is impossible currently due to the sheer level of noise, because then a retransmission will fail also, so it could be that the modem uses an algorithm containing a rule that always triggers a resync every time SNRM goes negative, or goes negative for a certain period of time. I seem to remember that some modems would carry on sometimes even though the SNRM has gone negative, so hanging on in the hope that things will improve, although god only knows what happens to received downstream packets in the meantime. I can’t remember how I might have seen that an SNRM was negative back then though, so I don’t know what the evidence might have been. Thinking about it, this behaviour ought to be configureable. In my bonded setup, I want the link to drop asap, as that mends things sooner.