Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[tommy45]

I having looked cannot see any changes apart from  loss of attainable and SNR But around 9pm the connection started flapping SNR attainable rates DS as well  dipped to below my sync rate a few times as well as very briefly rising to 87mbps  there were also 100's of thousands of fec's in bursts mainly on the ds,

I powered off the modem for an hour,as it wanted to avoid racking the up error rate & possible DLM action, When it had re synced at 10pm there i can see that there was a brief repeat of what i saw just before 9pm, then it eased off,

 but looking at the G-MIN EFTR screen i do see something a little odd the upstream was still working even though G.inp had been disabled on the upstream on the 31st may some 20hrs earlier,

surely this should of stopped as soon as dlm made the changes ? Also whilst the modem was powered down i did a qlt & could hear the occasional click,pop which wasn't there today, Possibly the start of a developing elusive HR fault? as if VDSL is affected in a similar way to DSL then the upstream frequencies are nearest to the voice side of things and the upstream is more severely impacted ,

Code: [Select]

Max: Upstream rate = 22618 Kbps, Downstream rate = 84124 Kbps

Bearer: 0, Upstream rate = 19999 Kbps, Downstream rate = 79999 Kbps

Bearer: 1, Upstream rate = 0 Kbps, Downstream rate = 0 Kbps

Link Power State: L0

Mode: VDSL2 Annex B

VDSL2 Profile: Profile 17a

TPS-TC: PTM Mode(0x0)

Trellis: U:ON /D:ON

Line Status: No Defect

Training Status: Showtime

Down Up

SNR (dB): 7.0 11.0

Attn(dB): 13.7 0.0

Pwr(dBm): 12.4 3.8

VDSL2 framing

Bearer 0

MSGc: -6 26

B: 130 237

M: 1 1

T: 0 42

R: 8 16

S: 0.0518 0.3781

L: 21468 5374

D: 16 1

I: 139 127

N: 139 254

Q: 16 0

V: 14 0

RxQueue: 60 0

TxQueue: 20 0

G.INP Framing: 18 0

G.INP lookback: 20 0

RRC bits: 0 24

[Chrysalis]

tommy had a look at your graphs, there is a chance of a fault but I standby my earlier comment its not DLM.

Crosstalk can have all sorts of effects which can be independent from each other.

Error rate (including FEC rate)
DS SNR
US SNR
Power cutback intensity.

Your shifts in US attenuation are very small, not large enough to be conclusive.

You can try reporting a fault, but if my memory is right, zen are not easy going on callout fee's. Not as easy going as aaisp and plusnet.  If it were me given you still have 20000 US sync, I would live with it.  I would only do something if the error rate (CRC) increased enough to be service affecting.

[Ronski]

I get 45/6, I used  to get 40/12, when I use the phone my snr drops, have I done anything about it, no because my connection works fine and I have other things more important to sort than something I can probably do nothing about.  If I  had your line I would be celebrating.

PS. You obviously didn't take our advice because you looked at the stats, stop fretting over it and enjoy the connection. If it goes wrong then deal with it. 

[loonylion]

as if VDSL is affected in a similar way to DSL then the upstream frequencies are nearest to the voice side of things and the upstream is more severely impacted ,

The first US band is right next to the voice band, there are others. Unlike ADSL, VDSL has several bands of US and DS and the bands alternate across the tone range (US/DS/US/DS etc).

If you have noises on QLT then you probably can raise a voice fault.

[jid]

as if VDSL is affected in a similar way to DSL then the upstream frequencies are nearest to the voice side of things and the upstream is more severely impacted ,

The first US band is right next to the voice band, there are others. Unlike ADSL, VDSL has several bands of US and DS and the bands alternate across the tone range (US/DS/US/DS etc).

If you have noises on QLT then you probably can raise a voice fault.

I'd agree possibly some kind of voice fault starting up - I had a HR fault so small affecting upstream, but it affected my line in terms of errors and noise, and by DLM intervening.

I would say your issues are nothing to do with DLM or G.INP and are either a line fault, or some form of external interference you can do nothing about.

I myself have learnt that if it isn't broken then don't fix it, my line and yours are both at full sync, and g.inp was removed from upstream, however I'm not experiencing any issues so I'm leaving it and getting on with things. A while ago I became obsessed with looking at stats all the time. Take the other guys advice here and just leave it for a week or so and see how its going then, if its a fault it may develop further, if not then its just the way it goes

[tommy45]

Well as of 10am  the lost SNR found its way back so 11 became 15.2db again, Which i have no real answer for,I agree that the loss of SNR & attainable wasn't DLM (as that would need a re sync) But it may of been as a knock on effect of dl removing g.inp on the upstream, or the update pushed to the modem didn't work properly??

As for the fault if it got more pronounced and became more service affecting, causing deviations in SNR when the phone was in use, then if zen where not being co -operative i would move on to pulse 8 or AAISP  if only to get the fault fixed,

[tommy45]

as if VDSL is affected in a similar way to DSL then the upstream frequencies are nearest to the voice side of things and the upstream is more severely impacted ,

The first US band is right next to the voice band, there are others. Unlike ADSL, VDSL has several bands of US and DS and the bands alternate across the tone range (US/DS/US/DS etc).

