Kitz ADSL Broadband Information
adsl spacer  
Support this site
Home Broadband ISPs Tech Routers Wiki Forum
 
     
   Compare ISP   Rate your ISP
   Glossary   Glossary
 
Please login or register.

Login with username, password and session length
Advanced search  

News:

Pages: 1 ... 10 11 [12] 13

Author Topic: Erratic line behaviour after remote resync  (Read 36389 times)

kitz

  • Administrator
  • Senior Kitizen
  • *
  • Posts: 33881
  • Trinity: Most guys do.
    • http://www.kitz.co.uk
Re: Erratic line behaviour after remote resync
« Reply #165 on: April 25, 2017, 01:24:01 AM »

Kitz welcome to Atmospheric line conditions where the SNRM lowers in the evening now all the engineers i've had say my pair balance is excellent via this JDSU but they have never hooked it up in the evening time when the SNRM drops cause the OR engineers don't attend a customers premises at 6pm to 10pm.

If they did they would see a big difference  ;)

Mine definitely isnt atmospheric.  It pulsates too regularly and can be very cyclic.  Its far more symptomatic of REIN/PEIN if anything.   
See sceencap below from DSLstats which may show a much clearer picture than on MDWS.

Also it doesnt cause the huge amounts of Err/Secs that occur in a massive block very suddenly.  Its some sort of massive noise burst introduced on to the line.  :(   What the cause of the noise is Ive no idea..  It could be from a high open, it could be REIN or it could be a faulty line card.
Logged
Please do not PM me with queries for broadband help as I may not be able to respond.
-----
How to get your router line stats :: ADSL Exchange Checker

Chrysalis

  • Content Team
  • Addicted Kitizen
  • *
  • Posts: 7382
  • VM Gig1 - AAISP L2TP
Re: Erratic line behaviour after remote resync
« Reply #166 on: April 25, 2017, 12:43:30 PM »

no worries kitz lets wait to see what sky say, here are my "theories" :) I have learnt to not insist I am right.

Bear in mind attainable should be based on the target snrm so the modem reports what it believes attainable should be based on the targer snrm which is circa 6.3db.  So during a power cut event the line still syncs at that snrm but when disturbers come online the actual snrm will drop to a lower number with the crosstalk but the attainable doesnt adjust for that.  This explains why my attainable is not a high number.
I agree the fact I have no access to live stats during the sync, not only due to the dslstats not tallying at that exact moment but also that most of my network equipment would be disconnected following the power cut, I actually had no access to stats for quite a while due to my pfsense unit issue.  However QLN is generated at the sync and doesnt update so I could still check the QLN data.
My line without any crosstalk should easily be able to get a 80mbit sync and should be able to get in excess of 100mbit as was the case when I first had FTTC, granted this is a different pair but this pair the characteristics actually are better than the original pair.

Now the 2 points you raised, the point of banding above what my line can achieve at 6.3db and the power levels?

The one purpose of banding the line the way they have done I expect is to prevent a line from syncing at a unstable rate following a power cut, the exact event that caused my line to sync so high, we know openreach have wide area event detections in place, so my theory is that somehow their systems can put it all together and determine that banding is beneficial, in which case I think DLM has actually done its job well, my line as it turned out did eventually have excessive errors at the 3db margin, after a second power cut its now synced at a more modest speed giving me around a 4.5db margin which should be more likely to not have the same problem.  This is of course assuming I am banded.

With the ECI power level issue, my only theory is that if they are actually reducing power output (and its not a reporting bug) then they have determined it reduces errors to prevent DLM interleaving lines and as such is beneficial.  Sync speed isnt everything, quality of service comes into play such as line stability and latency.  If they have been reducing levels, then hopefully they will revert it after g.inp is working.

:)
Logged

Chrysalis

  • Content Team
  • Addicted Kitizen
  • *
  • Posts: 7382
  • VM Gig1 - AAISP L2TP
Re: Erratic line behaviour after remote resync
« Reply #167 on: April 25, 2017, 12:53:36 PM »

Mine definitely isnt atmospheric.  It pulsates too regularly and can be very cyclic.  Its far more symptomatic of REIN/PEIN if anything.   
See sceencap below from DSLstats which may show a much clearer picture than on MDWS.

