80/20 > 40/20 Stability?

So.., currently having issues with my PN connection, was syncing at 61000+/19999 but now only 56000+/19999 and dropping by the day it seems,

Plusnet don't seem to give a c**p and have said they won't send an engineer until it drops below 50000 as its apparently within my lines estimates (Which have changed since being activated it seems) as when I joined my line was 56 -78mbps (BT Wholesale) and Plusnet quoted 56mbps!

Currently I'm only able to test at 50-52mbps and even though my upstream still remeains synced at 19999kbps speed tests on both speedtest.net and TBB vary between 10 -18mbps and seem very unstable compared to just a few days ago.

and Interleaving has been activated on both downstream and upstream according to my modem stats but PLusnet are saying their end say its off!

Hmmm but theirs not a fault

ANYWAY!

If I was to downgrade to a 40/20 (38/19.5) product would this make the line more stable and hopefully reduce the line interleaving depth or even return it to fast path?

and by changing product with DLM be reset on my line as if it was a new activation?

Cheers in advance!

The Openreach ranges are the 20th percentile and 80th percentile, so there are people on similar lines outside the range. Openreach won't generally accept a fault from the ISP, for just speed issues, until you are below the 10th percentile.

Changing to a Plusnet 40/20 package won't help, as it will be provisioned on Openreach 80/20 product, and limited within Plusnet. You'll still sync at 56/20.

Someone on Kitz had worked out how to configure the modem to a lower speed manually, to get stability back, just as you want. Not sure which modem though...

No offence but in English please?

So when will openreech intervene with an issue?

How much percentage of a speed must one lose before they will get of their thrones!

So when will openreech intervene with an issue?

When Plusnet request that they do so.

In reply to a post by mlmclaren:

No offence but in English please?

If you have an unlocked HG612 with the latest firmware you can limit the sync speed yourself to increase stability.

In reply to a post by BatBoy:

In reply to a post by mlmclaren:

No offence but in English please?

If you have an unlocked HG612 with the latest firmware you can limit the sync speed yourself to increase stability.

My Bad I actually meant

The Openreach ranges are the 20th percentile and 80th percentile, so there are people on similar lines outside the range. Openreach won't generally accept a fault from the ISP, for just speed issues, until you are below the 10th percentile.

In reply to a post by Zarjaz:

So when will openreech intervene with an issue?

When Plusnet request that they do so.

and if Plusnet won't?

When you change to a service provider who will. (cue the talk of A&A)

Yeah I heard those guys work for there money!

Whats Zen like for these sort of issues, do they hodl off calling Openreach or will they do stuff for the customer also!

Whats Zen like for these sort of issues, do they hodl off calling Openreach or will they do stuff for the customer also!

I really don't know, and the comment about A&A is based on hearsay from these boards.

Plusnet base their decision at least partially on the GEA test result.

The GEA test will fail if a line loses more than 25% of sync speed in a short period of time, I dont know how long that period of time is. Thankfully when my own line went below 50 and I had my pair swap, my GEA test failed for that reason meaning I had some clout to push for a fix.

Edited by Chrysalis (Thu 19-Mar-15 20:59:26)

Thanks for the info all,

My connection hasn't yet lost 25% of its bandwidth though its not to far off, So far I've lost 15.25% and that has been slowly increasing since the issue first began so maybe a week and I will be allowed a visit!

So I've got to wait for it to hit 44.25 Mbps before I can get an Openreach engineer!

Well I had a message today saying below 50Mbps and I've done a few tests today that have come in at less than that so I think thats my VIP pass to meet an Openreach employee...

Should I feel lucky or excited!

In reply to a post by mlmclaren:

No offence but in English please?

OK.

But start by understanding that BT expect your speed to drop as a natural event, as other subscribers get added. You should expect it to happen too.

BT shows you the amount they expect the speed to drop by giving you the estimated speed in a range.

In reply to a post by WWWombat:

The Openreach ranges are the 20th percentile and 80th percentile, so there are people on similar lines outside the range.

"Percentile" is a statistical concept, used as follows:

In order to come up with your estimate, BT compares your line to a whole host of "similar lines". It then considers the full variation of speeds on those lines, and extracts two values...

The first value, used as the upper end of your estimate range, represents the "80th percentile"; this is the speed where 80% of the "similar lines" have lower speeds, and 20% of them have higher speeds. If your line achieved this speed, it would be in the top 20%.

The second value, used as the lower end of your estimate range, represents the "20th percentile"; this is the speed where 20% of "similar lines" have lower speeds, while 80% have higher speeds. if your line only achieved this speed, it would be in the bottom 20%.

When you look at the estimated range that BT provides you with, you can see that 20% of those "similar lines" get a speed below the bottom of the range, 20% get a speed above the top of the range, and 60% of lines get a speed inbetween.

