Kitz Forum
Broadband Related => FTTC and FTTP Issues => Topic started by: les-70 on October 26, 2014, 11:18:31 AM
-
I think I am aware of Zen and Plusnet advice re the FTTC DLM and the general view of it being error seconds and 0.5, 1.0 or 2 per minute being possible thresholds.
I therefore looked through all the non interleaved FTTC connections in my dslwebstats to see who had FTTC and what the max ES rates were for non interleaved connections. i think the winner with most errors but on fast path is BaldEagle1 :clap: and his ES rate looks to be a bit over 30/hour. I am sure he could give an accurate figure. It looks like no one exceeds much more than about 30-40/hour as an average and if no one is at a higher rate then I assume more than 30-40 will lead to intervention. This makes me suspicious that that is the actual threshold for most on us. If we get a big enough sample I think that mydslwebstats is good way of testing reality.
My failure :-[ :( was to also check re capped speeds and check the number of interleaved and non interleaved connections. Maybe another day or someone else!
-
I see. Also take into consideration the possibility of the DLM profile not being same for every connection.
I'm not sure if someone has posted it a while ago, but I stumbled into an FTTC training doc, a little old but nonetheless has the same information regarding DLM. http://johnboyle.me.uk/joomlazen/images/resources/tech_info_fibre/FTTC%20Training%20Doc%20(MWright).docx
It mentions what DLM takes into consideration, a table of the MTBE and such like (good and bad thresholds, not just bad thresholds), colour coding that DLM does, and so on. Whether it's accurate, well, don't ask me. So far though I'd say for my own connection it seems reasonably accurate. I'm currently on 49/15 (can easily get 80/20, but lost the sync a few days ago due to multiple re-syncs by the ASUS router on buggy firmware in the early hours of the morning). DLM hasn't relented yet, but I have a hunch that DLM isn't relenting because my error seconds aren't below the 'good threshold' (which I worked out from the MTBE to be 'less than 288 error seconds' I think) for the speed profile. But it might also be that I have a barrier and must wait a bit longer, we'll see. I do have the ECI /r modem, so if it doesn't budge in a week or so then I'll plug that back in and see what happens.
-
its 2880 I am very sure of it.
Someone on tbb posted they were fast path with 27xx and then interleaved at 28xx.
-
I am surprised at that given the mydslwebsats cases. There are certainly a lot of issues but my feeling is that the highest sustained error rates on not-interleaved and not-capped lines ought to give a good guide to practical values of errors that your not likely to be able to exceed for very many days.
The biggest complication maybe not knowing which of the three DLM settings apply to people. That said I am surprised that no one seems to be beating Baldeagle1's 30-40 ES/hour. No one gets near the 120 corresponding to 2880.
I am thinking of having a go at beating Baldeagle1 :-X I get similar or slightly greater values of errors when running without a speed cap. I suspect the result will be interleaving but it is worth a try.
-
FWIW, my connection very rarely ran on fastpath when it could achieve higher speeds (i.e. before crosstalk reduced them).
That was undoubtedly due to significantly higher error counts, causing interleaving to be applied.
On the lower speeds & since the October 2013 firmware updates, my connection is now on fastpath for the majority of the time with typically around 900 - 1000 DS Error Seconds, 6000 DS RSUnCorr & 1300 DS CRC errors per day.
Interleaved at around 30 Mbps, I would typically see only around DS 110 Error Seconds & low totals of DS RSUnCorr & DS CRC errors.
-
I have just started my un-capped test run with a sync of about 72Mb/s. I am expecting from recent short tests an ES rate of about 15/hour at quiet times peaking to about 120/hour in the early evening period. I do not like to guess the 24 hour average error rate as I have not run it like that for long. My best shot is ~40ES/hour.
I will give it week or until the DLM notices!
-
A question for BE1 or anyone
Which do you prefer a DS sync @ 22300 Kbps non interleved or DS sync @ 30000 kbps interleaved ?
As you know my downstream has never been moved onto fastpath since day 1 with infininty thats going on 3 years now, I could capp my line to 25000 kbps for a month or two and see if the DS get's moved onto fastpath It's just I don't know what a non interleaved DS line feels like.
-
As I'm not an online gamer, latency isn't really an issue for me.
Therefore my preference would be 30000 kbps interleaved for faster downloads.
Along with the higher interleaved DS sync speed, I also had a higher US fastpath sync speed of 5700 kbps compared to today's 4300 kbps, which helped when uploading large files to the office when working from home.
-
As I'm not an online gamer, latency isn't really an issue for me.
Therefore my preference would be 30000 kbps interleaved for faster downloads.
Thanks BE1 my online gaming days are non existence these days but still enjoy an offline game here and there, i'll not be in a hurry to get DS fastpath so i'll stick with what i have ;)
PS hope you had a good holiday as we are deffo back to long winter nights again :(
-
A question for BE1 or anyone
Which do you prefer a DS sync @ 22300 Kbps non interleved or DS sync @ 30000 kbps interleaved ?
As you know my downstream has never been moved onto fastpath since day 1 with infininty thats going on 3 years now, I could capp my line to 25000 kbps for a month or two and see if the DS get's moved onto fastpath It's just I don't know what a non interleaved DS line feels like.
in your case I would probably prefer the 22.3 but when downloading large games etc. the extra 7mbit can help so I guess isnt clearcut, but it depends how you use the connection really.
Lower latency speeds up web browsing as web browsing is latency sensitive, it will improve the experience of ftp, cli ssh, it will keep gamers happier who like lower latency, it can also help downloads because downloads can be rtt limited. My experience is that also netflix buffers up to super hd quicker as well.
If you were to ask me would I have 70mbit interleaved or 60 fast path, that is a definite no brainer. Your question is a bit harder as 30 vs 22 is a bigger %.
It is a shame you cannot choose target snrm on FTTC, then you could choose maybe 9db and have fast path. We also seen on kitz line recently the extra snrm on fast path was just as effective as interleaving in mitigating her errors.
-
A question for BE1 or anyone
Which do you prefer a DS sync @ 22300 Kbps non interleved or DS sync @ 30000 kbps interleaved ?
As you know my downstream has never been moved onto fastpath since day 1 with infininty thats going on 3 years now, I could capp my line to 25000 kbps for a month or two and see if the DS get's moved onto fastpath It's just I don't know what a non interleaved DS line feels like.
in your case I would probably prefer the 22.3 but when downloading large games etc. the extra 7mbit can help so I guess isnt clearcut, but it depends how you use the connection really.
Lower latency speeds up web browsing as web browsing is latency sensitive, it will improve the experience of ftp, cli ssh, it will keep gamers happier who like lower latency, it can also help downloads because downloads can be rtt limited. My experience is that also netflix buffers up to super hd quicker as well.
If you were to ask me would I have 70mbit interleaved or 60 fast path, that is a definite no brainer. Your question is a bit harder as 30 vs 22 is a bigger %.
It is a shame you cannot choose target snrm on FTTC, then you could choose maybe 9db and have fast path. We also seen on kitz line recently the extra snrm on fast path was just as effective as interleaving in mitigating her errors.
Interestingly you can choose target SNRM on the ASUS DSL-AC68U, I've tried it and it works. I'm trying to get my capped sync profile lifted, but I think my ES isn't below the 'good' threshold so DLM currently won't increase the profile after it was decreased some days ago from 74/20 to 49/15 due to previous version of ASUS firmware causing multiple re-syncs in the early hours. Either that or I'm once again stuck on 49/15 for a year or more. So frustrating that ISP's don't have the ability to reset DLM years later from Infinity being rolled out.
-
yeah if I understand that info right then ES needs to be below 288 to get a DLM reversal?
-
Looking at the collection of lines on mydslwebstats I think there are many FTTC lines that seem stuck on their current banded or interleaved states with ES quite a bit less than 288. Again the reality depicted by lines on mydslwebstats does not seem to match the 2880 theory. ??? If your on an band most should be in that band e.g. 288-2880 for the fast band.
The expected ranges according to the doc are either 72-720, 144-1440, or the 288 to 2880. mydslwebstats suggest not many or any are on the 288-2880 band. Zen may be an exception I did not look who might be on Zen. I suspect most may be on 144-1440.
-
well plusnet claimed earlier in the year when asked people are on the speed profile, would they lie, or have they misjudged who knows?
I estimated kitz last week to have less than 2880ES when she got interleaved but unfortunately she never confirmed that 24H stats from her router.
I think its not 100% accurate to guess daily ES from those graphs tho.
I think people only get unbanded if they syncing at the max cap of the band. I am more referring to interleaving levels.
-
well plusnet claimed earlier in the year when asked people are on the speed profile, would they lie, or have they misjudged who knows?
I estimated kitz last week to have less than 2880ES when she got interleaved but unfortunately she never confirmed that 24H stats from her router.
I think its not 100% accurate to guess daily ES from those graphs tho.
I think people only get unbanded if they syncing at the max cap of the band. I am more referring to interleaving levels.
It's all confusing, as I expect there's more to the DLM algorithm than just those ranges. The training doc states that it also takes into account the history of the line, the FEC count, and variations in things such as the rate (presumably either attainable rate or sync rate, not sure), that's assuming it's all accurate information.
Unfortunately the unbanding didn't work that way for me. More than a year ago I was stuck on 60/20 although I had an attainable rate of over 90 meg down. Around late December 2013 to January 2014 I was back at 80/20. I wasn't interleaved on either band. Suffice to say it took several months before I managed to get 80/20 back, either due to a reset that was performed at the cabinet perhaps (firmware upgrade rolling out at the time for the HG612?), or something relating to DLM's algorithm decided to let me have 80/20 again.
As it stands, at the moment I'm officially below the estimates on both clean and impacted ranges. Attainables are currently 98 meg down and 21 meg up (reduced transmit power which increased the downstream attainable rate but reduced the upstream attainable rate, obviously relating to the attempt to cut down the number of ES on my connection - though ASUS doesn't report an accurate number I'm trying to count it by other means). I may return to the ECI /r if it doesn't relent in a couple of days. Another idea I had was what happened if interleaving was put on my connection, perhaps after a few weeks DLM might then unband and remove interleaving at the same time (as my connection ES should be within '< 288').
-
I am with TTB and have been speaking with two levels of their technical support. It seems that all TT FTTC lines home and business are on standard and not speed. It also seems impossible to get it changed with them. They said they have set up their systems so the option is simply not available and the policy is not to allow it.
With Plusnet I don't recall seeing anything so explicit. I wonder if confusion is easy as the FTTC DLM settings may have different names to the adsl ones.
-
I estimated kitz last week to have less than 2880ES when she got interleaved but unfortunately she never confirmed that 24H stats from her router.
I think its not 100% accurate to guess daily ES from those graphs tho.
I think people only get unbanded if they syncing at the max cap of the band. I am more referring to interleaving levels.
Sorry not had time to play with any figures, but what I have done is compiled a text file which shows each days error count during the period of my line problem.
If you want to do the maths - feel free :)
---------
ETA just realised I forgot to add the 17ths in too - now reuploaded new file.
-
The training doc states that it also takes into account the history of the line, the FEC count, and variations in things such as the rate (presumably either attainable rate or sync rate, not sure), that's assuming it's all accurate information.
I too have seen a document that says it takes into account line history. A line which has never been interleaved or banded before will recover much quicker than one which has a troublesome history.
-
The training doc states that it also takes into account the history of the line, the FEC count, and variations in things such as the rate (presumably either attainable rate or sync rate, not sure), that's assuming it's all accurate information.
I too have seen a document that says it takes into account line history. A line which has never been interleaved or banded before will recover much quicker than one which has a troublesome history.
This may explain why it took several months before I returned from 60/20 fastpath to 80/20 fastpath, possibly.
-
well plusnet claimed earlier in the year when asked people are on the speed profile, would they lie, or have they misjudged who knows?
I estimated kitz last week to have less than 2880ES when she got interleaved but unfortunately she never confirmed that 24H stats from her router.
I think its not 100% accurate to guess daily ES from those graphs tho.
I think people only get unbanded if they syncing at the max cap of the band. I am more referring to interleaving levels.
As I noted in the post a few above it looks like all TT FTTC is on standard. I recall the Plusnet default also being standard but I can find a reference at the moment. I still think it may be good advice to take 1440/day as the limit even if it is for safety.
Your right that estimating averages from mydslwebstats is not easy and unless the sampling is continuous 24/7 almost impossible. I do still stand by my comment that it is odd that no one looks to reach more than 30-40/hour unless almost all have a limit of 60/hour. There are probably more DLM hit users than not so many must have tested and gone through the limits. If the limit was 120/hour I am sure there should be some cases with more than 30-40/hour.
It does look like Kitz went over all the limits when the DLM hit. Kitz then ended up back in the green for any of the limits when it fully recovered so we can't say much from her case.
-
Well Les-70 looking at MDWS @ SNRM over 24/7 I must be the biggest swinger in town :D
-
kitz you had exactly 2788 ES on the US for many days in a row? that seems very odd as if a bug.
-
The training doc states that it also takes into account the history of the line, the FEC count, and variations in things such as the rate (presumably either attainable rate or sync rate, not sure), that's assuming it's all accurate information.
I too have seen a document that says it takes into account line history. A line which has never been interleaved or banded before will recover much quicker than one which has a troublesome history.
yes it will have a lower requirement for # of days in GREEN status. I dont think the thresholds change just the # of days required.
-
kitz you had exactly 2788 ES on the US for many days in a row? that seems very odd as if a bug.
No its not a bug - those are my cumulative figures.
Since they fixed whatever it was Ive not had any more US Errs - and my US ES count has stayed the same for days. Same with the CRCs, Ive not had any US CRCs for days either.
To find the days total you have to subtract the current day from the previous day - which is why I said I hadnt had time to do the maths to find out each individual days total.
Theres also one day when the figures will be skewy and thats I think a week last Friday when I put the HG612 on and I left the line without any sync for a few hours whilst I was out before swapping the router over.
-
I dont think the thresholds change just the # of days required.
I'd agree with that. This will have been my first real run-in with the DLM and it started to correct itself as soon as Id had one full good day.
Same with adslmax when he got clobbered the other month. iirc it was his first time of being hit with the DLM too and he was back to normal 2 days later (ie one full day of the line behaving.
The one figure for sure that doesnt seem to tally is the 20 syncs. adslmax did 5 to get hit. His ErrSecs were ridiculously low, like about 10 so it cant have been that.
Plusnet supplied a copy of his RADIUS log for the past week and you could see from that that he did indeed only have 5 resyncs whilst swapping out routers. iirc there were a couple of PPP disconnects too, because he was trying to get on to a BNG, but the DLM isnt supposed to be able to see those.. and anyway even if you did count the PPP re-connects it was still waaaaay under 20.
Ive seen too many others get clobbered way before 20 too.
-
With Plusnet I don't recall seeing anything so explicit. I wonder if confusion is easy as the FTTC DLM settings may have different names to the adsl ones.
I asked last year - the reply I got from MattTaylor is here
http://community.plus.net/forum/index.php/topic,116753.msg1031733.html#msg1031733
-
The TTB technical support said his screen showed my FTTC set at standard. He had no options at all to change anything. He then got through to provisioning who said they always provision on the BT/OR standard setting of standard and that they have a policy of not allowing other profiles. He implied that the provisioning chap said there was a speed profile but I find ISP answers can be hard to really evaluate and rely on. They give answers but are not always right! The Plusnet reply looks clearer but i still wonder.
If we find someone on Plusnet with average errors of more than 60/hour for at least a few days and not DLM'd then I would tend to believe Plusnet is on Speed. As it is, mydslwebstats has only one - Baldeagle_1 over about 30/hour and he is banded, and next two others in the range 20-30 and not DLM's -- 120/Hour just does not look like what is actually hitting people. There are also as well many DLM'd with ES/hour always less than both 12 and 6 who seem stuck with the DLM. These lmay or may not be explained by memory of the past.
As you say its the same with resyncs, The exact numbers do not quite add up.
-
kitz you had exactly 2788 ES on the US for many days in a row? that seems very odd as if a bug.
No its not a bug - those are my cumulative figures.
Since they fixed whatever it was Ive not had any more US Errs - and my US ES count has stayed the same for days. Same with the CRCs, Ive not had any US CRCs for days either.
To find the days total you have to subtract the current day from the previous day - which is why I said I hadnt had time to do the maths to find out each individual days total.
Theres also one day when the figures will be skewy and thats I think a week last Friday when I put the HG612 on and I left the line without any sync for a few hours whilst I was out before swapping the router over.
ok so the data you provided you only had a couple of days of errors then your line turned pristine with 0 on US :)
regardless the 2 days of errors was below 2880, did those 2 days DLM act?
-
I dont think the thresholds change just the # of days required.
I'd agree with that. This will have been my first real run-in with the DLM and it started to correct itself as soon as Id had one full good day.
Same with adslmax when he got clobbered the other month. iirc it was his first time of being hit with the DLM too and he was back to normal 2 days later (ie one full day of the line behaving.
The one figure for sure that doesnt seem to tally is the 20 syncs. adslmax did 5 to get hit. His ErrSecs were ridiculously low, like about 10 so it cant have been that.
Plusnet supplied a copy of his RADIUS log for the past week and you could see from that that he did indeed only have 5 resyncs whilst swapping out routers. iirc there were a couple of PPP disconnects too, because he was trying to get on to a BNG, but the DLM isnt supposed to be able to see those.. and anyway even if you did count the PPP re-connects it was still waaaaay under 20.
Ive seen too many others get clobbered way before 20 too.
also my first time with DLM I know I recovered quickly, not quite as quick as you guys but I am pretty sure was under a week.
-
The TTB technical support said his screen showed my FTTC set at standard. He had no options at all to change anything. He then got through to provisioning who said they always provision on the BT/OR standard setting of standard and that they have a policy of not allowing other profiles. He implied that the provisioning chap said there was a speed profile but I find ISP answers can be hard to really evaluate and rely on. They give answers but are not always right! The Plusnet reply looks clearer but i still wonder.
If we find someone on Plusnet with average errors of more than 60/hour for at least a few days and not DLM'd then I would tend to believe Plusnet is on Speed. As it is, mydslwebstats has only one - Baldeagle_1 over about 30/hour and he is banded, and next two others in the range 20-30 and not DLM's -- 120/Hour just does not look like what is actually hitting people. There are also as well many DLM'd with ES/hour always less than both 12 and 6 who seem stuck with the DLM. These lmay or may not be explained by memory of the past.
As you say its the same with resyncs, The exact numbers do not quite add up.
There is one thing that happened, that may shed some light but it wont be reliable.
When I migrated to plusnet within a week I was interleaved on a line that was on fast path for several months on infinity. I also made a post on plusnet's forums asking if plusnet were using a different DLM profile to BT and the reply I got was along the lines no they use the most passive profile, but i cant be bothered to find that post now.
If all of us plusnet peeps are indeed on the middle profile then that would be 10 disconnects and 1440 ES for DLM action?
Also plusnet cannot see loss of sync events, they can only see loss of PPP.
-
mdslwebsats is a mix of ISP's but more or less consistent with 1440 i.e. 60/hour average as a probable limit and probably need for a sustained less than 6/hour average to recover. Until we can be really sure I think 1440 is much safer guide figure.
On mydslstats there are about 7 non-interleaved in the range 20-40 ES/hours where the ES/hours, as noted above, are have to precisely estimate. No one is above ~40/hour, I guess if they were then an odd bad day or two would lead to DLM action.
I guess the 6 to recover is so low as interleaving markedly reduces errors and without a low limit, for good, things would just switch on and off.
!0 disconnects is still more than the 5 or so some have observed but it is easy to forget what messing around may have occurred the day before and still be in a 24/hour time span.
-
Im afraid I really dont have time atm to look at the figures. I possibly buggered totals up a bit too because I swapped out routers a couple of time to make sure it wasnt hardware at my end. I also left the router without sync for a few hours -it was Sat not Friday that I swapped routers, but iirc Id also done a full system boot on the Friday just also to ensure it wasnt the Zyxel that had got itself in a tizz after the outage (Several routers do this after electrical outages - but it wasnt that either)
To find out exactly how many errsecs there are, then it would need something like DSLstats or HG612 to automatically count the totals at midnight which is when the DLM averages out the days totals.
Ive had a quick look and according to that on the first day (17th) I had 2453 Err Secs.
The next morning the DLM applied interleaving depth 357 & INP 3
On the 18th I had 2839 ErrSecs but apprx three 3hrs without sync whilst I swapped routers out.
For that the DLM changes Interleaving depth to 325 & rate limited the line to 17Mb
Im afraid you'll have to wait until I get chance to look and break down the other days.
One thing I did notice which I dont know if is co-incidence or not with the rate limiting, is that on each of the profiles my SNRm seemed to be damn near to either 6dB, 9dB or 12dB. Again something I will have to check when I get chance.
-
!0 disconnects is still more than the 5 or so some have observed but it is easy to forget what messing around may have occurred the day before and still be in a 24/hour time span
Thats why it was handy to see adslmax's RADIUS log, and whilst chrys said that PN cant see the loss of sync as such. If everything is working correctly then loss of sync should also cause loss of PPP session. It was also pretty easy to spot as you could see he'd left the router off approx each time he swapped over routers, thinking 10-15 mins would be long enough to avoid DLM action.
My RADIUS log has picked up all my loss of syncs over last week.
-
I guess this depends on the router, on my asus if I lose sync only momentarily the ppp will survive 90% of the time. It usually needs an actual sync outage to drop the ppp. My PPP seems to drop at least 2-3 times a month completely of its own accord, whether that's plusnet rebalancing, BTw maintenance or something else I dont know.
I guess one of us should query again on the plusnet forum which profile they using but I think they wont be too open about it. Someone higher up may have decided its easier on their tech support department to deal with moaners about interleaving instead of having more unstable lines.
-
Bear in mind that interleaving depth isn't an accurate metric of what DLM's doing to your connection, as the sync rate adjusts that value. The speed band (if any), INP and delay are generally the values I'd suggest observing.
-
Thats why it was handy to see adslmax's RADIUS log, and whilst chrys said that PN cant see the loss of sync as such. If everything is working correctly then loss of sync should also cause loss of PPP session. It was also pretty easy to spot as you could see he'd left the router off approx each time he swapped over routers, thinking 10-15 mins would be long enough to avoid DLM action.
The trouble is that not everything works correctly.
When I first wrote the connection logging scripts due to my very unstable connection at that time, I could see numerous connection resyncs at differing speeds.
However, PlusNet could only see an occasional PPP disconnect/reconnect in their Radius logs.
They obviously initially argued that my connection was in fact stable & didn't warrant further investigation.
EVENTUALLY, they came round to accepting that the HG612 modem would often resync quicker than their PPP session timeout settings & thus their Radius logs were not a reliable tool for measuring the actual number of resyncs.
I think we are all now aware that this potential issue is mentioned in BT's SIN498 documentation.
My RADIUS log has picked up all my loss of syncs over last week.
Was that when using the combined ZyXel modem/router?
If so, I would imagine that a resync would also disconnect/reconnect the PPP session as per a typical ADSL combined modem/router.
Still using a HG612 modem with my original Netgear WNR 1000v3 router, my connection doesn't resync very often these days & when it does, the PPP session is still often retained (confirmed by the dynamically allocated IP address & BT's IP profile remaining unchanged).
i.e. I still have to sometimes manually force a new PPP session via my Netgear router in order to initiate a new PPP session so that BT will send a delta report for PlusNet to adjust their own profile.
-
Also there could have been a period on adslmax's line where he had several resync in one short period that plusnet just seen as one PPP outage because the uptime was never long enough to establish a new ppp session.
-
To find out exactly how many errsecs there are, then it would need something like DSLstats or HG612 to automatically count the totals at midnight which is when the DLM averages out the days totals.
That was fairly easy to do in MDWS as the needed data is there just before it's plotted.... As an experiment only I've changed the standard ES graph to show both Total and Average figures for Downstream only ES along with the usual hourly totals. The average data and totalling starts at 01:00 with the 00:00-01:00 hour's total and is plotted each hour until reset after the 23:00-00:00 totals are shown.
To be accurate it needs a complete 24 hours worth of data with no downtime on the graph. Otherwise the results are not accurate as it just uses the data that's there. Showing several days at a time is possibly the best way.
So there are four plots which may need a bit of close eyeball work for low values but I believe the idea here is to see higher values when it is much easier to decipher. Dragging a small area horizontally will zoom it if needed.
If it's of any use or preferred I can split it out into two new sets of graphs so you'll have ES (Normal), ES DS AVg+Totals and ES US AVg+Totals.
Attached is a composite plot for 3 days for BE1....
-
That looks really good for the always on users. It is quite likely that I have missed one but, over the last 10 days the biggest fast path 24 hours I can find are about 900ES/day on just odd days and very few are above 800ES/day.
If you look at my 10 day plot you will see what is probably the inevitable consequence of intermittent logging, maybe it can be improved a bit but the needed info to be complete just not available to you. I think it may be time to invest in a Rb Pi.
-
To find out exactly how many errsecs there are, then it would need something like DSLstats or HG612 to automatically count the totals at midnight which is when the DLM averages out the days totals.
That was fairly easy to do in MDWS as the needed data is there just before it's plotted.... As an experiment only I've changed the standard ES graph to show both Total and Average figures for Downstream only ES along with the usual hourly totals. The average data and totalling starts at 01:00 with the 00:00-01:00 hour's total and is plotted each hour until reset after the 23:00-00:00 totals are shown.
To be accurate it needs a complete 24 hours worth of data with no downtime on the graph. Otherwise the results are not accurate as it just uses the data that's there. Showing several days at a time is possibly the best way.
So there are four plots which may need a bit of close eyeball work for low values but I believe the idea here is to see higher values when it is much easier to decipher. Dragging a small area horizontally will zoom it if needed.
If it's of any use or preferred I can split it out into two new sets of graphs so you'll have ES (Normal), ES DS AVg+Totals and ES US AVg+Totals.
Attached is a composite plot for 3 days for BE1....
nice job, can you add a column to display the hardware used (when known), I would guess its possible to get of ronski's app as I have to select which modem I am using so its stored in the config.
-
Nice job, can you add a column to display the hardware used (when known), I would guess its possible to get of ronski's app as I have to select which modem I am using so its stored in the config.
Sorry, nope, don't know it as it's not available in any of the uploaded data.....
-
If you look at my 10 day plot you will see what is probably the inevitable consequence of intermittent logging, maybe it can be improved a bit but the needed info to be complete just not available to you. I think it may be time to invest in a Rb Pi.
See if it's any better now..... It can still go wrong but looks more like it should :) I've set it to reset if the hours value is less than the last plot's hours and not 0.
-
Thanks, as you say that is much better. :) I don't know exactly what is uploaded or whether you base stats just on errors within 1 minute, but if ES since link is uploaded, tracking the change in that total ES might give a better ES/hour with intermittent uploads.
(I am doing some HG635 testing at the moment and consequently not uploading.)
-
To find out exactly how many errsecs there are, then it would need something like DSLstats or HG612 to automatically count the totals at midnight which is when the DLM averages out the days totals.
That was fairly easy to do in MDWS as the needed data is there just before it's plotted.... As an experiment only I've changed the standard ES graph to show both Total and Average figures for Downstream only ES along with the usual hourly totals.
That is brilliant.. because it fits nicely with something else I had in minde :clap2:
Once you have some figures to play with.. this may be of use :-
http://www.kitz.co.uk/adsl/DLM_calculator.php
The average data and totalling starts at 01:00 with the 00:00-01:00 hour's total and is plotted each hour until reset after the 23:00-00:00 totals are shown.
Information seems to suggest that the DLM starts at midnight, so should work well. Over the past week Ive been trying to dig out anything and everything I can about the DLM, theres also some contradictions on some of the info I have found, but I guess we just have to do what we can with what we can.. and guess at the rest :D
To be accurate it needs a complete 24 hours worth of data with no downtime on the graph. Otherwise the results are not accurate as it just uses the data that's there. Showing several days at a time is possibly the best way.
Indeed, but genuine downtime can and will be adjusted accordingly by the DLM. The calculator should also for 15 min bins same as the DLM. I need to revisit rounding, so for the time being Ive left it with simple rounding to 2 decimal points. :D I can only stress its beta atm, and something Ive put together tonight after I got home.
I wont have chance to do anything more on it now for several days... but theres a few things I want to try and contact a couple of people about to clarify with, but that will have to wait as my dad is very ill :'( Ziggs is also poorly and dunno whats happening atm. I have him home tonight, but hes got to go back at 8:30 tomorrow. Ive also just got results back for my annual checkup and it looks like I'll also be back in hospital sometime soon. ::)
-
This is a real quicky which chrys may be interested in. Dont have time to put all info.. but you know that 5,10,20 figure for resyncs that gets quoted.. well in one of the docs Ive read there was something about 'grey' ie its a fast track down the DLM scale for really troublesome lines.
When I coded the DLM calculater I noticed that for the MTBR it seems to suggest 10 resyncs is about all you can get away with.
I checked and double checked and it appears to be calculating correctly. Ive done a search to find out if there is any more sets of MTBR figures then I noticed this on the Plusnet site linky (http://community.plus.net/library/broadband/broadband-faults-guide-our-testing/)
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fcommunity.plus.net%2Fwp-content%2Fuploads%2F2013%2F11%2FLine-Quality.jpg&hash=0a8c298528d5b66674882441ccea80cef9d737db)
Zoom in and see what it says for ILQ Scarlet.
Im going to attempt to contact a couple of people but as mentioned previously, I wont have chance now until when Im not sure ... at least until after the weekend :/
-
I did read the zen doc which shows there is more than just green and red status, there is some other colour codes as well, interestingly if a line exceeds the resync threshold DLM will always assume its a DS issue and will not take action on the US for resyncs.
I have been wondering now if its BTw policy to use the standard not speed profile on FTTC and isp's have just been assuming standard=speed but never had it verified?
-
Back to the observations. Here (I think) are all the connections on fast path exceeding 480/day at least once in the last 10 days, there are no higher fast path values per day. Below the number of errors per day is shown for each line. I don't think Chrysalis should really be on the list as it looks like he had just one odd bad event.
I believe that if I run my connection uncapped at full sync with the HG612 I will get about 500 and with the Billion about 750. I would say that if you go over 1000 much you should expect the odd bad day to take you interleaved when you hit the standard level of 1440/day.
AnnM 944 F
Baldeagle 1100 F
Crowroad 786 F
Nb99999 526 F
Nokiboi39 744 F
Chrysalis 554 only odd day F
Vdsl user 682 F
I may do an analysis of those interleaved. My impression, just looking as I went through all the lines, is that once interleaved you seem to need very very low error rates to recover and lower than the 144/day suggested in the Zen doc. Interleaving may of course manage to achieve that.
-
yesterday was a lot of rain, I seemed to have a larger amount of ES than normal, but who knows, as every afternoon I am getting bursts of CRC's which started about half a week or so after I had my new pair put in, which seems to coincide with the dentist across the road doing some major rebuilding work.
I think the 2880/day theory per day on speed is correct, so my theory is now that plusnet (who supply most members on this site) are not using the speed profile.
-
I somewhat would agree with your theory, be it intentional or be down to BT wholesale who apparently they have to go via to action this sort of thing, currently my line is interleaved due to some random interference that caused a lot of errors and packet loss , over 14 days ago, i have swapped modems so i could get some idea as to why I'm not back on fast path again, over the past 2 days there have been 0 crc's and 0 error seconds generated on the DS DLM is a joke IMO
-
I somewhat would agree with your theory, be it intentional or be down to BT wholesale who apparently they have to go via to action this sort of thing, currently my line is interleaved due to some random interference that caused a lot of errors and packet loss , over 14 days ago, i have swapped modems so i could get some idea as to why I'm not back on fast path again, over the past 2 days there have been 0 crc's and 0 error seconds generated on the DS DLM is a joke IMO
DLM is indeed a joke. I believe I'm now stuck on a banded profile again, although fastpath, 49/15. Been like this for quite a few days now, I was stuck on 60/20 for several months before it gave me 80/20 around the start of January this year. Maybe it'll recover again at the beginning of January? Definitely below the estimate either way. :help:
-
An analysis of the interleaved FTTC connections, 12 of them I think with 10 day stats, rather than the 22 with fast fast path is not encouraging! Noting the error rates of 1,2,3 hour as 24 48 and 72 per 24 hours there are 5 interleaved lines with a max value in the 10 days of more than 72/hour, 3 >48 but <72, 3 >24 but<48 and just one at 23. The one at 23 garypower had a slight reduction in interleaving depth in the 10 days. No one else had any change in interleaving. Morphium had 9 days with a max of 17/24hours but one day at 37.
It looks like once your interleaved you may need to sustain less than 1ES/hour to recover to fast path!!! :-X. Interleaving can give a big error rate reduction but 1/hour does not sound much to me.
I suspect that the Zen doc. lower green band, which for standard would be 6/hour, might apply to a banded line but it looks quite unrealistic for those on interleaving.
-
Where did zen get this info ? openreach or some other 3rd party or did they make it up?
-
Morphium had 9 days with a max of 17/24hours but one day at 37.
He's in Switzerland 8)
-
An analysis of the interleaved FTTC connections, 12 of them I think with 10 day stats, rather than the 22 with fast fast path is not encouraging! Noting the error rates of 1,2,3 hour as 24 48 and 72 per 24 hours there are 5 interleaved lines with a max value in the 10 days of more than 72/hour, 3 >48 but <72, 3 >24 but<48 and just one at 23. The one at 23 garypower had a slight reduction in interleaving depth in the 10 days. No one else had any change in interleaving. Morphium had 9 days with a max of 17/24hours but one day at 37.
It looks like once your interleaved you may need to sustain less than 1ES/hour to recover to fast path!!! :-X. Interleaving can give a big error rate reduction but 1/hour does not sound much to me.
I suspect that the Zen doc. lower green band, which for standard would be 6/hour, might apply to a banded line but it looks quite unrealistic for those on interleaving.
bear in mind every time I have been interleaved I have recovered. My error rates whilst interleaved were something like 0-5 CRC/ES a day. #It is understandable why the recovery target rates are so low, its to avoid lines flapping in between fast path and interleaving which is far from desirable. They have to be reasonably sure that a line that recovers isnt going to keep flapping.
-
One extra observation is that judging by the relation between attainables and actuals I think only ixel looks to be speed capped by the DLM. I can't help wondering how the DLM might decide between interleaving and a speed cap.
-
I bet it's based on resyncs.
-
another thing that will band a connection is if it syncs too low then the banding gets reduced so the aim is for the sync to be close to middle of banding as possible.
-
I bet it's based on resyncs.
That's also my theory. If the MTBR is exceeded then banding is most certainly used. If the MTBE is exceeded then most certainly INP and delay are used, but possibly banding as well depending on the severity. So far I'm not convinced the MK3 has managed to reduce the trickling CRC's I'm getting, but it's early days. I'm on the HG612 at the moment due to instability occuring yesterday on the ASUS (graphs on other thread), you may have already noticed my username on MyDSLWebStats.
-
Ronski who has had interleaved ES/day rates between 22 and 84 went fast path today. That suggest the value for a change is probably bigger than the 1/hour suggested above. Maybe it really is 6/hour but with a history dependence that can mask seeing that as the actual value?
-
I see. I suspect for a connection on the 'stable' OR DLM profile, that it is 6/hr (144/day) or less than that depending on the line history and perhaps the FEC (if the training doc is correct). I'm trying to keep my ES below 288, it's pretty bad that an ES is counted for just 1-2 CRC's as that's hardly unstable. I haven't been able to isolate the cause of this, just wish the ECI /r has reliable statistics. I'm not keen on capping the connection further than what DLM is currently capping it at (49/15) as it might well encourage DLM to set a lower banding, capping me further. My theory is that the banding won't lift unless my ES is below a certain amount.
I'm also studying the ASUS TC Console app at the moment, trying to get the statistics from that to work with my graphing app (as the TC Console reports error seconds).
-
My HG612 consistently gives the lowest error rates and my line generates enough errors for errors to be the significant factor in deciding which modem to use. The ECI may be better or worse but if I can't see the ES I don't like using a device.
-
It appears DLM has raised my upload speed banding, from 15Mbps~ to 19Mbps~. It looks like the theory of keeping the ES below the good threshold in order to raise the speed banding may be correct, as DLM didn't lift it previously so I guess the ES was above the supposed rate of 288 daily on the 'speed' OR DLM profile (though I suspect there's some mathematical formula that takes FEC and other factors into account - FEC wasn't much yesterday either). My ES yesterday was 203.
This may also explain why I was stuck on 60/20 for several months when I experimented with capping a while back. Eventually I must've encountered a day, or a couple of days, where ES was below the good threshold (factoring in line history and FEC count - according to that training document) and so DLM raised the profile to 80/20. If I can keep ES below 288 in 24 hours then I imagine DLM will intervene again in the next day or two.
-
I've gone back to the ECI /r this morning. Although I can't currently log any statistics from it (due to the way it's connected up, unless I can telnet from the DSL-AC68U via the WAN port to it), not to mention the statistics last I recall aren't entirely reliable anyway, I will leave it connected for a week or so and see if DLM increases the speed banding.
EDIT: I've put the HG612 back on again for 24-48 hours as the ferrite toroid has arrived. I've done 5 turns. Statistics available on MyDSLWebStats under 'Ixel', though so far I can't say it has made much difference to the intermittent CRC's, but it's early days I guess. QLN on DS3 looks smoother however.
-
I am back down to circa 150 ES day now even on weekdays with no sudden bursts of CRC.
The people across the road started digging holes and I thought next was concrete for the car park, but today they finished up and gone. No car park built. They even removed a small shed type building did some work there and put it back after, odd.
However it has also been dry the last 2-3 days so this also could be related to the weather.
-
I notice one person AnnM has exceeded 1440/day on two unusually bad days and, with no resync yet, is still on fast path. May have been local thunderstorms --- if so some say the DLM recognizes all lines are suffering and ignores it.
-
or its possible 2880 is the actual limit, what isp is AnnM on?
-
MDWS does not show the isp on the AnnM line. When I see rather more than just these two excursions over 1440 on MDWS i will believe in the 2880 values. Apart from that exception, so far, no one occupies the 1440-2880 territory.
-
As soon as I put the ECI /r back on, 24 hours later DLM intervened and changed my banding from 49/19 to 49/20. I'm hoping it will begin stepping up the downstream speed banding next.
-
interesting is that ronski exceeded both 1440 and 2880 yesterday but is still on fast path.
I wonder if he will be DLM'd tomorrow and its not considered that data yet.
-
It looks like events in one hour took him to 4171/day. Unless that was discounted due to it appearing on all the lines on the DSLAM, as in a thunderstorm, you would certainly expect action.
-
He has been DLM'd this morning. We can't learn much from that as he went well over the possible thresholds.
-
Over the past couple of days I seem to have a few isolated episodes of SHINE (http://www.kitz.co.uk/adsl/rein.htm#SHINE).
I dont know what these are about nor why they occurred. From the times they occurred, they weren't generated by anything I was doing.
What is interesting about these is the fact that the amount of CRCs generated yesterday should take me way over the MTBE red threshold if the DLM includes CRC errors.
We know that the DLM calculates MTBE normalised over the course of a day. We dont know if that is midnight to midnight or any 24hr period ie ie current time minus 24hrs.
If the DLM monitors over the course of a day (say midnight to midnight) and uses CRCs, then in theory it should have taken action this morning. If it monitors over any 24 hr period then it should also have kicked in this morning.
Ive had another burst a short while ago, not as bad as yesterday, but still sufficient to exceed the MTBE if its monitors over any 24 hr period.
Wondering how it will react now that it's seen two consecutive days whereby a 24hr period has exceeded the MTBE (if it looks at CRCs).
-
I thought that the DLM should observe ES, not CRC errors. It apparently observes FEC, but in what way I haven't a clue. I imagine it either looks at the FEC seconds or the total FEC's during the 24 hour period?
-
What is SHINE? forgive my dumbness :)
A day or two ago I had a burst of ES, thankfully I stayed below the ES threshold.
I believe kitz only ES is used not CRC, a short time ago I posted I had a 17k error burst and was not touched by DLM.
Kutz I just checked your graphs and your MTBE isnt affected, your ES looks normal for your history.
I do see the CRC spikes tho and they are probably a burst of CRC in a very short time period. Did your SES increase?
A line that gets no errors for 12 hours, then a burst of 5000 errors all in one second, and then no errors for another 12 hours will have a excellent MTBE dispite the high CRC count, whilst a line that gets exactly 1 CRC error every 20 seconds whilst would have have a lower CRC count would also have a much inferior MTBE.
-
SHINE = Single High Impulse
PEIN = Prolonged
REIN = Repetitive
SHINE = A pain in the arse.
-
SHINE is the trouble maker on my line. I wonder over some arcing switches in the area round here.
From the various examples in mydslstats I think we can be fairly confident that CRC are not directly counted. I guess that a CRC spike is bad enough to worry about, the DLM thinks it will be associated with a resync.
-
D'oh. :doh: Ive always said that the DLM doesnt use CRCs. I just thought this would prove it once and for all which is why I said IF.
I am fully not expecting to be DLM'd. I wasnt DLM'd today for yesterdays, nor am I expecting to be tomorrow for todays.
This has been discussed many times and Ive always stuck to Errored Seconds. Ive debated this several times and this is my thoughts on the subject.
~ Detection of Errors (http://www.kitz.co.uk/adsl/DLM.htm#dlm_error_events)
The DLSAM's Data Collector (http://www.kitz.co.uk/adsl/DLM_system.htm#DLM_Data_Collector) will record the amount of errors seen on your line. These will be the same errors as displayed by your modem/router. It is not known exactly which errors it uses, documentation states 'Code Violations' and it is assumed to most likely be Errored Seconds (http://www.kitz.co.uk/adsl/linestats_errors.htm#ES).
It is unlikely to use FEC (http://www.kitz.co.uk/adsl/linestats_errors.htm#FEC)s as these just prove that interleaving is working as it should plus FEC is not a code violation. A single CRC error (http://www.kitz.co.uk/adsl/linestats_errors.htm#CRC) or burst of CRCs will usually triggers an errored second event. It is also known that xDSL Status Test Summary only records Errored Seconds and HEC errors.
Note: In all the documentation I've seen there is only one parameter for 'Errors' that is recorded by the Element Manager. However, there are instances whereby if a line is performing particularly poorly, then RAMBO will undertake additional line monitoring direct with the DLSAM. In such cases it monitors additional parameters such as SNR Margin which are not normally monitored at all for most lines. For more information see: DLM System - Additional Line Monitoring. (http://www.kitz.co.uk/adsl/DLM_system.htm#DLM_additional_monitoring)
What is SHINE? forgive my dumbness
Slaps Chrys with a wet fish, :graduate: I included a link in my post to explain what SHINE (http://www.kitz.co.uk/adsl/rein.htm#SHINE) was.
What I dont know is the exact MTBE red thresholds for each of the stability metrics. Ive come across several metrics that they could be using. ATM I believe 30 on speed is the most recent that is documented anywhere. I have my suspicions though that there may be another newer algorithm out there for speed. When Ive sorted out a few R/L and far more important things then Im going to look further into that, because something is still nagging me re 'speed' and stable which doesnt quite sit right atm.
The other thing I dont know is the exact time metric start and finish.
Ive said for months that MTBE (http://www.kitz.co.uk/adsl/DLM.htm#MTBE) is normalised to uptime. Documentation says 24hrs.. but I dont know when the 24hrs starts and when it ends, because we dont know at what time the Element Manager (http://www.kitz.co.uk/adsl/DLM_system.htm#element_manager) passes the data over to the DLM Management Device (http://www.kitz.co.uk/adsl/DLM_system.htm#RAMBO_what)
-
thanks guys, yeah SHINE I expect would be nigh impossible to find, but the good news is DLM shouldnt act on it.
-
looks like I had 10 SHINE events today :)
rather have SHINE than either REIN or PEIN, since SHINE will come and go in a flash the chances of it affecting anything you doing is small.
-
From a DLM doc ...... backing up Kitz comments.
Mean Time Between Errors (MTBE) = Uptime / Errored Second Count. MTBE measures errored seconds only (Not HEC, CRC or FEC).
-
PEIN = Prolonged
Ive never really looked at PEIN as its not something you seem to hear as much about because most of us have seen samples of REIN and SHINE but not PEIN.
I just did a google on PEIN, and found this which I found interesting
http://www.joepeesoft.com/Public/DSL_Corner/Docs_ETSI_TM6/071t29_Noise_PEIN.pdf
OMG I have a PEIN in my U0 !!!!1!!!111one*
PEIN isnt something we tend to see that often, but its interesting that its now recognised as a type of interference in its own right. I should update the REIN page to include it..
[PS to BS
I am jk about the PEIN - Im not concerned about it and know theres nothing I can do, sit back and relax ]
-
Ha ha ............... thank the mighty lord for that, Kitz. ;D
Have a look at this regarding your other musings.
-
From a DLM doc ...... backing up Kitz comments.
Mean Time Between Errors (MTBE) = Uptime / Errored Second Count. MTBE measures errored seconds only (Not HEC, CRC or FEC).
Thank you muchly Mr Black Sheep. :flower: You wont believe the documents & white papers Ive trawled through and read over the past few months whilst trying to put together the DLM pages.
Most of the DLM stuff says 'code violations'. A code violation discounts FECs but could include CRCs, ES and SES.
However I saw absolutely no reason why they would count individual CRCs because a CRC would trigger an ErrSec anyhow and IMHO theres no point recording all the individual errors during that noise burst. Its way more sensible to measure that a noise burst has occurred. Its just that Ive not seen BT put Err/Secs in writing. The nearest I have seen is ErrSecs and SES.
-
Ha ha ............... thank the mighty lord for that, Kitz. ;D
Have a look at this regarding your other musings.
WOW! I love you Mr Black Sheep. Thank you so very much. :clap: I had a feeling in my bones that the other figures weren't right and that they'd done an update, I'd seen mention of an update, but no hard figures. There the ones I was looking for. Do you happen to know when they came into effect. I think it may have been fairly recent within the past few months. .
-
The doc is dated late April this year .......... glad you're a happy bunny. ;) ;D ;D
-
Thanks for that, Ive seen so many algorithms, but none of them seemed to fit what we've been seeing recently.
These were the original figures
Service Option MTBR red threshold MTBR green threshold MTBE red threshold MTBE green threshold
1 8,640 16,800 60 600
2 16,800 33,600 600 6,000
3 33,600 67,200 6,000 60,000
Then last year they halved them, but I saw something that implied they may be reviewing and reducing further. It seems to be all change with Rambo atm, and its looking like he may be retired in favour of a new system. Those of us on the new MSE bRAS (http://www.kitz.co.uk/adsl/MSE_BRAS.htm) (fttc goes first) are seeing all sorts of changes. Since the change, my broadband connection no longer goes through my own exchange - instead the fibre goes straight to the MSE bRAS location in another town, and hops on the core quicker.. which is why some of us have seen the odd ms shaved off our latency.
glad you're a happy bunny
yep thanks. Im a sad git who is easily pleased. ;D As you know I go in hopical tomorrow.. armed with all my juicy reading material I shelled out for for last week. Some really good stuff in there. Ive only skimmed so far, but the contributions from people in there from Adastral Park inc appx 30 from BTw and BT Exact is huge. Some of it is dated, but all the FFTC stuff is there including FeXT projections, from the guy who designed the fttc platform. So thats my reading sorted for a good while. :)
-
Ha ha ...... you is a nutter, lady. I can picture the faces of the nurses when they see all your DLM papers ! Hope all goes well for you. :P ;D ;D ;D
-
From a DLM doc ...... backing up Kitz comments.
Mean Time Between Errors (MTBE) = Uptime / Errored Second Count. MTBE measures errored seconds only (Not HEC, CRC or FEC).
you mean my comments.
I am the one mentioning ES. I got no idea why kitz confused things mentioning CRC.
-
Ha ha ............... thank the mighty lord for that, Kitz. ;D
Have a look at this regarding your other musings.
indeed this suggests the 2880 is outdated info and also interesting is a custom field, might mention that to plusnet next time they say they have no control.
so do I have this right?
on standard 17280 ES day before action?
on stable 288 ES day before action?
on super stable just 24 per ES per day?
these seem odd. The older figures seem to have closer correlation with user's data.
With these new figures newt should be back on fast path.
-
indeed this suggests the 2880 is outdated info and also interesting is a custom field, might mention that to plusnet next time they say they have no control.
Ive mentioned the custom field several times in the past going back months. Thats not for Plusnet.. thats for Openreach.
Sheesh I was beginning to think no-one was listening to my earlier posts on DLM.. and now I know they werent, because I keep repeating myself. :lol:
Remember how I said just the other day how Openreach becomes a customer of BT Wholesale, when we were talking about plans to scrap the Wholesale Division and I linked to the pretty picture
* The current situation is that BTw controls all the profiles via NCAS & the OSS (http://www.kitz.co.uk/adsl/DLM_system.htm#DLM_grahic). The SP hooks into NCAS and can make configuration requests.
However with FTTC, Openreach becomes a customer of BTw so only BToR has access to the OSS to perform any changes and the ISP has no direct access. Same as any third party/white label supplier has no direct access to DLM and has to go via whomever they purchase from.
Further evidence that Openreach is a customer of BTw is also shown in the fact that they don't use the normal stability levels (http://www.kitz.co.uk/adsl/DLM.htm#dlm_stability_level) and instead use the custom thresholds which is why we see E/Secs rather than SNR parameters and all the confusion between Standard /Stable/Speed.
These additional layers only serve to complicate things for the ISP and EU. So yes I believe merging the two would be beneficial to the consumer.
But the diagram shows what Im trying to say, whereby when BToR becomes the customer of BTw, then it breaks the chain where the dotted orange line is for any config changes.
-
The older figures seem to have closer correlation with user's data.
I suspect that OR hasnt changed the speed parameters. That is what I intend to find out when I get the chance. I nearly have all the pieces of the jigsaw. Thats it from me now for a few days. Got stuff I still need to do tonight.
-
why would openreach add a custom field just for themselves?
that list would be for CP's to choose from for their customer lines.
ok reread your post, yeah I remember that post it confused the hell out of me.
You seem to be saying that openreach buy some kind of service of BTw for FTTC and not the other way round?
As I understood it, openreach sells FTTC to the likes of BTw, sky and talktalk. Then BTw resell to the likes of BT retail, plusnet, aaisp etc. Openreach own and operate the cabinet equipment, why would they be BTw's customer?
-
>> You seem to be saying that openreach buy some kind of service of BTw for FTTC and not the other way round?
... and THAT is exactly why I said the other day, FTTC is a complete tangled web, because each are buying from the other. It worked oK before FTTC, but since then its hard to know which bit belongs to whom.
The backhaul belongs to BTw. The OSS belongs to BTw. FTTC belongs to Openreach. NCAS is a BTw system. The FTTC cabs need Element Managers which are owned by BTw. The Management Device is owned by BTw. FTTC Openreach needs to hook into NCAS and get to the OSS to make any changes to the DLM, and it then becomes difficult to know who owns what and who is purchasing from whom. The ISP is buying an Openreach product, from which Openreach needs to access NCAS, and then the ISP buys it from Wholesale.. and have no access to the OSS because, Openreach is the customer. Confused yet? Yep you should be.
why would they be BTw's customer?
Because they need to use the DLM system. Regardless of which ISP is reselling the product. Sky or Plusnet or whatever. They all use the BTw OSS.
-
Hi Kitz please enjoy your hols ;D
When you get back I hope you can provide the number of errored seconds needed over 24 hours for 14 days for an interleaved line to become non-interleaved ;)
-
Hi Kitz please enjoy your hols
I take it that was a joke, but yes it may be a holiday lol :D
Re the E/Secs... I shall certainly try, because this is what Im hoping to get to the bottom of. What I thought was going to be pretty straight forward and the page I originally started had to temp be put on hold, because I realised that the whole DLM system (http://www.kitz.co.uk/adsl/DLM_system.htm) needed explaining before I could attempt to explain the the functions If I'd done it the other way round, people would soon be asking "Whats an Element Manager", Whats RAP, whats NCAS, whats OSS etcetc.
-
Hi Kitz please enjoy your hols
I take it that was a joke, but yes it may be a holiday lol :D
Sorry i've put my foot in it, thought you were going on holiday and look back at your previous post after i posted :-[
I'm am a complete dick head there is no other word for it.
-
>> You seem to be saying that openreach buy some kind of service of BTw for FTTC and not the other way round?
... and THAT is exactly why I said the other day, FTTC is a complete tangled web, because each are buying from the other. It worked oK before FTTC, but since then its hard to know which bit belongs to whom.
The backhaul belongs to BTw. The OSS belongs to BTw. FTTC belongs to Openreach. NCAS is a BTw system. The FTTC cabs need Element Managers which are owned by BTw. The Management Device is owned by BTw. FTTC Openreach needs to hook into NCAS and get to the OSS to make any changes to the DLM, and it then becomes difficult to know who owns what and who is purchasing from whom. The ISP is buying an Openreach product, from which Openreach needs to access NCAS, and then the ISP buys it from Wholesale.. and have no access to the OSS because, Openreach is the customer. Confused yet? Yep you should be.
why would they be BTw's customer?
Because they need to use the DLM system. Regardless of which ISP is reselling the product. Sky or Plusnet or whatever. They all use the BTw OSS.
enjoy your break kitz but when you back are you sure openreach do not have their own separate DLM, if it was BTw operated I would have expected it to operate in the same manner as 21CN adsl and it doesnt.
It has different tags for each profile and a different algorithm. Plus I assume this would be illegal under ofcom rules since openreach and BTw are supposed to be operated separately.
What stops openreach having their own OSS or equivalent?
-
Hi Kitz please enjoy your hols
I take it that was a joke, but yes it may be a holiday lol :D
Sorry i've put my foot in it, thought you were going on holiday and look back at your previous post after i posted :-[
I'm am a complete dick head there is no other word for it.
Not sure what is going on there I guess is something more known about on the VIP section of the board that BS is on.
Hope the hospital visit is swift and without issues whatever it is for.
-
Hi Kitz please enjoy your hols
I take it that was a joke, but yes it may be a holiday lol :D
Sorry i've put my foot in it, thought you were going on holiday and look back at your previous post after i posted :-[
I'm am a complete dick head there is no other word for it.
No please no need for apologies, I thought you may be joking about taking a holiday. The past few weeks have been a bit manic. :flower:
-
>> You seem to be saying that openreach buy some kind of service of BTw for FTTC and not the other way round?
... and THAT is exactly why I said the other day, FTTC is a complete tangled web, because each are buying from the other. It worked oK before FTTC, but since then its hard to know which bit belongs to whom.
The backhaul belongs to BTw. The OSS belongs to BTw. FTTC belongs to Openreach. NCAS is a BTw system. The FTTC cabs need Element Managers which are owned by BTw. The Management Device is owned by BTw. FTTC Openreach needs to hook into NCAS and get to the OSS to make any changes to the DLM, and it then becomes difficult to know who owns what and who is purchasing from whom. The ISP is buying an Openreach product, from which Openreach needs to access NCAS, and then the ISP buys it from Wholesale.. and have no access to the OSS because, Openreach is the customer. Confused yet? Yep you should be.
why would they be BTw's customer?
Because they need to use the DLM system. Regardless of which ISP is reselling the product. Sky or Plusnet or whatever. They all use the BTw OSS.
enjoy your break kitz but when you back are you sure openreach do not have their own separate DLM, if it was BTw operated I would have expected it to operate in the same manner as 21CN adsl and it doesnt.
It has different tags for each profile and a different algorithm. Plus I assume this would be illegal under ofcom rules since openreach and BTw are supposed to be operated separately.
What stops openreach having their own OSS or equivalent?
I've seen the diagrams of how the FTTC cabs hook into the DLm system. It's just not as pretty as my diagram and uses plain square boxes. They all hook into the one system
If they purchase a service from btw then no it's not illegal. Custom allows for separate profiles, which is what bt or have done. Why don't they purchase their own. Well they could do, but they'd be duplicating equipment and a system that is already there. The dlm system is massive.
Look how they also use bras profiles at the bras for the bt based ISPs.
-
Hi Kitz please enjoy your hols
I take it that was a joke, but yes it may be a holiday lol :D
Sorry i've put my foot in it, thought you were going on holiday and look back at your previous post after i posted :-[
I'm am a complete dick head there is no other word for it.
Not sure what is going on there I guess is something more known about on the VIP section of the board that BS is on.
Hope the hospital visit is swift and without issues whatever it is for.
Nothing to do with the Pte section. I've told you before that only has about 4 threads in about 5yrs. :/. I actually mentioned it in this thread, which is where a couple of people such as BS and bcat picked up on it.
Damn ipad can't post link.
-
Here you go post 43 of this thread
http://forum.kitz.co.uk/index.php?topic=14598.msg273161#msg273161
-
kitz when you back can you post that diagram that shows openreach using BTw systems, thanks, and get some rest. Dont worry about replying to me now.
But basically as I understand what you saying is openreach have effectively outsourced the DLM, so effectively they paying BTw to run the DLM. Whether or not that means openreach have told BTw how to set the profiles or BTw makes that decision? curious.
There was a guy on the BT retail forums a year or so back telling people BTw ran DLM and everyone was calling him a liar, not so sure now.
-
I am loosing the wood for the trees in this discussion. How much of the above discussion is about the FTTC DLM and how much is about the BT/BTw adsl2+ DLM? I thought the FTTC DLM was a separate and distinct beast with quite different characteristics to the adsl2+ one.
-
BTW could soon be folded into Openreach!
See
http://www.telegraph.co.uk/finance/newsbysector/mediatechnologyandtelecoms/telecoms/11229857/BT-plans-to-scrap-2.4bn-Wholesale-division.html
-
And perhaps GCHQ will take Openreach, Operate and all the infrastructure away from Beattie, for the good of the Nation. :-X
-
Ok..I've been following this thread for a while now and I grasp that DLM applies interleave when a line exceeds ES thresholds.
However, I can see no explanation of what criteria DLM uses, or a timescale of when DLM deems the line ok and puts you back to fastpath...My stats are on MDSW (username Strontium) and my line has held sync for 38 days with no DLM intervention..there is nothing glaringly bad about my stats and apologise for my ignorance if I've missed something..it's a long line btw but even so...
-
In short I don't think it is clear either. It is also not clear in all cases which DLM posters refer to FTTC or adsl2.
If you read through the thread carefully there are suggestion that the criteria may be less than 6 ES/hour coupled with knowledge of line history. In contrast the observation is that there are quite a few like you with about or less than 1ES/hour who seem stuck on interleaved. However a few have gone fast path with rather more ES/hour than you.
It has been suggested that when interleaved FEC may also be monitored but no criteria is clear. I did wonder about looking at average FEC rates of the interleaved lines but FEC are so spiky that you can't guess an average from mydslwebstats.
-
Cheers Les-70...perhaps I should try powering down the modem And rebooting after 30 mins?
-
Thats because the DLM system is the same regardless if its FTTC or adsl. What is different is the configuration parameters.
I know for a fact that the BTw system was a few years ago supposedly originally aligned to match the BToR system to be able to map the Standard -> Speed, Normal -> Stable etc
The last policy change for FTTC MTBE may have occurred late 2012. Thats the last date I can find that specifically mentions FTTC policy. I cant find any more info than this, but as I keep saying, it is something I intend to follow up when I get chance.
However, I'd seen something that implied MTBE may be changing this year... and as confirmed by BS in this thread, it would appear that indeed the adsl2+ system at least has reduced their parameters for Standard MTBE... but whether or not BToR system for Speed has also followed is not yet clear.
As regards to why some people get interleaving switched back on the next day and others can take months, there is a reason for that too.. its what used to be called Blip Logic... but now its more complicated and Ive seen something to infer that it could take some lines anything up to over a year to get back :( (Cant recall figure now but something like 15mths - dont have the documentation to hand to check- so don't quote me on that)
I doubt that the DLM monitors FECs. All documentation says Code Violations.. of which an FEC isnt! However, there are instances where the Management box can directly monitor a line (bypassing the Element Managers) that is classified as performing very poor.. and in such cases do monitor other parameters such as SNRm.
-
Thats because the DLM system is the same regardless if its FTTC or adsl. What is different is the configuration parameters.
Thanks for that I was not aware that it was the same, even if parameter changes can make the outcomes rather different. I will however, for the moment, trust what I see on mydslwebstats more than theory as getting reliable info seems hard to do.
-
As regards to why some people get interleaving switched back on the next day and others can take months, there is a reason for that too.. its what used to be called Blip Logic... but now its more complicated and Ive seen something to infer that it could take some lines anything up to over a year to get back :( (Cant recall figure now but something like 15mths - dont have the documentation to hand to check- so don't quote me on that)
Cheers Kitz you have just ruined my day ;D
There was me thinking if I cap my downstream to say 25000 kbps and wait for 14days i'll get a chance to experience fastpath and no way I'm gonna wait 15 months to see if the experiment worked or not :(
-
Blip logic is now called doubler something, so each step takes longer to recover from. I promise I will get around to putting all the info up as soon as I can. I think I fell down a rabbit hole when looking at DLM. :silly: :crazy: I never realised the 21CN/FTTC one was such a large topic. I covered it many years ago when maxdsl first came in. Then never bothered with it for years when on BE* - didnt need to. Its so bleeping complicated now. Before I put something up on the main site though, I want to be pretty damn certain of the facts and make sure I fully understand it all, before trying to explain it to others. The pieces are slowly coming together, most of it is straightish in my head aside from the missing MTBE for FTTC Speed profile.
--
Edit MTBE typo
-
I never realised the 21CN/FTTC one was such a large topic. I covered it many years ago when maxdsl first came in. Then never bothered with it for years when on BE* - didnt need to. Its so bleeping complicated now.
I know Kitz it's friken hard to see the DLM collation from interleaved line to non-interleaved line could it be down to ES/SES CRC SNRM or even attenuation and others there must be constant and you will find it I am sure of it ;)
-
Everything Ive seen says Code Violations, which totally rules out FECs. Code Violations could be either CRCs/ES/SES. Im pretty certain it doesnt use CRCs, it would be far to easy to exceed the MTBE, plus Ive exceeded that a few times myself over the past week or so and touch wood the DLM left me alone.
The Element Manager only has one parameter for errors which it uploads to the Management Device for DLM. As far as DLM goes all the Management Device (RAMBo) seems to need from the Element Manager is uptime, Errors, retrains & sync speed.
There is another file that the Element Manager produces, but thats just a very simple binary file, which RAMBo uses to identify wide area events and unforced retrains.
Oh and the OSS keeps a record of line data for a period of time, but I think thats more to do with say when the ISP says runs a WHOOSH and for fault finding, and nothing to do with DLM/RAMBo.
The only thing up until last week that said anything specific was a mention of ErrSecs and SES.. then Zen came up with the FECs.
However last week BS checked and found this:
From a DLM doc ...... backing up Kitz comments.
Mean Time Between Errors (MTBE) = Uptime / Errored Second Count. MTBE measures errored seconds only (Not HEC, CRC or FEC).
There is one instance though when DLM will perform additional monitoring and thats when a line goes Scarlet (Very Poor). At this point RAMBo goes into overdrive and kicks the Element Manager (http://www.kitz.co.uk/adsl/DLM_system.htm#element_manager) into touch, bypassing it completely. It then undertakes intensive monitoring of the line direct with the DSLAM. During additional line monitoring (http://www.kitz.co.uk/adsl/DLM_system.htm#DLM_additional_monitoring), RAMBo looks at other parameters such as SNRm to see if it can figure out whats going on. During this intensive care stage, a line's DLM can be immediately changed, it doesnt have to wait for the normal 24hr monitoring reports. Im beginning to wonder if this is where FECs may have crept in :-\
RAMBo does not directly monitor every single line, the vast majority of lines data gets collected by the DSLAMs Data Collectors and over to the Element Managers... then once a day to RAMBo.
Im still open to the possibility of FECs being used, but atm Ive seen nothing in writing which would back this up. Its the blip logic/doubler process which is used to decide when parameters are removed. It may also depend on which parameter caused the DLM to kick in because these are permanently recorded as RED(retrains) or CRIMSON(errors)
---
PS Im saying RAMBo only because most people are familiar with that name, but strictly speaking it should now be called Management Device. The DLM has now become the major function and the RAP process does comparatively very little since 21CN/FTTC - and absolutely nothing for the GEA Fibre lines.
-
As regards to why some people get interleaving switched back on the next day and others can take months, there is a reason for that too.. its what used to be called Blip Logic... but now its more complicated and Ive seen something to infer that it could take some lines anything up to over a year to get back :( (Cant recall figure now but something like 15mths - dont have the documentation to hand to check- so don't quote me on that)
Cheers Kitz you have just ruined my day ;D
There was me thinking if I cap my downstream to say 25000 kbps and wait for 14days i'll get a chance to experience fastpath and no way I'm gonna wait 15 months to see if the experiment worked or not :(
Capping your connection will reduce your ES, so try it it may get you back on fastpath.
The longer DLM recovery is more so for lines that have been bouncing a lot, yours hasnt been bouncing but just stuck on interleaving for a long time.
-
The only thing up until last week that said anything specific was a mention of ErrSecs and SES.. then Zen came up with the FECs.
However last week BS checked and found this:
From a DLM doc ...... backing up Kitz comments.
Mean Time Between Errors (MTBE) = Uptime / Errored Second Count. MTBE measures errored seconds only (Not HEC, CRC or FEC).
Im still open to the possibility of FECs being used, but atm Ive seen nothing in writing which would back this up. Its the blip logic/doubler process which is used to decide when parameters are removed. It may also depend on which parameter caused the DLM to kick in because these are permanently recorded as RED(retrains) or CRIMSON(errors)
FWIW, Asbokid provided the following resync reasons quite a long time ago.
I think the information was geared mainly to VDSL2 connections, but I'm not 100% sure:-
Los Detector 0
Rdi Detector 1
Negative Margin 2
Too Many Us FEC 3
CReverb1 Misdetection 4
Teq Dsp 5
Ansi Tone Power Change 6
Ifft Size Change 7
Rack Change 8
Vendor Id Sync 9
Target Margin Sync 10
Tone Ordering Exception 11
Command Handler 12
Dsl Start Physical LayerCmd 13
Unknown 14
G992 Failure 15
Ses 16
Co Min Margin 17
I don't know what some of the reasons mean, but from monitoring my own & quite a few other users' VDSL2 connections, these are the only reasons I have seen:-
Reason 0 - Modem reboot or modem power off/on
Reason 1 - Unconfirmed, but seems to be a DLM initiated resync (often in the early hours but has also occasionally been seen) at other times
Reason 2 - User initiated resync (not a full modem reboot)
Reason 3 - Very, very rare - unconfirmed as to whether it was actually FEC related (DS or US)
Reason 4 - Also very, very rare, but again, unconfirmed as to what actually caused it.
So, I suppose that if a connection reyncs at a lower speed in order to apply interleaving (or at a higher depth for already interleaved connections) & thus reduce various error counts (FEC included), High FEC counts COULD indirectly account for a resync that maybe IS taken into account.
-
As regards to why some people get interleaving switched back on the next day and others can take months, there is a reason for that too.. its what used to be called Blip Logic... but now its more complicated and Ive seen something to infer that it could take some lines anything up to over a year to get back :( (Cant recall figure now but something like 15mths - dont have the documentation to hand to check- so don't quote me on that)
Cheers Kitz you have just ruined my day ;D
There was me thinking if I cap my downstream to say 25000 kbps and wait for 14days i'll get a chance to experience fastpath and no way I'm gonna wait 15 months to see if the experiment worked or not :(
Capping your connection will reduce your ES, so try it it may get you back on fastpath.
The longer DLM recovery is more so for lines that have been bouncing a lot, yours hasnt been bouncing but just stuck on interleaving for a long time.
You know Chry I may setup the cap this evening, just would like the full command line instructions be it using Telnet and if the HG612 is powered off does the command still survive ? can you use DSlstats custom commands for this ?
Never mind have capped my DS sync from 30000 kbps to 25000 kbps and a wee bit from the US so lets see what happens :-\
As my DS has never been moved onto non-interleave how long should I wait ?
place your bids please the winner gets my old Dlink 2640B modem :D
-
Reason 0 - Modem reboot or modem power off/on
Reason 1 - Unconfirmed, but seems to be a DLM initiated resync (often in the early hours but has also occasionally been seen) at other times
Reason 2 - User initiated resync (not a full modem reboot)
Reason 3 - Very, very rare - unconfirmed as to whether it was actually FEC related (DS or US)
Reason 4 - Also very, very rare, but again, unconfirmed as to what actually caused it.
Yes BE1 you would like Reason 0 thats the best one, though it takes the HG612 to be powered off for just over 30 minutes to get it.
-
Yeah, I have a feeling FEC's may not be used as it may not be an accurate measurement - for example it's not the number of FEC seconds? One way to test this might be if I set my ASUS device to go on heavy interleaving for a month (assuming I'm not on a long delay of some kind with increasing the profile) and that way I should produce a large amount of FEC's (this device does that on interleaving, but connection itself is stable however) but a minimal or non-existent amount of ES. I will try it if people want me to.
-
As regards to why some people get interleaving switched back on the next day and others can take months, there is a reason for that too.. its what used to be called Blip Logic... but now its more complicated and Ive seen something to infer that it could take some lines anything up to over a year to get back :( (Cant recall figure now but something like 15mths - dont have the documentation to hand to check- so don't quote me on that)
Cheers Kitz you have just ruined my day ;D
There was me thinking if I cap my downstream to say 25000 kbps and wait for 14days i'll get a chance to experience fastpath and no way I'm gonna wait 15 months to see if the experiment worked or not :(
Capping your connection will reduce your ES, so try it it may get you back on fastpath.
The longer DLM recovery is more so for lines that have been bouncing a lot, yours hasnt been bouncing but just stuck on interleaving for a long time.
You know Chry I may setup the cap this evening, just would like the full command line instructions be it using Telnet and if the HG612 is powered off does the command still survive ? can you use DSlstats custom commands for this ?
Never mind have capped my DS sync from 30000 kbps to 25000 kbps and a wee bit from the US so lets see what happens :-\
As my DS has never been moved onto non-interleave how long should I wait ?
place your bids please the winner gets my old Dlink 2640B modem :D
hopefully 14 days :)
-
hopefully 14 days :)
:D the famous 14 days, I have been watching STARMAN on MDWS his/her errored second counts are reaching 4000+ a day and he/she line is still non-interleave, have seen the DLM hit Kitz with less errored seconds a few months ago.
-
Well spotted --- quite surprising!!!!
-
Well spotted --- quite surprising!!!!
a classic example when the sync rate is much higher than the attainable, I guess the next time Starman re-syncs the modem or the modem is forced to re-sync by the DLM they could be in for a :o but would say it will only take 5 days for the DLM to relax :-\
-
Good spot NS
Using the DLM calculator (http://www.kitz.co.uk/adsl/DLM_calculator.php) with yesterdays errors of 4739 and 24 hrs uptime his MTBE is 18.23
I changed the parameters last week to update with the new figures that BS provided (http://forum.kitz.co.uk/index.php?topic=14598.msg274611#msg274611) which we know are definite for ADSL, just not sure about FTTC, and it comes out as Amber.. in which case the DLM should leave him alone.
On the old figures of 2880, then by now he should have been DLM'd, because thats 3 full days now where its exceeded 2880. This is going to be an interesting one to watch.
-
From a DLM doc ...... backing up Kitz comments.
Mean Time Between Errors (MTBE) = Uptime / Errored Second Count. MTBE measures errored seconds only (Not HEC, CRC or FEC).
you mean my comments.
I am the one mentioning ES. I got no idea why kitz confused things mentioning CRC.
No that was in response to my comments on FECs. Ive always said they will NOT include CRCs, and Im doubtful about FECs. Ive stuck with Err Secs since the very beginning.
-
have seen the DLM hit Kitz with less errored seconds a few months ago.
Taking this onboard, Ive just gone back to my stats for a couple of those days. You have to bear in mind that I also had down time whilst BT did what ever they were doing. Plus I also had some unforced downtime because I swapped routers over and waited before putting the other on (I think I went out during one of those periods)
Ive only calculated the first 2 days because its taken ages. On day 2 my ErrSecs total wont quite be correct because it took me an extra time to reconfigure HG612 modem stats with each router config details, so there was some time when I was sync'd but HG612 stats wouldnt have been recording, so day2 total could be a bit higher. Anyhow these are my figures
Day1 MTBE = 33.75
Day 2 MTBE = 27.58
--
Edit MTBE typo
-
Okaaaaaaaay. Ive just gone back and looked at the line data history for Starman. A few days ago that line had some pretty heavy interleaving applied. (Depth 643) and INP=4. The SNRm was at 23dB.
A line does not just go from real heavy DLM to no DLM in one fell swoop, look also how the upstream has done the same. That line looks like it could have had a DLM reset. Wonder if Starman can confirm please :)
Edit - looks like he may recently have had a line fault (http://forum.kitz.co.uk/index.php?topic=14262.msg274291#msg274291).
-
ok so he hasnt had that ES for a long time then?
Still if he has managed 2 days, then that suggests newt is onto something as DLM will react within a day or two to a breach.
-
Ok...I still don't understand..My stats are on MDWS and my ES, CRC's are ZERO...only FEC and bitswaps have values and my understanding is these are resultant of Interleaving anyway's..
Could someone please tell me why DLM hasn't done anything with my uptime being almost 42 days?
With ADSL my profile frequently got stuck but by that stage I had the CEO of BT's office phone no and I had this fixed and interleave permanently removed (Fastpath)
I've had my Upstream "stuck" on VDSL and had to have an engineer visit to rectify this...(it only lasted a week lol)..
Are some lines just permanently stuck on Interleave with no prospect of it ever been removed?
-
give it 14 days.
-
FEC and bitswaps are not resultant of Interleaving.
-
Fair enough...what then are the criteria for keeping interleaving on if not ES?
Chrysalis..I've a feeling 14,000 days won't make a difference...look at my stats on mdws..
-
sorry I misread the 42 days.
has your line been unstable in the past bouncing around?
IF not then you can try and somehow get a profile reset but currently that needs an engineer, and for that you need to have what's considered a fault.
-
The last problem I had was a thunder storm in the summer and I wasn't at home so couldn't switch modem off...
I had an engineer visit about May when he replaced a joint on the pole about 300 yards away...He thought REIN unlikely...profile was reset but it only lasted a week till interleaving and banding on the US applied...couldn't face talking to india again
It's a long rural line and about half a mile above ground...but it is pretty stable as you can see from my stats...so will DLM ever kick in and do something positive?
Personally I find DLM far too aggressive and too slow to react to stability...42 days is a joke..
-
Fair enough...what then are the criteria for keeping interleaving on if not ES?
ES and resyncs, I think.
-
ES = Zero,
Resync = Uptime 42 days..
Maybe DLM just doesn't like me?
-
Assuming that your strontium on MDWS then you have about 10-30 ES/day which you would think is enough to get fast path?? If it is any consolation others have similar stats and the same issue. Kitz has suggested it may be some long past line history which is being remembered in such cases.
-
Thanks les-70...It does seem I am being punished for something I am not aware of...does anyone else agree that DLM is far too slow to react to stability an d surely the algorithm needs modification?
-
I didnt check the site as I am way too busy today, so les has confirmed your ES is not 0.
The daily ES threshold we have discussed here is far from confirmed, we just been posting guess's based on documents found on the internet and people's experiences.
All I can say is when DLM moved me back to fast path in the past my ES was either 0 or extremely low, maybe 1-2 per day at the most.
-
If it's of any help at all, I've been off and on fastpath twice in the past 4 months (currently on fast).
Here is the graph that shows the total ES since 1st August to today. Bit difficult to read but it might show something. The highest value when interleaved is about 138. I think you can see what put it back on interleaved most recently...
Note that you can't generate this graph yourself for that period of time as I frigged the code to do it locally on my home server, hence why it says 48hrs... :)
Edit:
Added BE1's since 1st Jan - interesting!!
-
Assuming that your strontium on MDWS then you have about 10-30 ES/day which you would think is enough to get fast path?? If it is any consolation others have similar stats and the same issue. Kitz has suggested it may be some long past line history which is being remembered in such cases.
Possibly ?? Taken from ADSL DLM docs, may also apply to VDSL ??
1) A lines performance history is considered by DLM
2) DLM learns from the actions it has taken in the past to influence the actions it will take in the future
3) For example if interleaving has been removed from a line and it becomes unstable, DLM will wait longer next time before taking the same action
-
Thanks BS. Yep thats the one. Its one of the DLM processes. :)
Both ADSL and FTTC use the same DLM system and both have exactly the same DLM processes and functions. They may however have different parameters.
For example with adsl the speed/standard profile MTBE params are [5,250] yet for FTTC they may not yet have been updated and may still be [30,300]
Another example of a parameter difference is configuration of the DLM profile: On ADSL1 its simply [Interleaving, SNRm] ADSL2+ its [Interleaving, INP, SNRm] and on FTTC its [Interleaving, INP, Banding]. The process how it decides something needs changing and how it implements it though is the same.
Edit MTBE typo
-
While the DLM parameter changes may have altered starmans 4000+ ES for a few days now puzzle me. I wondered whether, if work is done on a line and things are reset, whether the DLM does not go into action until the job is logged as complete. I had a week or so after my FTTC install with Openreach trying to rebook appointments to do the install even though it was done. I was told by TT that until the engineer signed it off the DLM actions would not start as the system did not count me as connected. Maybe BS can comment.
-
3) For example if interleaving has been removed from a line and it becomes unstable, DLM will wait longer next time before taking the same action[/b][/i]
What if like me there is no history this line has never been moved off interleave from the very first day on FTTC over 3 years now, though can't be 100% sure as I didnt have the HG612 unlocked to monitor stats on activation day but the pings were around 25ms.
-
All I can say is when DLM moved me back to fast path in the past my ES was either 0 or extremely low, maybe 1-2 per day at the most.
If thats the case then capping wy line was a waste of time as I my errored seconds have dropped but know way near close to 0 or 1-2 per day more like 70 a day :-\
-
FWIW, Asbokid provided the following resync reasons quite a long time ago.
I think the information was geared mainly to VDSL2 connections, but I'm not 100% sure:-
Thanks BE. Unfortunately though, I can confirm that although our modems may record those codes, and that they may be logged in the OSS. As far as DLM process is concerned it doesnt take a blind bit of notice of any of those codes and it has its own system which it uses to detect wide area events (thunder storms) & unforced retrains (those done by the user), which is all logged by the Element Managers.
It is able to differentiate between instability due to retrains and those due to Errors, and it does keeps a permanent record of whether DLM intervention was due to retrains or errors.
Still in draft format but explanation of how it calculates these are described in Detection of sync events (http://www.kitz.co.uk/adsl/DLM.htm#dlm_sync_events) and further depth Unforced retrains (http://www.kitz.co.uk/adsl/DLM.htm#unforced_retrains) and Wide area events (http://www.kitz.co.uk/adsl/DLM.htm#wide_area_events)
I make no apologies for how long this is taking me to put together. I stress that my information hasnt come from BS, but I think he may be one of the few who will be able to see and appreciate how hard it is to separate the wheat from the chaff in all the information that is available. Ive literally spent what must now amount to several hundred hours trying to pick meat from the bones, just to get at the stuff we are interested in. The subject is HUUUUUUUUUUUUGE. I never realised what a mammoth task this was going to be :(
-
N*Star, I can assure you that for the very first 24 hours after the installation, your line will have been configured "wide open" on fast-path. It would have been from the second day onwards that the DLM system would have taken an interest in the line (and then only if it had just cause to do so).
-
While the DLM parameter changes may have altered starmans 4000+ ES for a few days now puzzle me. I wondered whether, if work is done on a line and things are reset, whether the DLM does not go into action until the job is logged as complete. I had a week or so after my FTTC install with Openreach trying to rebook appointments to do the install even though it was done. I was told by TT that until the engineer signed it off the DLM actions would not start as the system did not count me as connected. Maybe BS can comment.
You may have a point there les. I know when I had a line fault the other month, my ISP kept saying that there was certain information they couldn't access about my line, because the fault was still open with BT and not yet signed off.
-
While the DLM parameter changes may have altered starmans 4000+ ES for a few days now puzzle me. I wondered whether, if work is done on a line and things are reset, whether the DLM does not go into action until the job is logged as complete. I had a week or so after my FTTC install with Openreach trying to rebook appointments to do the install even though it was done. I was told by TT that until the engineer signed it off the DLM actions would not start as the system did not count me as connected. Maybe BS can comment.
I have no idea about when DLM triggers on new installs, I'm afraid.
But the comment I've highlighted above suggests repair-type work, of which the DLM goes into action the moment it's been re-calc'd (reset). Our processes tell us only to reset if a fault has been located, but (as I've said many times), I tend to do one before I even get to site in order that I can see the full error-rate without it being masked. I will apply the caveat that I do view the circuits history before doing this, so I have an understanding of previous behaviours. :)
In short, the job does not have to be signed off on repair work for DLM to be triggered.
-
N*Star, I can assure you that for the very first 24 hours after the installation, your line will have been configured "wide open" on fast-path. It would have been from the second day onwards that the DLM system would have taken an interest in the line (and then only if it had just cause to do so).
I can confirm this. Although I did see something that implied it may be 2 days - ie install day + one full day. Be damned if I can find it now though to go back and check :( .. but for sure everyone starts off with the wide open profile and interleaving wont have been added right from the start.
-
FWIW, Asbokid provided the following resync reasons quite a long time ago.
I think the information was geared mainly to VDSL2 connections, but I'm not 100% sure:-
Thanks BE. Unfortunately though, I can confirm that although our modems may record those codes, and that they may be logged in the OSS. As far as DLM process is concerned it doesnt take a blind bit of notice of any of those codes and it has its own system which it uses to detect wide area events (thunder storms) & unforced retrains (those done by the user), which is all logged by the Element Managers.
I should have commented right after B*E1 made that post. The information quoted is from a header file to the Broadcom driver code. It is only used within the driver and is, essentially, decoupled from the "external, real world situation".
Edited to add:
Not the file for which I was actually looking but I managed to "put my paws" on one that contained the following section of code --
/* line-drop reason code */
#define kRetrainReasonLosDetector 0
#define kRetrainReasonRdiDetector 1
#define kRetrainReasonNegativeMargin 2
#define kRetrainReasonTooManyUsFEC 3
#define kRetrainReasonCReverb1Misdetection 4
#define kRetrainReasonTeqDsp 5
#define kRetrainReasonAnsiTonePowerChange 6
#define kRetrainReasonIfftSizeChange 7
#define kRetrainReasonRackChange 8
#define kRetrainReasonVendorIdSync 9
#define kRetrainReasonTargetMarginSync 10
#define kRetrainReasonToneOrderingException 11
#define kRetrainReasonCommandHandler 12
#define kRetrainReasonDslStartPhysicalLayerCmd 13
#define kRetrainReasonUnknown 14
#define kRetrainReasonG992Failure 15
#define kRetrainReasonSes 16
#define kRetrainReasonCoMinMargin 17
Note the section-header comment: /* line-drop reason code */
-
N*Star, I can assure you that for the very first 24 hours after the installation, your line will have been configured "wide open" on fast-path. It would have been from the second day onwards that the DLM system would have taken an interest in the line (and then only if it had just cause to do so).
Good point B*CAT the 2 day wide open connection, We could give Oprenreach a call and say there is a fault could you come out and check the line and while your at it reset it for me and I make the best tea/coffee in the UK.
-
. . . I make the best tea/coffee in the UK.
Not forgetting the fresh cat-mint and kitteh treats! :D
-
Ok, thats it from me for today as far as DLM is concerned, Ive spent all day sat at the PC reading white papers and docs and other stuff thats made my head hurt - not to mention a numb bum. :D Im done in and off to watch some TV curled up comfy on the sofa with the kittehs.
Enjoy your tea/coffee/wine/cat-mint everyone.
-
Here is the graph that shows the total ES since 1st August to today. Bit difficult to read but it might show something. The highest value when interleaved is about 138. I think you can see what put it back on interleaved most recently...
Added BE1's since 1st Jan - interesting!!
Thanks for those, as you say very interesting. Yours shows clear behavior but it is odd that all the excursions above 1440 go also well above 2880 and don't reveal just what errors may be needed. BE1's has some odd events. It bothers me that over those time periods all of the big error values could have been due to thunderstorms - indeed surely some must be- yet all except one of BE!'s were acted upon. It looks like the errors get very low before a recover from interleaving -- any idea how low?
However maybe RAMbo is dead or changing now.
-
here is why he not been DLM'd with the high ES, mystery solved :D
http://www.thinkbroadband.com/news/6726-assia-court-case-forces-openreach-to-turn-off-dlm.html
I guess you stuck newt :(
-
It bothers me that over those time periods all of the big error values could have been due to thunderstorms - indeed surely some must be- yet all except one of BE!'s were acted upon.
several times over the past few months Ive inferred how the DLM detects wide area events (http://www.kitz.co.uk/adsl/DLM.htm#wide_area_events), I even put a link yesterday which describes it in more detail including the algorithm.
the element manager also produces an event data file which is used to monitor for Wide Area Events and forced retrains. This event data is recorded as an array of each 15 min period in binary format [Uptime, Retrains, Errors]. For example a line which has uptime and errors but no retrains will record [1,0,1].
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.
-
I am aware that, which is why I am puzzled that all of the high ES event but one of BE1's were acted upon. Over the time spans involved I would have expected more high ES due to e.g. thundersorms that were not acted upon. I think there is strong hint in those traces that wide area events are not well dealt with. I wonder if it is high ES events that are not quite bad enough to give many resyncs over the "wide area" that cause some of the interleaving transitions in the plots. It might be better if the criteria was simply 50% of lines had errors without a further check on more than 10% getting resyncs. You would need more examples to be sure.
-
This is 100% definite.
Typical that the info comes a bit too late :( but here are some of the answers anyhow for the FTTC DLM.
The BToR DLM measures the following parameters:
Total 24hr SES (downstream)
Total 24hr ES (downstream)
Total 24hr SES (upstream)
Total 24hr ES (upstream)
Total 24hr uptime
Total 24hr unforced retrain count
Total 24hr Full Initialisations
Total 24hr failed initialisations
Line rate (downstream) in previous 24hr period
Minimum line rate (downstream) in previous 24hr period
Maximum line rate (downstream) in previous 24hr period
Line rate (upstream) in previous 24hr period
Minimum line rate (upstream) in previous 24hr period
Maximum line rate (upstream) in previous 24hr period
The days monitoring file covers the period 00:00 to 23:59:59
Definitely no FECs
-
This is 100% definite.
Typical that the info comes a bit too late :( but here are some of the answers anyhow for the FTTC DLM.
The BToR DLM measures the following parameters:
Total 24hr SES (downstream)
Total 24hr ES (downstream)
Total 24hr SES (upstream)
Total 24hr ES (upstream)
Total 24hr uptime
Total 24hr unforced retrain count
Total 24hr Full Initialisations
Total 24hr failed initialisations
Line rate (downstream) in previous 24hr period
Minimum line rate (downstream) in previous 24hr period
Maximum line rate (downstream) in previous 24hr period
Line rate (upstream) in previous 24hr period
Minimum line rate (upstream) in previous 24hr period
Maximum line rate (upstream) in previous 24hr period
The days monitoring file covers the period 00:00 to 23:59:59
Definitely no FECs
That's good to know. If FTTC DLM is uneffected by the ASSIA patents (and just BT's ADSL DLM which is effected) then that will continue to apply. Has anyone been able to confirm if FTTC DLM is still operational?
-
Its not the ADSL DLM that is the problem, its the FTTC DLM one, I'll make a post in a few mins in the other thread.
-
Its not the ADSL DLM that is the problem, its the FTTC DLM one, I'll make a post in a few mins in the other thread.
Ok, thanks for confirming :).
-
here is why he not been DLM'd with the high ES, mystery solved :D
http://www.thinkbroadband.com/news/6726-assia-court-case-forces-openreach-to-turn-off-dlm.html
I guess you stuck newt :(
Have a feeling that the last part of your post is for me :)
Then should one give up on the sync capping as it seems futile after reading your TBB link.
-
@kitz Any idea how SES are used? They provide a measure of the frequency of high CRC events
-
No sorry. Not got that info.
All I know is that SES are usually a good indication of SHINE type noise. Its easy(ier) to rack up a ES as they can be triggered by just a couple of CRCs in a second.... but a SES is when a one second period contains >30% errored data.
-
SES certainly look like a good counter of the number of SHINE events I get each day. At times first thing in the morning but mainly at lighting up time when ever that is. You see it vary though the year. I had guessed they were counted as much worse than an ES and limiting them has been my main speed cap and modem messing about aim. I had rather hoped only ES and resyncs counted but it seems my fears may be well placed.
-
SES certainly look like a good counter of the number of SHINE events I get each day. At times first thing in the morning but mainly at lighting up time when ever that is. You see it vary though the year. I had guessed they were counted as much worse than an ES and limiting them has been my main speed cap and modem messing about aim. I had rather hoped only ES and resyncs counted but it seems my fears may be well placed.
Les-70 you are known as the sync capping guru has the experiment failed ?
-
No I suspect not. Due to SHINE my line is probably close to border line re DLM actions and capping seems to have held it bay.
-
here is why he not been DLM'd with the high ES, mystery solved :D
http://www.thinkbroadband.com/news/6726-assia-court-case-forces-openreach-to-turn-off-dlm.html
I guess you stuck newt :(
Have a feeling that the last part of your post is for me :)
Then should one give up on the sync capping as it seems futile after reading your TBB link.
Well someone on OCUK is claiming to have been banded yesterday which would suggest at least "part" of DLM is still enabled, note kitz suggested earlier it may only be a partial shutdown.
I now agree with kitz about how DLM is managed, with the different components of the network managed by BT wholesale.
So I dont know if what you doing is futile or not, the press reports suggest it is disabled, and the guy with the high ES not been DLM'd seems to fit into that.
It is even possible DLM was turned off but is now back on, it may have just been off for a very short time.
Edit - to add openreach press release stated they start shutting down 21 nov, meaning it might be the case they are in the process of shutting it down but it takes time to do nationwide. So thats another possibility.
-
N*Star, I can assure you that for the very first 24 hours after the installation, your line will have been configured "wide open" on fast-path. It would have been from the second day onwards that the DLM system would have taken an interest in the line (and then only if it had just cause to do so).
I can confirm this. Although I did see something that implied it may be 2 days - ie install day + one full day. Be damned if I can find it now though to go back and check :( .. but for sure everyone starts off with the wide open profile and interleaving wont have been added right from the start.
I notice wwwombat is also saying 2 days here (http://community.plus.net/forum/index.php/topic,134392.msg1175999.html#msg1175999)
On the third day, DLM uses the statistics gathered on the first 2 days to decide whether to intervene;
-
BT's SIN 498 document has this to say on the matter:-
2.2.1 Dynamic Line Management
Dynamic Line Management (DLM) is employed in GEA-FTTC. DLM constantly manages lines to maintain a target link quality (speed and stability). It does this for as long as the product exists.
At provision, the line is put on “wide open” VDSL2 line profiles allowing the upstream and downstream line speeds to run at the upper limit of the product option selected.
On the first day of operation, DLM will intervene if severe instability is detected. Otherwise, DLM will wait until the day after provision before deciding if it must intervene, provided that the line has been trained up for at least 15 minutes during the preceding day.
If DLM intervenes it will set a profile with a maximum rate and a minimum rate, where the minimum rate is set at approximately half of the maximum rate. The purpose of the minimum rate is to ensure that the line does not train at a rate which is significantly below the level the line should be able to achieve. If this happened, then the line is likely to remain at a very low rate until a re-train is forced by the user by powering off the modem.
Note : It is the DLM system that sets the line profile, and this should not be interfered with by CPs/users setting rates, SNR margins etc. at the modem.
-
On the first day of operation, DLM will intervene if severe instability is detected. Otherwise, DLM will wait until the day after provision before deciding if it must intervene, provided that the line has been trained up for at least 15 minutes during the preceding day.
Thank you, Feathers. That is exactly what I was vaguely recalling. :)
-
I'll keep this sync capping in the on position as what I have noticed the ES's don't just suddenly drop off drop when you cap the sync the errored seconds gradually start lowering every 24 hours.
-
On the first day of operation, DLM will intervene if severe instability is detected. Otherwise, DLM will wait until the day after provision before deciding if it must intervene, provided that the line has been trained up for at least 15 minutes during the preceding day.
Thank you BE
So SINET says "day after provision".
An internal document says one full day after provision (install day + 1 full day).
Plusnet say 2 days (http://community.plus.net/library/browsing/fttc-dlm-what-it-is-how-it-works/)
How confusing...
.. or could it just be the devil is in the detail on what a 'day' / full 24 hrs mean?
-
I'll keep this sync capping in the on position as what I have noticed the ES's don't just suddenly drop off drop when you cap the sync the errored seconds gradually start lowering every 24 hours.
It should do NS. I think thats just the way that its graphed now in that 00:00 shows your highest figure and 01:00 shows your lowest, as the total is reset only after the 00:00 has been plotted. Because MDWS only plots the E/S every hour, that is why between 00:00 it appears to decline, but in reality they would slowly be creeping back up again.
-
I'll keep this sync capping in the on position as what I have noticed the ES's don't just suddenly drop off drop when you cap the sync the errored seconds gradually start lowering every 24 hours.
It should do NS. I think thats just the way that its graphed now in that 00:00 shows your highest figure and 01:00 shows your lowest, as the total is reset only after the 00:00 has been plotted. Because MDWS only plots the E/S every hour, that is why between 00:00 it appears to decline, but in reality they would slowly be creeping back up again.
This DLM ES observation seems random you have STARMAN on his 6th day with 6000+ ES's in 24hr and me down from 192 to 100 ES in 24hr to me the DLM does not treat eveyone equally though there are more EU's who have a lower attenuation who are non-interleaved than EU's with a higher attenuation so background noise is a big factor on longer lines.
-
It looked like Starman has a manual reset of DLM after his recent line fault. I think the timing of the reset on the 21st & the recent ASSIA/BT dispute means that he has escaped the wrath of DLM and under normal circumstances, DLM would have caught up with him by now.
I suspect your line has a high ILQ rating based upon what ever happened in your first few months of FTTC, so therefore it will take a lot longer to recover. Personally I think the recovery procedure is tough and way too strict.
Im also unsure what profile BTretail provide their lines as.. theres only Plusnet and Zen who have been open and said they provide on 'Speed'.
BT may provide as 'Standard' which is the default setting. There is rumour that TT customers with TalkTalkTV are provisioned on 'Stable'.
Customers provisioned as Standard or Stable by their ISP are going to take a lot longer to recover and get interleaving removed than those on an ISP which used 'Speed' :(
-
is newt not on plusnet then?
-
No hes not.
The default profile setting for DLM is 'standard'.
Theres only been Zen and Plusnet who've come out and said they provision on Speed, although I suspect AAISP will also likely be using 'Speed'.
If BT retail are provisioning on standard, that will likely be a contributing factor why NS will be DLM'd quicker, and it will take a heck of a lot more stability to get interleaving removed. I pity any poor person with TalkTalkTV provisioned on Stable, as that will be a complete nightmare to get any changes removed - 2 Errored seconds per day and youve blown your chances. :'(
Someone needs to find out what BTr provision at, but finding out that info could be hard, as I bet most of the reps wouldnt have a clue what you are talking about :(
-
No hes not.
The default profile setting for DLM is 'standard'.
Theres only been Zen and Plusnet who've come out and said they provision on Speed, although I suspect AAISP will also likely be using 'Speed'.
If BT retail are provisioning on standard, that will likely be a contributing factor why NS will be DLM'd quicker, and it will take a heck of a lot more stability to get interleaving removed. I pity any poor person with TalkTalkTV provisioned on Stable, as that will be a complete nightmare to get any changes removed - 2 Errored seconds per day and youve blown your chances. :'(
Someone needs to find out what BTr provision at, but finding out that info could be hard, as I bet most of the reps wouldnt have a clue what you are talking about :(
It did feel as if I was DLM'd to interleaving faster when I was with BT Business (until the time I capped my connection 60Mbps downstream which brought it back to fastpath). With Zen it so far has been speed banding followed by interleaving, rather than interleaving being done first - interestingly.
-
Poor old STARMAN line has become interleaved :(
-
Looks like its been switched back on. I notice someone else on the forum said theyd been DLM'd yesterday too.
-
This is 100% definite.
Typical that the info comes a bit too late :( but here are some of the answers anyhow for the FTTC DLM.
The BToR DLM measures the following parameters:
Total 24hr SES (downstream)
Total 24hr ES (downstream)
Total 24hr SES (upstream)
Total 24hr ES (upstream)
Total 24hr uptime
Total 24hr unforced retrain count
Total 24hr Full Initialisations
Total 24hr failed initialisations
Line rate (downstream) in previous 24hr period
Minimum line rate (downstream) in previous 24hr period
Maximum line rate (downstream) in previous 24hr period
Line rate (upstream) in previous 24hr period
Minimum line rate (upstream) in previous 24hr period
Maximum line rate (upstream) in previous 24hr period
The days monitoring file covers the period 00:00 to 23:59:59
Definitely no FECs
Interesting... only my first or second post here, wish I had more time.
An interesting thing has happened to my VDSL. Some weeks ago, lets say the end of October I purchased a Draytek DSL Router to replace my OR/Sky router/Asus router combination. At that point, my sync was sitting at 61/20 and had been for as long as I'd been on the 80/20 profile. Because the Draytek decides that everytime you make a change to a setting it wants to reboot I was hammered by the DLM, there were also stability issues with the Draytek ( now sorted ) which added to the probem. Leaving it for a week saw no improvement so I put back the OR modem and after a few days there was still no change. Sky mamanged to get the DLM reset somehow, engineer call out to the cab I suspect, however, service was restored and I was back at 61/20. Being an optimist and with new firmware in the Draytek I reconnected it. This time it sat at 61/20 but over a few days fell to 51/20, then fell to 39/10!
Called Sky again, this time an OR engineer came to the house, I now having replaced the Draytek with the OR modem/Sky Router/Asus combo. Fair play to the guy, he was very thorough, popped his meter on there ( nice piece of kit! ) and said there were far too many errors and found a problem with the connections in the back box, not common but known about, replaced the back box and error count on his meter fell drastically. Connected the OR back up 68/20 and all working. Overnight the sync dropped back to its 61/20 as interleave was applied and I was back to my old rates; this was the Wednesday morning.
On the Frday evening, forever the optimist I reconnected the Draytek, determined I would get this thing to work. Synced at 61/20 and stayed there until the following Tuesday. On that morning I went out and bought an Asus DSL-AC68, No!!! I hear you say, well whatever, connected it up and it locked at 68/20, well I thought that's nice. At the time I was running at TBB Ping test and refering back to it I noticed that at 8:30 that morning there had been a momentary interuption and the latency had more than halved, so the sudden increase had occurred before the Asus was installed. The Asus as we now know was very unstable and must have re-synced several times it did not however trigger a DLM response. I ran the Asus intermittently over the next week testing new firmware versions but was never happy at the amount of errors I was seeing.
At this point let me say that the Asus has since left the premises and returned from whence it came ( PC World ). Since that day, I have had the Draytek running now for about 3 weeks, stable no re-syncs unless I cause it but I have on occassion forced a re-train or reboot with new firmware, something that prior to that one morning at 8:30 would have caused a DLM response.
I can sync quite happily at 68/20 but I see about 2400 FEC a day and maybe 180 ES so I have increased my SNR to 8db to reduce this, there are always zero SES and zero HEC.
I have lsearched and tried to see what is a normal range for these errors, as there will be errors but cannot find any definative values, it also appears that on the Tuesday I was put back on an open profile and the DLM has not interfered since, strange, any thoughts?
-
So far my initial thoughts are that the ASUS seems to handle interleaved connections better than the HG612 (only thing I can safely compare it with), though this is just comparing ES/SES/CRC values and not the FEC value. The FEC on the ASUS for the downstream does eventually go wild - though the connection remains fine still. On the HG612 I would still get some CRC errors/ES but with the exact same interleaved connection I would get little to no CRC errors/ES on the ASUS. The ASUS on the other hand seems to handle fastpath extremely unreliably, which I'm hoping will eventually be improved to a point where it's usable or better in comparison on fastpath.
-
I have since I posted this found a link that does give some detail on thresholds. If its true then I can afford to reduce my SNR back to 6db and still be in the safe zone.
I'm pretty sure that this has been seen before on this site, but here's a link anyway.
http://community.plus.net/library/broadband/broadband-faults-guide-our-testing/ (http://community.plus.net/library/broadband/broadband-faults-guide-our-testing/)
Ixel, I would really have liked to have been successful with the Asus, and I may, if they sort it out, go and buy one again. However, I cannot afford to have it randomly resetting as both myself and SWMBO work from home and we use VC a lot.
I'll not mention said modem again as it's off topic for this thread.
-
Fair enough, just sharing my thoughts as you asked :).
-
Yep my heart sunk for you when I saw mention of the DSL-AC68, although I do believe they are slowly getting there and at least PC World took it back.
>> so I have increased my SNR to 8db to reduce this,
Interesting, does this lower the sync speed? because all attempts with other routers the DSLAM over-rides it and still sets it at 6dB. With the BCM routers weve found that it is possible to increase the SNRm, but only by capping the maximum sync speed.
>> replace my OR/Sky router/Asus
Out of interest which OR modem did you get. If its a HG612 it may be worthwhile having a go at unlocking it.
>> I have lsearched and tried to see what is a normal range for these errors, as there will be errors but cannot find any definative values
Ive seen a few sets, but Im not sure if any of them are correct. The only ones we know for sure are the latest 21CN ones (http://www.kitz.co.uk/adsl/DLM.htm#DLM_categorising_the_line) and its pretty apparent that the fttc parameters dont appear to have changed at the same time the 21CN ones did.
30/300 seems to be about the nearest figures to what we see. But you also have to bear in mind we dont know which ISPs are provisioning on what stability level. Theres only Zen and Plusnet who so far have come out and said 'Speed'.
>> I would really have liked to have been successful with the Asus, and I may, if they sort it out, go and buy one again. However, I cannot afford to have it randomly resetting as both myself and SWMBO work from home and we use VC a lot
If you are looking for the best stability with the highest bit rates, then IMHO its got to be either a Billion, the HG612 or a Zyxel.
-
Raising the snr by 2db drops me from 69 to around 63, lowering it by 2db will take my sync rate up to 73+, of course if I do that the I see a proportional increase in errors.
My HG612 is as originally supplied when I went fttc, and I have unlocked it.
from what I have read it seems there are three profiles, speed, stable and super stable; my impression is that my (Sky) profile was set to super stable and is now on speed, that's the only way I can explain what has happened to my line.
The Draytek is solid now on the beta firmware I am running, so I have no worries with that, I am more interested in seeing how far I can raise the error rates without incurring the wrath of the DLM.
-
I thought it might be useful to post my Draytek stats at 8db SNR. Link up time is now at something like 23hrs 30 minutes. I'll reset the snr to 6db after I post this message and post the stats again after about 24 hours at that SNR.
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fs28.postimg.org%2Fy6u0f4o4d%2FCapture.png&hash=30cb3153586dc3318bdb147821b7d3f46b994e46)
Hmmm... OK, could be 7db then, whatever.. resetting to 6db now.
-
Notes for me and others
Currently reading the court case link (http://www.bailii.org/ew/cases/EWHC/Patents/2013/3768.html)
Section 235 - 238 lists some interesting info
Priority between interleaving and cap level
In some circumstances the ILQ indicates that green logic should be run. The green logic has a number of steps. The first important decision step in the downstream logic (step B) is an operation which provides a YES or NO answer. If the answer is YES the logic branches one way whereas if the answer is NO the logic branches another way. The YES branch may reduce the interleaving level while the NO branch may increase the cap level. In fact the NO branch includes some further questions (Step C and within step G) which might send the flow back to the interleaving branch but that is a detail and makes no difference to this analysis.
Importantly on the YES branch, the interleaving level may either be reduced by one or left as it is but whether the interleaving changes level or not, there cannot be a change to the cap level. On the other hand on the NO branch (subject to steps C and G) the cap level may be increased (or left alone) but if the cap level is to be increased, the interleaving level cannot be altered. So the green logic can lead to three possible outcomes overall: no change, reduce interleaving or increase cap level. These are the only possibilities. The logic cannot change both the interleaving and the cap level at the same time. The decision whether to actually change interleaving or cap level depends on line conditions.
A key part of the claimant's infringement case here involved arguing that this logic showed that the system gave a higher priority to increasing cap level over reducing interleaving. The defendant did not agree. One aspect of the claimant's argument and Prof McLaughlin's evidence was based on the defendant's marketing materials but I reject that. The priorities, if they exist, must be derived from the logic of the method used and not from assessments about the subjective views of the operator. Considering the logic itself, I fail to see how it is possible to state meaningfully that this green logic gives a higher priority to increases in cap level over interleaving. The logic simply chooses which branch to take in certain circumstances. The choice depends on line conditions. In this logic there is no priority between interleaving and cap rates.
Accordingly for these two distinct reasons, I reject the claimant's case that the NGA logic as a whole, or the entire green logic as a part of it, infringes the claims.
Since this has been rules as non-infringing then its likely that at least this part of the ILQ will stay?
We already know that the DLM classifies Red and Crimson (http://www.kitz.co.uk/adsl/DLM.htm#DLM_profile_changes) Red being from MTBR and Crimson from MTBE. We also know that DLM only reduces profiles if the ILQ is green. Therefore info contained in the above para would perhaps seem to indicate that which step if the ILQ deems your line as could depend on whether you were DLM'd for either MTBE or MTBR.
Need to try and do some more digging in this area..
-
Woooooo lookie what I just found whilst searching on info from the above para - a patent US 8582460 B2 (http://www.google.com/patents/US8582460) dated 2009 specifically devoted to the ILQ ;D
kitzy has lots more reading to do... and try figure out how it slots in with what info is already available.... and then if/how the patent would be applied to fttc.
Although the invention talks about changing SNRm, there are a couple of tables in there [table 3 & Table 4 ] that specify capped profiles.
Theres a bit of interesting information in there too about monitoring the SNRm. We already know that RAMBO can and does do this already when checking whether to apply a capped rate profile for poorly performing lines (http://www.kitz.co.uk/adsl/DLM_system.htm#DLM_additional_monitoring). It looks like this same function could also/is being used to monitor the line's SNRm for 'x' days before deciding whether to remove interleaving/caps.
Too soon to say anything definite until Ive digested it all and worked out how it fits in with existing BT DLM info.. but I thought some of you guys may also find this interesting. Im saving that patent to read later because Im still trying to work my way through the court case to see if any other gems of info come out of it which may aid further understanding.
-
Just to confirm the Draytek does alter sync rate when changing the SNR, last night I posted the stats for approx 24 hours at 8db, it WAS 8db even though it said 7.
Below are the stats for 25 hours at 6db ( default ). Now, a question for all those who have more knowledge than I do, and that's most people, are the stats below likely to trigger a DLM response or am I safe to leave it?
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fs27.postimg.org%2F53mqs9mtv%2FCapture.png&hash=03c69d9d997967f5a216d0aeb6a00a37b43367ac)
-
Just to confirm the Draytek does alter sync rate when changing the SNR,
Thats very interesting. Thank you for confirming it. Previously altering the target SNRm has been impossible.
Anyone on VDSL with a BCM based router want to try and see if it works on theirs too? Is this something to do with the recent changes.
are the stats below likely to trigger a DLM response or am I safe to leave it?
Sorry its a bit impossible to say from one set of stats. I cant tell how long a period the ESecs cover.
232 E/S for a day is perfectly fine. Your upstream looks more concerning though :(
-
If BT retail are provisioning on standard, that will likely be a contributing factor why NS will be DLM'd quicker, and it will take a heck of a lot more stability to get interleaving removed.
Kitz i do think it's going to take a miracle for interleaving to be removed, it's now 7days since capping the sync from 30000 kbps to 25000 kbps even with 100 downstream errored seconds over 24 hours and with my oscillating SNRm this is going to be hard to get interleaving removed :(
-
Just to confirm the Draytek does alter sync rate when changing the SNR,
Thats very interesting. Thank you for confirming it. Previously altering the target SNRm has been impossible.
Anyone on VDSL with a BCM based router want to try and see if it works on theirs too? Is this something to do with the recent changes.
are the stats below likely to trigger a DLM response or am I safe to leave it?
Sorry its a bit impossible to say from one set of stats. I cant tell how long a period the ESecs cover.
232 E/S for a day is perfectly fine. Your upstream looks more concerning though :(
The upstream statistics might be doing what the ASUS modem's statistics do (at least through TC Console, not the web interface). That being it has the ability to fetch the statistics from the DSLAM for the upstream and the DSLAM keeps record of these even when a re-sync occurs. They might be the actual total for the connected port since the port was made active on the DSLAM.
-
That's correct, it's fetching the total FE errors even after a re-sync, so those are the total figures from the DSLAM. I wonder it that's the figures since it was reset, now almost a month or since the DSLAM went live on that circuit.
I have just started to put a program together which will pull the figures down and keep delta stats so makining it easier to see what's happening. Strangely, the telnet interface where I pull the data from does not give me the same amount of information as the web interface, and I have yet to work out how to extract the figures from the web interface. Think I'll email Draytek and ask for an extended console status command.
-
If BT retail are provisioning on standard, that will likely be a contributing factor why NS will be DLM'd quicker, and it will take a heck of a lot more stability to get interleaving removed.
Kitz i do think it's going to take a miracle for interleaving to be removed, it's now 7days since capping the sync from 30000 kbps to 25000 kbps even with 100 downstream errored seconds over 24 hours and with my oscillating SNRm this is going to be hard to get interleaving removed :(
It's making me think that the sudden increase in sync rate was then just that the Draytek is producing less errors than the HG612 or at least is not reporting them back to the DSLAM, in the same way that Ixel can overide the DSLAM, although as you say the errors look fine.
ES count would have been 24hrs and 30 minutes, or at least the DS one is.
It gets ever more confusing!
-
Here's an interesting fact for everyone to chew into ;). This morning DLM intervened and increased my upstream (by increased, I mean changed profile to be fastpath - roughly two weeks after it was interleaved I believe). However, here's where the interesting bit comes in:
Downstream PTM TPS-TC chennel 0 Capabilities
Min_net_data_rate = 128 kbit/s
Max_net_data_rate = 49000 kbit/s
Rederved_net_data_rate = 0 kbit/s
Max_interleaving_delay = 8 ms
INP_min = 3 symbols
Dynamic interleaver reconfig(amd1) = N
INP no erasure = N
Pre-emption = N
Short packet = N
CIpolicy(amd1) = Mandatory
Upstream PTM TPS-TC chennel 0 Capabilities
Min_net_data_rate = 128 kbit/s
Max_net_data_rate = 20000 kbit/s
Rederved_net_data_rate = 0 kbit/s
Max_interleaving_delay = 1 ms
INP_min = 0 symbols
Dynamic interleaver reconfig(amd1) = N
INP no erasure = N
Pre-emption = N
Short packet = N
CIpolicy(amd1) = Mandatory
Notice the 'min_net_data_rate', it's not roughly half the 'max_net_data_rate', yet it used to be (could this be part of the DLM changes relating to ASSIA patents court case?).
Here's an old sample for comparison:
Downstream PTM TPS-TC chennel 0 Capabilities
Min_net_data_rate = 25000 kbit/s
Max_net_data_rate = 49000 kbit/s
Rederved_net_data_rate = 0 kbit/s
Max_interleaving_delay = 8 ms
INP_min = 3 symbols
Dynamic interleaver reconfig(amd1) = N
INP no erasure = N
Pre-emption = N
Short packet = N
CIpolicy(amd1) = Mandatory
Upstream PTM TPS-TC chennel 0 Capabilities
Min_net_data_rate = 10000 kbit/s
Max_net_data_rate = 20000 kbit/s
Rederved_net_data_rate = 0 kbit/s
Max_interleaving_delay = 8 ms
INP_min = 4 symbols
Dynamic interleaver reconfig(amd1) = N
INP no erasure = N
Pre-emption = N
Short packet = N
CIpolicy(amd1) = Mandatory
-
>> 'min_net_data_rate', it's not roughly half the 'max_net_data_rate'
Thats interesting. Im pretty certain that in amongst all the stuff Ive read on DLM there was something about a minimum figure and max figure is used, but for what I cant recall where now. Ive read sooooo much stuff you wont believe, but Ive tried to be methodical about it and only concentrate on each step of the process at any one time, otherwise its information overload. I'll no doubt come across it again as I work my way through the next step or two.
Problem here is that most routers dont show that info. The BCMs have a MaxDataRata setting, but I cant recall a Minimum. These figures dont show up on any of the line stat figures either. We do get a figure though which is about 1/4 of my sync speed (Number of bits in PMD Data Frame.)
L: 20104 5410
Next time I have a few hours (and the will) to go through all the stuff again I will be on the lookout for it.
As an aside. Whilst making this post Ive just had a resync completely out of the blue. There is no reason why my line should have resync'd and it wasnt generated at my end. Its not unusual for my DLM resyncs to occur at 10-11am, yet I cant see that any line params have been changed. Anyone else have unexplained resyncs this morning at about the time the DLM would force changes?
-
yes usually the min is half the max, I seen this when I used my friztbox.
Interesting find ixel.
-
>> 'min_net_data_rate', it's not roughly half the 'max_net_data_rate'
Thats interesting. Im pretty certain that in amongst all the stuff Ive read on DLM there was something about a minimum figure and max figure is used, but for what I cant recall where now. Ive read sooooo much stuff you wont believe, but Ive tried to be methodical about it and only concentrate on each step of the process at any one time, otherwise its information overload. I'll no doubt come across it again as I work my way through the next step or two.
Problem here is that most routers dont show that info. The BCMs have a MaxDataRata setting, but I cant recall a Minimum. These figures dont show up on any of the line stat figures either. We do get a figure though which is about 1/4 of my sync speed (Number of bits in PMD Data Frame.)
L: 20104 5410
Next time I have a few hours (and the will) to go through all the stuff again I will be on the lookout for it.
As an aside. Whilst making this post Ive just had a resync completely out of the blue. There is no reason why my line should have resync'd and it wasnt generated at my end. Its not unusual for my DLM resyncs to occur at 10-11am, yet I cant see that any line params have been changed. Anyone else have unexplained resyncs this morning at about the time the DLM would force changes?
Yeah, it's unfortunate that most modems don't display that data. I'm hoping the rumour of ASUS locking down TC is not true, if that happens then I'll probably sell the router on or take it back for a refund/credit note. Anyway, my guess is your connection might have had its minimum sync rate altered to like mine is now (128Kbps), presumably under DLM's changes regarding the ASSIA patents court case.
-
@Kitz
No retrains here, 37 hours uptime since the last re-sync when I changed the SNR.
-
I've been up for 45 days now, and still interleaving is not relenting. As far as I can see, I have very few errored seconds. Do my stats on mydslwebstats offer any kind of clue to you knowledgeable folk as to whether I might ever come back off of interleaving? I was off for a couple of months once upon a time!
Sent from my Lumia 1520 using Tapatalk (with free typos)
-
I can see no rhyme or reason with the way the DLM operates, yours looks very clean.
-
I've been up for 45 days now, and still interleaving is not relenting. As far as I can see, I have very few errored seconds. Do my stats on mydslwebstats offer any kind of clue to you knowledgeable folk as to whether I might ever come back off of interleaving? I was off for a couple of months once upon a time!
Sent from my Lumia 1520 using Tapatalk (with free typos)
If Sky provision their FTTC services on DLM's 'standard' profile then it's no surprise that you're not on fastpath yet. Looking at your graphs and entering the average ES daily (around 30-40 error seconds each day I see for the last couple of days mostly), on Kitz's DLM calculator it shows the status as 'amber', meaning no change is necessary. I'm not sure what thresholds the Kitz's DLM calculator follows, but I'm guessing it's not the ones shown in Zen's FTTC training document from a few years ago. To get a 'green' status on DLM's 'standard' profile the calculator shows you need less than 15 errored seconds in a 24 hour uptime period. If this is the case then Zen's document is clearly wrong, as going by the document your line should've had a change (unless you have a large caution counter or w/e it's called).
-
I've just had a look at the web stats, the only thing that stands out is on the US snrm, I wonder if the DLM is looking at that in some way. I am also on Sky and unless I have been put on a fast profile I would have thought my ES was sufficient to trigger the DLM. Of course I am not complaining. :)
-
on Kitz's DLM calculator it shows the status as 'amber',
Its currently set for WBC 20/21CN rather than FTTC. :( and although its dead easy for me to change the parameters, it seems pretty obvious that fttc is using a different set of figures for the 'speed' profile.
I guess I really need to build 2, or probably better add an option to select FTTC/WBC. That said, if it showing as amber now on WBC then because the fttc params are stricter, then it wont be green for fttc either.
-
or probably better add an option to select FTTC/WBC.
Done.
-
I've been up for 45 days now, and still interleaving is not relenting. As far as I can see, I have very few errored seconds. Do my stats on mydslwebstats offer any kind of clue to you knowledgeable folk as to whether I might ever come back off of interleaving? I was off for a couple of months once upon a time!
Sent from my Lumia 1520 using Tapatalk (with free typos)
If Sky provision their FTTC services on DLM's 'standard' profile then it's no surprise that you're not on fastpath yet. Looking at your graphs and entering the average ES daily (around 30-40 error seconds each day I see for the last couple of days mostly), on Kitz's DLM calculator it shows the status as 'amber', meaning no change is necessary. I'm not sure what thresholds the Kitz's DLM calculator follows, but I'm guessing it's not the ones shown in Zen's FTTC training document from a few years ago. To get a 'green' status on DLM's 'standard' profile the calculator shows you need less than 15 errored seconds in a 24 hour uptime period. If this is the case then Zen's document is clearly wrong, as going by the document your line should've had a change (unless you have a large caution counter or w/e it's called).
of course this is dependent on what profile he/she is on.
I think sky are not using the performance profile, my guess is based on the fact their own ADSL DLM is very conservative, they seem to like to play it safe.
-
of course this is dependent on what profile he/she is on.
I think sky are not using the performance profile, my guess is based on the fact their own ADSL DLM is very conservative, they seem to like to play it safe.
[/quote]
Which is where it gets strange, I am on sky, ES per day is running a little over 220 no retrains and I'm on Fastpath.
This leads me to another thought. A few weeks ago, when I was having issues with the DLM, not going to go into it, but if you wish to read the story it's my first post in this thread, I spoke to Sky support who said they were going to try something new, it might take 48 hours to work. I thought that would be a remote DLM reset but now I wonder if it was a change of profile to speed. Hmmm... the mystery continues.
-
@kitz Please can you say which set of figures you are using for the FTTC option DLM calculator. For amber I get the follows ES/day from it.
Speed 287-2880
Standard 14-287
Stable 1-24
They look like the one BS provided, but do you really think they apply to FTTC? They are very different to be previous ZEN or Plusnet ones. They seem so severe on stable that not many MDWS users could be on stable. A number of fast path TT people have been OK over these standard limits but not over the 1440 limit. In fact as noted before no one seems to be above 1440 for more than an odd day. As far as you can get TT to tell you they provision on standard. The speed figures look credible but the other seem dreadfully severe --- Max rates for amber of 12ES/hour on standard and max 1ES/Hour on stable. Virtually no line could ever achieve 1 ES/hour average without lots of interleaving.
-
@kitz Please can you say which set of figures you are using for the FTTC option DLM calculator. For amber I get the follows ES/day from it.
Speed 287-2880
Standard 14-287
Stable 1-24
They look like the one BS provided, but do you really think they apply to FTTC? They are very different to be previous ZEN or Plusnet ones. They seem so severe on stable that not many MDWS users could be on stable. A number of fast path TT people have been OK over these limits but not over the 1440 limit. In fact as noted before no one seems to be above 1440 for more than an odd day. As far as you can get TT to tell you they provision on standard. The speed figures look credible but the other seem dreadfully severe --- Max rates for amber of 12ES/hour on standard and max 1ES/Hour on stable. Virtually no line could ever achieve 1 ES/hour average without lots of interleaving.
The above sound like the ones I found mentioned on Zen's website/training document.
-
The speed number are the same but the rest are totally different.
-
The speed number are the same but the rest are totally different.
Oh, didn't notice that, yes you're right. No idea where the other two come from then :s.
-
Whilst DLM things may still be in a state of flux broadstairs (on TT) was OK at ~800ES/day but went interleaved with ES+SES a bit over 1440 and quickly recovered today with 39 and 32ES/day in the two days that followed. (I got the 39 by counting a part day from the point of interleaving). That does not seem to match the new Kitz criteria. As noted above, TT reps claim TT is on standard?
My previous analysis of 10 days of all the MDWS interleaved connections and a few transitions suggested that you needed to be below ~20-40ES/day, often for a very long while, to go to fast path, an exact figure just can't be deduced. Most MDWS interleaved connections get 30-200ES/day and over the length of record that I looked at seem stuck interleaved.
-
^^This..
I've rebooted the modem in the hope it might become "unstuck" after 50 days sync..in 9 hours up I have 8 ES and it tallies with previous figure of about 28 ES per 24 hours..
It seems with most interleaved connections using BT's DLM, you are on interleaved for keeps
-
It seems with most interleaved connections using BT's DLM, you are on interleaved for keeps
I guess for most people that have been Interleaved for a long time the connection is just to noisey to be moved off interleave and even by capping my own sync the errored seconds went down by 50% 87-100 ES per Day this is still way of the mark if 20-40 ES Per Day is the requirement for the DLM to move one's line off interleaving.
-
Well they (TT) put me back on fastpath this morning and so far my stats are not too bad but we'll see what the evening brings. Also because of the way DSLStats works MDWS got turned off earlier today and I did not notice for quite a while, so MDWS totals will not be accurate today.
Stuart
-
@kitz Please can you say which set of figures you are using for the FTTC option DLM calculator.
WBC should be using BS figures. FTTC should be using Zen 30/300 figures.
So far Ive found 8 possible different parameter profiles.
as noted before no one seems to be above 1440 for more than an odd day.
That would need something like a 60/600 profile then. The only set I have that has a 60/600 is the very first set when BToR mapped direct to BTw profiles back in 2009. Ive attached a copy of the full params below. I note the MBTR figures map quite nicely with the BS WBC figures - they are still the same. MBTE are quite a lot different though. See what you think.
-
The speed number are the same but the rest are totally different.
Oh, didn't notice that, yes you're right. No idea where the other two come from then :s.
Oops - spot the deliberate C&P error when splitting into 2 separate functions. It involved lots of C&P :-[
Sorry I was rushing last night to get it up asap and I missed changing something. The WBC should have been returning correctly, but you can spot why fttc returned a mixture of Zens and BS
if ($DSL_type == 'FTTC') {
$status1 = get1_mtbe_fttc($mtbe); // Get statuses for different profiles using the MTBE function.
$status2 = get2_mtbe_wbc($mtbe);
$status3 = get3_mtbe_wbc($mtbe);
should now be sorted. Thanks for pointing it out.
-
So is the suggested FTTC version the ZEN provided one below? I think that is also different from the Plusnet posted one which does not indicate the speed/standard/stable option. A poor image of that is below.
edit The Plusnet figures give amber between 205 and 8640 ES/day and although they appear "ambiguously" on the page Kitz gave a link to many post ago I doubt that they apply to FTTC.
-
So is the suggested FTTC version the ZEN provided one below?
Yes those are the figures Im using atm for the FTTC calculation ie the 30/300 which equates to an allowance of 2880 E/s per day.
I think that is also different from the Plusnet posted one which does not indicate the speed/standard/stable option.
Thats one of the eight that I have. Those figures are very different from Zens 30/300 profile. PNs is showing profile 10/420.. Ive another set of profiles that are very similar to those PN ones... which are WBC ones dated 2011. (see below)
I dont think fttc is using 10/420 from what we see on MDWS which is why I discounted it. Put it this way, a 10/420 profile = 8640 ErrSecs for red & 205 green.
Just to complete the picture:
30/300 profile (Zen) = 2880 red & 288 green
60/600 profile (orig 2009 profile) = 1440 red & 144 green
I have seen a document that states a new FTTC profile was put in place more recent than that.. unfortunately though the link for the actual profile param details it sends me somewhere behind the BT paywall so I dont know what it says :(
These are what I think may the full params for the PN one
Stability MTBE Red MTBE Green MTBR Red MTBR Green
1 10 420 8640 16800
2 300 6000 16800 33600
3 3600 60000 33600 67200
-
What did plusnet post?
kitz can you post all 8?
-
Whatever DLM is now running it seems very slow at reacting.
On the 20th November it nudged me up from approx. 40/14 to 47/17 having dropped the ASUS DSL-AC68U completely a few days prior. Since then no change despite what look like very good stats and just one reboot to change some dsl params...
Total time = 7 days 7 hours 44 min 16 sec
FEC: 6618766 250663
CRC: 119 55
ES: 20 22
SES: 0 13
UAS: 33 33
LOS: 0 0
LOF: 0 0
LOM: 0 0
Either DLM isn't running nationwide just yet or it's forgotten about me :'(
-
I find these higher ES threshold values way to high before the DLM kicks in, as this evening got 60 errored seconds in under 1 minute due to faulty table light switch it was fizzling & the light flickered the HG612 has done a re-sync very close to this event with a retrain 6 code.
You can have a look at MDWS and see the results for yourselves
-
Whatever DLM is now running it seems very slow at reacting.
On the 20th November it nudged me up from approx. 40/14 to 47/17 having dropped the ASUS DSL-AC68U completely a few days prior. Since then no change despite what look like very good stats and just one reboot to change some dsl params...
Total time = 7 days 7 hours 44 min 16 sec
FEC: 6618766 250663
CRC: 119 55
ES: 20 22
SES: 0 13
UAS: 33 33
LOS: 0 0
LOF: 0 0
LOM: 0 0
Either DLM isn't running nationwide just yet or it's forgotten about me :'(
Im in a similar situation. Think dlm is punishing those that used the asus dsl-ac68.
Sent from my LG-D855 using Tapatalk
-
Whatever DLM is now running it seems very slow at reacting.
On the 20th November it nudged me up from approx. 40/14 to 47/17 having dropped the ASUS DSL-AC68U completely a few days prior. Since then no change despite what look like very good stats and just one reboot to change some dsl params...
Total time = 7 days 7 hours 44 min 16 sec
FEC: 6618766 250663
CRC: 119 55
ES: 20 22
SES: 0 13
UAS: 33 33
LOS: 0 0
LOF: 0 0
LOM: 0 0
Either DLM isn't running nationwide just yet or it's forgotten about me :'(
Im in a similar situation. Think dlm is punishing those that used the asus dsl-ac68.
Sent from my LG-D855 using Tapatalk
I've always found that DLM is slow to react to improving the downstream on any device, though is quicker to react to improving the upstream (if it needs to).
-
Looks like DLM finally took a sniff at my line this morning around 9.30am (odd time).
Increased from 47/17 to 54/17, so it looks like the affects of the ASUS are slowly being undone.
-
Pleased to hear that. My limited understanding of the DLM is that if you had for example 3 successive stabilizing actions taken by the DLM that the last one will come off quite quickly if the errors go low enough, but each of the other hits will take an increasingly long time of good performance to convince the DLM to reverse things. So if you have another level to remove that may need an even longer wait.
-
It seems as though after reading this thread I'm none the wiser on DLM!
I spent 2 months with a manually banded line at 38,000Kbps with an attainable of 51,000Kbps and an SNRM of 9.4dB. Error rates were lower than 2 ES per hour, and even after 2 months my connection was not put on fast path.
It had only previously been disconnected 3 times in 3 months (once manually, twice by DLM which was in the first two days of install) and it still didn't recover.
I've let it go back to whatever it wants and I'm currently sat at 44,000Kbps and an SNRM of 6.4dB (I was tired of slower downloads), ES are currently at 8 ES/hr after 20 days uptime, and again no change.
Would we expect me to be put on fast path based on what we've found?
I'd love to get on fast path because I'm a big gamer.
-
Who knows... Only OR and they won't tell anyone, maybe a freedom of information request by your MP may help!
Whatever it is, it seems it's an exponential curve when it comes to restoration.
-
My previous analysis of 10 days of all the MDWS interleaved connections and a few transitions suggested that you needed to be below ~20-40ES/day, often for a very long while, to go to fast path, an exact figure just can't be deduced. Most MDWS interleaved connections get 30-200ES/day and over the length of record that I looked at seem stuck interleaved.
@xreyuk Interleaving gives a very big CRC/ES reduction so recovery needs low values. Where your correct to be puzzled is that there are many interleaved people who seem stuck interleaved whose long term daily ES rate is significantly less than suggested values of 60 standard and 120 fast. Line history should influence the ease of recovery but to many it does look its line archaeology that seems to count. As noted above a value more like a sustained less than 30ES/day seems a better fit to experiences of a return to fast path.
-
there are many interleaved people who seem stuck interleaved whose long term daily ES rate is significantly less than suggested values of 60 standard and 120 fast.
The 60/600 profile which I posted last week dates back to 2009.
I recently came across a new algorithm dated Jun 2012 which is labelled NGA, its worded strangely but if you do the maths then it comes out with exactly the same figures as quoted by Zen. Ive contacted someone for confirmation if theres anything later but so far they are keeping stum. I cannot find anything that specifically relates to FTTC that is newer than the 30/300 profile.
As mentioned previously there is another algorithm which decides how soon your line recovers, and it certainly implies that recovery is different depending on whether the DLM kicked in due to MTBE or MTBR.
-
PS - dont forget part of that step... and as previously mentioned... from what Ive been reading in the court case about the flow chart.. seems to suggest that for those who have gone deeper down the DLM rabbit hole, then their SNRm is monitored for 14 days before positive changes are made.. and if your SNRm varies by more than say 4dB over that 14 day period then you are stuffed :(
-
My previous analysis of 10 days of all the MDWS interleaved connections and a few transitions suggested that you needed to be below ~20-40ES/day, often for a very long while, to go to fast path, an exact figure just can't be deduced. Most MDWS interleaved connections get 30-200ES/day and over the length of record that I looked at seem stuck interleaved.
@xreyuk Interleaving gives a very big CRC/ES reduction so recovery needs low values. Where your correct to be puzzled is that there are many interleaved people who seem stuck interleaved whose long term daily ES rate is significantly less than suggested values of 60 standard and 120 fast. Line history should influence the ease of recovery but to many it does look its line archaeology that seems to count. As noted above a value more like a sustained less than 30ES/day seems a better fit to experiences of a return to fast path.
Thanks Les, I think I just got tired of waiting for it to restore and let it do what it wants. I'm still getting around 21ms to the BBC, so it's not like I'm sky high for gaming, just would have been nice if it was lower!
-
PS - dont forget part of that step... and as previously mentioned... from what Ive been reading in the court case about the flow chart.. seems to suggest that for those who have gone deeper down the DLM rabbit hole, then their SNRm is monitored for 14 days before positive changes are made.. and if your SNRm varies by more than say 4dB over that 14 day period then you are stuffed :(
so the recovery process is now changed since the court case?
-
Tbailey2 has been over 1440 ES/day since the 5th December. That seems to be the first solid evidence in MDWS stats that the Plusnet ES limit is 2880/day.
-
DLM adjusted my line again this morning around 9.30am, up from 54/17 to 54/19, 5 days after the last alteration. It would seem that DLM is a good deal quicker at raising the Up Stream than Down stream. Fingers crossed the next adjustment should restore fast-path on the downstream.
-
PS - dont forget part of that step... and as previously mentioned... from what Ive been reading in the court case about the flow chart.. seems to suggest that for those who have gone deeper down the DLM rabbit hole, then their SNRm is monitored for 14 days before positive changes are made.. and if your SNRm varies by more than say 4dB over that 14 day period then you are stuffed :(
so the recovery process is now changed since the court case?
No reading the court case notes, led me on a path to searching for something else which I found more info on.
Too long to explain atm, but I think I posted a link a few pages back to a BT patent which showed the algorithm. Lots of reading to do to understand it, but I will at one point attempt to summarise it all.
-
Mentioning here as I know people are watching MDWS - I'm 'JustAnothe', had a line fault where the leg back from the 'junction point' (?) to my house had started to break down, introducing static and popping on the line suddenly, a few days back. I had a real BT engineer visit (not from Kelly Communications) who diagnosed the issue - but importantly completely swapped the line as it turned out we have a spare properly ducted line into the property (compared to unprotected 'armoured cable' of the original line).
So now I have an almost error-free line synching at a much better upstream rate (downstream too but I'm not too bothered by that) - he also reset the DLM properly, so I suddenly have no interleaving or banding or anything. So don't think that my stats reflect normal behaviour of DLM, aside from when things went to hell earlier ;)
He did a really good job and was genuinelly interested in sorting the problem - initially I was going to have to wait months to have the fault diagnosed and the line dug up to be replaced.
-
It's nice to read a story which ended well.
I had a real BT engineer visit (not from Kelly Communications) who diagnosed the issue
<snip>
He did a really good job and was genuinelly interested in sorting the problem
<snip>
Clearly one from Black Sheep's flock. ;D
-
B*Cat, :blush: :blush: :blush: ......... still a good few of us knocking around, here and there. ;D ;D ;D. Great result, Justanother. May I ask, what part of the country do you reside in (Just the County will do), it's just it sounds very similar to one I've been on recently ?? Cheers.
-
I am looking at JustAnothe on MDWS and to me the errored seconds look worse than it was 3 days ago :-\
-
While the ES are "worse" they are now with interleaving off. It was on before so you can't really compare them.
-
While the ES are "worse" they are now with interleaving off. It was on before so you can't really compare them.
Your quite right of course, should have taken that into consideration while looking back into stat's
-
My secret headquarters are somewhere in the Midlands ;) It was an AM slot today for the record.
-
Alas, nowhere near you my friend. No worries, hopefully the issue has been fully resolved. Cheers. :)
-
While the ES are "worse" they are now with interleaving off. It was on before so you can't really compare them.
Your quite right of course, should have taken that into consideration while looking back into stat's
given he is now staying within the DLM threshold, I would agree with him the line is now performing better. As obviously the line was previously bad enough to get interleaved.
-
Alas, nowhere near you my friend. No worries, hopefully the issue has been fully resolved. Cheers. :)
you think its good when we get pair swaps then? :)
-
On a 'Garden Leader' (from kerb to premises), it's common-place to perform a pair-swap if the new pair tests OK. It saves potential ground-works on the EU's premises (anything from a small garden front, to a palatial spread). This is in regard to 'Direct in ground' (Armoured) cable
It's rare for a 'Ducted cable' to have a faulty pair, I've personally only known one, which was down to a rat chewing on it. There is always the very rare occasion that there could be split-pairs (Causing poor AC Bal), but this doesn't seem to be what the forum member is talking about ?
However you want to view it, we weren't there on-site and not privy to the full details and as such, any comments are pure speculation and personal opinions only. :)
-
He said that a proper ducted pair was like gold dust here, so I'm lucky that the line was put in for my father's work (paid for by his company), which then went unused some years later.
-
given he is now staying within the DLM threshold,
Yeah but then it means there are two different thresholds one for Interleaved and non Interleaved and still both of those values are still in the grey area, yet there is a constant here and that is to reset the DLM to obtain a non Interleaved line when the DLM get's stuck.
The above will of course put a strain on BT Openreach resources yet JustAnother got there line issue sorted out in two days from fault to fix that's impressive :)
-
I notice that this morning my connection went interleaved. ??? I am surprised at this. It was running along with about 250ES/per day and one or two SES. I can't see any obvious reason at all in my stats which are now 24/7. I think the only possibility is the something to do with my cable tidy up yesterday. When doing this I accidentally pulled the power supply cable from the modem. However I was surprised to see a reason 1 Resync though so maybe I did more than this or did it in a way which caused errors before the power down. After this I deliberately disconnected for about 40 minutes in order to do a good tidy up job without the same thing happening again.
For now I am treating it as an experiment and will see again if I really notice any difference. My speed cap is still in place but having almost no effect as the snrms are close to 6. It confirms my judgment that I was capping at about the interleave sync speed. If get more than a few ES I will cap the speed a bit lower.
-
Well les-70 I left my sync speed cap at 26000 kbps for 14 days and still not interleaved, so have given up hope so reset the HG612 (power off for 30 mins) there is no point in trying to fool the DLM ;)
-
Yeah but then it means there are two different thresholds one for Interleaved and non Interleaved and still both of those values are still in the grey area,
No theres just the one. If you breach the MTBE whilst non Interleaved, then you get interleaved. If you breach the same MTBE when interleaved then it applies a further depth of interleaving/INP applied. If you breach it again then you get capped, etc etc.
-
I notice that this morning my connection went interleaved. ??? I am surprised at this. It was running along with about 250ES/per day and one or two SES. I can't see any obvious reason at all in my stats which are now 24/7.
Ive had a quick look too. How strange because I cant see any obvious reason either. ???
-
Well les-70 I left my sync speed cap at 26000 kbps for 14 days and still not interleaved, so have given up hope so reset the HG612 (power off for 30 mins) there is no point in trying to fool the DLM ;)
A little known fact is that before DLM is reduced your SNRm appears to be monitored. Depending on circumstance, you also have to satisfy a period of time with a steady SNRm of 'x'.
-
Talking about reduced SNRm it looks like Starman is in that area his/her DS SNRm is 0.9dB at the moment this is one facinating line to watch.
-
Yes, indeed. I have just taken a look and see that the DS SNRM appears to be hovering around 1 dB. :o
If the last three days are displayed, it is clear that some event has occurred . . . probably during the time when no data was being uploaded to MDWS.
Three days ago: DS a little above 6 dB, US a little below 7 dB. The delta (difference between DS & US) was ~0.7
Now: DS a little above 1 dB, US a little below 5 dB. The delta is ~3.8
-
It's just a guess could Starman be is using the sync capping commands to sync higher than the attainable sync this would have a massive negative effect on the downstream SNRm :-\
-
A little known fact is that before DLM is reduced your SNRm appears to be monitored. Depending on circumstance, you also have to satisfy a period of time with a steady SNRm of 'x'.
Thankyou Kitz have read your topic on DLM and you did mention the SNRm could be monitored if a line like my own swings alot over 24 hours, as you know there is nothing I can do to stop my SNRm fluctuating so the x could be 1dB variation threshold on the SNRm.
Though I have been seeing many large OprenReach vans working close to our premises over the last month, they seem to be working on two manhole covers and there was one yesterday at 12pm this caused the line to become unresponsive for 45 minutes.
-
It's just a guess could Starman be is using the sync capping commands to sync higher than the attainable sync this would have a massive negative effect on the downstream SNRm :-\
That certainly is worth a thought . . . but I am not sure if you can use the command to set a cap greater than the maximum.
-
the attainable sync is not a cap so no.
-
the attainable sync is not a cap so no.
Don't understand your answer ?
Can you set --Maxdatarate higher than attainable, for example say my DS attainable is 35000kbps and US attainable is 6000
would --maxdatarate 38000 7000 40000 work ?
-
the attainable sync is not a cap so no.
Don't understand your answer ?
Can you set --Maxdatarate higher than attainable, for example say my DS attainable is 35000kbps and US attainable is 6000
would --maxdatarate 38000 7000 40000 work ?
I have tried this on the HG612 in the past, it didn't seem to work. However, on the ASUS DSL-AC68U I am able to specify a higher sync rate than the one set on the DSLAM, as well as change the minimum INP and maximum delay on the downstream (can't modify the upstream however). It's the only device I've found so far which can do this type of thing, unfortunately finding the stable soluiton to it is a tricky matter (for fastpath). I am persisting though.
-
With BCM devices e.g. HG612 the cap is just a cap you can't beat the attainable.
-
With BCM devices e.g. HG612 the cap is just a cap you can't beat the attainable.
say no more ;) I know what your upto but you can't beat the DLM :D
-
the attainable sync is not a cap so no.
Don't understand your answer ?
Can you set --Maxdatarate higher than attainable, for example say my DS attainable is 35000kbps and US attainable is 6000
would --maxdatarate 38000 7000 40000 work ?
The cap is what the banding is set to.
By default on a new line the banding will match the product spec so e.g. 80/20.
The attainable speed reported by the modem has no relation to the banding, it is simply estimating what the line can achieve on current noise margin and target snrm.
e.g. A line can have an attainable of 110mbit even tho its capped to 80mbit by the banding.
My line is capped to 80 yet its attainable is only 72-73.
There is nothing stopping you set a cap of say 90mbit on the modem, but I would think the DSLAM's own banding would come first and as such you wouldnt sync over 80mbit.
-
I thought I would use this thread to add an observation concerning roseways's connection. Starting in early Jan his line started getting extra errors and then exactly 20 days ago while he was in process of changing modem/routers his line went interleaved downstream.
Since then he has had only 1-5 ES/day downstream. His snrm has varied a little by ~0.5db and it puzzles me why the DLM has not backed off. This is especially true as the level of interleaving is quite high and at the least a change back to lower interleaving would be expected given the very low ES rates. If nothing happens on his line soon I may be joining the FEC conspiracy theories.
-
@les-70: You're quite right in every respect. I know FECs have been dismissed as playing any part in DLM, but it's hard to think of any other reason why my connection is still on the fairly high interleaving level.
-
I've long suspected FEC is a DLM consideration.
During the time I was using the ASUS DSL-AC68 despite minimal CRC/ES/SES errors DLM would never adjust my profile upwards unless I stuck the Openreach Modem in-front of it or switched to a Broadcom device. This it would seem was because the ASUS was recording 100x more FEC errors than the Broadcom device.
I've since started using a Fritzbox 7490 which is a ECI chipset and my line is much quicker at reversing DLM actions, as was the case earlier this month when roadworks outside my home caused Interleaving to be applied for 72 hrs. Had the Asus still been in place I doubt I would even be on a Fastpath connection.
-
Apparently, the HG612 does (or did) consider US FEC as a reason for causing the connection to resync (Retrain Raeson 3).
This is from the HG612's SP10 driver code (I don't have a copy of the SP08 version):-
/* line-drop reason code */
#define kRetrainReasonLosDetector 0
#define kRetrainReasonRdiDetector 1
#define kRetrainReasonNegativeMargin 2
#define kRetrainReasonTooManyUsFEC 3
#define kRetrainReasonCReverb1Misdetection 4
#define kRetrainReasonTeqDsp 5
#define kRetrainReasonAnsiTonePowerChange 6
#define kRetrainReasonIfftSizeChange 7
#define kRetrainReasonRackChange 8
#define kRetrainReasonVendorIdSync 9
#define kRetrainReasonTargetMarginSync 10
#define kRetrainReasonToneOrderingException 11
#define kRetrainReasonCommandHandler 12
#define kRetrainReasonDslStartPhysicalLayerCmd 13
#define kRetrainReasonUnknown 14
#define kRetrainReasonG992Failure 15
#define kRetrainReasonSes 16
#define kRetrainReasonCoMinMargin 17
#define kRetrainReasonANFPMaskSelect 18
I have quite recently seen evidence of fastpath connections resyncing where all DS error counts appeared to be quite low, yet US error counts were relatively high.
In some cases, quite high depths of US interleaving, INP & delay were applied & although DS remained on fastpath, with zero values for DS INP & delay, DS sync speeds were also reduced.
FWIW, tabiley2's connection recently resynced at lower speeds with Retrain Reason 6 (Retrain Reason Ansi Tone Power Change).
Do any of you know what that actually means?
-
Have been waiting to see roseways DS stats change to non-interleaved for a few weeks now but nothing has changed, roseways DLM history looks clean to me and should have been put back on non-interleave by the fifth day after the DS issue.
Sure my line was always interleaved for years with consistent medium FEC errors and low errored seconds 200 per day did the DLM relent ? fecking no way ;)
-
@les-70: You're quite right in every respect. I know FECs have been dismissed as playing any part in DLM, but it's hard to think of any other reason why my connection is still on the fairly high interleaving level.
which device are you currently using?
-
Billion 8800NL for the last 14 days.
-
Ooooh ... a whole thread on DLM that I must have missed while BT got around to sorting out my PCP record.
some interesting reading tomorrow...
-
It looks as though I was a little premature in what I said about FECs. At 02:43 today, DLM put me back on fastpath and I'm back up to near maximum downstream speed. G.INP isn't enabled. It took over three weeks but it got there in the end.
-
It is good that the DLM has repsonded :) ----eventually. I notice Aardvark is now on his 11th day with zero ES over the whole period. If he is also delayed then I suspect DLM algorithm changes have been made away from the previous 10-11th day time for a response.
-
It is good that the DLM has repsonded :) ----eventually. I notice Aardvark is now on his 11th day with zero ES over the whole period. If he is also delayed then I suspect DLM algorithm changes have been made away from the previous 10-11th day time for a response.
Based on past experience i am expecting it will be around the 14 day point when DLM will re-sync my line back up to the original level.
I caused some of the delay by re-syncing the Zyxel after 6 days to switch on everything outstanding (G.INP [PhyR DS & PhyR US] & SRA) in case they ever get used by OR in the future.
[Been reading about some people getting G.INP switched on.]
(Fingers crossed re-syncs soon :) )
-
I notice that as AArdvark expected the DLM started to change on day 15 (just upstream so far), I don't know why he thought 2 weeks but for me It has always been 10 days. Maybe it depends on the DSLAM vendor.
I still can only see one MDWS user with G.INP i.e. danbl. danbl has attainables of about 122 and 36 Mb/s and it surprises me that G.iNP is on at all on that line. If comments on Black Sheeps recent G.INP post are correct G.INP ought to be available, but maybe not in use, on about half lines in about about a months time.
-
I still can only see one MDWS user with G.INP i.e. danbl. danbl has attainables of about 122 and 36 Mb/s and it surprises me that G.iNP is on at all on that line. If comments on Black Sheeps recent G.INP post are correct G.INP ought to be available, but maybe not in use, on about half lines in about about a months time.
Indeed the only one that has it does not need it that's a good example of a paradox.
-
Unless Aardvark has some explanation the DLM seems to hate him. Aardvarks line went fully interleaved on 14th Feb then with completely no errors at all went fast path on the upstream only on the 1st March only to go back to interleaved on the 4th. During that 3 day interval his upstream errors were very low. Aardvark is now past 21 days and still fully interleaved, in the 21+ days he had 5 resyncs, MDWS never showing more than 1 per day and all reason 0 LOS. Two other resyncs were the DLM changes on the upstream. Aardvark may of course know more of any other possible events.
Previously back in September he had 14 days interleaved but otherwise has been on fast path until now. If 21 days with completely zero errors is not enough to see a change you have to wonder and fear what has happened to the DLM or its algorithms!!
-
Thanks Les-70 for looking at my stats etc.
A good precis of what has been happening to my line.
I am chasing Plusnet to get some feedback.
DLM seems to be very touchy of late and very slow to recover.
I am on a Huawei DSLAM and the recovery time appears to be 14 days (unless you bounce the line ::) ;D ;D ;D )
Some Planned BT Network Maintenance is due on my exchange tomorrow, so I expect it will bounce again.
Never know might get G.INP ........ ;D
[Flying Porcine objects detected at 6 o.clock] :o
-
I have just been disconnected and resynced, and suddenly MyDSLWebStats has emailed me to say G.INP is enabled on my line! I jumped from 1.42MB/Sec up to 1.69MB/Sec up so I am very pleased. So I guess no more DLM bullshit ever here.
-
FEC's seem to be the second check box to ES errors.
On my upload side I have slightly higher ES's but lower FEC's and thats not interleaved. But on my download side I have lower ES's than the upload, but more FEC errors, with an interleaving set to 1283.
It's been like that for 28 days.
I'm running an older firmware at the moment: A2pv6C035m.22g (with software version SP10). I intend on updating this soon. I'm just seeing how long the modem holds connection. 28 days is my record so far, previously the HH5 never got past 14 days lol.