Also it doesnt cause the huge amounts of Err/Secs that occur in a massive block very suddenly.  Its some sort of massive noise burst introduced on to the line.  :(   What the cause of the noise is Ive no idea..  It could be from a high open, it could be REIN or it could be a faulty line card.

yeah that to me is electrical.

Ironically I found out by accident when I turned my pc speakers on last night a usb power hub (cheap china unbranded unit) was omitting interference, I unplugged it to fix the speakers and at the same time my snrm jumped 0.2db.

I expect your interference is very likely to be local, but pinning it down is hard, I know you have a thoery its could be ECI chipset related but I think its local REIN.
Logged

ejs

  • Kitizen
  • ****
  • Posts: 2078
Re: Erratic line behaviour after remote resync
« Reply #168 on: April 25, 2017, 02:43:59 PM »

So not only do we not have g.INP and no prospect of vectoring, now weve had our power cut back drastically for some obscure reason.
Go through the list on MDWS and look at power levels for the Huawei cabs and you will see they havent changed.   Then look at the figures for those on ECI's, we are only getting a fraction of the output power compared to what we used to get.

Isn't this merely buggy reporting, where it shows downstream transmit power equal to upstream transmit power? I thought this anomaly was spotted when the cabinet firmware changed from 0xb204 to 0xb206. The transmit power stats per band may look more likely to be accurate.
Logged

WWWombat

  • Kitizen
  • ****
  • Posts: 1674
Re: Erratic line behaviour after remote resync
« Reply #169 on: April 25, 2017, 02:52:35 PM »

It pulsates too regularly and can be very cyclic.  Its far more symptomatic of REIN/PEIN if anything.   
See sceencap below from DSLstats which may show a much clearer picture than on MDWS.

If that SNRM was a simple signal level, then I'd say it looks like an interference pattern or "beats" between two other signals, where the difference in frequency resulted in the period of 335 seconds - a difference of 0.003Hz.

BUT the single SNRM is, I guess, really a combination of SNRM across many tones. I wonder if you'd still see the same patterns that way?

Do you see much difference in the SNRM-per-tone graphs at the times of the peaks and troughs?
Logged

burakkucat

  • Respected
  • Senior Kitizen
  • *
  • Posts: 38300
  • Over the Rainbow Bridge
    • The ELRepo Project
Re: Erratic line behaviour after remote resync
« Reply #170 on: April 25, 2017, 05:15:28 PM »

Those of us who have studied the behaviour of Kitz' circuit in the past . . . before the "oscillations" . . . will recall that the SNRM plot would just show two "ruler-straight" lines with the occasional little "pip".

However (physical) things have now changed. The relevant PCP has been re-shelled and internally, what was an array of hooks, from which pairs of wires would hang (somewhat messily), has been replaced with Krone (or Krone-like) blocks (all neat and tidy) . . . without a break in service. The latter statement does not seem possible but it is the case. (It can be done with extra jumpering and implies that, for a time, there will be double jumpers linking the "left-hand side" with the "right-hand side".)

I attach, below, the last 24 hours SNRM plot from Kitz' circuit. Notice the difference from what I described, above? The two "ruler-straight" lines have now been replaced with those that show a 24 hour cyclical effect; the SNRM drops during the hours of darkness and then rises once again in daylight. And it is to that which I believe N*Star was referring with his "Kitz welcome to Atmospheric line conditions where the SNRM lowers in the evening . . ." statement.
« Last Edit: April 25, 2017, 06:12:14 PM by burakkucat »
Logged
:cat:  100% Linux and, previously, Unix. Co-founder of the ELRepo Project.

Please consider making a donation to support the running of this site.

kitz

  • Administrator
  • Senior Kitizen
  • *
  • Posts: 33881
  • Trinity: Most guys do.
    • http://www.kitz.co.uk
Re: Erratic line behaviour after remote resync
« Reply #171 on: April 25, 2017, 06:04:09 PM »

Quote
Bear in mind attainable should be based on the target snrm so the modem reports what it believes attainable should be based on the targer snrm which is circa 6.3db.  So during a power cut event the line still syncs at that snrm but when disturbers come online the actual snrm will drop to a lower number with the crosstalk but the attainable doesnt adjust for that.

It does. Its basic DSL theory that any changes to the SNRM is reflected in the max attainable.  We see evidence that the attainable rate mirrors the SNRM every day in MDWS.
 
Whilst not the best example I attach a copy of mine doing it this week.  Note Apr 20th 14:36 my SNRM spiked from 6.0 to 6.9dB as what looks typical of one of my disturbers rebooting their modem. At exactly the same time my max attainable rose from 81365 to 84779.  There are plenty of better examples - Erics line does it often as he usually comes back up before his disturbers.

To be strictly correct the calculation uses the real SNR, minus the SNRGAP ...  which is effectively the SNRM.

See screencap below from T-REC G.993.2 showing the formula for calculating the attainable. 
It uses the current SNR, the SNRGAP and the Target SNRM

Quote
My line without any crosstalk should easily be able to get a 80mbit sync and should be able to get in excess of 100mbit
So should mine, but it never-ever does any more, no matter how quick I come back up.  My max attainable used to be ~110 Mbps  :(

Quote
The one purpose of banding the line the way they have done I expect is to prevent a line from syncing at a unstable rate following a power cut, the exact event that caused my line to sync so high,

They have a param on the DSLAM which is supposed to do that - MAXSNRM - which should then adjust the power accordingly.
I'm not saying that you arent banded, just that it doesnt make sense for them to do this, nor can I see any firm evidence that you are.


Quote
Isn't this merely buggy reporting, where it shows downstream transmit power equal to upstream transmit power? I thought this anomaly was spotted when the cabinet firmware changed from 0xb204 to 0xb206.

Thank you.  I must have missed that.  I only noticed it fairly recently and meant to make a separate post querying this, but never got around to it.  I shall have a look at the individual bands later.

ETA
Forgot to add attachments.
« Last Edit: April 25, 2017, 06:57:42 PM by kitz »
Logged
Please do not PM me with queries for broadband help as I may not be able to respond.
-----
How to get your router line stats :: ADSL Exchange Checker

kitz

  • Administrator
  • Senior Kitizen
  • *
  • Posts: 33881
  • Trinity: Most guys do.
    • http://www.kitz.co.uk
Re: Erratic line behaviour after remote resync
« Reply #172 on: April 25, 2017, 06:18:51 PM »

If that SNRM was a simple signal level, then I'd say it looks like an interference pattern or "beats" between two other signals, where the difference in frequency resulted in the period of 335 seconds - a difference of 0.003Hz.

BUT the single SNRM is, I guess, really a combination of SNRM across many tones. I wonder if you'd still see the same patterns that way?

Do you see much difference in the SNRM-per-tone graphs at the times of the peaks and troughs?

Already been there.  It appears to affect U2, D1, D2, D3.   See attached graphs below from when I was doing the intensive logging and it shows up very clearly.    I pondered in an earlier thread why D1 is affected, being smack bang in the middle of U0 & U1 which arent.  The only possible difference I can think is U0 & U1 have PCB and PSD masking, but how that should effect Ive no idea.  The cycles were exactly every 5 mins 35 seconds.

U0 does sometimes get affected.  U1 is hardly ever affected. U2 always shows the most extreme effects 
D1,D2,D3 are almost always equally affected.
Logged
Please do not PM me with queries for broadband help as I may not be able to respond.
-----
How to get your router line stats :: ADSL Exchange Checker

ejs

  • Kitizen
  • ****
  • Posts: 2078
Re: Erratic line behaviour after remote resync
« Reply #173 on: April 25, 2017, 06:31:23 PM »

See screencap below from T-REC G.993.2 showing the formula for calculating the attainable. 
It uses the current SNR, the SNRGAP and the Target SNRM
I think I know what the screencap is, although it hasn't actually appeared at the time of me writing this, please read the paragraph preceding that formula in the G.993.2 document. That formula is an alternative, simplified method for calculating the ATTNDR during loop diagnostic mode. That formula won't be used when in the normal "showtime" state.

They have a param on the DSLAM which is supposed to do that - MAXSNRM - which should then adjust the power accordingly.
Any MAXSNRM parameter would only do anything if the SNRM would be above it, which generally would imply that the line bandwidth had already reached the rate cap. The rate cap would still very much be needed first.
Logged

kitz

  • Administrator
  • Senior Kitizen
  • *
  • Posts: 33881
  • Trinity: Most guys do.
    • http://www.kitz.co.uk
Re: Erratic line behaviour after remote resync
« Reply #174 on: April 25, 2017, 06:33:23 PM »

yeah that to me is electrical.

Ironically I found out by accident when I turned my pc speakers on last night a usb power hub (cheap china unbranded unit) was omitting interference, I unplugged it to fix the speakers and at the same time my snrm jumped 0.2db.

I expect your interference is very likely to be local, but pinning it down is hard, I know you have a thoery its could be ECI chipset related but I think its local REIN.

Ive said from the start it looks very REIN /PEIN like.   I cant recall ever saying its anything to do with the ECI chipsets.  :no:  There have been a couple of others on ECI cabs may have said they are seeing similar to me.   
I have said as an alternative theory, that the only time I have seen in the past something similar which was when there were a batch of faulty line cards.  It was years ago though and unfortunately now I cant recall which manufacturer line cards they were.   If Azzaka from Zen is around he will remember for sure.   There were a lot of people getting REIN like symptoms that were resolved when transferred to another port on the DSLAM.   
Logged
Please do not PM me with queries for broadband help as I may not be able to respond.
-----
How to get your router line stats :: ADSL Exchange Checker

burakkucat

  • Respected
  • Senior Kitizen
  • *
  • Posts: 38300
  • Over the Rainbow Bridge
    • The ELRepo Project
Re: Erratic line behaviour after remote resync
« Reply #175 on: April 25, 2017, 06:34:20 PM »

If that SNRM was a simple signal level, then I'd say it looks like an interference pattern or "beats" between two other signals, where the difference in frequency resulted in the period of 335 seconds - a difference of 0.003Hz.

I wonder if it could be the result of an overloaded amplifer input stage due to a defect in an AGC circuit failing to stabilise the overall gain. Or something similar. (Whatever any of that may mean . . .)  :-\
Logged
:cat:  100% Linux and, previously, Unix. Co-founder of the ELRepo Project.

Please consider making a donation to support the running of this site.

kitz

  • Administrator
  • Senior Kitizen
  • *
  • Posts: 33881
  • Trinity: Most guys do.
    • http://www.kitz.co.uk
Re: Erratic line behaviour after remote resync
« Reply #176 on: April 25, 2017, 06:52:34 PM »

I think I know what the screencap is, although it hasn't actually appeared at the time of me writing this, please read the paragraph preceding that formula in the G.993.2 document. That formula is an alternative, simplified method for calculating the ATTNDR during loop diagnostic mode. That formula won't be used when in the normal "showtime" state.
Any MAXSNRM parameter would only do anything if the SNRM would be above it, which generally would imply that the line bandwidth had already reached the rate cap. The rate cap would still very much be needed first.

Are you therefore saying that attainable doesnt move when the SNRM does.  Because this is contary to everything we have ever seen. Attainable does adjust in line with the SNRM both when disturbers come on and offline.

Do you see any evidence that Chrys's line is banded or could be syncing higher? Why would DLM apply banding without first ever applying INP first.  It does not make sense nor follow anything we do know about DLM.


Sorry I forgot to add the screen caps - will do so in a mo.   Whilst the ATTNDR is calculated during loop diagnostic mode... it also says.

Quote
The attainable net data rate shall be calculated by the receive PMS-TC and PMD functions during
loop diagnostic mode and initialization. The measurement may be updated autonomously and shall
be updated on request during showtime. The attainable net data rate shall be sent to the far-end VME
during loop diagnostic mode and shall be sent on request to the near-end VME at any time. The
near-end VME shall send the ATTNDR to the far-end VME on request during showtime.
Logged
Please do not PM me with queries for broadband help as I may not be able to respond.
-----
How to get your router line stats :: ADSL Exchange Checker

ejs

  • Kitizen
  • ****
  • Posts: 2078
Re: Erratic line behaviour after remote resync
« Reply #177 on: April 25, 2017, 07:34:23 PM »

Are you therefore saying that attainable doesnt move when the SNRM does.  Because this is contary to everything we have ever seen. Attainable does adjust in line with the SNRM both when disturbers come on and offline.
No, I am saying that the actual ATTNDR calculation is going to be more complicated than that formula. Of course the ATTNDR varies with the SNRM.

Do you see any evidence that Chrys's line is banded or could be syncing higher? Why would DLM apply banding without first ever applying INP first.  It does not make sense nor follow anything we do know about DLM.
I took the decision to not register with MDWS, so I don't see any evidence because I'm not looking at anything. It's a shame there aren't more devices like the FritzBoxes which prominently report the rate caps, then there would be less guessing. However, the DLM applying banding without INP is akin to increasing the SNRM, still without INP. So I suppose it depends on what the DLM is trying to protect against. If the DLM is trying to increase resilience against sources of constant noise, then it might increase the target SNRM, or cap the rate, which both achieve the same result. Alternatively, if it's trying to protect against pulsed noise sources, either isolated pulses, or repetitive (REIN), then it could set INP. Also, it wouldn't surprise me if BT try to avoid any form of INP to avoid the equipment using slightly more electricity from doing all that extra processing.
Logged

Chrysalis

  • Content Team
  • Addicted Kitizen
  • *
  • Posts: 7382
  • VM Gig1 - AAISP L2TP
Re: Erratic line behaviour after remote resync
« Reply #178 on: April 25, 2017, 10:23:53 PM »

attainable moves with snrm but i didnt reply before as i think may be a misunderstanding, given i currently have a 4.5 db snrm it is expected to see a lower attainable than my current sync and my existing crosstalk levels mean we cannot see what the crosstalk free attainable is
Logged

NewtronStar

  • Kitizen
  • ****
  • Posts: 4898
Re: Erratic line behaviour after remote resync
« Reply #179 on: April 26, 2017, 12:40:47 AM »

Chry if you do a manual resync of the modem what does your SNRM show after it ?
Logged
Pages: 1 ... 10 11 [12] 13