Openreach won't generally accept a fault from the ISP, for just speed issues, until you are below the 10th percentile.

When Plusnet raise a fault with BT for a line fault or a speed issue, BT make a choice about whether to reject that report without sending an engineer.

When the fault report is just for a speed issue without an underlying copper issue, Openreach have been getting more stringent about the faults they accept. One of the specification of FTTC between BTW and ISPs (hidden away out of public sight) is that they will only accept faults that are *just* about speed if the speed has gone below the 10th percentile, or has dropped by a significant amount in a short space of time (IIRC, a drop of more than 25% in less than a week, but I might be wrong).

In that specification, the "10th percentile" represents the speed that the slowest 10% of "similar lines" gets; this speed will be quite a level below the bottom of the estimate range that you have been quoted (ie the 20th percentile).

So when will openreech intervene with an issue?

Openreach will consider any fault sent to them by Plusnet, but will reject it if it doesn't meet the requirements I mentioned earlier. Plusnet know this, so don't bother wasting their time in raising the fault in the first place.

Note:
If you have some evidence that there is more to the fault than just a drop in speed, then Plusnet should take that into account. When you contact Plusnet about a drop in speed, they will also use some of the automated line test tools to check out the physical line for signs of a fault. In either case, if there is evidence of some sort of line fault behind the speed drop, they will raise the issue with Openreach, who are likely to involve an engineer.

However, if there is no sign of a physical fault, and *only* a reasonable drop in speed, they will not involve an engineer.

Why?

Because they expect the VDSL2 lines to drop in speed. They expect speed drops to happen slowly over time, as take-up increases. And, separately, they know that DLM intervention can cause a speed drop too.

As these are known events that are expected to happen - and because an engineer cannot fix anything in the former case, and because the main cause of the latter case is in-home wiring - they aren't willing to send an engineer out.

How much percentage of a speed must one lose before they will get of their thrones!

More than 25% in a 3 or 4 day period will do it.

Or when your speed has dropped well below the bottom of the *current* estimate range. In this case, your ISP has told you the level it will have to drop below.

In reply to a post by WWWombat:

In reply to a post by mlmclaren:

How much percentage of a speed must one lose before they will get of their thrones!

More than 25% in a 3 or 4 day period will do it.

Or when your speed has dropped well below the bottom of the *current* estimate range. In this case, your ISP has told you the level it will have to drop below.

Plusnet didn't give me a range for my line, only an estimate (56Mbps),

also my line was not physically existent until ducting was installed in the ground and an Openreach engineer spent a few hour putting new cabling in a connecting a "new" pair in every junction from the front of my house to the PCP.

You should be able to get the range from http://www.dslchecker.bt.com/adsl/adslchecker.welcome
I'm not sure how they use the clean/impacted figures to decide a threshold for getting out an engineer.

Hi thanks I had thought of that but I'm thinking of the approach to Plusnet as they sold me something and failed to mention that within a month I would lose nearly 15% of bandwidth and go from having the best latency and great online gaming experience to not being able to play online gaming anymore.

Also I've noticed that my speedtest.net server seems to think I'm up by Sheffield usually it put me locally by Maidenhead and ideas why this has happened.

This is what BT Wholesale is reporting for my line (Phone Number)

http://tinypic.com/r/2087k3n/8

So my connection is right at the low end of an impacted line which is amazing considering how new the local network is and the also the absolute silence on my phone line..

Surely getting 50mbps on this line should mean an Openreach visit, the FTTC service around here is not exactly that busy nor is it new..

Enabled in 2011 and when I was the 67th line to be connected (not active I must add) and most this area is still using Virgin Media as nobody fancy's their drives being dug up to install the ducts to their homes.

In reply to a post by StephenTodd:

I'm not sure how they use the clean/impacted figures to decide a threshold for getting out an engineer.

I'm not entirely sure when they use one band or the other.

"clean" means that you have the line working in the proper, expected way for that line. No internal wiring issues, no external wiring faults.

"impacted" means that the presence of faults cannot be ruled out - usually because a self-install was done.

If you had an engineer install, then he should have been able to do enough tests to have your line working within the "clean" range. The engineer ought to be savvy enough to make sure there is no impact from internal wiring, and there are no faults on the external side.

If you had a self-install, then your line could fall into the impacted side, simply because no-one skilled has been confirmed to have checked the line out - even if you have personally made sure there are no internal issues.

BUT...

If the line was a self-install, does this mean Openreach won't send an engineer until your speed drops off the bottom of the "impacted" range, rather than the clean range?

I'm not so sure. The "impacted" range implies there are line faults - which ought to be detectable by other tests; Openreach ought to still send an engineer when you see speed drops alongside line faults.

However, they may want you to take steps to ensure that the problem is not caused by an issue with the internal wiring. Usually they do this by making you take the faceplate off to disconnect the extensions.

