Kitz Forum
Broadband Related => FTTC and FTTP Issues => Topic started by: broadstairs on August 27, 2016, 07:57:31 AM
-
This morning I had DLM intervene after some 25 days of very good running on fastpath and it slapped on interleaving. Yes I had a very large number of errors yesterday but all during the early hours of Friday morning all cause by a significant amount of thunderstorm activity for about 4 hours all over East Kent with 1000's of strikes/hour. I had expected DLM to ignore these errors as it has been said in the past that any thunderstorm activity is factored into it. Well it patently is NOT. This intervention was simply not necessary in any way.
Doing this just reinforces my view that the current DLM is not fit for purpose. My line is still banded and limited to 59995kbps as well downstream for no good reason as all the issues I had for a couple of months were on the upstream which is still running not interleaved at 20000kbps. Just more proof if it were needed that the current infrastructure is not fit for the 21st century.
Stuart
-
Hmmm does that mean the wide area event monitoring has also been turned off that is not good at all :o
-
Funny you should mention that...
After my FTTC went live about six weeks ago, I've had very low error rates and an excellent connection. Last week, there was one sudden, very brief 'event' with the first SES that I've seen. I actually caused it, mucking about near the modem. It dropped my connection and I got interleaving when it reconnected.
I'm very unimpressed. I've been trying not to think about it...
-
You can hardly compare the 2. DLM has no way of knowing that you were "mucking about near the modem". If your line was the only 1 to suffer the SES then DLM did exactly what it was supposed to by stepping in.
Broadstairs situation is very different though. It's highly unlikely that a thunderstorm caused errors on his line only. It's specifically designed to ignore "Wide area events" where a certain percentage of users on the DSLAM all suffer errors/resyncs in the same 15 minute bin. Any such pattern of errors should cause that 15 minute bin to be completely ignored.
You could put the argument DLM was possibly a bit quick to step in. I don't know how you expect it to know the difference between genuine errors due to line instability, and a user "mucking about". Chalk and cheese comes to mind.
-
Be interesting to know if anyone else on here near the storms on Friday early morning have had a similar issue the timing was from around 01:30 for about 4 or so hours and covered mots of Kent and probably some of Sussex and east Essex. You can see lightning maps from the archive at http://en.blitzortung.org/historical_maps.php?map=12 (http://en.blitzortung.org/historical_maps.php?map=12). Just make sure you look at the 26th August from about 01:00 (they use UTC or GMT).
Also been quite a lot of storm activity recently in Dorset/Hampshire up to the Midlands and over into East Anglia, be good to know if anyone else with no previous issues sees a DLM hit.
Stuart
-
I'm between Ashford and Folkestone, and my ES rate increased by a factor of ~10 at that time but it didn't have any other untoward effects. We were on the edge of the thunderstorm area.
-
Well I am over 3k ES for today, so my line will be a test to see if wide area events are still taken into account on DLM.
Sods law the last 2 storms here have both been whilst I am streaming leics games meaning I couldnt go offline. I think the one before that was also during a game as well, so 3 storms in a row on Saturday afternoons. The one today tho was more severe and longer lasting there was lots of brownouts as well.
Seems I am actually according to MDWS just below the speed error threshold, 2614.
From modem
Latest 1 day time = 23 hours 47 min 56 sec
FEC: 0 3741
CRC: 19629 174
ES: 2719 122
SES: 11 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
-
I could have turned my router off as at that time very little goes on, only my weather station updates. However I did not wake up ;) My wife on the other had did and watched it but did not wake me up ;D although in hind sight perhaps would have been better if she had :(
Stuart
-
I'm pretty sure my line hasn't resycned recently, and I'm the other side of Broadstairs. My works line has also been OK. Haven't looked at the error rates on either though.
-
Looking at Chrysalis B0 CRC errors that is what a typical thunderstorm looks like and don't see this on Broadstairs B0 CRC graph just one big spike of 694.000 CRC during modem reboot time.
Edit I can see it now it's being dwarfed by that 694 thousand CRC error of MDWS :o
-
I had 1633 ES in 24 hours on Friday 26th August 2016, I think those CRCs at reboot time are a function of the reboot and this router, I often see a spike of CRCs at reboot time, not always but it does happen. For standard profile 1633 ES in 24 hours is 'action' however it should have seen the issue with the thunderstorm I would have hoped and ignored it, I just wonder if I was just enough under the centre of the storm that I go more hits than others.
If this is the case then I would submit that the algorithm is not good enough to detect storms especially at night when many routers may well be turned off. In which case I would suggest they invest in some real storm detection equipment to interface with the BT equipment and properly detect thunderstorms. I think the algorithm should also take account of the previous good days of running before it jumps to conclusions which cannot be substantiated by other means.
Stuart
-
I just wonder if I was just enough under the centre of the storm that I go more hits than others.
As it says it's a wide area event T/Storms can start effecting users stats when the cell is even 25 miles from users home so that would effect hundreds of DSLAM cabinets which then sends the data back to central command and after 24 hours it then decides which cabinet & port number needs some DLM.
-
I'm sure I read somewhere that DLM gives 20% discount on es for wide area events. To way of thinking it should discard them all. I live in Kent near Ashford too. I got dlmed in the last lot of storms a couple of weeks ago. To fair DLM put me back on fast path after 7 days. I do have my line quite heavily capped. I managed to escape these storms as I think we were on the edge. I agree with Stuart, I find DLM to be really annoying . The "we know what's good for you son!" Attitude of openreach is unbelievable, I can't see why I can't specify how I want my line in the way of g.inp, interleaving or fastpath. I'm sure it's the cause of a lot of calls to ISP call centres too.
-
@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?
-
I'm sure I read somewhere that DLM gives 20% discount on es for wide area events.
Check For Wide Area Events (http://www.kitz.co.uk/adsl/DLM.htm#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
-
@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 (http://www.kitz.co.uk/adsl/DLM.htm#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
-
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)
-
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
-
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.
-
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.
-
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.
-
So it is reduced to 10% if 50% of lines experience errors. But yeah there needs to be an allowance for 0% retrains.
-
still on fast path, will resume MDWS later.
-
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.
-
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.
-
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.
-
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.)
-
When I was on ADSL2+ LLU from TalkTalk, I had the DLM disabled which was nice.
Not possible on FTTC though unfortunately.
-
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.
-
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
-
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
To be honest when looking at your stats Stuart you would be better off with an ISP that uses the Speed profile than TT who use the standard profile the difference is an allowance of 2880 ES per day (Speed) vs 1440 per day (standard) only Interleaving or G.INP would keep those errors below 1440 on TT
-
Just a point re Wide Area Events. Most DLM systems do not have anything and afaik monitoring for wide area events is a BT specific thing.
TBH when I first read about it, I thought what a brilliant idea. Without it, all lines would be clobbered during thunderstorms once they'd reached the MTBE threshold. I agree its not perfect and relies on 'x'% of users seeing a resync... but it is better than not being in place at all.
-
My issue with Wide Area Events monitoring is that it seems likely that it only works where a large number of users have issues and this is far less likely during the night as was my case with the storm being between 0200 and 0430 and I guess a large number of users probably turn off their routers at night or their traffic is so low it keeps the error rates down.
For thunderstorms there are loads of ways of monitoring them and to be honest BT would be better off using this perhaps in conjunction with the existing design to determine what is going on. What happened to me is simply not acceptable as turning off the router is not an option as my connection is used 24x7 by my weather station.
Stuart
-
May be, as it's from me, it's a silly question, but could DLM for wide area events have had included something like standard and a low users' activity parameters, where the MBTE for one could be larger than the other? I'm thinking were something like that implementable it could be good for folks like our friend, who must be on the increase.
Priorities, cost and willingness allowed for naturally!
-
or their traffic is so low it keeps the error rates down.
Happy to stand corrected, but I thought DSL error monitoring continued just as effectively on a quiescent line as a busy one? Agreed though, some folks do probably switch off modems overnight.
Per monitoring lightning strike data, I would imagine the data providers expect handsome payment when the data was to be used for commercial gain. That would be one disincentive against its use.
Per DLM wide area events in general, the first place I ever saw it mentioned was in a BT patent. If BT hold the patent, it might explain why nobody else can do it, or at least not without paying BT for license.
Ps, edited to remove accidental irrelevant smiley. Darned, fiddly, mobile phone keyboard. :-[
-
As i said further up this thread, the Wide Area Event checking ignores users who have disconnected. It also makes absolutely no difference if your connection is sitting idle or if you are heavily downloading when a thunderstorm hits the area. If you are connected, you will get a very large spike in errors. The only way to avoid an increase in errors is to disconnect the modem for the entire storm.
-
If the end user's modem is disconnected, then they'll be no DSL signal and therefore no data for the DLM to gather, all it needs to do is not treat the no data as there being zero errors.