If you have noises on QLT then you probably can raise a voice fault.

I'd agree possibly some kind of voice fault starting up - I had a HR fault so small affecting upstream, but it affected my line in terms of errors and noise, and by DLM intervening.

I would say your issues are nothing to do with DLM or G.INP and are either a line fault, or some form of external interference you can do nothing about.

I myself have learnt that if it isn't broken then don't fix it, my line and yours are both at full sync, and g.inp was removed from upstream, however I'm not experiencing any issues so I'm leaving it and getting on with things. A while ago I became obsessed with looking at stats all the time. Take the other guys advice here and just leave it for a week or so and see how its going then, if its a fault it may develop further, if not then its just the way it goes

"If it ain't broke,then don't try and fix it" It's BT who need to learn that lesson not me,  if G.inp is operating as intended  (in use with a compatible modem)  then why roll out something that breaks that advantage and could be seen as a case of one step forwards and 3 steps back ,
They should stop their meddling with stuff they know nothing about , it's why we will never have a roll out of FTTH/P on a national scale

[jid]

as if VDSL is affected in a similar way to DSL then the upstream frequencies are nearest to the voice side of things and the upstream is more severely impacted ,

The first US band is right next to the voice band, there are others. Unlike ADSL, VDSL has several bands of US and DS and the bands alternate across the tone range (US/DS/US/DS etc).

If you have noises on QLT then you probably can raise a voice fault.

I'd agree possibly some kind of voice fault starting up - I had a HR fault so small affecting upstream, but it affected my line in terms of errors and noise, and by DLM intervening.

I would say your issues are nothing to do with DLM or G.INP and are either a line fault, or some form of external interference you can do nothing about.

I myself have learnt that if it isn't broken then don't fix it, my line and yours are both at full sync, and g.inp was removed from upstream, however I'm not experiencing any issues so I'm leaving it and getting on with things. A while ago I became obsessed with looking at stats all the time. Take the other guys advice here and just leave it for a week or so and see how its going then, if its a fault it may develop further, if not then its just the way it goes

"If it ain't broke,then don't try and fix it" It's BT who need to learn that lesson not me,  if G.inp is operating as intended  (in use with a compatible modem)  then why roll out something that breaks that advantage and could be seen as a case of one step forwards and 3 steps back ,
They should stop their meddling with stuff they know nothing about , it's why we will never have a roll out of FTTH/P on a national scale

Removing the G.inp from your line likely isn't the cause of what you're seeing.

My line also had G.inp removed upstream and nothing on mine changed like yours did. Therefore I'd suggest it's something relating to a fault, interference - either external or internal, fault internal wiring, external wiring maybe weather related.

Sent from my Nexus 6 using Tapatalk

[tommy45]

 Well it looks like I'm not the only one to see a changes in the upstream following removal of G.inp on it   they are reporting a loss of around 1mbps of actual upstream sync, Which tallies with what I'm seeing even though my SNR is back to 15.1/2 my attainable used to be higher when on fastpath, which according to the stats  the upstream currently is fast path
 https://community.plus.net/forum/index.php?topic=136287.944

[burakkucat]

As for the fault if it got more pronounced and became more service affecting, causing deviations in SNR when the phone was in use, then if zen where not being co -operative i would move on to pulse 8 or AAISP  if only to get the fault fixed,

That is a very sensible plan of action.

[Dray]

To me the obvious problem is that with contractors doing the installs, and also with self-installs, there are many sub-optimal connections now. However, the good thing is that G.INP handles these problem connections well and gives a really good experience. But, as BT have had to remove G.INP on the upstream, these problem connections will once again become apparent.

[tommy45]

To me the obvious problem is that with contractors doing the installs, and also with self-installs, there are many sub-optimal connections now. However, the good thing is that G.INP handles these problem connections well and gives a really good experience. But, as BT have had to remove G.INP on the upstream, these problem connections will once again become apparent.

As will some other issues  no doubt, another point will be what sort of action has DLM been programmed to take ? will it just re enable G.inp on the upstream ,or will it bork things ?

[NewtronStar]

no doubt, another point will be what sort of action has DLM been programmed to take ? will it just re enable G.inp on the upstream ,or will it bork things ?

As a guess if the Upstream errors has gone above the the DLM threshold then an increase on INP  values will be introduced and with higher interleaving.

[tommy45]

That would = borking it imo when imo they should re-apply what is known to work well  and be acceptable to the EU (G.inp) Because then the EU would be in a very similar situation  to an EU that didn't have a G.inp compatible modem prior to the roll out that broke g.inp  i can see trouble ahead

[NewtronStar]

That would = borking it imo when imo they should re-apply what is known to work well  and be acceptable to the EU (G.inp)

Thats not going to happen unless the end-users can start a large 2nd campaign to there ISP's and tell them you lost sync and increased latency since the MKII G.INP was introduced on their lines and if there is enough complaints then OR will halt this rollout.

IMO it's rare to see Upstream errored seconds go  above the DLM threshold but it does happen especially when user has some kind of HR fault on the line, and the MKI G.INP enabled on the US it was masking a probable line fault brewing.