|
|
Hi everyone!
I've compared my line's SNR Per Tone graph between when it experiences occasional DS SNRM drops and doesn't. I've noticed that most DS tones above 332 (1431 kHz) are impacted when this occurs. Does anyone know what could be causing this?
Thanks!
Will
During drop: https://prnt.sc/lp4w9q
Normal: https://prnt.sc/lp4xko
Edited by deleted (Fri 30-Nov-18 21:29:07)
|
|
|
The SNRM drops because the graphed data is lower  . Not the other way round as your post implies.
The graphed data is lower because the noise is greater.
This effect has been known since ADSL was invented  . It�s why we monitor SNRM, as that�s what it tells us just by looking at the stats in the modern.
The purpose of the graphs you posted is to show up unusual patterns compared to the particular line�s usual one, or compared to other �normal� lines. Your two patterns are basically identical, suggesting there is nothing odd going on. There are known causes of many short stretches of such graphs having consistent unusual or sudden short gaps or very low values, so helping problem diagnosis.
The standard SNRM graph is more useful day to day, enabling you to spot time-patterns for significant drops other than the expected night-time ones. Then you might find the SNR per tone ones for the precise times affected useful.
My broadband basic info/help site - www.robertos.me.uk. Domains, site and mail hosting - Tsohost.
Connection - AAISP Home::1 80/20. 200GB. Sync 01/10/18 - 72382/13812Kbps @ 600m. (Disabled:BQMs - IPv4 & IPv6)
==================================================
If you never think of anything off the wall, you'll never think of anything original. |
|
|
Thanks, Bob. If you look closely though, they are far from identical. Here's the SNRM plot for the last 24 hours, as you can see it's a mess. I have posted my line stats, too. Each time there is a DS SNRM "spike" the tone graph is virtually the same.
http://prntscr.com/lpaw6l
| Text | 1
23
45
67
89
1011
1213
1415
1617
1819
2021
2223
2425
2627
2829
3031
3233
3435
3637
3839
4041
4243
4445
4647
4849
5051
5253
5455
5657
5859
6061
6263
6465
6667
6869
7071
7273
7475
7677
7879
8081
8283
8485
8687
8889
9091
9293
9495
9697
9899
100101
102103
104105
106107
108109
110111
112113
114115
116117
118119
120121
122123
124125
126127
128129
130131
132133
134135
136137
138139
140141
142143
144145
146147
148149
150151
152153
154155
156157
158159
160161
162163
164165
166167
168169
170171
172173
174175
176177
178179
180181
182183
184185
186187
188189
190191
192193
194195
196197
| adsl info --stats
adsl: ADSL driver and PHY statusStatus: Showtime
Last Retrain Reason: 0Last initialization procedure status: 0
Max: Upstream rate = 8558 Kbps, Downstream rate = 53014 KbpsBearer: 0, Upstream rate = 8589 Kbps, Downstream rate = 52438 Kbps
Bearer: 1, Upstream rate = 0 Kbps, Downstream rate = 0 KbpsLink Power State: L0
Mode: VDSL2 Annex BVDSL2 Profile: Profile 17a
TPS-TC: PTM Mode(0x0)Trellis: U:ON /D:ON
Line Status: No DefectTraining Status: Showtime
Down UpSNR (dB): 3.8 5.0
Attn(dB): 26.2 0.0Pwr(dBm): 12.0 5.4
VDSL2 framing
Bearer 0MSGc: -6 -6
B: 227 227M: 1 1
T: 0 0R: 10 10
S: 0.1383 0.8443L: 13768 2255
D: 4 4I: 238 238
N: 238 238Q: 4 4
V: 0 0RxQueue: 125 15
TxQueue: 25 5G.INP Framing: 18 18
G.INP lookback: 25 5RRC bits: 24 24
Bearer 1MSGc: 122 58
B: 0 0M: 2 2
T: 2 2R: 16 16
S: 8.0000 16.0000L: 32 16
D: 1 1I: 32 32
N: 32 32Q: 0 0
V: 0 0RxQueue: 0 0
TxQueue: 0 0G.INP Framing: 0 0
G.INP lookback: 0 0RRC bits: 0 0
Counters
Bearer 0OHF: 0 0
OHFErr: 567 0RS: 3995588552 2069552738
RSCorr: 152799634 8789RSUnCorr: 0 0
Bearer 1OHF: 27194957 27305688
OHFErr: 0 3RS: 217559159 109222753
RSCorr: 118522 133RSUnCorr: 0 0
Retransmit Counters
rtx_tx: 1311299 10574rtx_c: 1176138 722
rtx_uc: 1722 0
G.INP CountersLEFTRS: 209 54
minEFTR: 52404 8582errFreeBits: 349131341 57102151
Bearer 0
HEC: 0 0OCD: 0 0
LCD: 0 0Total Cells: 1081369746 0
Data Cells: 525612005 0Drop Cells: 0
Bit Errors: 0 0
Bearer 1HEC: 0 0
OCD: 0 0LCD: 0 0
Total Cells: 0 0Data Cells: 0 0
Drop Cells: 0Bit Errors: 0 0
ES: 45 0
SES: 20 0UAS: 124 124
AS: 436891
Bearer 0INP: 54.00 47.00
INPRein: 1.00 0.00delay: 0 0
PER: 0.00 0.00OR: 0.01 0.01
AgR: 52552.76 8607.38
Bearer 1INP: 2.00 4.00
INPRein: 2.00 4.00delay: 0 0
PER: 16.06 16.06OR: 63.75 31.87
AgR: 63.75 31.87
Bitswap: 220863/239847 1733/1757
Total time = 5 days 1 hours 23 min 35 secFEC: 152799634 8789
CRC: 567 0ES: 45 0
SES: 20 0UAS: 124 124
LOS: 0 0LOF: 0 0
LOM: 0 0Retr: 0
FailedRetr: 0FailedFastRetr: 0
Latest 15 minutes time = 8 min 35 secFEC: 41806 0
CRC: 17 0ES: 1 0
SES: 0 0UAS: 0 0
LOS: 0 0LOF: 0 0
LOM: 0 0Retr: 0
FailedRetr: 0FailedFastRetr: 0
Previous 15 minutes time = 15 min 0 secFEC: 26565 6
CRC: 0 0ES: 0 0
SES: 0 0UAS: 0 0
LOS: 0 0LOF: 0 0
LOM: 0 0Retr: N/A
FailedRetr: N/AFailedFastRetr: N/A
Latest 1 day time = 1 hours 23 min 35 secFEC: 641163 28
CRC: 17 0ES: 1 0
SES: 0 0UAS: 0 0
LOS: 0 0LOF: 0 0
LOM: 0 0Retr: 0
FailedRetr: 0FailedFastRetr: 0
Previous 1 day time = 24 hours 0 secFEC: 26624694 1414
CRC: 411 0ES: 17 0
SES: 12 0UAS: 0 0
LOS: 0 0LOF: 0 0
LOM: 0 0Retr: 0
FailedRetr: 0FailedFastRetr: 0
Since Link time = 5 days 1 hours 21 min 31 secFEC: 152799634 8789
CRC: 567 0ES: 45 0
SES: 20 0UAS: 0 0
LOS: 0 0LOF: 0 0
LOM: 0 0Retr: 0
FailedRetr: 0FailedFastRetr: 0
NTR: mipsCntAtNtr=0 ncoCntAtNtr=0 > |
Edited by deleted (Sat 01-Dec-18 10:28:45)
|
|
Register (or login) on our website and you will not see this ad.
|
|
|
Yes, I was tired re the shapes being virtually identical. They seemed at the time to move up and down together but now I see parts don�t.
What you also need to look at is
adsl info �pBparams
when normal and when low.
My broadband basic info/help site - www.robertos.me.uk. Domains, site and mail hosting - Tsohost.
Connection - AAISP Home::1 80/20. 200GB. Sync 01/10/18 - 72382/13812Kbps @ 600m. (Disabled:BQMs - IPv4 & IPv6)
==================================================
If you never think of anything off the wall, you'll never think of anything original. |
|
|
Thanks, Bob. Would you say if parts don't, then it's interference from an electrical item?
Have looked at the pbParams, and the only values that change are the SNRM per band values, which are graphed here: http://prntscr.com/lpb3uc
Edited by deleted (Sat 01-Dec-18 10:53:53)
|
|
|
Blow the graph. Post the pBparams at good and bad times.
My broadband basic info/help site - www.robertos.me.uk. Domains, site and mail hosting - Tsohost.
Connection - AAISP Home::1 80/20. 200GB. Sync 01/10/18 - 72382/13812Kbps @ 600m. (Disabled:BQMs - IPv4 & IPv6)
==================================================
If you never think of anything off the wall, you'll never think of anything original. |
|
|
|
All the information you need is in the graph, nothing else changes.
|
|
|
Fine. Goodbye.
My broadband basic info/help site - www.robertos.me.uk. Domains, site and mail hosting - Tsohost.
Connection - AAISP Home::1 80/20. 200GB. Sync 01/10/18 - 72382/13812Kbps @ 600m. (Disabled:BQMs - IPv4 & IPv6)
==================================================
If you never think of anything off the wall, you'll never think of anything original. |
|
|
|
Just giving you the facts, no need to act like that; immaturely.
|
|
|
Have you tried a radio tuned to the frequencies where the dips are? Likely to find a strong station at that frequency
|
|
The author of the above post is a thinkbroadband staff member. It may not constitute an official statement on behalf of thinkbroadband.
|
|
|
|
Yes, I did find stations around that frequency. Do you think it could be the AM radio station(s) causing the drops?
|
|
|
Well that is a common cause of problems and is well documented and why ADSL behaves the way it does
|
|
The author of the above post is a thinkbroadband staff member. It may not constitute an official statement on behalf of thinkbroadband.
|
|
|
Interesting. I must've thought wrong that DSL was designed to not be affected by radio stations, then. It just seems weird/unsophisticated that an AM station can sometimes cause DS SNRM drops/mass errors/occasional resyncs.
Edited by deleted (Sat 01-Dec-18 21:00:58)
|
|
|
The design is to not use the frequencies where the radio stations impact the ability of DSL to operate which often explains the dips rather than a smooth drop off due to the physics of attenuation
|
|
The author of the above post is a thinkbroadband staff member. It may not constitute an official statement on behalf of thinkbroadband.
|
|
|
Right, but surely if it's service affecting (errors/resyncs (albeit not many of the latter)), then it's not working as it should?
Edited by deleted (Sun 09-Dec-18 14:59:17)
|
|
|
It is designed precisely to work like that.
If there is a factory chucking out electromagnetic noise, there is nothing xDSL can do about that factory.
That is why the SNRM exists. To allow for varying noise levels or even constant ones, to make the system work. If you didn't have a margin, but let the line connect at the full speed that you could get with the full Signal to Noise Ratio, then ever time you turned the central heating on there'd be a chance of a disconnection and re-sync.
When the sun goes down in the evening electromagnetic noise in the atmosphere goes up. In the morning the noise goes down as the sun rises. The principle is the same.
At some points in the day some noise hits your line for a while, then goes away. But the service continues happily providing you with the speed you are sync'ed at.
My broadband basic info/help site - www.robertos.me.uk. Domains, site and mail hosting - Tsohost.
Connection - Three 4G, tbb tests 35-45Mpbs down, 9-15 up.
==================================================
If you never think of anything off the wall, you'll never think of anything original.Edited by RobertoS (Sun 09-Dec-18 15:17:47)
|
|
|
That feel when you know who wrote a thread before actually looking at it
|
|
|
|
Well, I'm just interested. That's perfectly ok.
|
|
|
|
Thanks, Bob. I may as well just put up with it then.
|
|
|
'Fraid so. It is only if it seriously knocks your connection around over quite a while and takes you below the estimates for the line consistently that even a good ISP is going to be interested.
Getting the sort of speeds we do over copper lines is incredible, and the way the system works is essential. Otherwise, to lower error counts and things by the very nature of physics would mean slowing us all down to a tenth of what we get. The fundamental concept has to be for designers to say to themselves:- "this is what noise does to us - how can we work round it and still get high speeds?"
The data your graphs plot are the answer.
My broadband basic info/help site - www.robertos.me.uk. Domains, site and mail hosting - Tsohost.
Connection - Three 4G, tbb tests 35-45Mpbs down, 9-15 up.
==================================================
If you never think of anything off the wall, you'll never think of anything original. |
|
|
Dont ask Bob William he is no longer on copper has gone for mobile broadband. 
Tim
www.uno.net.uk & freenetname
Asus DSL-N55U and ZyXEL VMG1312-B10A Bridge on 80/20 Meg Fibre
Speed Test
Current Sync: 79993/19661
BQM
|
|
|
LOL
And completely erased my memory ?
My broadband basic info/help site - www.robertos.me.uk. Domains, site and mail hosting - Tsohost.
Connection - Three 4G, tbb tests 35-45Mpbs down, 9-15 up.
==================================================
If you never think of anything off the wall, you'll never think of anything original. |
|
|
|
True. It has to work with an element of margin, or as Openreach call it "scope of acceptance" or something along those lines.
|
|
|
Haha! Hi Tim! Hope you're well.
Edited by deleted (Mon 10-Dec-18 16:59:51)
|
|
|
Not completely linked, but I noticed today that the U1 signal attenuation increased and the DS/US SNRM dropped gradually, when it was raining earlier. These then returned to normal after it became drier. Could this be a mini-HR fault?
Edited by deleted (Sat 15-Dec-18 17:12:59)
|
Pages in this thread: 
Print Thread
