Kitz Forum
Broadband Related => ADSL Issues => Topic started by: Weaver on November 22, 2018, 11:24:28 AM
-
Just now I am seeing an amazingly low SNRM upstream on my line #3 of only 0.4 dB. It should be 6dB. None of the others are showing this. For quite a while, until today, the upstream sync rate had been far lower, at 358 kbps, now 509 kbps. It has a history of jumping up and down between these two levels, jumps of around 100k or more, often 150k, but always between these two levels of ~350k and ~450-500k.
xdslctl: ADSL driver and PHY status
Status: Showtime
Last Retrain Reason: 8000
Last initialization procedure status: 0
Max: Upstream rate = 336 Kbps, Downstream rate = 3448 Kbps
Bearer: 0, Upstream rate = 509 Kbps, Downstream rate = 3136 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 0.4
Attn(dB): 64.5 40.4
Pwr(dBm): 18.5 12.4
The following SNRM graph shows the bizarre 24 hour history of the upstream SNRM in green. Huge jumps down to this very low level, no gradual changes over time. Would anyone care to comment?
https://www.dropbox.com/s/ogjfm5lv1gld4rr/IMG_0029.jpg?dl=0
It seems that therein lies the explanation for the sync rate jumps: it all depended on when one resynched: if done at the right time then the current noise level was would be very different, on the other side of one of the strange upward/downward transitions.
-
I have been having same issue on my upstream as well however mine goes in either low SNRM or high SNRM.
Bet the line test shows no faults up either.
-
I am curious to see the bitloading with SNR also plotted. Ideally both graphs when normal SNR (~6 dB) and extremely low SNR (but the latter is most important).
Since the upstream tones, on ADSLx, occupy the very low frequencies it should not be subject to issues relating to high loop loss as much. Even still, this jump in SNR is huge and perhaps I would consider something at fault somewhere at the near end. Presumptuous, I know.
-
Bitloading:
xdslctl: ADSL driver and PHY status
Status: Showtime
Last Retrain Reason: 8000
Last initialization procedure status: 0
Max: Upstream rate = 436 Kbps, Downstream rate = 3356 Kbps
Bearer: 0, Upstream rate = 509 Kbps, Downstream rate = 3136 Kbps
Tone number Bit Allocation
0 0
1 0
2 0
3 0
4 0
5 0
6 0
7 9
8 10
9 10
10 10
11 10
12 10
13 9
14 9
15 8
16 8
17 8
18 8
19 7
20 7
21 7
22 6
23 6
24 6
25 6
26 6
27 6
28 6
29 5
30 5
31 5
32 0
33 8
34 9
35 10
36 10
37 10
38 10
39 11
40 11
41 11
42 11
43 11
44 11
45 11
46 8
47 12
48 12
49 12
50 12
51 12
52 12
53 12
54 12
55 2
56 12
57 12
58 10
59 10
60 11
61 12
62 12
63 12
64 12
65 11
66 11
67 10
68 11
69 11
70 11
71 11
72 11
73 11
74 11
75 11
76 10
77 10
78 10
79 10
80 10
81 10
82 10
83 10
84 10
85 10
86 9
87 9
88 9
89 9
90 9
91 9
92 9
93 9
94 9
95 8
96 8
97 8
98 8
99 8
100 8
101 8
102 8
103 7
104 7
105 7
106 7
107 7
108 7
109 7
110 7
111 7
112 6
113 6
114 6
115 6
116 6
117 6
118 6
119 6
120 5
121 5
122 5
123 4
124 3
125 2
126 0
127 3
128 3
129 3
130 3
131 3
132 4
133 4
134 4
135 3
136 3
137 3
138 3
139 3
140 3
141 3
142 3
143 3
144 0
145 3
146 1
147 3
148 0
149 2
150 2
151 1
152 0
153 1
154 1
155 1
156 1
157 0
158 0
159 0
[Moderator note: It is best to wrap such blocks of data with [code] . . . [/code] tags. It preserves the format, allows the code block to be scrollable and allows the data to be easily selected by left-clicking on [select].]
-
I am curious to see the bitloading with SNR also plotted. Ideally both graphs when normal SNR (~6 dB) and extremely low SNR (but the latter is most important).
I meant in graph form. Sorry if that was not clear. You can use DSLstats or HG612 stats for it.
Alternatively, if you are unable to use those programs to provide a graph, you could provide the individual stats for me to look at using the following commands:
adsl info --Bits
adsl info --SNR
-
Charts, data and spreadsheets of bitloading available :
- pdf (https://www.dropbox.com/s/7ykk8shsd4eqy4z/Upstream%20weird%20jumping%20bitloading%20hi%202018-11-22.pdf?dl=0)
- Microsoft Excel xlsx (https://www.dropbox.com/s/qdkubh0ep0uobvz/Upstream%20weird%20jumping%20bitloading%20hi%202018-11-22.xlsx?dl=0)
- Apple Numbers spreadsheet (https://www.dropbox.com/s/62wtxbzn0v2339f/Upstream%20weird%20jumping%20bitloading%20hi%202018-11-22.numbers?dl=0)
- CSV format data (https://www.dropbox.com/s/cv2gbwmaatpohdg/Upstream%20weird%20jumping%20bitloading%20hi%202018-11-22.csv?dl=0)
-
And spreadsheets and charts of the SNR-vs-frequencies dataset, again ‘hi SNRM’ unfortunately. Unfortunately the modem gave me all zeros for the low tones, the upstream. No idea why. ?
- PDF format - spreadsheet and chart (https://www.dropbox.com/s/7ykk8shsd4eqy4z/Upstream%20weird%20jumping%20bitloading%20hi%202018-11-22.pdf?dl=0)
- Microsoft Excel xlsx spreadsheet and chart (https://www.dropbox.com/s/qdkubh0ep0uobvz/Upstream%20weird%20jumping%20bitloading%20hi%202018-11-22.xlsx?dl=0)
- Apple Numbers format - spreadsheet and chart (https://www.dropbox.com/s/62wtxbzn0v2339f/Upstream%20weird%20jumping%20bitloading%20hi%202018-11-22.numbers?dl=0)
- CSV format spreadsheet data (https://www.dropbox.com/s/cv2gbwmaatpohdg/Upstream%20weird%20jumping%20bitloading%20hi%202018-11-22.csv?dl=0)
-
I can't see the SNR plot? Perhaps just provide raw output using commands I supplied previously if possible.
-
I can't see the SNR plot? Perhaps just provide raw output using commands I supplied previously if possible.
You have a PM. b*cat has acted as an intermediary and the raw data (bit loading and SNR per sub-carrier) should now be available to you. ;)
-
This is the SNR history pic for the 24 hours leading up to last night. Generated by our very own Johnson’s superb B10A-embedded stats and SNR graphing http server thanks to his custom B10A firmware. See
https://www.dropbox.com/s/p3ae1jyuf1q8na4/IMG_0031.PNG?dl=0
-
@b*cat:
I have responded. Thanks for the PM.
@Weaver:
I apologise that I misunderstood what you meant with the all zeros at lower tones (I thought you were referring to the gaps for some reason, but I didn't have access to SNR stats at the time). I can see you meant it in reference to SNR on the upstream tones.
-
In a later SNR-history graph captured right now, Sat 17:59, it shows nicely the droop in downstream SNRM from its daylight high of say 3.1 dB - its downstream target is 3dB, so that is as it should be - down slowly to a current 2.5 dB, the downward slope starting at sunset. Based on history it will only get slightly lower still eventually. The previous day’s minimum was at around 21:30, followed by a sligh rise and then a lesser, broad dip whose minimum was at around 04:10. So I am assuming that temperature is controlling the d/s SNR. The upstream doesn’t show any such thing much as the jumps up and down are so overwhelming. And the odd thing is that the high upstream rung value is still way too low, at 4.1 dB roughly, instead of the 6 dB u/s target.
-
re0 and the black cat have discussed the oddity that is occasionally observed with the circuit using line number three. (Extremely low SNR margin.) It might be interesting to see the snapshot data following a circuit retrain during an "odd" period. If the output produced by the following command sequence could be captured it might shed some light on the puzzle --
xdslctl connection --up
(Wait while the circuit retrains.)
xdslctl info --Hlog
xdslctl info --QLN
xdslctl info --Bits
xdslctl info --SNR
There is the possibility that the retrain may clear the oddity but whatever the end result, it would be a worthwhile experiment.
-
Will certainly do so and will post raw data here as post-attachments. Unfortunately it has just transitioned to the ‘high’ upstream SNRM state, so will have to wait for a few hours.
-
I realise that I should have waited until it was a ‘low’ SNRM time, but just out of curiosity, I did an xdslctl connection —up. After retraining, the upstream sync rate dropped from 509 kbps to 445 kbps because the sync rate went back to normal at 6 dB from 4.1 dB. At 04:00 Sunday:
> xdslctl info --stats
xdslctl: ADSL driver and PHY status
Status: Showtime
Last Retrain Reason: 8000
Last initialization procedure status: 0
Max: Upstream rate = 420 Kbps, Downstream rate = 3392 Kbps
Bearer: 0, Upstream rate = 445 Kbps, Downstream rate = 3012 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.3 6.0
Attn(dB): 64.0 40.2
Pwr(dBm): 18.0 12.4
ADSL2 framing
Bearer 0
MSGc: 52 14
B: 34 46
M: 4 1
T: 3 1
R: 12 12
S: 1.4633 3.3007
L: 831 143
D: 2 8
Counters
Bearer 0
SF: 54476 52923
SFErr: 0 0
RS: 2369716 1057486
RSCorr: 12 25
RSUnCorr: 0 0
ReXmt: 14 0
ReXmtCorr: 13 0
ReXmtUnCorr: 0 0
Bearer 0
HEC: 0 0
OCD: 0 0
LCD: 0 0
Total Cells: 6199996 914755
Data Cells: 252564 24440
Drop Cells: 0
Bit Errors: 0 0
ES: 303 114
SES: 26 0
UAS: 216 195
AS: 873
Bearer 0
INP: 26.00 2.50
INPRein: 0.00 0.00
delay: 8 7
PER: 15.91 16.50
OR: 29.15 9.69
AgR: 3027.88 453.88
Bitswap: 232/237 8/8
Total time = 12 days 13 hours 58 min 1 sec
FEC: 115337 36582948
CRC: 1997 146
ES: 303 114
SES: 26 0
UAS: 216 195
LOS: 3 0
LOF: 18 0
LOM: 0 0
Latest 15 minutes time = 13 min 1 sec
FEC: 11 23
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: 42 62
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 52 52
LOS: 0 0
LOF: 0 0
LOM: 0 0
Latest 1 day time = 13 hours 58 min 1 sec
FEC: 4602 3614813
CRC: 13 2
ES: 10 2
SES: 0 0
UAS: 52 52
LOS: 0 0
LOF: 0 0
LOM: 0 0
Previous 1 day time = 24 hours 0 sec
FEC: 5740 4968487
CRC: 3 13
ES: 2 10
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Since Link time = 14 min 33 sec
FEC: 12 25
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
NTR: mipsCntAtNtr=0 ncoCntAtNtr=0
-
finally, a low, upstream SNRM again, precipitous drop from ~5.8 dB to ~1.7 dB. See attached raw data for all stats as requested, plain ascii
[Attempt to attach text files failed somehow - see attachment at subsequent post below.]
[Moderator edited to remove the attachment of the size zero file.]
-
0 KB? :hmm:
-
I have no idea what on earth happened there, try again :-[
-
As simple graphs:
-
And Hlog:
-
I have also plotted the snapshot graphs -- sent to Weaver as an e-mail attachment -- and here is the montage of the four plots . . .
-
Shame that QLN and Hlog isn't showing anything for the upstream, but perhaps we won't need it.
Going on things from the SNRM perspective, unless I have missed something important, I can't actually see any issues. The data provided shows that the SNR values would be high enough to sustain the bits allocated at a SNRM target of 6 dB (bits*3+6) across the whole upstream.
If the modem was reporting an SNRM of ~1.7 dB at the time of taking these stats, then I am stumped. I think this reporting could be erroneous if the previous condition is true, but part of me questions how it could be inaccurate (makes me believe I am wrong somehow).
Anyone else got an input? Have I overlooked something?
-
I’m hoping we can spot the specific points of difference between the data sets for the ‘high’ and ‘low’ states. Line #2, the latest, has these vertical jump transitions too, but not as large.
[Line #3 which is being discussed here is, in chronological order, the second pair in the first drop cable. (Line #4 is the first pair of an additional drop cable, which was put in later, and line #2 is #4’s later companion.) The numbering unfortunately ended up a bit weird because of AA allocating a ‘slot’ entry to a link of another type, other than a DSL line, a SIM, iirc, at some point in the history.]
It really is a damned nuisance losing such a big chunk of upstream, something like 20% or maybe more. I could increase the target SNRM to 9dB if things get really bad. Another problem is that I have to set the Brick’s upstream egress rates to be correct for the speed of each link, so unless I get those numbers right, ie low enough to cope when the rate drops because it happens to sync at a low SNRM time, then I am going to get terrible packet loss, dreadful speed and unreliability. So I won’t be able to ever get any benefit by resyncing during the high SNRM periods, not unless it is guaranteed to be able to hang on without dropping the link.
Another question: Can I get some idea of how many real errors, uncorrected corrupted upstream packets, are being seen when the SNRM is very low? That way I will know if Inhave another real problem.
-
Another question: Can I get some idea of how many real errors, uncorrected corrupted upstream packets, are being seen when the SNRM is very low? That way I will know if Inhave another real problem.
So CRC errors?
You can examine their totals for up and down using xdslctl info --stats, or for time series data if you are still running the SNRM graphing firmware on any of your devices then the CRCs for down and up are the last two entries in that order, in the logfile (/var/tmp/stats/data/logfile) eg:
1517542818 3.6 6.2 4762 0 0 0
1517542849 3.6 6.2 4262 0 0 0
1517542879 3.4 6.1 42196 0 7 0
1517542909 3.6 6.2 132515 0 0 0
1517542939 3.4 6.2 4148 0 0 0
1517542970 3.4 6.2 10259 0 0 0
This shows a burst of 7 down stream CRCs. From left to right, time - down SNRM - up SNRM - down FEC - up FEC - down CRC - up CRC.
-
Am I correct in thinking that the FECs were corrected? Or uncorrected but handled by L2 ReTx ?(because we have PhyR here, at least in the downstream direction, both directions?)
I get confused because there are so many levels where ‘errors’ may or may not have been mitigated, FEC successful mathematical correction, then errors fixed by an L2 Retx, at the cost of some time lost for the retransmission, and then a corrupted packet and total failure, with an ATM HEC error, but I think our kitizens told me that ATM doesn’t correct bad cells, only detects them, and so finally we end up with duff data delivered to L3.
The other thing I find very confusing is ‘errors per what’ and ‘ or counts over what period / since when? And cumulative counts or deltas?
I ought to try and get some help writing all of this stuff up and putting it in one place for reference so that I will be able to refer to it without the failed attempts to remember it.
-
Am I correct in thinking that the FECs were corrected? Or uncorrected but handled by L2 ReTx ?(because we have PhyR here, at least in the downstream direction, both directions?)
FEC errors are corrected - FEC means 'Forward Error Correction'. This correction is present when the line is interleaved (and interleaving has a slight overhead).
CRC (Cyclic Redundancy Check) errors are more important to look out for as those require restansmission (corrupt) and can slow down throughput if there are many.
I am not sure about PhyR (someone probably explained it to me in the forum before but I don't remember) but surely PhyR has its own counters like G.INP?
The other thing I find very confusing is ‘errors per what’ and ‘ or counts over what period / since when? And cumulative counts or deltas?
It is not unusual for the the rate of FECs and CRCs to increase with a lower SNR margin. Each line has its own characteristics so there is all the reason to be confused what is considered ample. An easy way to grasp the concept of error rates is to either use a third-party application that can telnet/SSH to your modem, or even use the adsl info --stats command since it shows error rates for the:
- Total time
- Latest 15 minutes
- Previous 15 minutes
- Latest 1 day
- Previous 1 day
- Link time (since xDSL link established)
Errors, just like resyncs, can be categorised using values that signify MTBx (Mean Time Between x) in reference to the DLM; MTBE (Mean Time Between Errors) in this case. There's a good amount of information here (https://kitz.co.uk/adsl/DLM.htm) for that. May be relevant if you have the DLM enabled.
Since we have seen your stats with the upstream SNR low, perhaps you could also provide the same stats from when the SNR is about normal? Would be nice for comparison.
-
Raw stats’ session log, captured straight from CLI, attached
-
What is the current SNRM? It looks like it is about 6 dB.
If it is the case that the SNRM is about 6 dB, then the statement I made in a previous post (about the SNR per tone being sufficient) is false and I will need to revisit the excel document and ensure I know what I am talking about. Perhaps there is an aspect of ADSL that I am missing.
-
Raw stats’ session log, captured straight from CLI, attached
Montage of the four plots, attached below . . .
-
It was 6dB upstream when that data was captured, if memory serves.
-
So where am I going wrong?
I thought you could work out the required SNR for the current bits allocated with bits*3+6 where bits are the bits allocated, 3 is 3 dB of SNR (equating to a single bit) and 6 is the target SNRM in dB (any target SNRM figure can be used).
I somehow think this is wrong since the first set of values (when the SNR was ~1.7 dB) seem to show it being sufficient by that calculation (possibly up to around 7 dB margin), but the later stats appear to show the SNR being 6 dB higher (thus almost a 12 dB margin by the calculation).
Can someone correct me? I know the very simple calculation is flawed.
-
I would assume that we need to convert log2 bits into log10 for dB and double it because of the squaring operation required to get power from amplitude. Constellations are two-dimensional, so we need to also have a factor of 1/2 in there.
So bits * 2 / 2 * 10 * log10( 2 ) + some constant which I don't know the value of. That would be about bits * 0.3 * 10 + constant, ie bits * 3 + C. But I don't know what the assumed zero dB power reference is. Since SNR is a ratio, the constants will cancel out, so in that case isn't my constant simply zero?