Kitz Forum
Broadband Related => FTTC and FTTP Issues => Topic started by: broadstairs on July 09, 2017, 11:02:00 AM
-
I was set to interleaving after quite a large thunderstorm at the end of May, already banded since July/August 2016. Since the 30th May I have been running in the green on MDWS, yes I have had a couple of re-syncs but not to the extent that it should adversely affect me. So is DLM now stuck and should I try to get TT to do something about this? It is very frustrating to be both banded and interleaved when I do see any reason for either.
Stuart
-
Being green on MDWS does not seem to be sufficient condition for removing interleaving. I think you need to keep ES per day less than 20-30 for at least 14-15 days. You seem to have exceeded that a few time since being interleaved. Most probably due to thunder storms but I would not trust the DLM to recognise that.
-
That's my big issue with DLM, it seems that it has its own way of detecting thunderstorms which dont take account of location. We often get storms on the French coast which can badly affect my connection but probably dont show up as enough of an issue around Kent in general for DLM to recognise it as a problem which should be ignored. There are much better ways of finding out about storms that watching connections over a wide area. This to my mind is a significant issue with the design of DLM but I dont expect BT to do anything about it. Both of those days which shows up as 60+ ES were caused by storms in France or mid Channel and as such should be ignored.
Stuart
-
Understand your pain I was applied with interleaving on 25th May due to high error rate. Now getting 3-5 errors a day and interleaving still not been removed.
-
Recently I had a bad period of errors resulting in interleave and delay being applied with a very high interleave level. Within a week dlm had removed both and returned my line to fastpath. Sounds stuck based on my experience recently. I suppose the issue will be if the line is in within the expected parameters tt might be much like sky who are relucant to do anything..
-
I suppose the issue will be if the line is in within the expected parameters tt might be much like sky who are relucant to do anything..
That is my expectation of TT, the line is syncing at a little over 59000kbps so I would expect them to do nothing.
Stuart
-
There isn't a time frame that anyone can say, as it will depend upon your line history - each time the DLM intervenes, then the longer it will take to be removed.
I've been keeping note of how long DLM takes to remove Interleaving on my line.
1st time it took one full day of MTBE Green
2nd time it took 10 days of MTBE Green
3rd time it took 14 days of MTBE Green
-
That's my big issue with DLM, it seems that it has its own way of detecting thunderstorms which dont take account of location. We often get storms on the French coast which can badly affect my connection but probably dont show up as enough of an issue around Kent in general for DLM to recognise it as a problem which should be ignored. There are much better ways of finding out about storms that watching connections over a wide area. This to my mind is a significant issue with the design of DLM but I dont expect BT to do anything about it. Both of those days which shows up as 60+ ES were caused by storms in France or mid Channel and as such should be ignored.
Stuart
It is supposed to take into account location! I think you may have misinterpreted the term 'wide area'.
How wide a location I'm not sure because it wasn't that specific, but it will be fairly localised at an exchange level. It will either be DSLAM...... or probably* the element manager (http://www.kitz.co.uk/adsl/DLM_system.htm#element_manager) at the exchange where the data is analysed. - So with FTTC that will include all DSLAMs in your area.
TBF I don't think it does always seem to detect some events very well, perhaps the percentage used in the algorithm should be lowered.
- See Checking for wide area events (http://www.kitz.co.uk/adsl/DLM.htm#wide_area_events).
* As mentioned documentation wasn't specific, but I suspect it is more likely to be element manager than DSLAM. That would explain why some events occurring at one specific DSLAM could be negated if averaged out over say 20-30 DSLAMs
-
More in hope than expectation I have opened a thread on the TT forum asking them to get something done about my interleaving not being removed and my banding (now very nearly 12 month old) removed. At least this is a start and if they refuse to do anything I guess it will be a complaint again to the CEO's office.
Stuart
-
Hi Stuart
Just wondered if say you moved ISP at some point I guess this would remove the banding?
-
Hi Stuart
Just wondered if say you moved ISP at some point I guess this would remove the banding?
Not easy right now as I took out an 18 month contract about 3 months ago, frankly I doubt it would do any good on the banding and there is not a lot of choice round here, until Virgin Media arrives. Removing the banding wont buy much until G.INP comes back here and I suspect it might take until VM arrives before that happens.
Stuart
-
Well I said it was a forlorn hope and indeed it is. TT point blank refuse to do anything, they consider my line to be perfectly acceptable as it is. Will consider what I will do later when I have had time to reflect, but I'm not giving up yet - I like a good fight and like to cause trouble for these jobsworths.
Stuart
-
I think initially I'll go back and complain, which wont get me anywhere, next I'll end up raising this again with the CEO's office which again will go no where, so then left with complaint to OfCOM which again I suspect wont go anywhere but at least I'll make a nuisance of myself.
What I find unacceptable is that TT are saying because I am syncing above their quoted maximum when I renewed my contract they will not do anything, however I have no actual paperwork from them quoting any speeds at all, plus the speed that was mentioned on a webpage when I renewed was below the value I have always obtained. I also notice now BT are even quoting a maximum speed on their adverts well below the potential maximum. If I remember correctly the mention was 55000kbps which according to the BT Wholesale checker is the minimum I should get but I have sync'd at around 59000+ kbps probably 99% of the time and with G.INP when it was on ECI cabinets I was running at just over 70000kbps.
I simply believe that BT and ISPs are now lowering the speeds quoted to deliberately reduce the potential for customers to complain, irrespective of what their line could potentially run at.
Roll on Virgin Media ;)
Stuart
-
probably yes to manage customer expectations, the BT wholesale checker has absolutely no bearing on your contract with talktalk, the estimated speed they gave you at signup does, but that can be anything of their choosing although they tend to use the estimate information provided by BT as a guideline.
So as an example if talktalk estimated 40000kbit sync speed, BTw estimated 60000 and you got 45000, then you got little to back you up on a performance related fault as you still 5000 above what talktalk told you.
-
If you can stand the speed reduction you could cap your sync speed enough to reduce the odd bursts of errors that keep hitting you. e.g. try a cap to say 40Mb/s for about 3 weeks. I suspect a more modest speed cap might not get rid of the odd thunderstorm impacts enough.
From experience I would not notice such a speed cap in ordinary use (speed tests aside) but I would notice your interleaving.
-
Have an Idea for broadstairs you move your ISP/sign up to Vodafone and you have a 30 day cooling off period with them you then move back/sign up to TT on the 14th day that will give you two DLM resets to remove any banding ;D
-
The whole point I am trying to make about my interleaving is that it should never have been applied in the first place since it was a thunderstorm which caused the errors and DLM did not see it as a wide area event because of my proximity to the French coast. DLM should not be determining wide area events the way it does it is so 1960's. It whould be looking at what is available to detect thunderstorms.
Stuart
-
Have an Idea for broadstairs you move your ISP/sign up to Vodafone and you have a 30 day cooling off period with them you then move back/sign up to TT on the 14th day that will give you two DLM resets to remove any banding ;D
Nice idea but am unable to do this as I signed up to renew with TT a couple of months or so ago.
Stuart
-
interleaving I have never heard of getting stuck unlike banding, so there must be a reason DLM isnt switching you back.
-
so there must be a reason DLM isnt switching you back.
I know what your saying Chry and it says noise, my own line could never handle Fastpath with ISP's which used the Standard DLM profile and most of my 5 years with FTTC it was interleaved for 3 years until G.INP was introduced.
-
My line has handled fast path quite well even after they took G.INP away. The ONLY reason my line has not had a continuous period of very low ES has been thunderstorms which DLM is refusing to acknowledge is the issue and should ignore it. DLM is not fit for purpose in this area. There are plenty of very accurate ways to detect these storms and determine the areas they cover and that is the only way DLM should handle them not by some nefarious algorithm which obviously does not work correctly.
BT have no reason to change any of this stuff and by ISPs point blank refusing to raise the issue nothing will ever get done about it, all they want to do is hide behind their own estimates of line speed and do not care about providing the end user with a proper service.
Come to that the vast majority of ISPs are in the same category, do anything they can to reduce what they have to do to provide a real service. We are left with a 19th century infrastructure to run a 21st century system - it's never going to work as well as it should. I'm sorry to say this is firmly laid at the door of both BT, and the Government should have insisted on 21st century infrastructure.
Stuart
-
Well Broadstairs I can honestly say that I've never had T/Storm events take my errored seconds above the DLM threshold unfortunately we don't get that many here due to the higher latitude of N54.39 the land temperatures are not high enough to develop into large cumulonimbus clouds.
Now don't take this personally but I think you could have a fight with your own shadow :-\
-
Now don't take this personally but I think you could have a fight with your own shadow :-\
OH dont I know it but I'm not a grumpy old man for nothing.
Stuart
-
For quite some time, b*cat has had thoughts that b*stairs is just a re-incarnation of Victor Meldrew (https://en.wikipedia.org/wiki/Victor_Meldrew). :D
-
For quite some time, b*cat has had thoughts that b*stairs is just a re-incarnation of Victor Meldrew (https://en.wikipedia.org/wiki/Victor_Meldrew). :D
My wife would totally agree with you ;) In fact some who have known me for years might have said I was the example used when he as created.
Stuart
-
We could solve this problem completely by sending along Arya Stark to the premises as an Openreach engineer.....
-
We could solve this problem completely by sending along Arya Stark to the premises as an Openreach engineer.....
Sorry I had to Google her - I dont watch Game of Thrones....
Stuart
-
As I said before , if you can stand the speed reduction you could cap your sync speed enough to reduce the odd bursts of errors that keep hitting you. e.g. try a cap to say 40Mb/s for about 3 weeks. I suspect a more modest speed cap might not get rid of the odd thunderstorm impacts enough. In most internet use you won't notice any impact from such a speed cap. Hopefully you will notice things being a bit sharper in response when interleaving is removed.
In the long term TT is not the best ISP for you as they provision on the standard rather the fast DLM profile.
-
Well my support thread on the TT site is getting me nowhere, they point blank refuse to do anything about this cap. It was placed on my line a year ago to try to fix a line fault but failed to do so but they never removed it despite that. I think all I can try now is complaining to the TT CEO again and then maybe OFCOM.
Stuart
-
I remember having a banding issue like this a long time ago at my old address, if I recall I was stuck on 60/20 instead of getting 80/20 which I could've achieved. It was caused by a faulty faceplate filter which I replaced, the one the engineer installed was faulty which caused DLM to intervene. I got no where with them however, then they called a few months later to ask why I rated them bad in the survey after the phone call haha (BT Business at the time).
Fortunately after what must've been a year, DLM apparently reset and I was on a wild open profile, then shortly after that on the normal 80/20 profile. Not sure to this day what caused that.
-
Why not email openreach ceo directly. Explain the situation and they might help you out. When I had my complaint some time ago I had many a dlm reset done automatically from the noc without the need for an engineer whilst it was being investigated. Its got to be worth a go.
They were testing different profiles but had to reset each time whilst trying to figure out what was going on.
-
Well at around 3 hours ago my line did a re-sync and lo and behold I have had the cap removed and I'm back on fastpath, sync'd now at 65336kbps @ 6.3db.
Now I have a sneaky idea why this happened. On Tuesday morning I emailed the BT OR CEO and got a reply from one of his minions who asked for some details which I sent this morning. At around 18:00 this evening the cap and interleaving all got removed. I think I must have made quite a good case over the cap especially as it had been over 12 months since it was applied initially.
Stuart
-
Good to know all you need now is G.INP on ECI to get into the 70s.
-
Well at around 3 hours ago my line did a re-sync and lo and behold I have had the cap removed and I'm back on fastpath, sync'd now at 65336kbps @ 6.3db.
Now I have a sneaky idea why this happened. On Tuesday morning I emailed the BT OR CEO and got a reply from one of his minions who asked for some details which I sent this morning. At around 18:00 this evening the cap and interleaving all got removed. I think I must have made quite a good case over the cap especially as it had been over 12 months since it was applied initially.
Stuart
Glad my suggestion helped you out perhaps - nice!! :congrats:
-
I think I should point out that just complaining to the BT CEO wont necessarily work. It has been over 12 months with the cap and nearly 4 months of interleaving and I put together a detailed explanation of both the original issues which got the cap initially plus why I got interleaved (thunderstorms) and how I had exhausted all the avenues via TalkTalk and still got nowhere, so I asked politely if there was anything that BT could do to resolve this and yes it seems to have worked a treat. I just dont want anyone to get the idea that you can simply bypass an ISP and go over their head to BT without good cause and a well thought out case.
I've not heard back from the guy in the CEO's office but I think a note of thanks will be in order.
Stuart
-
Spoke too soon. At 10am today DLM intervened to put me back on interleaving despite only 192 ES in past 24 hours and sync dropped to 57465kbps. Have no idea if the cap got replaced. Needless to say I have emailed my BT contact about this. Very disappointing as I had expected DLM to leave me alone at least for a few days to determine how it was going. >:(
Stuart
-
But if you did have a DLM reset, then the line then going into interleaving the next day is no surprise?
Very often the reset puts the line into open profile, then within the next 48 hrs interleaving will be applied by default and you then have to wait for that to be removed. Even when BS reset his own line it went to Interleave for a while.
-----
As regards to the Wide Area Event detection and this
The ONLY reason my line has not had a continuous period of very low ES has been thunderstorms which DLM is refusing to acknowledge is the issue and should ignore it. DLM is not fit for purpose in this area. There are plenty of very accurate ways to detect these storms and determine the areas they cover and that is the only way DLM should handle them not by some nefarious algorithm which obviously does not work correctly.
I still think there may have been something else going on. TBF saying the Wide Area Event system is rubbish is a tad harsh.
Most DLM systems don't even have Wide Area Event detection, its something unique that BT came up with that is actually advantageous to the EU.
Other DLM systems will just penalise you straight off and take no absolutely no account of what's been happening locally. It is also supposed to be local - ie those on the same exchange also experiencing a high amount of errors and or resyncs.
Yes it does work - we had massive thunderstorms here on the 19th Jul. On the same day my Err Secs reached 10.9k which is far in excess of the MTBE and I fully expected to be penalised by DLM. I wasn't and DLM totally ignored what happened that day - see graph of my stats below.
IMHO, I think perhaps they could lower the algorithm trigger a little so it catches more events, but to class the system as not fit for purpose is unjust.
-
IMHO, I think perhaps they could lower the algorithm trigger a little so it catches more events, but to class the system as not fit for purpose is unjust.
My brain won't let me track DLM like I used to, but ... I used to argue the same thing.
IMHO DLM started down a trajectory of becoming unfit for purpose when they made the first adjustments to cope with ECI's G.INP problems.
Choosing to use the FEC+interleaving setting as the post-reset default, making resets unpredictable, letting caps be instilled as anything except a last recourse, making caps irreversible - these are all harsher steps than they need to be, and all have dramatic effects to the sync speed.
I would suggest that DLM needs a new guiding principle: First, do no harm.
Then rework it, following that principle, always asking "will this action be harmful"?
-
This I agree with ^ , although I think things may have started to go to pot after the ASSIA case.
- They did a botch job with g.inp mkII to 'fix' what was happening with the many modems that weren't fully capable of performing retransmission in both directions.
- They also appear to have done a botch job with capping NGA lines after the ASSIA court case.
-----
Sorry maybe I didn't make myself clear - Stuart was specifically talking about the Wide Area Event system which is what I was responding to.
The Wide Area Event detection is afaik unique to BT systems and is one area where IMHO it is better than the other systems which take no account of such things happening locally. When I said "lower the algorithm trigger a little so it catches more events" I was talking about Wide Area Event detection.
The wide area event thing is one of the good things - the capping and g.inp botch job things are total muck ups and not at all beneficial.
I've said many times I dislike how INP is applied by default after a reset*, and the line rate capping is unjust in many cases.
*I may have done a rambling post somewhere, why they may be applying INP, but thats not to say I agree with the INP by default. IMHO it was just a botch to get G.INP back asap.
Like you I agree they need to sit down and do a total rework of the DLM actions for the NGA system and steps it takes - unfortunately until they at least get both ECI and Huawei systems both behaving in a similar way, then I dont think they will :(
-
I am in 2 minds.
DLM's priority is to maintain stability, low speed is annoying, but a connection dropping out is far more annoying, if it drops out in middle of watching netflix then it wont be a good experience.
In addition I dont think a DLM that keeps flipping between 2 profiles is good, as it creates inconsistent performance (nightmare for personal QoS) as an example as well as further dropouts to enforce those changes.
I think the real problem here is that openreach want to maintain full control of DLM, they dont want to handover a reset button or profile overide option to the ISP's (assuming the ISPs are even asking for it).
Part of that reason I expect is they know that DLM will 'mask' problems, so by removing DLM's actions then the problems become visible again and a net result will be higher fault reports. A post on TBB on Ixel's issue shows this perfectly, zen told Ixel his line is good because DLM will mask the errors.
I think how long people are expected to wait for g.inp is clearly way too excessive, I dont know why openreach have done that config change as DLM wasnt like that at the start of g.inp rollout.
I think a banded speed cap is vastly superior to interleaving but I value latency a lot more than max burst speed, I respect not everyone agrees with me there, and for that reason banding should not be permanent. At least not a first offence.
Thats my 5 pence in this.
-
I take the point about DLM and a reset although it is somewhat annoying to have 65Mbps and then within 12 or so hours get dropped to 57Mbps with interleaving. My worry about the interleaving is that it was applied and not removed for nearly 4 months despite a very low error rate (thanks to my VMG3925 which is less susceptible to thunderstorm as well), I hope it does not take another 4 months and emails to BT to get it removed this time.
My point about the wide area event is that it is of little use in a location like mine where probably only a small number of folks will be hit by the effect of storms in the Channel or coastal France. we are about 130 feet up a hill and my copper line has line of sight across the Channel to France. I think it is about time they looked at a different way or at least complementary way to view storms, after all there are loads of places which may storms in real time.
Stuart
-
>> My worry about the interleaving is that it was applied and not removed for nearly 4 months despite a very low error rate
If your line was reset, then hopefully it shouldnt take too long especially if your MTBE remains green. :fingers:
I agree its annoying in the meantime though.
>> I think it is about time they looked at a different way or at least complementary way to view storms,
But the DLM device is dumb in that respect and doesn't hook up to any external data - it's only getting info from the element manager which in turn are the same as the data bins in your router.
I actually think its pretty cool that someone came up with the idea that if > x% of lines on that element manager are throwing errors and or excessive retrains that its likely to be something local, so lets disregard that data.
There's lots of things I don't like about NGA DLM, but the Wide Area Event is one of the few good things that I think BT have got right on their system that can be beneficial to the EU's. Its a bonus & far better than nothing... which what the other DLM [such as TT's own] systems have.
-
I agree that DLM's wide area event process, as far as it goes, is good. However that does not mean that they should rest on their laurels and do nothing. It should not be beyond BT's ability to extend what works for the majority to work for all by capturing data about storms and using it as well as what they have today. Being an island I suspect that there are quite a lot of coastal communities where the current design is less than perfect. Plus in my view it would be good if they could tell that a wide area event was NOT caused by thunderstorms and therefore look closer to find out what the cause was.
Stuart
-
Another thing thats clearly an issue is the late reaction.
Lets say you watching netflix at 8pm and you get a 2 hour burst of noise that just trashes the experience, that noise may not make it resync so the person who may not be mindful a resync might help would just be stressed about a 2 hour outage.
The DLM we got now would probably take action the following day hours after the incident has ended. Then keeping the line crippled for several days or even weeks again after the incident has passed.
I would like it that say within if consecutive 5 mins of high ES/CRC then the line is resynced banded or interleaved. (preferably banded for me). The choice should be picked by if an end user has told their isp they prefer latency (e.g. a gamer) or higher speeds. Then the line is reviewed again by DLM 24 hours later and if the noise was only a short lived event it reverses the changes, if the event occurs again repeatedly then to prevent a flapping line the recovery time would be set higher to stop the line flapping, however it should try a quick recovery first before deciding that.
Is this type of logical behaviour patented by that silly organisation? I still dont get how someone can patent a software configuration, what a silly world we live in.
For me DLM should be a firefighting service, that can react to short lived events, it shouldnt be used to mask chronic, long term line issues which what seems to be its main purpose with the slow reactions and slow recoveries.
-
I think the real problem here is that openreach want to maintain full control of DLM, they dont want to handover a reset button or profile overide option to the ISP's (assuming the ISPs are even asking for it).
Part of that reason I expect is they know that DLM will 'mask' problems, so by removing DLM's actions then the problems become visible again and a net result will be higher fault reports.
There is a post, somewhere, by Black Sheep in which he mentioned that, in certain cases, he would perform a "circuit recalc" upon arrival at the EU's premises. The logic behind his action is so that he can see how the circuit is behaving when not "masked" by the DLM's choice of intervention.
-
yeah my install engineer does the same.
-
Mr Cat is as always, correct. Just to confirm. :)
-
I contacted my BT person again yesterday and have heard back. It seems that despite changing the line profile to 80/20 DLM reset it back to 60Mbps again as well as turning on interleaving. They also reset the card but to no avail. Now they are sending an engineer to check to check out speeds at the cabinet. If this still fails to turn up what is wrong their next step is a lift and shift assuming there is a spare port. So it would seem that there is a problem somewhere in the part which BTOR are responsible for and TT's refusal to report my issue merely covers up a problem which does no one any good at all. I am not waiting to hear back from BT as to what is happening.
Stuart
-
It seems that despite changing the line profile to 80/20 DLM reset it back to 60Mbps again as well as turning on interleaving.
Im not sure about the 60Mbps cap as that isn't possible to see because the line is interleaved and interfering with your sync speed. However, turning on interleaving again is not unexpected.
What I am suspecting is that they have done a remote DLM reset. I've noticed for a long time now (since ASSIA) that there appears to be 2 types of DLM reset.
- 1) Remote DLM reset - these never seem to clear any capping
- 2) Engineer DLM reset - a full line reset which will remove capping and start things afresh. These can only be done by Openreach Engineers.
-
You're right Kitz, on two counts.... I had taken it to mean DLM in general, rather than wide-area events specifically. And I had forgotten the ASSIA impact.
I too think that the wide-area checking is a good move, in principle.
-
I contacted my BT person again yesterday and have heard back. It seems that despite changing the line profile to 80/20 DLM reset it back to 60Mbps again as well as turning on interleaving. They also reset the card but to no avail. Now they are sending an engineer to check to check out speeds at the cabinet. If this still fails to turn up what is wrong their next step is a lift and shift assuming there is a spare port. So it would seem that there is a problem somewhere in the part which BTOR are responsible for and TT's refusal to report my issue merely covers up a problem which does no one any good at all. I am not waiting to hear back from BT as to what is happening.
Stuart
Hi Stuart
You may recall my cab was not giving 80mb + at the cab ports when I had lots of issues with sync rates etc.. it was an eci too. In the end the engineer thought the ports/cards were at fault as he could not get more than 65mb at the cab which meant a further decrease at my house and regardless how many port swaps were tried they were all the same .A further pcr engineer deemed a physical wiring fault between cab and PCP which resulted in replacing the wiring loom on the eci cab... it only took me 4 months to get it fixed :-\
-
I remember all your issues described on here.
I am waiting now for some feedback from my BT contact. I have had some downtime around 12:50-13-02 today when I guess something happened at the cabinet. I will update when I hear more. Depending on what BT say I may update TT with their findings especially if they report that there were issues at the cabinet. I think TT need to be more pro-active in reporting issues to BT where they have been long running things which should have been corrected earlier even if the line meets their (restricted) line speed estimates.
Stuart
-
DLM has intervened once again after the work yesterday. Is there any way to estimate how much speed one loses when interleaving is applied? This time I've lost some 7000kbps. I have not heard back from BT so I suspect this is as was suggested normal still annoying though.
Stuart
-
I lost about 10meg.
-
Depends on the INP, the higher it is then the more it'll take away. On my connection I've lost perhaps 1-2 megabits I think (downstream) when I get INP 3 with delay 8ms compared to fastpath. More delay gives a bit more speed and error resistance (though not as much resistance as applying INP too).
-
Is there any way to estimate how much speed one loses when interleaving is applied?
There are two factors...
The first takes away bandwidth, by using some of the bits as parity bits for the Forward Error Correction process. This tends to steal between 5% and 25% of the raw bandwidth...
- 5% is normal when G.INP retransmission is active
- 15-20% is normal for old-style interleaving intervention
- 25% is about the highest I've seen anywhere
You can see this from the framing parameters in the statistics. Parameter "R" shows the number of bytes being used as parity bytes, and the total block size is the "N" parameter.
(R/N)*100 gives you the percentage of bandwidth grabbed for FEC.
For example, mine are currently:
VDSL2 framing
Bearer 0
MSGc: -6 26
B: 130 237
M: 1 1
T: 0 42
R: 8 16
S: 0.0518 0.3781
L: 21468 5374
D: 16 1
I: 139 127
N: 139 254
Q: 16 0
V: 14 0
RxQueue: 60 0
TxQueue: 20 0
G.INP Framing: 18 0
G.INP lookback: 20 0
RRC bits: 0 24
(8/139)*100 = 5.8%
The second factor comes from "coding gain". Because turning on FEC and interleaving increases the coding gain, the modem can try to carry more bits on each tone - because it knows that some of the errors are going to get corrected.
I don't know how to calculate this, but it seems to have two outcomes:
- On normal levels of old-style interleaving intervention, it gives you back about half of the bandwidth taken by the parity bits
- On G.INP retransmission intervention, it seems to increase the speed that the user experienced when on fastpath
Taking these two outcomes together, I think coding gain adds about 10% to bandwidth.
Combining both factors together, I think that these might be fair results:
- Old-style interleaving drops around 10% of speed
- New-style interleaving (as part of G.INP) adds around 5% of speed.
-
wombat and kitz any comment on my opinion?
-
wombat and kitz any comment on my opinion?
I think it may be a personal preference.
- Some people don't notice or mind the higher latency that comes with INP.
- Others may prefer to lose a bit of speed rather than incur longer ping times.
>> I dont think a DLM that keeps flipping between 2 profiles is good,
In theory it shouldn't - each subsequent action should require a longer ILQ green status before DLM takes any backwards steps in order to prevent flapping profiles.
>> openreach want to maintain full control of DLM
They have probably made a rod for their own back with this approach. I don't see why they couldn't give some control to the SPs. There was talk a few years back that they were looking into it or considering it, but it all seems to have gone quiet.
>> they know that DLM will 'mask' problems, so by removing DLM's actions then the problems become visible again and a net result will be higher fault reports.
Agreed - it masks certain faults quite well. Conversely some issues could perhaps be resolved with a reset. The thing is there are some sensible ISPs, but some who would just push the button and hope that it fixes things.
>> how long people are expected to wait for g.inp is clearly way too excessive
Couldn't agree more. As mentioned above with wombat, the whole DLM structure needs a rework.
>> I dont know why openreach have done that config change as DLM wasnt like that at the start of g.inp rollout.
As mentioned, it was a botch job - a 'quick' fix to sort out the problem with the g.inp incompatible modems. IMHO they vastly under-estimated the amount of users that had eci modems and HH5A's etc.
>> I respect not everyone agrees with me there, and for that reason banding should not be permanent.
The problem is that it seems almost permanent and does cut in too soon. People wait for months and nothing seems to shift even if the line has improved.
-
1. I don't think DLM (as we understand it today) should attempt to be a fast-response vehicle. It should be slow and considered, and leave the line profile in a suitable base state there the modem & DSLAM can handle the fast response themselves.
DLM, designed to run remote from the DSLAM, can never hope to scale up enough to cope with fast-response requirements on so many DSLAMs. IMHO (as a writer of scalable, robust, remote software), the Irish pun applies: "I wouldn't start from here".
Far better to use something like SRA, and/or FRA in G.Fast. Something running live, in the modems.
1a. Note too that I think DLM ought to mask problems with a line. Not forever, of course, but sometimes having a working line is better than one that only ever resyncs.
Perhaps it should keep you informed as to whether it has restricted a line below the fault threshold.
2. DLM also works to some strange requirements: to attempt to keep a line in a state where the end user sees no artifacts (visual/audio glitches on TV; almost no packet loss on data), but doesn't really get feedback from that source. The human end-user never gets to add their feedback to this loop, and it might be beneficial. No-one gets asked about whether you care.
Perhaps this is restricted to that latency vs speed option, or perhaps it just asks a question: do you see any problems?
3. Finally, DLM gets one thing wrong that wasn't obvious back when we first started with VDSL2: Its first action is always to change the line profile in some manner ... which kinda assumes that something is wrong with the current line profile.
Nowadays, as we encounter higher takeup and power/reset of the DSLAM, we get plenty of lines running on a low SNR because of crosstalk. Or lines that endure high ES rates because of the port's chipset.
In cases like these, the first step is a simple resync, to regain the target SNRM, and maybe reset the port. No need for any intervention more severe than that as step 1.
-
Getting back on track here a bit about my line.... The other day I had a call which was supposed to be TalkTalk asking me to call about an open complaint. Now because this caller sounded like someone from the Indian sub-continent I ignored it just like all the spam calls I have been getting. However having asked my contact in BT who was handling my issue whether they contacted TT the answer was yes! So it probably was a genuine call, oh well serves them right for having an Indian call centre, how am I supposed to know if the call was genuine or not as I had not got an open complaint with them as far as I knew.
Stuart
-
Openreach will raise a complaint reference with your ISP as they are your provider etc. They usually will pass on findings back to the ISP. I used to get the exec complaints team at sky feeding back the same info that the openreach person had already told me....
-
Well DLM finally intervened last Saturday (after 14 days) to lower interleaving by about 50%, so now running at 59988kbps wit attainable at 74044kbps and around 6db downstream, suspiciously close to the 60000kbps cap. Having also heard nothing from TT despite asking on their forum what was going on I contacted my BT person who replied to say that they have heard nothing back from TT either and have escalated it. I wonder what speed I would get if DLM removed interleaving? Makes me wonder if an ISP can somehow affect maximum speed being allowed on a connection?
Stuart
-
ISP’s have zero control over any of the DLM parameters.
-
That's what I thought but there seems to be an issue here with my lime which keeps getting it capped despite very low error rates.
Stuart
-
ISPs can choose the DLM profile, from Speed, Standard and Stable (Openreach naming), so not quite no control.
The max attainable rate calculated while you have FEC+interleaving tends to be higher than what you could actually get.
-
I realise that DLM takes action after a reset, just that two weeks to reduce interleave by 50% with ES rate barely above 20 per day most days seems excessive especially if I have to wait another 2 weeks for the next drop which in my view should be fastpath. I should be back to around 65000kbps which I was originally last year when the removed G.INP from my ECI cabinet.
Stuart
-
What's actually changed, the INP and delay values? The interleaving depth changing doesn't necessarily indicate very much.
-
From what I can see of DLM in the past 1-2 years on fast path recovery is that on a first incident it will now recover very quickly within 1-2 days, if you waiting 20 days then its probably not a first incident and I agree with openreach that a repeat incident should take longer to recover. More speed is nice, but not when it results in instability.
The issue as I see it is the lack of manual override mechanisms in place rather than the speed of recovery, and of course how quick DLM reacts (often reacts after the event).
In the case of manual override where the customer gives their consent to risk the line been unstable, its fine to go ahead and force the issue, but with automated recoveries the customer has not given their consent to compromise stability which may be of real importance to them.
-
The whole problem with my interleaving was that the line was NOT unstable and had quite reasonable error rates well below the threshold for DLM to take action. However I had a few times quite close together with significant peaks in error rates which were caused by thunderstorms which DLM refused to accept as wide area events, probably because of my geographic location 130 feet up a hill about 800 yards from the Channel in east Kent and these thunderstorms were out in the Channel and on the French coast. It then did nothing to remove interleaving for several months, also ofcourse my line was being capped for speed for over 12 months with no recovery from that. None of this is acceptable and for my circumstances DLM is not fit for purpose.
Stuart
-
I have just had a re-sync and now connecting at 67000kbps so not banded and on fastpath. Now I dont know f this was another reset by BT or just DLM as I had waited over two weeks for DLM to take action again to reduce of remove interleaving and as it had not I emailed my contact in BT again to ask why, so this may be the result and if so will likely go round the DLM loop again for 4+ weeks!
As an aside I got a DSLStats alert email for the re-sync before MDWS has sent anything.
Stuart
-
As an aside I got a DSLStats alert email for the re-sync before MDWS has sent anything.
Stuart
It's plainly obvious there will be a delay in MDWS sending the mail as you are one user locally that can send the mail immediate whereas MDWS is looking after 200+ users and has to receive and then process it all via various timed processses that delay it by at least 2-3 minutes, not that that matters I would guess...
-
It's plainly obvious there will be a delay in MDWS sending the mail as you are one user locally that can send the mail immediate whereas MDWS is looking after 200+ users and has to receive and then process it all via various timed processses that delay it by at least 2-3 minutes, not that that matters I would guess...
Tony I totally understand and did indeed not expect anything different, I only mention it because in the past DSLStats has failed in sending a resync alert by email.
Stuart
-
lol it does happen
banding got removed today what the hell.
-
Just to say now I am getting plagued by caller from TalkTalk wanting to discuss this but they are unable to speak clear and understandable English so I have told TT that in future I will only discuss with a caller in the UK who speaks clear and understandable English! I wonder what will happen now? Is this too much to expect from a UK Company?
Stuart