Kitz Forum
Broadband Related => FTTC and FTTP Issues => Topic started by: tommy45 on June 01, 2015, 10:10:50 PM
-
Well my connection went really haywire Both US/DS SNR taking a 1db nose dive and thousands of FEC errors and increased CRC's also it would appear that for the first time in the past 3 months since it was first rolled out G.inp is suddenly unable to correct some the errors, what a joke BT are, So what do i do, disconnect my modem again (just done so for 1 hr) and leave off overnight ? do i leave it on so the errors rack up ? Which will almost certainly lead to DLM breaking the connection further by it adding tones of interleave , what a load of BS this is, if i can't get this fixed by adding G.inp back to the upstream, or removing it altogether, i will cease the connection altogether, sell the pc and go to the pub and very very drunk
PS line rental & voice service would cease to
-
This what i would do turn off any stats software and don't run a speedtest or ping test for two weeks, you may have developed stats obsessive compulsive disorder and i am not joking.
Take your stats offline for a few weeks and just use the internet watch movies plays games and email and surf, there is more to life than line stats ;)
-
This what i would do turn off any stats software and don't run a speedtest or ping test for two weeks, you may have developed stats obsessive compulsive disorder and i am not joking.
Take your stats offline for a few weeks and just use the internet watch movies plays games and email and surf, there is more to life than line stats ;)
I don't want my connection broken further by DLM , when the fec errors are clocking up at the rate of 1000s per minute it's hard not to worry, I can't be doing with laggy connections , if it was a choice of only laggy or nothing then i would opt for nothing , no joking
-
I think you really need to take NS's advice. Thousands of FEC a minute is nothing! At work we've regularly have 600,000 FEC a minute and we all have no problem.
-
I too would heed NS and Ronski's advice. Get some fresh air. ;)
-
I took your advice but when i got home i find that my US SNR has crashed from a healthy 15.2 as it should be on fast path to 11db, and attainable rate has crashed too was nearly 30mbps now only 22mbps it's an effing joke this is,
Something is clearly wrong here just look at the variation in SNR that ain't normal it's either the way they have configured the profiile or it's a fault with the VDSL or line plant, which is convenient
-
I'm confused? You seem very upset, yet Your SNR is 11 against a target of 6, and your US sync is 20 against - well actually you are getting the maximum. What have you got to complain about? You are getting the highest speed offered, and despite you seeing changes in your stats that you can only see because you are looking, I doubt there is any perceivable change in your connection speed or quality?
Sent from my Lumia 1520 using Tapatalk (with free typos)
-
I would LOVE that line!
-
I'm confused? You seem very upset, yet Your SNR is 11 against a target of 6, and your US sync is 20 against - well actually you are getting the maximum. What have you got to complain about? You are getting the highest speed offered, and despite you seeing changes in your stats that you can only see because you are looking, I doubt there is any perceivable change in your connection speed or quality?
Sent from my Lumia 1520 using Tapatalk (with free typos)
So just because it was only spare noise margin and attainable rate that i have been robbed of ,that means it's ok ? I think not if i had of been just about able to get the full upstream rate and this had happened would it of still of been ok if my upstream sync dropped by 7mbps ? No it would not, you have to think about others who may be like me get hit in a similar way, first they roll-out G.INP that some of the supplied EU hardware is not compatible with , (did they not test this hardware to see if it would support G.inp vectoring ect)? then they instead of sorting the problem out by supplying new compatible EU hardware or offering an opt out of G.inp they devised a botch up fix that could have potentially broken even more EU's connections my circuit operated fine when it was g.inp enabled, why force a change to this that clearly doesn't work in the EU's interests ?
Also as a result of this i am more likely to loss the full sync rates thank't to the bludering BT, if i do i'm gone as said cease both voice and data or go back to ADSL2+ without any DLM on a LLU network screw bt
-
Perhaps the decrease in your upstream max attainable rate is due to increased UPBO for you, decreasing the excess upstream power output which won't matter since you're still getting the full speed, for the benefit of reducing crosstalk for other lines.
-
High FEC's counts are not always bad it's showing the forward error correction is working this won't effect your errored seconds.
To-day i have witnessed very large burst of FEC's errors on my line 1.5 million per minute from 11:00am to 18:48pm to-day don't know where this is coming from but the line is stable.
And a wee link is provided by myself it sometimes help when you see it in words
http://en.wikipedia.org/wiki/Forward_error_correction (http://en.wikipedia.org/wiki/Forward_error_correction)
-
tommy looks like new crosstalk rather than a DLM thing.
Neighbour near by probably got FTTC installed.
-
tommy looks like new crosstalk rather than a DLM thing.
Neighbour near by probably got FTTC installed.
Its rather odd to see it on the upstream only, but not impossible. The time ie 4:30pm doesnt look like anything DLM related and Ive never ever seen anything DLM related kick in the afternoon, nvm late afternoon. It would also usually mean a resync to change any config params which I cant see any of those either. I tend to agree with chrys in that under those circumstances it looks more like a crosstalker.
-
That's the easy get out ooh it's cross talk , i don't buy it, they remove g.inp from the us and a short time later i loose some attainable, just like those who lost when g.inp was roiled out first time , and they still haven't got it back
-
Ive just had a look at your config params in the other thread. Those presumably were at 1pm and before the changes at 4:30pm. If you want to post those again and we can compare if theres been any changes in the upstream config that could relate to the loss of upstream.
The figures I was looking at were
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
-
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 ,
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
-
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.
-
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.
-
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.
-
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 :)
-
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,
-
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
-
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
-
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 (https://community.plus.net/forum/index.php?topic=136287.944)
-
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.
-
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.
-
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 ?
-
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.
-
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
-
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.
-
I think due to the fact that since the beginning of the rollout they have been surprised at how many Homehubs and ECI modems weren't compatible. Then theres also the issue of the ECI cabs which dont appear to be able to do upstream either. Then choosing the most sensible path is to keep g.inp switched off for the upstream. SINET has always said that upstream is optional. They tried it and it caused too many issues for too many people so it makes sense that they dont apply it plus this way then its standardised for all and more compatible across all platforms.
The MkI system was a mess and caused large degredations in service so there was no way they could continue with the way things were. I think BT arent alone in this, when searching I found another foreign ISP who appeared to be having similar issues too. Cant recall who it was now, but the link is on these forums somewhere. Italy I think.
I seriously dont think your problem is anything to do with g.inp.... and if it is a fault materialising then regardless if you had g.inp or not before, then the line would still likely have further DLM intervention applied.
-
The thing is that G.INP can fix a lot of issues on upstream without having to resort to interleaving. Openreach should make it selectable by the end user - another thing for Sky to request and add to their fibre pro product perhaps?
-
What is specs of fiber pro as I remember it had some power user stuff because of EX BE users?
I am considering moving to sky.