Print

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

[Weaver]

I turned my three modems off the other day, because I was moving them to a new UPS. (ADSL1 20CN) I left them off for the recommended half an hour. When modem #2 came back on it racked up 800 errored seconds in about six hours and dramatic packet loss was crippling streaming video. The other two modems were fine. Andrews and Arnold's PPP LCP “ping”-like continuous line quality testing showed red on the troubled modem with LCP ping loss when there was a lot of downstream traffic.

The sad modem had been DS-syncing at 2272  for several days, at least, not sure how long. When it was turned back on, and went bad, it resumed at 2240. Any ideas as to why an off-on, with a slight _drop_ in ds sync rate, not an increase, should make things go so spectacularly bad?

The only thing I could think of was to turn it off and then _straight back on again_, in the hope that DLM would sort things out for me somehow. So that's what I did, a straight off-on, which cured the problem.

[Weaver]

has anyone else experienced this kind of thing, storm of errored seconds after modem has been off for an hour or so, when things were perfect before?

[kitzuser87430]

Yes I have experienced something similar.

My welder causes the adsl connection to go a little haywire, so i unplug the rj45 from the SSFP before I go to the workshop to weld.

On two separate occasions after i re insert the rj45 into the master socket, i have noticed a huge number of FEC's ....a reboot sorted it.

Ian

[Weaver]

@kitzuser87430 :-

clarification: I removed the power from my modem. You disconnected the DSL cable between the  master socket and modem.

I’m thinking about what happens when the modem loses its state.

What happens with the DSLAM’s memory of bits-to-bins allocation ?

[kitz]

What happens with the DSLAM’s have memory of bits-to-bins allocation ?

Only the modem has a record of bit allocation - it retains this in a bit allocation table (BAT).  The modem calculates the BAT depending upon the amount of available SNR at time of sync...  but the bit loading can vary depending on available SNRm in each tone and bitswap is an ongoing process.   

I think I mentioned in another thread just yesterday that there are occasions where a load of noise resulting in lots of bitswapping can take certain tones out of the BAT and the modem marks those frequencies as unusable..  If there has been lots of bitswap accross lots of tones, and several tones now unavailable then it can cause other tones to have less overhead to play with and generate lots of errors despite the SNR having recovered if the noise stops.   This is likely what will be happening with kitzusers welding equipment..   I think I also mentioned in the other thread that sometimes the router will start behaving erratically generating lots of errors due to too many tones being 'shut down'.  Usually the router will eventually perform a resync itself to get a fresh BAT, but sometimes the router hangs on so a manual resync is the way to go.


A resync will clear the BAT and a new one calculated as part of the 'exchange' * process during Initialisation and Synchronisation  * exchange = exchange of information not telephone exchange.

[Weaver]

That helpful post cleared my mind of an erroneous model of how state might persist, when its all fully calculated afresh independently at initialisation time.