Print

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

[Chrysalis]

So was a 2 hour storm here earlier, I didnt think to turn of the modem.

I accrued a fair whack of ES, MDWS shows a red light but as far as I know I havent breached the threshold for action which should be 2880 ES/day.

Has this threshold been confirmed to have changed?

[tbailey2]

So was a 2 hour storm here earlier, I didnt think to turn of the modem.

I accrued a fair whack of ES, MDWS shows a red light but as far as I know I havent breached the threshold for action which should be 2880 ES/day.

Has this threshold been confirmed to have changed?

The red light I see here (at bottom) for you is for the Stable profile, not the Speed profile you should be on (the top one).

I believe the DLM is programmed to recognise events like thunderstorms anyway and would ignore widespread spikes like this.

From a previous post:

Speed in excess of 2880 ES/Hr for action both up and down
Standard 1440
Stable 720

[Chrysalis]

tony ok thanks.

regarding the sky dlm info I just been reading the sky fiber pro forum.

Seems sky use the stable profile but they are letting pro customers request profile changes manually whilst waiting for the automated control panel system.

so you can add to tooltip sky stable.

Also they confirmed dlm is reset when the profile changes.  The sky pro staff dont seem scared to say bad things about openreach, fair few interesting posts there.

[Ronski]

We had a thunderstorm at midnight, and looking on the graphs  I can see a big spike in the error seconds at midnight.

[Bald_Eagle1]

We also had thunderstorms overnight.

This was the result:-

04/07/2015 02:36 - RESYNC detected (DS 20891 Kbps, US 3866 Kbps), AS = 10, Retrain Reason: 1
04/07/2015 02:50 - RESYNC detected (DS 21245 Kbps, US 3880 Kbps), AS = 4, Retrain Reason: 1
04/07/2015 02:54 - RESYNC detected (DS 20904 Kbps, US 3869 Kbps), AS = 4, Retrain Reason: 1
04/07/2015 03:00 - RESYNC detected (DS 20900 Kbps, US 3844 Kbps), AS = 20, Retrain Reason: 1


An ongoing montage for a 3 hour period that includes those resyncs is attached for information.

[kitz]

I note Errored seconds for my line has increased over the past few days purely due to electric storms and a few spikes in the evenings.

Thunderstorms should be detected as a Wide Area Event so any resyncs or E/Secs caused during that 15min period should be disregarded by DLM

The link explains it in more detail, but (the last known) algorithm is

>20% of users with uptime experienced a resync OR 
>50% of users with uptime experiencing errors && >10% of users with uptime experienced a resync.

The first one is designed to catch localised power cuts
The second one designed to catch thunderstorm events.

[Bald_Eagle1]

Well, my connection really doesn't like the recent thunderstorms:-

01/07/2015 22:53 - RESYNC detected (DS 18724 Kbps, US 3742 Kbps), AS = 36, Retrain Reason: 1  - Thunderstorm
01/07/2015 22:57 - RESYNC detected (DS 19573 Kbps, US 3757 Kbps), AS = 52, Retrain Reason: 1  - Thunderstorm
02/07/2015 01:41 - RESYNC detected (DS 21011 Kbps, US 3815 Kbps), AS = 8, Retrain Reason: 0   - Manually initiated
04/07/2015 02:36 - RESYNC detected (DS 20891 Kbps, US 3866 Kbps), AS = 10, Retrain Reason: 1  - Thunderstorm
04/07/2015 02:50 - RESYNC detected (DS 21245 Kbps, US 3880 Kbps), AS = 4, Retrain Reason: 1   - Thunderstorm
04/07/2015 02:54 - RESYNC detected (DS 20904 Kbps, US 3869 Kbps), AS = 4, Retrain Reason: 1   - Thunderstorm
04/07/2015 03:00 - RESYNC detected (DS 20900 Kbps, US 3844 Kbps), AS = 20, Retrain Reason: 1  - Thunderstorm
04/07/2015 19:48 - RESYNC detected (DS 21252 Kbps, US 3789 Kbps), AS = 590, Retrain Reason: 0 - Manually initiated
05/07/2015 15:44 - RESYNC detected (DS 20966 Kbps, US 3800 Kbps), AS = 31, Retrain Reason: 1  - Thunderstorm
05/07/2015 16:19 - RESYNC detected (DS 20685 Kbps, US 3822 Kbps), AS = 39, Retrain Reason: 1  - Thunderstorm