In reply to a post by mlmclaren:

So my connection is right at the low end of an impacted line which is amazing considering how new the local network is and the also the absolute silence on my phone line..

Absolute silence below 4 kHz ! With a low pass filter in there to keep the noise out too ... not really surprising.

If your hearing was capable of working up in the tens and hundreds of kilo-hertz you would certainly not be hearing silence. The cross talk from other ADSL and VDSL lines would be very noticeable.

In reply to a post by mlmclaren:

So my connection is right at the low end of an impacted line which is amazing considering how new the local network is and the also the absolute silence on my phone line..

I thought you said your line was syncing at 56,000?

That is still above the bottom of the clean range - so is certainly above the cutoff that Openreach will consider.

That's just below the range you show in the link, but what is the current estimate looking like?

Even just below the original clean range means you are just below the 20th percentile, but you likely aren't yet down to the 10th percentile - which is the threshold at which Openreach take action.

Surely getting 50mbps on this line should mean an Openreach visit, the FTTC service around here is not exactly that busy nor is it new..

Wasn't your mention of "50-52" a reference to download speeds on a speed test?

Your download speeds are of no concern to Openreach; they care about the line speed (ie sync speed). Note the output of the DSL checker: for FTTC, it only quotes line rates

With a sync speed of 56Mbps, you'd expect a download speed to be a maximum of 54Mbps, no higher; there is at least 3.3% in overhead in the various addressing protocols, which doesn't get measured by a download speed tester.

Getting download speeds just below the absolute maximum is the norm; there are many other places that can incur delays in the data stream. I personally find that Plusnet's speeds are a tad below the absolute maximum too - presumably as a result of the way they setup their management system, and having their own QoS system.

Enabled in 2011 and when I was the 67th line to be connected (not active I must add)

Connected in what way, if not active? Connected to what? The DSLAM?

Anyway, 10 lines can be enough to have most of the effect of crosstalk. Even 1 line can be enough, if it just happens to be the one major disturber.

and most this area is still using Virgin Media as nobody fancy's their drives being dug up to install the ducts to their homes.

So the developer didn't put any Openreach ducting or chambers in, leaving an effective lock-in with VM?

I presume they got a good kickback from doing that - as such, would be a developer I wouldn't touch with a bargepole. It sounds good to some people, but only ever turns out to restrict freedom of choice down the line.

Edited by deleted (Fri 20-Mar-15 11:10:04)

In reply to a post by WWWombat:

However, they may want you to take steps to ensure that the problem is not caused by an issue with the internal wiring. Usually they do this by making you take the faceplate off to disconnect the extensions.

That does't help with (common) star wiring faults as then the problem internal wiring won't be disconnected by taking the faceplate off. However, star wiring is somewhat unlikely for mlmclaren as sounds as if he is in a new build.

For mlmclaren: star wiring is where there are extensions taken from the incoming feed before the line reaches the master socket. This is common on old systems (often wired up in pre-broadband) and did not cause significant problems on ADSL, but wreak havoc with VDSL/FTTC. As well as telephone extensions, old Sky box wiring and alarm systems were often star wired.

In reply to a post by mlmclaren:

Hi thanks I had thought of that but I'm thinking of the approach to Plusnet as they sold me something and failed to mention ...

By dropping below Plusnet's estimated speed, you may indeed be able to invoke contract clauses that lets *something* happen..

But it doesn't mean that Openreach will be forced into doing something on your line; they (unfortunately) seem to be able to get away with responding based on the current estimate. You might only end up with one remedy - to leave Plusnet.

If you did that, then you'd have a new provider, who would give you the new, lower, estimate. And still with no promise that speeds won't drop. As they'd use the same BT cabinet to supply you, and the same physical copper line, you'd get exactly the same speeds.

that within a month I would lose nearly 15% of bandwidth and go from having the best latency and great online gaming experience to not being able to play online gaming anymore.

61Mbps to 56Mbps sounds like just under 10% to me.

Otherwise, it sounds like DLM has intervened - as the normal reaction is a loss of around 10-15% of speed, and an increase in latency of around 8-10ms.

Those changes would impact gaming, but not make it instantly impossible. If things have become totally impossible, then you are suffering some other problem - likely entirely unrelated to your line, and likely nothing that an Openreach engineer could do. Severe congestion would be such a problem - but you'd probably be seeing download speed tests drop a lot further in the peak hours (9-11pm).

On the positive side, BT are gradually introducing a new form of DLM, known as G.INP. That works to restore stability to your line in a different way, where you generally incur less of a speed drop, and less increase in latency.

If you want to restrict your own speed, so as to persuade DLM to de-intervene, then you want to check out the Kitz forum, looking for places where they are talking about the command "xdslcmd --configure --maxDatarate", or something similar. One example would be:
http://forum.kitz.co.uk/index.php?topic=14611.60

