Print

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

[broadstairs]

@Broadstairs, of interest, quite apart from DLM, and quite apart from speeds...

Is your line failing to provide any specific services (say, netflix video streaming) that it would provide better in the absence of this DLM intervention?

No I dont use streaming or any such thing. I still have an issue on my line which messes with the snrm everytime the phone is used and the cap is unnecessary  as it was running very well without it, it was done because DLM thinks all problems are downstream and does not consider the upstream may be the entire cause of the problems. In all the time I have had issues it was upstream causing them. Now my d/s is capped at 59995kbps interleaved but u/s is 20000kbps fastpath. It makes no sense at all. If they roll out 3db snrm here my line will drop every time the phone is used. I know its not the phone as it happens with either the DECT phone or the wired one, you can also see the effect with no phones connected and the number called from my mobile with only the router connected, and all the filters/faceplates have been replaced. I simply wont accept that because it stays up at the moment there is not an underlying problem.

Check For Wide Area Events
There's no 20% discount on ES
If it still works as Kitz wrote before the ASSIA court case then to be ignored as a wide area event it would need;
1) 50% of users to be experiencing errors AND 10% of users experiencing a resync
or
2) 20% of users experiencing a resync

I suspect that if this is the way wide area events works then problems like mine at night are far more likely to happen as I suspect many people turn their routers off at night. This just reinforces my opinion that in the case of storms BT should have an additional way of ignoring their effect. There are plenty of ways to monitor quite accurately where and when storms happen over the UK and what area is affected.

Stuart

[samwise78]

I can only echo what you are saying regarding this, I see the majority of my errors on the US.
I get US margin spikes to 10dB (as high as 37dB over the last 10 days) and down to 0dB, noise on voice calls which affects both DS & US margins and unexplained RDI resyncs while margin is reporting stable..
I don't mind being banded (DLM applied this last week after I monkeyed around with different firmware versions on my VMG8324 trying to eliminate misreported FEC errors) as this has sorted out my DS error rate, but wish I knew why the US is apparently ignored.

Sam

<edit> Just checked my DS margin for the last 10 days and it's just as ugly as the US (although big spikes are less frequent)

[Chrysalis]

My line will be back on 5-6pm a full 24 hours after the end of the error surge.  I was faced with having to bring it back on before midday (f1 race) but managed to get my STB working on the wifi hotspot from phone at same time as I have the usb tethering to this pc, couldnt get tethering working on my router, but this setup will do me fine for rest of day.

Also observed there is less drain with 4g+mobile data with screen off vs wifi overnight interestingly.  But yeah we will know in about 5-6 hours if my line has been DLM'd.

4g so much better for latency than 3g.

C:\Windows\system32>ping bbc.co.uk

Pinging bbc.co.uk [212.58.246.78] with 32 bytes of data:
Reply from 212.58.246.78: bytes=32 time=34ms TTL=51
Reply from 212.58.246.78: bytes=32 time=28ms TTL=51
Reply from 212.58.246.78: bytes=32 time=35ms TTL=51
Reply from 212.58.246.78: bytes=32 time=39ms TTL=51

Ping statistics for 212.58.246.78:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 28ms, Maximum = 39ms, Average = 34ms

[j0hn]

I suspect that if this is the way wide area events works then problems like mine at night are far more likely to happen as I suspect many people turn their routers off at night.

I should have clarified, it's supposed to only count users with uptime. Users who turn off their modem should be marked as dormant and ignored from any calculations.

It doesn't seem to be the best of systems though. If 100% of users have large amounts of errors, but not enough to cause 10% of users lines to resync, it wouldn't be classed as a wide area event.

DLM has screwed me. I was close to, but still just under the error threshold about 7 weeks ago. DLM applied interleaving anyway. Despite being ILQ green every single day since then it still hasn't returned my line to fastpath.

[Chrysalis]

So it only count's if there is resync's?

I can see lots of wrong results from that in short line area's as those lines will hold on probably.

Not only did my line comfortably hold on, it was perfectly useable, no packet loss on tbb, and I was able to use full throughput also.  The only reason I considered it a problem was DLM.

[j0hn]

So it only count's if there is resync's?

That's certainly how I read Kitz DLM page