[Chrysalis]

thanks kitz for the info and indeed my line hasnt had a DLM change but I was under the ES threshold anyway.

Is the wide area event exception also on standard and stable profiles?

[Chrysalis]

interesting BE even with g.inp the line seems no more resistant to loss of syncs, my line held out on plain fast path.

[Bald_Eagle1]

I think it would be fair to say that thunder/lightning are probably special cases that tend to seriously affect quite a few connections at the same time or that the 40 m or so of drop wire leading to my house is particularly susceptible.


As an aside, these thunderstorm resyncs are different to local power cut resyncs for 2 reasons:-

* They are reason 1, very quick resyncs whereas power cut resyncs are somewhat slower, full modem boot ups (Reason 0).
* Unlike Reason 0 power cut resyncs, these Reason 1 resyncs do not result in temporarily significantly higher attainable rates.

[kitz]

Is the wide area event exception also on standard and stable profiles?

Its applicable to all profiles.

[kitz]

interesting BE even with g.inp the line seems no more resistant to loss of syncs, my line held out on plain fast path.

G.INP is good for only certain types of noise - it works well for REIN type of noise but not so good when it comes to SHINE. There is a comparison here of noise types. 

G.INP isn't able to give much protection for the type of noise from electric storms.  In fact G.INP isn't the bee-all and end-all and can actually make some lines worse (source ASSIA) 

In fairness to BT I actually think their DLM system of monitoring for wide area events is better than the traditional method of using dying gasp.  OK it may catch out the odd person who is messing with their router, but should be much better when it comes to the likes of storms and local power cuts.

[kitz]

I think it would be fair to say that thunder/lightning are probably special cases that tend to seriously affect quite a few connections at the same time or that the 40 m or so of drop wire leading to my house is particularly susceptible.


As an aside, these thunderstorm resyncs are different to local power cut resyncs for 2 reasons:-

* They are reason 1, very quick resyncs whereas power cut resyncs are somewhat slower, full modem boot ups (Reason 0).
* Unlike Reason 0 power cut resyncs, these Reason 1 resyncs do not result in temporarily significantly higher attainable rates.

I think it also depends on how much the line is being pushed and if its using frequencies where it cant sustain full bit loading because those tones have less SNR to buffer and protect.
   
For example:

 - When on adsl I had full bit loading across all tones - during a storm my line wouldn't do anything, there may be the odd CRC if the strike was very near, but that was it.
 - When on adsl2+ at first it was like adsl, the odd CRC, but after a few years crosstalk meant I didnt quite have full bitloading and I could see CRCs start to rack up more than before, but it was hardly ever serious enough to give more than a couple of Err/Secs
 - On vdsl I see more CRCs and more Err/Secs than previously -  Im using much higher tones which dont have full bit-loading and you can clearly see the SNR tail off now.

Electric storms are very unlike REIN.   REIN will most likely be centred around certain frequencies - even SHINE can often centre around certain tones.  Storms affect all tones.  Only the very best and shortest lines with full bit load and/or plenty of SNRm to spare* are likely to be unaffected by electrical storms.


----
* added protection could be given by increasing the target SNRm

[Dray]

G.INP is good for only certain types of noise - it works well for REIN type of noise but pretty useless when it comes to SHINE. There is a comparison here of noise types. 

G.INP isn't able to give much protection for the type of noise from electric storms.  In fact G.INP isn't the bee-all and end-all and can actually make some lines worse (source ASSIA) 

I don't see why you think that G.INP is useless for SHINE. Presumably there is just a short burst of packets that have to be fixed - doesn't sound too onerous.

[kitz]

I was thinking more of single burst for thunder storms, which are about the worst type of single noise burst you can get not only because they affect all tones... they are longer than REIN bursts and even any attempted ReTX retransmissions during thunderstorms can contain errors.

My understanding (and apologies if wrong) is g.inp will attempt to retransmit if lost data is detected, but doesnt keep trying over and over as the buffer is only so big... and therefore only attempts retransmission on the original packet.  I'm sure I read somewhere (I thought it was on the ASSIA site but I cant find it now :/)  that suggested noise bursts of >15ms are better served by traditional RS Error Correction rather than G.INP Error Protection.