Also I've noticed that my speedtest.net server seems to think I'm up by Sheffield usually it put me locally by Maidenhead and ideas why this has happened.

It usually gets the idea of location from your IP address. For plusnet, it doesn't matter where Speedtest.net thinks you are - a tester in or near London is best. I find the Vodafone server in Newbury is the one that gives me the most stable results.

Hi Everyone

Just got off phone with Pluisnet and now they have listened to my issues besides the sync speed loss they have agreed to send an engineer on Monday morning.

I'm going to try and answer all you questions now,

My line is syncing at around 55000kbps now, compared to 62000kbps on Sunday!

I have removed all phone extensions from the NTE to assure no issues but I've seen no changes, all wiring is brand new is mentioned repeatedly.

My house and the area was developed in the early 70s and no telecoms where installed on my street until after people has moved in, and even then it was only to parts of the street who paid to have them installed.

Euro bell brought cable to the area and everybody including the previous tenants of my home has that installed rather than BT due to the cheap or free installation costs, (BT wanted £200)

Virgin also didn't bury cables as deep as BT was required to so therefore looked my attractive (until someone dug over the flower beds of course)

When I said the line was silent I meant there isn't even the hum you would normally be expected to hear from the exchange.

As my installation was by an engineer I should be expecting speeds within the clean line range then Yes?

In reply to a post by mlmclaren:

When I said the line was silent I meant there isn't even the hum you would normally be expected to hear from the exchange.

What hum do you normally expect from the exchange?

If you can provide line stats showing Attenuation, SNR margin, Sync speed and Max Attainable speed, it should be possible to tell if you have a line fault and what your connection should be able to deliver.

http://tinypic.com/r/14v4nrt/8

Your definition of star wiring isn't quite right.

Star wiring is indeed where the connections to multiple extensions fan out from one spot - but it doesn't have to happen from a point before the NTE (master); it can equally happen at the master, or after it, too.

Star wiring from/after the NTE isn't so much of an issue to VDSL2 (though is still not best practice), while star wiring that originates before the NTE is, as you rightly point out, a big issue.

However, the distinction of taking the faceplate off remains important. If the problematic wiring remains connected to the line, even with the faceplate disconnected - then it remains BT's responsibility - it is, by definition, their wire.

In reply to a post by mlmclaren:

As my installation was by an engineer I should be expecting speeds within the clean line range then Yes?

That would be the right assumption.

What were the other issues that made Plusnet change their mind?

In reply to a post by mlmclaren:

http://tinypic.com/r/14v4nrt/8

Is that current?

If so, you are syncing at 57.7Mbps, a little higher than your previous post; the comparatively high value of the attainable speed is typical of the ever-estimate seen when DLM has intervened - the usual "normal" speed would instead be around 63Mbps.

Unfortunately, the GUI for the unlocked HG612 has some bugs - one of which is that the attenuation is not displayed.

Better figures come from the command-line, and using the "xdslcmd info --stats" command and the "xdslcmd info --pbParams".

As you have the modem unlocked, perhaps the best thing to do would be to run one of the logging programs - either the "HG612 Modem Stats" or "DSLstats" found
http://forum.kitz.co.uk/index.php/board,46.0.html

Combining either of those with the "MyDSLWebStats" site can help too.

The fact that i'm seeing inconsistent and unstable speeds and that streams keep stopping randomly and that I have to intermittently refresh webpages 2/3 times for they load successfully.

They also now understand that the line is actually brand new and that it took 2-3 hours for just the phone to be connected and that the tests run o the line indicated it to be an "excellent" line and that I would know if any new properties had been added to the network as the work required to connect the lines isn't exactly quiet due to the roadworks required.

Also maybe my comments about not receiving the speeds originally indicated upon ordering and quoting parts of the terms and conditions that I agreed to on ordering the service.

I also noted that in my experience Interleaving isn't normally applied at such a high rate straight away and that it normally staggers until errors stop but in this case that didn't seem to happen.

Unfortunately the attenuation isn't shown, but there is a large gap between sync speed and attainable speed.

I did down modem stats the other day,

Note that both the pictures I've linked you are from the other day and speeds have dropped further er since then,

I will see if I can pull some more stats later.

These are what I pulled from the modem the other day

http://tinypic.com/r/2467sj8/8

In reply to a post by mlmclaren:

The fact that i'm seeing inconsistent and unstable speeds and that streams keep stopping randomly and that I have to intermittently refresh webpages 2/3 times for they load successfully.

Some of those issues could indicate a problem - especially if they see any re-syncs happening.

I also noted that in my experience Interleaving isn't normally applied at such a high rate straight away and that it normally staggers until errors stop but in this case that didn't seem to happen.

From what I've seen, which isn't enough yet, interleaving hasn't intervened in a particularly high rate. It looks quite standard so far...

