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:

Author Topic: 're-sync' event timeline and initiation  (Read 2148 times)

MollyCoddle

  • Member
  • **
  • Posts: 65
're-sync' event timeline and initiation
« on: March 04, 2009, 05:26:21 PM »

I am attempting to understand the decision and timing processes around a re-sync event. At this stage I want to ignore the possible causes of errors so that I can concerntrate on the event itself

Am I right in assuming  basically, that errors reach a threshold determined by some ADSL standards definition, this being moitored by the user end router, which decides to send a disconnect instruction to the BT network.

I would appreciate a more technical reference as this assumtion is the only way to understand the claims of my ISP, i.e. my router is issuing a disconnect 'packet' which is logged on their servers as a 'User requested' disconnection. Yet they do not appear to see the same when I power cycle the router!!!!!!

Thanks in advance,  MC
Logged

waltergmw

  • Content Team
  • Kitizen
  • *
  • Posts: 2765
Re: 're-sync' event timeline and initiation
« Reply #1 on: March 04, 2009, 06:04:45 PM »

Hi MC,

You might like to look at nasty problem I've been chasing since December at:-

http://forum.kitz.co.uk/index.php?topic=4399.15

The bottom of the first page shows how the bRAS rate changes with each incident.

The second page shows a picture of a "noise storm" which did disconnect and resynced. It also caused the bRAS to drop to 500 but I happened to be monitoring the situation and re-synced the modem manually and got back to 2,000 kbps.
Murphy has struck in that the line stabilised and has stayed in a good condition since then.

Kind regards,
Walter
Logged

MollyCoddle

  • Member
  • **
  • Posts: 65
Re: 're-sync' event timeline and initiation
« Reply #2 on: March 04, 2009, 06:43:23 PM »

@waltergmw
If nothing else, I am impressed with the involvement of your ISP in the thread. I have never heard an ISP talk of or understand e-side/d-side.

I'll monitor that thread with interest.

I would still like to get to grips with a deeper technical understanding, if possible, of what protol messages are sent and by what during a re-sync event.

MC
Logged

waltergmw

  • Content Team
  • Kitizen
  • *
  • Posts: 2765
Re: 're-sync' event timeline and initiation
« Reply #3 on: March 04, 2009, 07:35:09 PM »

@MC

Might I just whisper the splendid Z word !

I hope Kitz might add another section to her remarkably clear and consise treatise on DSL technology for the masses.

Kind regards,
Walter
Logged

kitz

  • Administrator
  • Senior Kitizen
  • *
  • Posts: 31911
  • Trinity: Most guys do.
    • http://www.kitz.co.uk
Re: 're-sync' event timeline and initiation
« Reply #4 on: March 05, 2009, 01:09:29 AM »

>>  would still like to get to grips with a deeper technical understanding, if possible, of what protol messages are sent and by what during a re-sync event.

>> I hope Kitz might add another section to her remarkably clear and consise treatise on DSL technology for the masses.


I'm afraid I cant do an in-depth on it,  despite having tried to find information about this in the past myself, there doesnt seem to be anything that describes it, even in technical type journals.  This may partially be down to certain events such as the DLM process being patented and certain info not being disclosed and also the fact that different routers can behave differently.

I wont put anything up on the main site until Im pretty sure of my facts, but as some of you know I do quite often theorise on the forums as long as the info isn't going to be taken as gospel.
There wont be any protocols as such.... and a loss of sync event event (not to be confused with a LoS - Loss of Signal)  will likely be down to a couple of different factors:

1) Bitswapping.

With the rate adaptive products used on LLU and Maxdsl, then bit swapping will/can have an effect on what goes on.  The bit swapping process on rADSL plays a big part in keeping your line connected.  If the SNR in a particular channel gets too low, bit swapping enables the line to remain connected by shifting things around so that the line can cope with a certain amount of noise. Problem with bitswapping is that once a router has marked a channel as unavailable then until you do a full resync those channels may not be usable again and the only way round getting a higher sync again is to perform a full resync. 

When there are insufficient usable sub channels to carry the amount of bits needed for your sync speed and there's insufficient SNR 'overhead' to swap the bits around, then your line will have to drop sync.

I'm ignoring Seamless Rate Adaption at this point because currently afaik there's only UKO in the UK that uses this technology.

2) Error Rate and Alarm State

This is where my knowledge gets flaky as there's not much info....  but here goes...
We are probably all familiar with CRC/HEC/FEC type errors we often see on our routers, but these are just the start of things.  Although CRC/HECs are errors, there's also many different states that are recorded but not necessarily displayed by all routers. Its these error - or more correctly - alarm states that can cause a line to resync.  Theres several different types of alarm states, a serious one is a LoS.. but there's other serious ones such as a UAS.  When the router enters into an alarm state it will monitor the type of error for 'x' amount of time and if there are 'y' amount of incidents during that time frame then the router will attempt a resync.  However if during the 'x' period, no further error state occur over 'z' period of time, then the line will recover.

'x', 'y' & 'z' could vary from different router manufacturers, but I shouldn't imagine it wouldn't be by much.

The alarm states are described on my page - Router Line Stats - Errors.
Have a look for eg at LoF and LoS.
If you have a bit of time to read the different error states you may be able to track a process through those.


----------

OK you now have what I know...  so try piecing it all together and you will see that the Alarm States and Error Rates also plays a big part of this process, then combine this info with bit-swapping  and see if you can come to any conclusion about what goes on.

Its probably easier to stick with what we do know and say resync will occur when theres insufficient SNR for bitswapping to occur and/or when the error rate gets too high... as thats all that most people normally need to know. :D
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
 

anything