slowing down plusnet

Hi ever since getting connected in November last year my plusnet fibre has been syncing bang on 70meg with an upload bang on 20meg even after reboots would always synk back onto 70/20, well last night the electric run out about 10pm and ive only just put it back on 5 mins ago the thing is though my modem had dropped right down to 59meg upload still 20meg but its still showing attainable as 75meg what do you thinks gone wrong?

PS of my modem

Thanks Ash

Do you know how to get the full line stats at the Command Prompt?

I suspect interleaving has been turned on. Those will show if that's the case.

(And it's nothing to do with Plusnet ).

Edited by RobertoS (Thu 14-Mar-13 11:54:55)

In reply to a post by RobertoS:

Do you know how to get the full line stats at the Command Prompt?

I suspect interleaving has been turned on. Those will show if that's the case.

(And it's nothing to do with Plusnet ).

i know its not exactly down to plusnet but my provider is plusnet and one of the most asked questions on here seams to be whos you ISP so i put it there just to show i am with them lol

And are these what you mean

xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 0
Max: Upstream rate = 20769 Kbps, Downstream rate = 73992 Kbps
Path: 0, Upstream rate = 20000 Kbps, Downstream rate = 59529 Kbps

Link Power State: L0
Mode: VDSL2 Annex B
VDSL2 Profile: Profile 17a
TPS-TC: PTM Mode
Trellis: U:ON /D:ON
Line Status: No Defect
Training Status: Showtime
Down Up
SNR (dB): 5.8 6.1
Attn(dB): 0.0 0.0
Pwr(dBm): 13.1 6.7
VDSL2 framing
Path 0
B: 39 236
M: 1 1
T: 64 5
R: 14 16
S: 0.0214 0.3771
L: 20209 5410
D: 1841 1
I: 54 255
N: 54 255
Counters
Path 0
OHF: 4954677 1111398
OHFErr: 23 7
RS: 1268396974 3485713
RSCorr: 52163 71
RSUnCorr: 283 0

Path 0
HEC: 55 0
OCD: 0 0
LCD: 0 0
Total Cells: 779023731 0
Data Cells: 1180385 0
Drop Cells: 0
Bit Errors: 0 0

ES: 3 5
SES: 0 0
UAS: 23 23
AS: 6807

Path 0
INP: 5.00 0.00
PER: 1.36 6.12
delay: 10.00 0.00
OR: 116.95 203.67

Bitswap: 1381 0

Ash

Yes re interleaving.

"D: 1841 1" shows downstream is on, the 1 shows upstream is still Fast Path.

I think the N line just below it is relevant as well, to calculate the latency increase. Others will know for sure.

Interleaving often seems to cause a drop of ~10Mbps downstream sync . If you are lucky and don't mess, in a few weeks it may revert to Fast Path.

In reply to a post by RobertoS:

Yes re interleaving.

"D: 1841 1" shows downstream is on, the 1 shows upstream is still Fast Path.

I think the N line just below it is relevant as well, to calculate the latency increase. Others will know for sure.

Interleaving often seems to cause a drop of ~10Mbps downstream sync . If you are lucky and don't mess, in a few weeks it may revert to Fast Path.

Right thanks, that's most likely why its dropped then as before i was on fast path (some one confirmed it for me in December)
I dont tend to mess with it just leave it on 24/7 (except when its out of my hands like last night) so fingers crossed will sort its self out

Ash

RobertoS

My speed has gone down by 2 meg in 2 days. was 68.5 mb/s, now it is 66.25 mbits. Not that I'm too bothered about it, but just to be clear in my mind what could be the reason/s? Thanks

The important bits are:

In reply to a post by acpsd775:

R:              14              16
D:              1841            1
I:              54              255
N:              54              255

INP:            5.00            0.00
delay:          10.00           0.00

"INP" and "delay" are the parameters set by DLM, to require 5 symbols of noise protection, while accepting up to 10 milliseconds of extra delay. These are quite high (values of 3 and 8ms are more usual), suggesting that DLM has noticed some severe problems.

"D" and "I" show interleaving - and that value for "D" is quite high, because "delay" has allowed it to be higher than usual.

"R" and "N" show the FEC parameters - 14 bytes out of every 54 are parity bytes used for error-correction. That's 26% of your line capacity, which again is rather high.

Upstream shows that you aren't interleaving, but you do have FEC turned on at a very low level (16 bytes in 255, or 6%)

So, how is your line doing now:

In reply to a post by acpsd775:

OHF:            4954677         1111398
OHFErr:         23              7
RS:             1268396974              3485713
RSCorr:         52163           71
RSUnCorr:       283             0

"RSCorr" is the number of RS blocks that FEC has corrected, while "RSUncorr" gives the number where the errors were too severe to be corrected. The 283 of these leads to the 23 "OHFErr" (aka CRC errors).

52,000 RSCorrs in 2 hours? If FEC was turned off, those would cause OHFErrs instead - perhaps 5,000 of them. That sounds a little high, so I would guess that you're likely to keep interleaving+FEC in some guise, but perhaps not as high as you currently do.

In reply to a post by WWWombat:

The important bits are:

In reply to a post by acpsd775:

R:              14              16
D:              1841            1
I:              54              255
N:              54              255

INP:            5.00            0.00
delay:          10.00           0.00

"INP" and "delay" are the parameters set by DLM, to require 5 symbols of noise protection, while accepting up to 10 milliseconds of extra delay. These are quite high (values of 3 and 8ms are more usual), suggesting that DLM has noticed some severe problems.

"D" and "I" show interleaving - and that value for "D" is quite high, because "delay" has allowed it to be higher than usual.

"R" and "N" show the FEC parameters - 14 bytes out of every 54 are parity bytes used for error-correction. That's 26% of your line capacity, which again is rather high.

Upstream shows that you aren't interleaving, but you do have FEC turned on at a very low level (16 bytes in 255, or 6%)

So, how is your line doing now:

In reply to a post by acpsd775:

OHF:            4954677         1111398
OHFErr:         23              7
RS:             1268396974              3485713
RSCorr:         52163           71
RSUnCorr:       283             0

"RSCorr" is the number of RS blocks that FEC has corrected, while "RSUncorr" gives the number where the errors were too severe to be corrected. The 283 of these leads to the 23 "OHFErr" (aka CRC errors).

52,000 RSCorrs in 2 hours? If FEC was turned off, those would cause OHFErrs instead - perhaps 5,000 of them. That sounds a little high, so I would guess that you're likely to keep interleaving+FEC in some guise, but perhaps not as high as you currently do.

ok TBF you've lost me on most of that lol, how come it would all of a sudden of gone messed up though like i say since November its been fine and i was defo on fast path in December some one told me on a forum also ive not noticed any disconnections and theres no noice on the line so as far as im aware nothing has change to make it go pear shaped all of a sudden

Ash

In reply to a post by acpsd775:

ok TBF you've lost me on most of that lol

The most important bits are that your latency went up 10ms, and that you lost 26% of your speed.

In reply to a post by acpsd775:

how come it would all of a sudden of gone messed up though like i say since November its been fine and i was defo on fast path in December

It is likely that nothing messed up or went pear-shaped.

For a perfectly decent line, working as normal, the most likely cause of degraded performance is crosstalk. This is interference caused by other FTTC users - so is pretty guaranteed to get worse over time, as more people sign up.

It largely depends on what other pairs lie close to yours in the cable, and when they sign up to fibre.

So... it could happen at any time (including from day 1), and there's nothing you can do to predict it or to remove it. You won't necessarily see disconnections or hear anything audible on the line.

There is technology to remove/reduce crosstalk, but it is still in the R+D phase, so might make it out into cabinets in the next 2-5 years.

some one told me on a forum

Ahhh, you don't want to believe posts on a forum

In reply to a post by WWWombat:

In reply to a post by acpsd775:

ok TBF you've lost me on most of that lol

The most important bits are that your latency went up 10ms, and that you lost 26% of your speed.

In reply to a post by acpsd775:

how come it would all of a sudden of gone messed up though like i say since November its been fine and i was defo on fast path in December

It is likely that nothing messed up or went pear-shaped.

For a perfectly decent line, working as normal, the most likely cause of degraded performance is crosstalk. This is interference caused by other FTTC users - so is pretty guaranteed to get worse over time, as more people sign up.

It largely depends on what other pairs lie close to yours in the cable, and when they sign up to fibre.

So... it could happen at any time (including from day 1), and there's nothing you can do to predict it or to remove it. You won't necessarily see disconnections or hear anything audible on the line.

There is technology to remove/reduce crosstalk, but it is still in the R+D phase, so might make it out into cabinets in the next 2-5 years.

some one told me on a forum

Ahhh, you don't want to believe posts on a forum

Ah thanks did not even think about crosstalk TBF it will most likealy be that as for the forum post of was also posting the stats of the router and they said i was on fastpath like u just did today for me.

if i had they money id be one of the ppl who get FTTP OD lol just because your more likely to get what's on the tin lol

Ash