In reply to a post by BatBoy:

Unfortunately the attenuation isn't shown, but there is a large gap between sync speed and attainable speed.

That's normal for the HG612 when DLM has intervened to put FEC and interleaving on; while the sync speed drops, the attainable goes up by a similar amount.

That often indicates a fault.

In reply to a post by mlmclaren:

Note that both the pictures I've linked you are from the other day and speeds have dropped further er since then,

Right. A monitoring programme would certainly help to see changes as and when they happen.

http://tinypic.com/r/2467sj8/8

It would help to see a few things lower down, particularly the INP and delay values.

The amount of FEC overhead downstream is 20%, which isn't especially high. However, you have a lot of FEC overhead upstream, alongside interleaving.

That suggests you are getting delays on both upstream and downstream, which would be affecting latency even more. Seeing the INP and delay settings will help to understand what DLM has asked for.

What would be really worthwhile is to monitor the changes to INP and delay over time - to see if DLM is making changes; DLM normally responds to resyncs and errors - so it would be good to see those over time too. I'd definitely recommend one of those monitoring setups.

What does?

In reply to a post by WWWombat:

From what I've seen, which isn't enough yet, interleaving hasn't intervened in a particularly high rate. It looks quite standard so far...

I don't think a jump of 16ms on my BQM is normal after fault free since connection on fast path.

The post I replied to, obviously.

So you agree that some of the settings on the connection need changing or resetting, as you said, interleaving has been set on both downstream and upstream with a delay of 8 (I saw in modem stats)

and if I'm right, your saying that if their is any fault it is on upstream and not downstream..

Here is my modem stats before the issues!

http://tinypic.com/r/2zz7ur8/8

58-59mbps download 17-18mbps upload and 11ms ping (rapidswitch, Maidenhead)

I've ulled the stats from my modem using telnet, they're as follows!

# xdslcmd info --stats
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 2
Max: Upstream rate = 25613 Kbps, Downstream rate = 66816 Kbps
Path: 0, Upstream rate = 19999 Kbps, Downstream rate = 56570 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): 6.2 6.6
Attn(dB): 0.0 0.0
Pwr(dBm): 13.6 7.1
VDSL2 framing
Path 0
B: 47 29
M: 1 1
T: 64 64
R: 12 10
S: 0.0270 0.0476
L: 17782 6717
D: 1201 673
I: 60 40
N: 60 40
Counters
Path 0
OHF: 8669008 3289725
OHFErr: 0 0
RS: 2219265617 3949549
RSCorr: 20892 11700
RSUnCorr: 0 0

Path 0
HEC: 0 0
OCD: 0 0
LCD: 0 0
Total Cells: 1634720162 0
Data Cells: 23551617 0
Drop Cells: 0
Bit Errors: 0 0

ES: 6 0
SES: 5 0
UAS: 127 127
AS: 15037

Path 0
INP: 3.00 4.00
PER: 1.72 4.57
delay: 8.00 8.00
OR: 111.13 73.46

Bitswap: 1747 643

Total time = 8 hours 44 min 0 sec
FEC: 48364 27567
CRC: 2945 0
ES: 6 0
SES: 5 0
UAS: 127 127
LOS: 5 0
LOF: 5 0
Latest 15 minutes time = 14 min 0 sec
FEC: 18 55
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
Previous 15 minutes time = 15 min 0 sec
FEC: 1714 677
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
Latest 1 day time = 8 hours 44 min 0 sec
FEC: 48364 27567
CRC: 2945 0
ES: 6 0
SES: 5 0
UAS: 127 127
LOS: 5 0
LOF: 5 0
Previous 1 day time = 0 sec
FEC: 0 0
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
Since Link time = 4 hours 10 min 35 sec
FEC: 20892 11700
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
# xdslcmd info --stats

also just pulled this too:

# xdslcmd info --pbParams
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 2
Max: Upstream rate = 25621 Kbps, Downstream rate = 66588 Kbps
Path: 0, Upstream rate = 19999 Kbps, Downstream rate = 56570 Kbps

Discovery Phase (Initial) Band Plan
US: (0,95) (868,1207) (1972,2783)
DS: (32,859) (1216,1963) (2792,3971)
Medley Phase (Final) Band Plan
US: (0,95) (868,1207) (1972,2783)
DS: (32,859) (1216,1963) (2792,3971)
VDSL Port Details Upstream Downstream
Attainable Net Data Rate: 25621 kbps 66588 kbps
Actual Aggregate Tx Power: 7.1 dBm 13.6 dBm
============================================================================
VDSL Band Status U0 U1 U2 U3 D1 D2 D3
Line Attenuation(dB): 3.8 22.1 33.7 N/A 11.1 27.4 43.2

Signal Attenuation(dB): 3.8 21.1 32.7 N/A 11.1 27.4 43.2