Check for Wide Area Events
Each day, the DLM Management Device receives sets of data from the DSLAM's element manager. First it will analyse the event data from all lines to check for events such as thunderstorms which may have caused multiple lines to resync and/or generate lots of errors.
If a pre-determined percentage of lines experience retrains and errors in the the same time frame then any events occurring in that time frame will be classed as a Wide Area Event.
Documentation would suggest that the percentage values for wide area events are: >20% of users with uptime experienced a resync OR  >50% of users with uptime experiencing errors && >10% of users with uptime experienced a resync.
So attempting to put it in simple terms, if data in the binary file in any of the 15 min bins at the same time frame meets any one of the following two criteria:
> 20% of bins are [1,1,1] OR [1,1,0]
> 50% of bins are [1,0,1] AND >10% of bins are [1,1,1]||[1,1,0]
then a wide area event is declared for that period. Data from any bin within the corresponding time frame is discarded and not used for the DLM calculation.

The binary figures being [uptime, retrains, errors].
The last few thunderstorms that have caused thousands of errors on my line haven't caused a resync.
The addition of something like
> 80% of bins are [1,0,1]
would be common sense, and cover periods of time where most lines have errors, but no resyncs.

[Chrysalis]

So it is reduced to 10% if 50% of lines experience errors.  But yeah there needs to be an allowance for 0% retrains.

[Chrysalis]

still on fast path, will resume MDWS later.

[sevenlayermuddle]

I'd speculate one problem with 'improving' DLM would be extra complexity.    And it is nearly always a mistake to try to fix a flawed algorithm by making it more complicated.   

I'd also suggest that BT get an actual measurable advantage for themselves and their customers by making DLM as aggressive as possible, as long as it doesn't interfere with actual real-world usability of customers' broadband.   Retransmissions do consume additional network bandwidth which, effectively, is wasted bandwidth, and aggressive DLM would reduce that wastage.

Speaking for myself, my line does appear to be under DLM control as every resync event (I average about 1-2 per week) seems to result in exactly the same speeds as before.   Then after a few weeks, the same thing, but with a different speed cap, sometimes higher, sometimes lower.   But does that bother me?   No, it doesn't, as long as the various services that I use continue to work albeit with variations in elapsed time for uploads/downloads.

[ejs]

But BTWholesale sell bandwidth to ISPs, and if the DLM reduces the bandwidth of the end users, then ISPs wouldn't need to buy so much bandwidth in total, so that would be less money for BTWholesale, which isn't advantageous.

TCP retransmissions would consume additional back-haul and Internet bandwidth, but not G.INP retransmissions, which are between the DSLAM and the modem.

[j0hn]

Making DLM more aggressive would defeat the whole purpose of offering different profiles to ISPs. The Stable profile (or superstable as BTw call it) is already twice as aggressive as Standard, which is twice as aggressive as Speed. Being more aggressive may well offer better stability and reduce overall errors, but it would whack unnecessary interleaving and error correction on everyones lines, increasing latency and decreasing speeds.

Ideally everyone should be able to choose their own profile via a simple checkbox on their account page on their ISPs website. Some people want better latency for gaming, others need a more stable connection for voip or multicast streaming tv. I would rather my line was on fastpath, and DLM was less aggressive and quicker at removing interleaving. That isn't really necessary though as changing to an ISP that works on the Speed profile should always keep my line fastpath. At the moment my line performs right on the edge of the Standard profiles limits, meaning I get hit by DLM.

[Weaver]

I believe TalkTalk Wholesale can offer a no-stupid-DLM service where you simply know what you're getting and you are in control. Is that right? (Possibly not suitable for some ISPs though, where staff or even end users aren't able to properly use the control which they have available to them.)

[GigabitEthernet]

When I was on ADSL2+ LLU from TalkTalk, I had the DLM disabled which was nice.

Not possible on FTTC though unfortunately.

[S.Stephenson]

I've had a crosstalker disappear recently that made banding applied on my downstream very visible, after being annoyed by BT I decided to switch ISP to TalkTalk only because they use the Stable profile.

I'll attach my SNR which goes to show banding is relentless.

[broadstairs]

I am on TT and sadly I am still banded, plus now hit with interleaving because the stupid DLM did not know about a huge thunderstorm which covered the whole of Kent and part of Sussex and Essex.

Stuart