Print

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

[gazaai]

Hi very strange, I have woken up to a 0.9 downstream SNR at a sync rate of 80mb 

Obviously this is a mistake by the cabinet right?

I have recently changed from BT to Plusnet so I don't have G.INP as of now, I used to be banded to 66999 before the change, so does this prove that changing from 76mb > 38mb > 76mb removes banding?

MyDSLWebStats username is: GaZaai

I obviously don't want to upset DLM but at the same time, I want to enjoy 80mb as I've never had it. Surprisingly the ES and SES actually aren't too bad...

What do you think I should do?

[Dray]

Your traffic lights indicate DLM will take action soon

[Ronski]

Not too bad??? You've had over 1500 ES every hour since it resynced,  probably better to power down the modem for half an hour and hope the DLM doesn't hit you too hard tonight.

[gazaai]

Oh didn't notice the ES counter reset on the billion after a resync. Could remember being at 5500 then thought 6000 was only a 500 ES increase in a few hours. I'm on my mobile so haven't had a look at MDWS. Oh well time to resync 

[WWWombat]

I see you've turned the modem off now. A very good move

Obviously this is a mistake by the cabinet right?

More likely that every modem resynced at the same time, saw little crosstalk at the time of measurement (no surprise, with dozens of channels no longer transmitting). Low noise gives a high sync speed with that 6 dB target. But as soon as data transfer starts on your modem, so too on dozens of others. Immediately the noise increases, SNR decreases and you get to 0.9dB.

As soon as you see something like this it merits a resync asap to keep errors at bay.

I have recently changed from BT to Plusnet so I don't have G.INP as of now, I used to be banded to 66999 before the change, so does this prove that changing from 76mb > 38mb > 76mb removes banding?

It does look that way. Something removed it, anyway, but it might go straight back

[gazaai]

Well its back to normal now

I am still waiting on G.INP to be activated, unfortunately I think its been around 3 weeks now and I still don't have it.

More likely that every modem resynced at the same time, saw little crosstalk at the time of measurement (no surprise, with dozens of channels no longer transmitting). Low noise gives a high sync speed with that 6 dB target. But as soon as data transfer starts on your modem, so too on dozens of others. Immediately the noise increases, SNR decreases and you get to 0.9dB.

I guess that does make sense, the issue is now I may have to put up with DLM now putting interleaving on my line or even worse re applying that banding... 

[Chrysalis]

you may have got away with it with g.inp, but without yeah the errors would get a bit crazy.  Right thing to kill the connection.

[gazaai]

you may have got away with it with g.inp, but without yeah the errors would get a bit crazy.  Right thing to kill the connection.

Yeah I bet the errors wouldn't have been anywhere near as bad with G.INP.

[WWWombat]

Fingers' crossed that it chooses G.INP activation.

It does make you wonder about the implementation of a 3dB SNRM target.

While a line would likely work well with a 3dB margin (with small diurnal variation), the fact remains that VDSL2 suffers crosstalk. In an environment with strong growth, there is likely to be a stream of regular new subscribers, so regular events that can cause a drop from 3 to 2 to 1dB.

While I might enjoy the speed boost available from 3dB running, I wonder if the risk it drops to 2dB with high errors is just too high? Perhaps the DSLAM should be configured to trigger a resync if SNRM drops to 2dB?

[WWWombat]

Yeah I bet the errors wouldn't have been anywhere near as bad with G.INP.

Actually ... I wonder if this could be caught as a "wide-area event" and ignored by DLM totally.

If it was caused by a DSLAM outage, the mass resyncs - and possibly mass errors too - might get today's statistics labelled as a "wide area event", and that would surely be the right conclusion.

[j0hn]

I don't think he'll be so lucky. The resyncs might be seen as a wide area event, but a large proportion of lines will have some form or error correction, and will have synced at the normal speed. you could hope that a number on the cabinet had high error counts but from looking at MDWS I reckon dlm will be hitting your line.

I had something similar happen last night. my attainable upstream has never gone above 8000, usually floating about 7900. I've woke up this morning to a sync of 12474 with upstream snrm sitting at 2.7. If I was seeing errors or if the snrm drops any more then I'll force a resync.

[WWWombat]

For reference, here is what @kitz has to say about wide area events: http://www.kitz.co.uk/adsl/DLM.htm#wide_area_events

We'll find out tomorrow, I guess.

[NewtronStar]

Some people may get Wide Area Events in the wee small hours up here in mid north of the UK N.Ireland and west of Dumfries outside temps hit 31.2° that should spark of some T/Storms

[j0hn]

For reference, here is what @kitz has to say about wide area events: http://www.kitz.co.uk/adsl/DLM.htm#wide_area_events

I'd previously read that. My presumption that DLM would hit him was on the basis that everyone would have resynced in the same 15 minute bin, and that would be ignored as a wide area event. His error count continued for hours after that, each hour breaking the days mtbe. He'll need 50% of bins to be 1,0,1 (uptime, no resyncs, high errors) to avoid DLM. Alternatively 20% of lines resyncing in every 15 minute bin over the next 4 hours. Please correct me if I'm reading that page wrong. I'm always happy to be corrected by more experienced members, you can never learn too much!

We'll find out tomorrow, I guess.

Indeed!

[WWWombat]

Kitz's words mostly say something like "time frame", which may be a precise reference to a 15 minute bin, and might be deliberately imprecise. She obviously simplified things for us somewhat, so either could be true.

If I were writing the code for WAE recognition, I'd probably do one stage that recognised a WAE, then, once identified, a second stage to determine a scope. Stage 1 might be harsh, but stage 2 lenient. Stage 1 might try to keep identification narrow, to a few lines, to prevent false positives. Stage 2 might be broad to prevent false negatives.

For me, I'd probably expect some instability after a WAE, especially with a lot of simultaneous resyncs. I think I'd design it to remain lenient for a good few hours afterwards.

It all depends on detailed design. Just saying " WAE identification " is easy. Writing analysis rules is much harder.