SNR Margin(dB): 6.6 6.5 6.6 N/A 6.1 6.1 6.1

TX Power(dBm): -2.2 -21.1 6.5 N/A 10.8 7.9 6.9

#

Thanks

Edited by deleted (Fri 20-Mar-15 18:15:46)

That's interesting -RetrainReasonNegativeMargin 2

In reply to a post by BatBoy:

That's interesting -RetrainReasonNegativeMargin 2

Is that what reason 2 is?

and does that mean the SNR dropped from 6 to below 0?

I think so

In reply to a post by BatBoy:

The post I replied to, obviously.

Duh...

What part of it indicates a fault? There are quite a few components, if you read the post carefully.

But I'll answer anyway... Any of those components can happen without a fault. DLM intervention. Turning FEC on. Turning interleaving on. Dropping Sync speeds. Over-estimated attainable speeds. Every single one can be business-as-usual.

In reply to a post by mlmclaren:

So you agree that some of the settings on the connection need changing or resetting, as you said, interleaving has been set on both downstream and upstream with a delay of 8 (I saw in modem stats)

DLM works by monitoring the rate of errors on your line (most specifically the ES counter); when it intervenes, it does so by setting the INP and delay parameters.

So, while you say that "some of the settings need changing or resetting", doing so *alone* is pointless. You would go back to having lots of errors - and DLM would re-intervene 2 days later.

What you need to do is figure out what was causing the errors, and eliminate that.

However, because DLM has now intervened, the errors will now mostly appear as FECs. To see when those events are happening, you need to run some monitoring software, and use the graphs to work out when the noise happens. Is it all day long? Is it when the heating turns on? etc.

I do agree that DLM has intervened heavily, and further than the norm. It is worth investigating.

and if I'm right, your saying that if their is any fault it is on upstream and not downstream..

DLM intervention is separate - and has happened on both. It suggests your line is receiving interference both up- and down-stream.

Here is my modem stats before the issues!

http://tinypic.com/r/2zz7ur8/8

Yup, they're OK. Ignore the error counts on the GUI, as it gets them mixed up. The text values are better - and the monitoring software uses those.

I think the negative margin indicates a fault rather than normal behaviour.

I don't see any negative margin. Or the line you quoted "That's interesting -RetrainReasonNegativeMargin 2" [puzzled]

Edited by RobertoS (Fri 20-Mar-15 19:02:52)

Just updated my modem firmware info here have noticed slight increase as mentioned in the link.

Is that SP08 now?

After a bit of study, there are a couple of things that stand out, beyond the things I've already mentioned:

RS: 2219265617 3949549
RSCorr: 20892 11700
RSUnCorr: 0 0

These figures show that FEC is turned on, but is having almost no work to do - the number of RSCorr is really pretty low compared to the total number of RS blocks.

The relative counts suggests that there really isn't that much for FEC/interleaving to do - in either direction - so perhaps DLM intervention isn't really warranted.

RSUnCorr implies that FEC managed to fix all the faulty blocks. However, these stats ...

ES: 6 0
SES: 5 0
UAS: 127 127
AS: 15037

... strangely, tell us that some nasty things were happening. In particular, that CRC errors happened (even though RSUncorr was zero).

And it is pretty bad to see the SES counter as high as the ES counter.

Now consider the next two bunches of stats:

1)

Total time = 8 hours 44 min 0 sec
FEC: 48364 27567
CRC: 2945 0
ES: 6 0
SES: 5 0
UAS: 127 127
LOS: 5 0
LOF: 5 0

and 2)

Since Link time = 4 hours 10 min 35 sec
FEC: 20892 11700
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0

Stats (2) match up with my comments for the earlier part - the FEC count matches the RSCorr count, and there are otherwise no errors at all; things don't seem too bad for this 4 hour period.

Altogether, stats (2) seem to show a rosy picture, for the most recent 4 hour period.

HOWEVER...

stats (1) shows how bad the previous 4hr 34min period must have been.

5 Loss of signal, 5 loss of frame, and an outage of 127 seconds says something isn't working well. Getting nearly 3,000 CRC errors within an 11 second period (5 ES plus 6 SES) is also rather bad - suggesting some really issues.

Stats (1) don't paint a rosy picture at all.

It is hard to correlate the behaviour seen in stats(2) against the behaviour seen in (1). That in turn suggests your line gets to see some intermittent problems.

Intermittent problems are the hardest to find, making 24/7 monitoring almost vital.

Once you have some basic monitoring running, there are some obvious things to check: Do high error rates occur at particular times of day? Do they happen with particular types of weather (heat, cold, rain, wind)? Do they happen when calls are made out? Or when calls come in?

In reply to a post by BatBoy:

I think so

I think so too.

If the SNR goes negative, when (at sync time) it will have started at 6dB, it suggests that noise has quadrupled. If that happens regularly, something nasty is happening.

