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] 2

Author Topic: horrible burst of errors then capped and strange stats  (Read 6669 times)

les-70

  • Kitizen
  • ****
  • Posts: 1254
horrible burst of errors then capped and strange stats
« on: May 10, 2014, 05:05:04 PM »

Had a gigantic burst of errors last night.  13000 crc in minute.   Today I notice that I am capped and interleaved.  Seems fair enough but the DLM might have been kind enough to wait to see if it happened again.  What puzzles me are the stats and bit loading.  The snr downstream is only 6.4.  With the attainable at 81864 I would have expected a value about 3db higher. e,g 9-10. Is this a strange or normal?

Below are the bit loadings and day or so before with a 64Mb/s self cap and those now with the DLM imposed cap of 68Mb/s The bit loadings with the DLM 68mb/s cap look rather like an 80mb/s sync bit loadings.   Again is this normal or odd? The value of snr (6.4) suggests a 80Mb/s  sync?   it certainly is all odd to me  ??? .

 new stats are

xdslcmd info --stats
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason:   0
Last initialization procedure status:   0
Max:   Upstream rate = 21604 Kbps, Downstream rate = 81864 Kbps
Bearer:   0, Upstream rate = 20000 Kbps, Downstream rate = 68901 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):    6.4       6.0
Attn(dB):    17.4       0.0
Pwr(dBm):    13.2       6.8

   the bit loadins are: 


   
« Last Edit: May 10, 2014, 05:10:39 PM by les-70 »
Logged

les-70

  • Kitizen
  • ****
  • Posts: 1254
Re: horrible burst of errors then capped and strange stats
« Reply #1 on: May 10, 2014, 06:13:33 PM »

  As an interim answer to myself -- I think I need to do some reading on interleaving and INP.   I am afraid that having never having been interleaved before I not taken too much notice of that subject. 
Logged

kitz

  • Administrator
  • Senior Kitizen
  • *
  • Posts: 33879
  • Trinity: Most guys do.
    • http://www.kitz.co.uk
Re: horrible burst of errors then capped and strange stats
« Reply #2 on: May 10, 2014, 06:19:35 PM »

Quote
Had a gigantic burst of errors last night.  13000 crc in minute.   Today I notice that I am capped and interleaved.  Seems fair enough but the DLM might have been kind enough to wait to see if it happened again.

