Register (or login) on our website and you will not see this ad.
|
|
|
Ignore what I said before - I misread some of the graphs - some of the FEC and CRC counts in the graphs come from the modem's GUI, which unfortunately gets them from the wrong fields compared to the "--stats" command.
With the "--stats" output, I can see that downstream, you aren't interleaved or set to have any FEC processing working. That means you *are* seeing CRC errors - and the stats for the 12 minute period, 15 minute period and (near) 5 hour period suggest an average of around 500-800 errors per hour, broadly spread out over time.
(To see it in the graphs, watch the "OHFErr" graph instead of the CRC one.)
That sounds quite high compared with ADSL, where it could easily cause interleaving to be added. My working hypothesis is that VDSL2 can have an error rate 10x higher and continue to work effectively. If that is true, then the DLM threshold might well be around 600 errors per hour. Mighty close... so worth watching each day.
Some observations over timing though...
- You resync'ed at 8:15 - was this manual, or caused by the neighbour's installation?
- The SNRM change happens at 8:45. Is this the time the neighbour's was turned on?
- But the CRC errors started at 8:30. Interesting, but not obvious why.
|
|
|
5072 DS Error Seconds in the 13 hours or so connection time also looks very high.
My connection is quite poor due to a long distance from the cabinet, but I usually only see around 110 Error Seconds in a 24 hour period, admittedly with DS Interleaving at a depth of 443, INP at 3.00 & delay at 8.00.
(To see it in the graphs, watch the "OHFErr" graph instead of the CRC one.)
Yes, I can confirm that.
The next version (to be released fairly soon) does not use any of the "duff" stats from the modem's GUI, taking all the data from xdslcmd info --stats instead.
Using the current script version, use the OHFErr graph instead of CRC & use the RSCorr graph instead of FEC.
HEC is still O.K. though.
Edited by Bald_Eagle1 (Tue 27-Nov-12 01:56:13)
|
|
|
Ok, so I got up this morning to find my line is now a 67Mbit line with interleaving  I'd imagine that over the next few weeks the DLM will notice the lack of errors now and remove interleaving and leave me with a lower sync speed on fast path?
On the timings:
The guy first arrived at 8:10, but didn't stop, just drove straight back up the road again.
He then came back and parked on next doors driveway as I was leaving the house at 8:20
From here on out I'm relying on what I've been told with regards to timings.
He stayed for maybe 5 minutes (8:25) and then drove off again. At this point I'm assuming he went to the cab to connect the patch cables over to the FTTC cab?
He then came back, don't know what time but I'd imagine it would have been shortly before 8:35?
Don't know what time he left but I'd imagine that he finished the install and turned the modem on at 8:45, right when my attainable rate dropped. The CRC'd then must have started when he connected then in the cab.
Has he knocked something?
Anyway, here is the latest data from the modem:
| 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
| xdslcmd: ADSL driver and PHY status
Status: ShowtimeRetrain Reason: 2
Max: Upstream rate = 27153 Kbps, Downstream rate = 79516 KbpsPath: 0, Upstream rate = 20000 Kbps, Downstream rate = 67333 Kbps
Link Power State: L0
Mode: VDSL2 Annex BVDSL2 Profile: Profile 17a
TPS-TC: PTM ModeTrellis: U:ON /D:ON
Line Status: No DefectTraining Status: Showtime
Down UpSNR (dB): 6.3 15.0
Attn(dB): 0.0 0.0Pwr(dBm): 13.8 6.0
VDSL2 framing Path 0
B: 63 237M: 1 1
T: 64 45R: 16 16
S: 0.0302 0.3782L: 21160 5373
D: 1067 1I: 80 127
N: 80 254 Counters
Path 0OHF: 8664341 2968811
OHFErr: 3 13RS: 1663553210 420793
RSCorr: 19940 256RSUnCorr: 5 0
Path 0
HEC: 2 0OCD: 0 0
LCD: 0 0Total Cells: 1634389645 0
Data Cells: 1053718 0Drop Cells: 0
Bit Errors: 0 0
ES: 6641 130SES: 20 4
UAS: 76 76AS: 12630
Path 0
INP: 3.00 0.00PER: 1.45 4.25
delay: 8.00 0.00OR: 115.71 60.17
Bitswap: 1907 60
Total time = 1 days 16 hours 28 min 39 sec
FEC: 19940 1777CRC: 3 228
ES: 6641 130SES: 20 4
UAS: 76 76LOS: 15 0
LOF: 10 0Latest 15 minutes time = 13 min 39 sec
FEC: 87 1CRC: 0 1
ES: 0 1SES: 0 0
UAS: 0 0LOS: 0 0
LOF: 0 0Previous 15 minutes time = 15 min 0 sec
FEC: 1565 4CRC: 0 1
ES: 0 1SES: 0 0
UAS: 0 0LOS: 0 0
LOF: 0 0Latest 1 day time = 16 hours 28 min 39 sec
FEC: 19940 499CRC: 3 63
ES: 3280 34SES: 7 0
UAS: 17 17LOS: 5 0
LOF: 5 0Previous 1 day time = 24 hours 0 sec
FEC: 0 127CRC: 0 32
ES: 1406 30SES: 11 0
UAS: 40 40LOS: 10 0
LOF: 5 0Since Link time = 3 hours 30 min 29 sec
FEC: 19940 256CRC: 3 13
ES: 1 10SES: 0 0
UAS: 0 0LOS: 0 0
LOF: 0 0# |
and..
| Text | 1
23
45
67
89
1011
1213
1415
1617
1819
2021
2223
| x
dslcmd info --pbParamsxdslcmd: ADSL driver and PHY status
Status: ShowtimeRetrain Reason: 2
Max: Upstream rate = 27130 Kbps, Downstream rate = 79516 KbpsPath: 0, Upstream rate = 20000 Kbps, Downstream rate = 67333 Kbps
Discovery Phase (Initial) Band Plan
US: (0,95) (868,1207) (1972,2783) DS: (32,859) (1216,1963) (2792,3959)
Medley Phase (Final) Band PlanUS: (0,95) (868,1207) (1972,2783)
DS: (32,859) (1216,1963) (2792,3959) VDSL Port Details Upstream Downstream
Attainable Net Data Rate: 27130 kbps 79516 kbpsActual Aggregate Tx Power: 6.0 dBm 13.8 dBm
============================================================================ VDSL Band Status U0 U1 U2 U3 D1 D2 D3
Line Attenuation(dB): 2.9 16.9 24.7 N/A 9.7 21.2 32.0 Signal Attenuation(dB): 2.9 15.9 24.1 N/A 9.7 21.2 32.0
SNR Margin(dB): 14.8 15.0 15.0 N/A 6.3 6.3 6.2 TX Power(dBm): -9.0 -29.0 5.9 N/A 11.2 7.8 7.0 |
Sorry if the formatting isn't quite right, posting this on an iPad..
Alex 
|
|
Register (or login) on our website and you will not see this ad.
|
|
|
|
Also just to note, I cannot explain the resync at 8:15. Very strange..
|
|
|
The reduction or complete removal of interleaving, if that happens, will increase your sync speed, not reduce them as you stated in the previous post to the one I'm replying to. I presume that was a typo.
Anyway, one possible way I can think of to determine if their Infinity has caused this loss in attainable speed is if they're willing to switch off/unplug their modem for a few minutes while you check your attainable rate. It does very much sound like their connection has brought your connection speed down though, given your timings.
Your current interleaving to me would indicate you have a moderate level. I don't really go by 'D' as that varies depending on your sync as well as some other parameters. I usually observe the INP and delay, and in my experience I've seen DLM set INP from 2 all the way to 5, not sure I've ever seen it higher than 5. I've never seen DLM use an INP of 1 either, just 0, 2, 3, 4 or 5.
Edited by Ixel (Tue 27-Nov-12 11:33:46)
|
|
|
Just posting this graph from my HG612 here for any opinions on whether this is a normal/expected level of crosstalk as a result of my neighbour having 80/20 FTTC installed this morning.
Graph Here
They have a 71.38Mbps IP Profile. We (currently) sync at the full 80/20, so 77.43Mbps profile. As you can see this won't be continuing due to our DS SNRM being ~ 4.5db, down from 8db this morning. I'm not too fussed just wondering if this is normal?
The increased crosstalk is causing some packet loss by the looks of my BQM.
I'm tempted to resync and take the hit on sync speed so the DLM doesn't step in and add interleaving.
Modem stats are: here and here.
Any thoughts?
Alex
looks like a DLM cause not your neighbour, your latency bumps on tbb graph meaning interleaving.
|
|
|
|
Yup that was a typo, I was thinking in my head that it would come back slightly under 79,999 on fastpath, but that's not what I wrote. Don't like mornings..
I don't really know my neighbours well enough to go round and ask them to switch off their modem for a few minutes, although I'd like to just to see what happens.
Hopefully the DLM will gradually reduce the interleaving depth over the next few days. I'll post an update in a weeks time, or if I get back on fastpath before then, whichever comes first.
|
|
|
looks like a DLM cause not your neighbour, your latency bumps on tbb graph meaning interleaving.
Yes the DLM caused the interleaving but that was as a result of next doors FTTC install causing increased crosstalk and thus errors on our line, hence the addition of interleaving to calm things down
|
|
|
looks like a DLM cause not your neighbour, your latency bumps on tbb graph meaning interleaving.
I think that is because you are now looking at the next day's BQM - not the graph for the day that I was looking at yesterday.
Alex - when you post a link on here, can you make it something that doesn't change? Anyone who finds this thread in a few days, weeks or months won't understand what we're talking about!
|
|
|
Anyway, one possible way I can think of to determine if their Infinity has caused this loss in attainable speed is if they're willing to switch off/unplug their modem for a few minutes while you check your attainable rate. It does very much sound like their connection has brought your connection speed down though, given your timings.
I agree on both fronts... it seems to be the neighbours, and a way to check your co-dependence would be to see how each other's lines perform when one modem is turned off. You can check their stats too if they're willing to let you plug your hacked modem in 
Your current interleaving to me would indicate you have a moderate level. I don't really go by 'D' as that varies depending on your sync as well as some other parameters. I usually observe the INP and delay, and in my experience I've seen DLM set INP from 2 all the way to 5, not sure I've ever seen it higher than 5. I've never seen DLM use an INP of 1 either, just 0, 2, 3, 4 or 5.
I agree with this - the 'INP' and 'delay' values are the ones set by DLM, and specify the degree of interleaving required.
Here's my understanding of the VDSL2 standard:
- INP can be from 0 to 16 incl
- INP=0 means no protection is required
- delay can be from 0 to 63 incl, or 255
- delay=0 means the delay is unbounded (so can be really high)
- delay=1 means the interleaving depth D should be set to 1 (minimum delay)
- delay=255 means a delay of 1ms
- delay=N otherwise means a delay of Nms
Higher INP values mean more protection is needed. High delays make it easier for the data to be spread out; lower delays make it harder - and so requires that the protection comes from a higher (relative) amount of parity protection. I think high INP and low delay forces a low N with high R.
I personally think the percentage value that comes from (R/N) gives you the best indication of how protected the data is - how much overhead is being consumed.
|
|
|
Pages in this thread: 
Print Thread