Or it suggests a line fault - such as a high resistance fault (HR fault).

Does your internet connection stay up when you lift the handset off-hook? Or make a call? Or receive a call?

OK Interesting turn of events!!!!

Updated HG612 to very latest version of firmware: A2pv6C038m.d24j

This has now sent my line rate speed higher than ever before (67000kbps)

My line profile on BTw diag test has changed to 64mbps though still only able to acheive 50mbps (maybe needs time to update)

Latency has also reduced by a lot though a slight bit of interleaving still remains...

Not able to confirm yet as modems GUI won't show but I think G.INP has been activated..

Managing to read via Telnet...

In reply to a post by RobertoS:

Or the line you quoted "That's interesting -RetrainReasonNegativeMargin 2" [puzzled]

It is possible that the "retrain reason" value of 2 means that a negative margin was encountered.

There is a post on Kitz detailing this
http://forum.kitz.co.uk/index.php?topic=13934.110

The values may, or may not mean this.

I don't see any negative margin.

It really needs monitoring 24/7 to see if this actually happens.

On ADSL, my current line exhibited symptoms of an HR fault. Lifting the handset caused SNRM to drop - sometimes 2dB, sometimes 6dB. Sometimes it would cause a resync - though I never checked the reason.

When we finally got Openreach to get the fibre connection working, the HR fault was history, so I guess it was either in the E-side, or in the PCP. The last engineer suspected it would be at the MDF.

But we could only really tell what was happening by monitoring the SNRM with DSLStats.

Yeah - please post the telnet data, we can confirm the G.INP status - which would indeed explain the return of the headline sync speed.

I don't think interleaving and G.INP will co-exist.

It is more complex than that.

Bearer 0 - the main communication channel - can continue to be configured with some small level of FEC (around 5% overhead instead of 20% overhead). And it can continue to have a small level of interleaving configured (0.2ms instead of 8ms). Both of these have been seen on live lines.

The "heavy lifting" of coping with big problems (SHINE) is left to retransmission (ie the core new feature of G.INP), but very small levels of REIN continue to be handled by FEC/interleaving - or at least, things can be configured that way.

Bearer 1 - the channel that the re-transmitted blocks are sent down - is extremely over-protected by FEC but not interleaving interleaving. This channel (0.1Mbps) runs at 100% FEC overhead, so I guess it really wants the block to get through.

Sounds like an interesting mix of ideas

I've got the stats program working again now!!

Damn windows 10 previews :/

Right screenshot here!

G.INP is a go!

I think the firmware image i have has had the BT Agent removed from it, I'm not sure if this is important or not.

Yeah Baby!

Back in business!

http://f8luresig.mouselike.org/sig.png?/54977.png

In reply to a post by mlmclaren:

My line profile on BTw diag test has changed to 64mbps though still only able to acheive 50mbps (maybe needs time to update)

The Plusnet Current line speed will be causing that. It updates a few times a day, rather than in real-time.

Thanks . I'll take a look at the Kitz link after some sleep. I doubt if much would sink in right now.

Good news. It will be interesting to see what happens next time the SNRM goes negative.

In reply to a post by RobertoS:

In reply to a post by mlmclaren:

My line profile on BTw diag test has changed to 64mbps though still only able to acheive 50mbps (maybe needs time to update)

The Plusnet Current line speed will be causing that. It updates a few times a day, rather than in real-time.

Thought as much, Thanks for confirming!

Might be something to checkout in the morning!

What do I do about Openreach engineer visit and it seems it might not be required but still don't know why what happened before happened?

and I would rather someone check it out rather than it occurring again later on!

There's a set of stats here, showing Pre & Post G.INP data:-

http://forum.kitz.co.uk/index.php/topic,15162.msg282...


Visitors to the site need to be registered to view the attachments.

In reply to a post by mlmclaren:

I've got the stats program working again now!!

Right screenshot here!

G.INP is a go!

That looks to be working fine - and the recovery of speed (from the DLM overheads) seems to be exactly what G.INP is all about.

The only thing is that we don't yet know how to best monitor the functioning of g.INP, to see when it is behaving well. I need to see a lot more stats, from more lines to figure it out properly. The graphs done by bald eagle help.

For your line, we need to be checking basic stability - that resyncs don't happen, and errors stay manageable...

In reply to a post by mlmclaren:

Yeah Baby!

Back in business!

http://f8luresig.mouselike.org/sig.png?/54977.png

Looking at this (live) graph at 2pm, I'm a little worried about events at 8am and 10am. Those look like resyncs to me, unless you were doing something yourself. If they happened by themselves, it isn't a good sign

Can you post another screenshot of the monitoring program? And the graphs you get from hitting the snapshot button? One of the montages will do, but we want to be able to see the graphs clearly, with at least the overnight data.

