Print

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

[aesmith]

I'm battling a rotten line at the moment, so experiencing DLM sanctions first hand.  The thing that occurred to me, is to wonder what's actually achieved by slowing down a line with a high error rate.  In general high level protocols are pretty good at handling errors so this slow down doesn't help end user response times or speeds.  Is it done to preserve BTW backhaul bandwidth, to reduce numbers of packets retransmitted?

To put some figures in place, on a 6dB target we connected at just under 4.5meg, error rate of around 30-40 CRC per minute, speed test download speed of 3.3meg.  On 12dB target sync speed is just under 3meg, 3-5 CRCs per minute, download speed 1.9meg.

Tony S

[Chrysalis]

The answer is in the data, your CRC rate has plummeted as your line now has a higher noise margin (which is a buffer against problems).

[ejs]

The thing is, the 30-40 CRC per minute isn't really that bad for normal web browsing and downloading, it would hardly affect that kind of usage at all. There's not really much point in having fewer CRC errors just for the sake of having fewer CRC errors.

[Chrysalis]

The important data is the ES rather than the CRC regarding DLM.

Do you have the ES data at hand for both situations.

Also SES.

30-40 CRC per minute is going to be approx 25920-34560 CRC per day, which to me is on the high side.

There would be 2 ways to interpret that data, if it was averaging say 1-5 CRC per ES then I agree probably not noticeable impact, but that would also have a very high ES easily exceeding DLM limits, or of it was perhaps 1000ES a day tied in with 30000CRC a day then thats on average 30 CRC per ES which is a lot.

[ejs]

Well, yeah, 18 or more CRCs would make it a SES.

[Black Sheep]

I'm certain I've read info somewhere quite recently, that stipulated 10 ES = 1 SES ??.

[ejs]

I'd like to know where that's from, because in a way, it's nonsense, you can't have 10 seconds in 1 second.

There are definitions of Errored second and Severely errored second in the ITU-T G.997.1 PDF, 7.2.1.1.2 and 7.2.1.1.3. That's where I got the 18 or more CRCs from.

Something that makes more sense would be if it was about the DLM considering 1 SES as bad as 10 ES. Or it might be about classing a problem as REIN or SHINE based on the ratio of ES to SES.

[Black Sheep]

Found it. It's from paper documentation sent to engineers who underwent a swap on their JDSU Hand-Held Testers, from an Infineon Chipset to a Broadcom one.

As with all things sent to us, the authors have to take into account the fact that their audience consists of new starters through to seasoned engineers, so they put quite a lot into the documentation. One such example is this 'Chipset update' info which has a page that covers 'Common error-code abbreviations' , and a one-line explanation of what it is when viewed on the JDSU.

Written here word-for-word .............. SES - Severely Errored Seconds - after 10secs of ES - SES are counted.

So you are right, I got the wording wrong from memory. It isn't 10 ES = 1 SES ...... its 10 seconds of ES.

[aesmith]

Just for fun I've dug out the statistics for three of the steps ..

Target NM  Synch   FEC/Min  CRC/Min  ES/Hour
   6dB      4256    2000     10-40     700
   9dB      3680    1000     10-40     600
  12dB      3104    1000      0-5      100 

These are as reported by 582N router via DSLstats software.  It's interesting to see that the first speed reduction made essentially no change to uncorrected errors, then the second change made no difference to FECs. No SES ever recorded, and no resynchs other than by DLM resetting NM.

I don't have data for 15dB because once we were knocked back to 12dB I swapped to a router where I can adjust noise margin, giving me a more useful connection at around 3.5meg (just fast enough for the 3.0meg profile), and I can hang onto that even when DLM is against the stops with a 15dB target as it has been for the last few days.

Edited to add that I get virtually no packets lost on my PRTG ping monitor.  That suggests that although those error numbers are high in terms of count, they are in fact only a tiny fraction of the frames (cells?) passed without error.

[Chrysalis]

700 ES hour is a lot and no surprise DLM took action.

Even 100 an hour is still high (by DLM standards) and gives approx 2400 per day.

[aesmith]

Cheers.  I more or less understand the DLM triggers, what I was musing about was whether anyone or anything is expected to benefit from these DLM invoked slow downs.  I could understand if a line is losing synch, as for some users a stable connection at low speed might be better than a fast line with random interruptions.   In the case of just errors, no resets, the effect on the end user is simply a slower link.

[Weaver]

> in general high level protocols are pretty good at handling errors

The thing is, BT can not assume the existence of say TCP or SCTP. If the user is watching IP broadcast telly, then dropping a packet is bad news. I don't know anything about VoIP, but that may be another important case.

I think BT's choices are biased quite rightly in favour of the cases where TCP won't save the day as these opportunities in 'X+1 play' are the justification for predictions of greater revenue opportunities than just email and web.

[Weaver]

> what's actually achieved by slowing down a line with a high error rate.

The intention is not to slow the line down. (In ADSL 1 20CN typically the data tx rate does not actually decrease for small sync rate decreases because the true tx rate is in fact lower than the effective value computed from the sync rate when overheads are removed)

The line is slowed down when the overheads increase or when the target SNRM is increased. In former case, extra overhead is there to guard against errors by allowing recover by computing the true  data sent. In the latter case the increased SNRM allows for a greater amount of bitswap to be performed to protect against unfortunate changes in the noise pattern vs bins. The greater SNRM is achieved by having lower bits per bin values than strictly necessary, but the extra bits can be sent by bitswap to a bin in crisis.

[Chrysalis]

There is also that DLM is not intelligent enough to know how the connection is affected, so they have resorted to using thresholds over a 24 hour period.

I dont like DLM but since BT dont want to micro manage lines its what we are stuck with on FTTC.

[aesmith]

It looks like it might be a while before OR complete whatever they need to do on our line.

Meanwhile our DSL has been knocked back by DLM to a 15dB target NM.  Is that the worst that it can do?   I'm running a bit faster by tweaking the router, and since the situation may drag on I was considering speeding up further to see if I can get the profile up another notch.  However there's no point in doing this if it just provokes DLM to knock us down to 18dB target or to make some other slowdown action.  So is 15dB the limit, or does it have more slow-down's up it's sleave?   This is ADSL Max on 20CN.