:( Seems a bit harsh if it was a one off.
The timing of you putting the new router though wasnt good either.   BToR in its infinite wisdom counts all resyncs as bad regardless or not if they were intended.  I wish they would make use of the dying gasp.. its documented that they dont and no allowance is made for if the resync was due to the EU or due to LoS :(


Quote
With the attainable at 81864 I would have expected a value about 3db higher.

hmmmm how strange - I agree.   Normally the additional SNR over the target margin is used to calculate the max.
Im as puzzled as you are.  The only other possible place where that additional reserve could be hiding is overheads for interleaving.


----

Warning - while you were reading a new reply has been posted. You may wish to review your post.
- I see you have now also mentioned interleaving yourself, but I'll leave my post above as was.
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: horrible burst of errors then capped and strange stats
« Reply #3 on: May 10, 2014, 07:00:44 PM »

I wish they would make use of the dying gasp.. its documented that they dont <snip>

Do you have a link or other details for that document, please?  :)
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: 33879
  • Trinity: Most guys do.
    • http://www.kitz.co.uk
Re: horrible burst of errors then capped and strange stats
« Reply #4 on: May 10, 2014, 07:22:11 PM »

eke...  I will try find it for you.   iirc its buried somewhere in one of BTs patent documents and not on their site.
It was discovered when we were talking about the differences between the BToR and BTw DLM.   I think it may have been 7LM that found it originally.
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: 33879
  • Trinity: Most guys do.
    • http://www.kitz.co.uk
Re: horrible burst of errors then capped and strange stats
« Reply #5 on: May 10, 2014, 08:14:50 PM »

ok I think this is the one.   It took me ages to find it, as I kept finding the earlier BTw one first. 
Im now running really quite late and I dont have time to double check and read through..   but I think this is the info you need.

https://www.google.com/patents/US20130201836?dq=ininventor:%22Christopher+Marcus+Croot%22&hl=en&sa=X&ei=BmcuUpjaDIOGhQeX24HABw&ved=0CDoQ6AEwATgK

Quote
for the most aggressive stability level the DLM function attempts to keep sync losses to below 12 per 24-hour period (including switching off modems/routers which count as a sync loss) and to keep the line error-free for 98.3% (59/60 seconds) of active uptime measured over a 24-hour period;
for the normal stability level the DLM function attempts to keep sync losses to below 6 per 24-hour period and to keep the line error-free for 99.8% (599/600 seconds) of active uptime measured over a 24-hour period;
and for the stable stability level the DLM function attempts to keep sync losses to below 3 per 24-hour period and to keep the line error-free more than 99.98% (5999/6000 seconds) of active uptime measured over a 24-hour period.


---
Added link
« Last Edit: May 10, 2014, 08:17:50 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

burakkucat

  • Respected
  • Senior Kitizen
  • *
  • Posts: 38300
  • Over the Rainbow Bridge
    • The ELRepo Project
Re: horrible burst of errors then capped and strange stats
« Reply #6 on: May 10, 2014, 10:56:29 PM »

Thank you.  :)  That url (https://www.google.com/patents/US20130201836) allowed me to download a copy of the original document as a PDF file. On attempting to read it my eyes went out of focus and a cat-nap prevailed!

To be honest, I do not see any mention that a modem's "dying gasp" is ignored. Turning off the CPE obviously results in a loss of synchronisation with the DSLAM/MSAN and I cannot see any reason why that event should not be counted.

I seem to recall some experiments that asbokid performed --
  • Severing the link between the CPE and DSLAM (as might be caused by "Sean O'Hoolihan" and his mechanical excavator) results in a loss of synchronisation event being recorded and the error second counter continuing to increment (along with all the other relevant error counters).
  • Powering down the CPE (which sends a "dying gasp") results in a loss of synchronisation event only being recorded. The error second counter, etc, is not incremented.
Section 0105 reads, in full --

Quote
[0105] In an alternative embodiment, the stability levels could operate such that for the most aggressive stability level the DLM function attempts to keep sync losses to below 12 per 24-hour period (including switching off modems/routers which count as a sync loss) and to keep the line error-free for 98.3% (59/60 seconds) of active uptime measured over a 24-hour period; for the normal stability level the DLM function attempts to keep sync losses to below 6 per 24-hour period and to keep the line error-free for 99.8% (599/600 seconds) of active uptime measured over a 24-hour period; and for the stable stability level the DLM function attempts to keep sync losses to below 3 per 24-hour period and to keep the line error-free more than 99.98% (5999/6000 seconds) of active uptime measured over a 24-hour period.

In other words, it sets out what could happen in an alternative embodiment . . .

Finally I not convinced that patent describes the DLM process as used by Openreach for its GEA-FTTC VDSL2 links.
« Last Edit: May 10, 2014, 10:58:55 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.

les-70

  • Kitizen
  • ****
  • Posts: 1254
Re: horrible burst of errors then capped and strange stats
« Reply #7 on: May 11, 2014, 09:46:19 AM »

   I was trying to avoid the DLM  by capping my speed.  The error burst came while the ZyXel VMG8324-B10A was connected with an uncapped sync close to 80Mb/s.  I have gone back to the HG612 for the moment to avoid too many variables at once. 

  I am now back to capping my speed at 64mb/s so as to ensure immunity from the big attainable drops on my line when others power up their modems. Currently this is giving me a 7.8db SNR downstream, if it goes back to fast path it will about 11db SNR.  I hope this is the best thing to do as I don't like any unexpected losses of sync and I wonder just what response the DLM would have in mind if left to its own devices in the face of the  6db drops in SNR that my line gets.
« Last Edit: May 11, 2014, 12:51:25 PM by les-70 »
Logged

les-70

  • Kitizen
  • ****
  • Posts: 1254
Re: horrible burst of errors then capped and strange stats
« Reply #8 on: May 12, 2014, 07:20:00 PM »

  Well after 48 hours of use I must say that as the 15ms addition to pings does not seem noticeable for my use the interleaving seems to make better use of the the bits per tone than a speed reduction on fast path.

 i.e if I were to cap to speeds to 69Mb/s on fast path I would expect a SNRM of about 8.5 and about 10ES per hour and roughly twice as many crc.  With the interleaving the sync is 69Mb/s  and SNRM is 6.2 but there has been a permanent zero ES.  I am more sympathetic to its use even if I think it imposed prematurely.
Logged

NewtronStar

  • Kitizen
  • ****
  • Posts: 4898
Re: horrible burst of errors then capped and strange stats
« Reply #9 on: May 12, 2014, 07:51:50 PM »

I think any High CRC or FEC bursts of errors in the of space of 15-30 minutes will be seen and be recorded by the DLM an then the DLM will act on line by whats called a retrain in the wee small hours, that could be 23.30 hours after the event had occured (bursts of errors), the next stage is harder to predict but it does seem upto 14 days is the minium  :( 
Logged

sevenlayermuddle

  • Helpful
  • Addicted Kitizen
  • *
  • Posts: 5369
Re: horrible burst of errors then capped and strange stats
« Reply #10 on: May 12, 2014, 09:55:10 PM »


It was discovered when we were talking about the differences between the BToR and BTw DLM.   I think it may have been 7LM that found it originally.

Sorry, just noticed this.  I certainly did post links to a couple of BT DLM patents in the dim & distant past.

I also vaguely recall a few discussions in which I participated, and that surmised BT's DLM probably ignored dying gasps, but I'm afraid I don't remember any hard evidence...  Possible of course that I have just forgotten.   ???
Logged

kitz

  • Administrator
  • Senior Kitizen
  • *
  • Posts: 33879
  • Trinity: Most guys do.
    • http://www.kitz.co.uk
Re: horrible burst of errors then capped and strange stats
« Reply #11 on: May 13, 2014, 09:29:31 AM »

Cant respond to this properly atm since I have a king size bed on its side obstructing my way to certain rooms and its manic this week trying to finish everything before the carpet fitters arrive on Fri...   so I really cant go searching for docs and linking to them.  I was pushed for time on sat to find the one I did and perhaps it was the wrong one - they take a heck of a lot of reading through and there are several that are similar at first glance.

But I do know for sure that 7LM found one of the patents, then I later found another one that without doubt mentioned FTTC and how the DLM worked with the what they called the minidslams in the cabs and hooked up to the legacy data collectors for RAMBO and the DLM system. (there was a diagram showing the dslams in the cabs) There were some algorithms that mentioned MTBE and MTBR both of these were confirmed to be in use by Plusnet last year as part of how the existing DLM worked.

Whilst I am fully aware of the dying gasp which Ive have been preaching about it since about 2005/2006 when I first did the DLM stuff.  If you search back in history to 2006,  there will be many a post by me telling people how to power down to trigger a dying gasp.  I also have no absolutely no doubt that the Huawei DSLAMs may be able to recognise the dying gasp messages.  The question here though is that the BTw DLM system doesnt now seem to be using this method. 

However I do seem to recall reading that the very first methods of detecting EU power downs - v - instability retrains proved unsatisfactory for various reasons and there was even discussion at one point about using power states (ie detecting when a router goes into low power mode)..  however, BT in its infinite wisdom decided to come up with their own version of DLM using the 15 mins blocks to detect user inactivity and also factor errors into the DLM MTBE algorithms (something which the earlier system didnt do either).

Although the FTTC DLM may factor different methods of application for when a line is classified as instable to the WBC DLM.   The BTw DLM does allow for this and you can set different profiles..   From observations and discussions in another thread on here, it was deemed that the BToR DLM preferred banding over SNRm configurations and iirc, then one of the documents did mention that these sort of configurations were allowed.
There is mention in one of the BT SINs (again cant recall which one) saying that an ISP can specify their own parameters if they so wished...  now Im guessing at this, but I'd say BToR have probably taken this option and set their own profiles by using the 'SP specific custom option'.   More musing but if they have taken this option then it could be the reason why ISPs themselves have a hard time trying to get any profile changes reset themselves and why its such a performance to get BT to make any changes with the FTTC profiles.
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

les-70

  • Kitizen
  • ****
  • Posts: 1254
Re: horrible burst of errors then capped and strange stats
« Reply #12 on: May 15, 2014, 07:51:38 AM »

  The DLM has been responsive.  On day 4 upstream interleaving was removed and now on day 5, I am fully back on fast path.  I guess there is some luck in all this unless unless the DLM has a memory that is saying that the connection was not bad apart from one bad day.  Some angle-grinder activity by a neighbor is the suspect cause of the bad day.
Logged

les-70

  • Kitizen
  • ****
  • Posts: 1254
Re: horrible burst of errors then capped and strange stats
« Reply #13 on: May 15, 2014, 06:23:16 PM »

 Does anyone understand why there seems to be a difference between the max attainable values on fast path and interleaved (INP=3.5).

 On fast path I had an attainable ~78Mb/s and sync ~77Mb/s, with SNR 6.3.  With the switch to interleaving it became an attainable of 83Mb/s and a sync of 69mb/s with SNR 6.4.  The bit loading in the states looked pretty much the same showing the interleaving using more bit loading for the same about of speed.  On returning to fast path the stats are now back to prior values.

 I think I understand all the values except the significance, if any, of the change in attainable from 78 to 83.  Maybe it is just a quirk of how the values are estimated in the two states?
Logged

Chrysalis

  • Content Team
  • Addicted Kitizen
  • *
  • Posts: 7382
  • VM Gig1 - AAISP L2TP
Re: horrible burst of errors then capped and strange stats
« Reply #14 on: May 20, 2014, 06:16:42 PM »

The reason your sync speed was lower was due to FEC overheads, even with same bitloading.
Logged
Pages: [1] 2