In reply to a post by mlmclaren:

What do I do about Openreach engineer visit and it seems it might not be required but still don't know why what happened before happened?

and I would rather someone check it out rather than it occurring again later on!

G.INP is still a DLM intervention, just less harsh than the old method. However, it is a sign that something is still there.

Right now, you want to check whether g.INP has helped with stability before deciding on the engineer

In reply to a post by WWWombat:

Looking at this (live) graph at 2pm, I'm a little worried about events at 8am and 10am. Those look like resyncs to me, unless you were doing something yourself. If they happened by themselves, it isn't a good sign

The re-syncs at 8am was me restarting the modem and the re-sync at 10am seemed to be the DLM reducing the latency back down again after is rose by 2ms after the restart at 8am!

In reply to a post by WWWombat:

Can you post another screenshot of the monitoring program? And the graphs you get from hitting the snapshot button? One of the montages will do, but we want to be able to see the graphs clearly, with at least the overnight data.

I will do later also will downloading a 10GB test file give a good indication of whether there is any issues as processing data through the connection will pickup on errors surely?

Or am I barking up the wrong tree with the above statement?

In reply to a post by WWWombat:

For your line, we need to be checking basic stability - that resyncs don't happen, and errors stay manageable...

Unfortunately the firmware I'm using on the modem at the moment doesn't seem to report errors correctly (or at least in the web gui anyway)

I say this as straight away I noticed errors on "Path 1" which don't seem to be in use (What is path 1 and what "could" it bring in the future)

I think the 2ms could be explained in the variance between Plusnet gateways, as you connect to different ones after a resyncs. We'll see from the graphs..

The 10GB file is questionable. The synced modems are constantly transferring blocks of data, even when you aren't downloading. Errors happen anyway, and become part of the stats. A download should make no difference.

Well, that was true before g.INP, and probably remains true ... but we need to observe more to be sure.

Path 1 might be bearer 1, as I described earlier.

But I don't trust the data in the GUI, and would need to compare it with the telnet output to say for sure

But what is path 1 for as currently I only see path 0 in use?

As requested!

http://tinypic.com/r/14iftll/8

If you scroll down your command line telnet print well below the VDSL2 framing section you see lots of settings for Bearer 1. As in this post from an older thread.

Path 0 in the GUI is Bearer 0 in the xdslcmd stats. Path 1 is Bearer 1 but doesn't have a sync. But it is definitely in use when G.INP is activated. Most of us don't see anything to do with Bearer 1 in our xdslcmd output. You didn't in earlier posts.

WWWombat explained what Bearer 1 does in this post .

OK, Thanks for pointing out the information and the post I missed

Easily missed .

I've just realised why doesn't have a sync! There's only one connection. (/me slaps head).

So it just bungs a few packets down the same sync'ed connection, with presumably some identifying field in the packet header. Effective loss of Bearer 0 throughput negligible in most cases, and no doubt DLM would get more excited if it felt there were too many packets on Bearer 1.

That's perhaps why they are only rolling it out slowly, to fine tune the DLM from real-world use.

Edited by RobertoS (Sat 21-Mar-15 23:55:50)

In reply to a post by RobertoS:

That's perhaps why they are only rolling it out slowly, to fine tune the DLM from real-world use.

Well I've become an unexpected trialist for G.INP by the looks of things, could have some local network guys on the phone this week asking questions about my modem!

Specially as my firmware version has had the BT Agent killed so they most likely won't be able to talk to it or even push the firmware back.

do you think g.inp is been made the new default profile? as seeing it been enabled on good lines.

Is G.INP dependent a on modem firmware update? I think I recently had an update, and about the same time got G.INP on the line. Not concerned one way or the other, just curious.

In reply to a post by StephenTodd:

Is G.INP dependent a on modem firmware update? I think I recently had an update, and about the same time got G.INP on the line. Not concerned one way or the other, just curious.

In my experiance this weekend it seems that Yes!a firmware update is necessary to activate G.INP, As I mentioned above it seemed that G.INP had been activated at my cabinet and my modem was confusing G.INP for INP.

That mad my connection slower and raised the INP levels, As soon as I updated the modems firmware it all reduced back to normal and my speed increased also.

Many from my region (South East) are also reporting similar issues with their connections over at the Plusnet forums.

Guy from Openreach been and gone and confirmed the line is fine, he spent 20-30 mins testing it and found no issues,

"very good line", also remarked on the external covers and capping which I harassed Openreach for after first install.

He agree's that the line issues seemed to be the enabling of G.INP confusing the modem but said he wasn't aware of what was going on with G.INP as many will agree "they seem to be keeping quiet on the rollout dates"

So until next time (fingers crossed their isn't one) I'm happy with my connection.

OK.

Keep an eye on the snrm graphs, to make sure they stay reasonably level - that's the first place to look for stability.