Kitz Forum
Broadband Related => FTTC and FTTP Issues => Topic started by: William Grimsley on February 21, 2016, 10:11:12 AM
-
Hi guys,
I was monitoring my line this morning from our holiday place and it shows on MDWS that it has been down since 08:37. I've checked our landline number against the Mouselike BRAS Checker and it's saying "No BRAS info". Does this mean my line is dead? I tried to access the router using the upload IP shown on the "Options" pop up on MDWS but could not access the router.
Any ideas?
Many thanks!
William
-
Sounds like a failure in the mouselike tool (or the services they make use of).
-
Sounds like a failure in the mouselike tool (or the services they make use of).
But, then there are no uploads to MDWS? I'm also getting nothing when I do a BT speed test (yes I know I'm not at home).
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fi.imgur.com%2F8QUYOl3.png&hash=134db22dcd93460d067ccd9bbac9b5edd40c651e)
-
I was monitoring my line this morning from our holiday place and it shows on MDWS that it has been down since 08:37. I've checked our landline number against the Mouselike BRAS Checker and it's saying "No BRAS info". Does this mean my line is dead? I tried to access the router using the upload IP shown on the "Options" pop up on MDWS but could not access the router.
Any ideas?
If I recall you use BT Retail/Infinity. As such, its possible your line dropped and your IP address has changed as a result. If you use an service such as no-ip.com you could discover new dynamic IP address via ping.
If you are using a BT Home Hub you can get remotely test and/or restart it using one of BT/s mobile apps (assuming its got connectivity) but as I recall you have switched that out for another modem - or do you still use the HH as a router?
If you think it might be a voice/line fault you could try running an automated line test via https://www.bt.com/fault to see if that detects anything
Or you could just relax, enjoy your holiday and see what has happened once you got back.. :)
-
We're back home. The Billion BiPAC 8800NL had stopped working. I could not believe it! What a peice of rubbish this Billion BiPAC 8800NL is! The internet light was a constant green and only occasionally flashing and the WLAN light was off! I just powered down and powered up the Billion BiPAC 8800NL and everything is back to normal. But, I wonder why the Billion BiPAC 8800NL had stopped working?
I might have to install the BT Home Hub 5 if the Billion BiPAC 8800NL stops working again. :(
The problem is that now I've had to power down and power up the Billion BiPAC 8800NL, it means DLM will not increase the Downstream Rate as quickly as hoped. Oh for crying out loud!
Just to say, I have nothing against Billion but for this to happen so soon after purchase is a bit worrying.
-
Ouch! 31033 FEC's occured on the line within 1 minute at 18:37! :no:
-
Have you loaded the latest firmware on the Billion? 2.32e.dh4 is the very latest.
Here it is: https://dl.dropboxusercontent.com/u/85443427/ETEC8800NL_2.32e.dh4.afw (https://dl.dropboxusercontent.com/u/85443427/ETEC8800NL_2.32e.dh4.afw)
-
Don't panic.
Sometimes it just happens. It could have been DLM doing a resync and for some reason the line just didnt come back up properly. Happens to the best of routers. Could just have easily happened with the HH5. Only difference is you wouldn't have been able to monitor and wouldn't have known till you got home.
it means DLM will not increase the Downstream Rate as quickly as hoped.
Seriously. Stop. Listen.
One extra resync isnt going to bother the DLM. Also, because it was off for several hours it will be seen as an unforced retrain and not counted!
I think you may also be getting in a tizz re the FEC. I note that its not unusual for you to have burst FECs nearing 30k. DLM monitors Err/Secs. FEC just shows that interleaving is working as it should.
Please, please, please dont get too worked up over the little things. Your traffic lights are still all green so all is good.
TBH one of the reasons why some ISPs use routers that dont show all stats is because some EU's used to get worked up about things which were perfectly normal. :(
-
Have you loaded the latest firmware on the Billion? 2.32e.dh4 is the very latest.
Here it is: https://dl.dropboxusercontent.com/u/85443427/ETEC8800NL_2.32e.dh4.afw (https://dl.dropboxusercontent.com/u/85443427/ETEC8800NL_2.32e.dh4.afw)
Ah, I hadn't. Thanks very much!
-
Don't panic.
Sometimes it just happens. It could have been DLM doing a resync and for some reason the line just didnt come back up properly. Happens to the best of routers. Could just have easily happened with the HH5. Only difference is you wouldn't have been able to monitor and wouldn't have known till you got home.
it means DLM will not increase the Downstream Rate as quickly as hoped.
Seriously. Stop. Listen.
One extra resync isnt going to bother the DLM. Also, because it was off for several hours it will be seen as an unforced retrain and not counted!
I think you may also be getting in a tizz re the FEC. I note that its not unusual for you to have burst FECs nearing 30k. DLM monitors Err/Secs. FEC just shows that interleaving is working as it should.
Please, please, please dont get too worked up over the little things. Your traffic lights are still all green so all is good.
TBH one of the reasons why some ISPs use routers that dont show all stats is because some EU's used to get worked up about things which were perfectly normal. :(
Ok, I am sorry, Kitz. I do aim to not come over as in a panic, I am just interested in what is going on. If you'd like me to limit my posts regarding these types of things, I am very happy to. Thanks for confirming. Hopefully, I'll get a positive DLM resync soon.
-
You sounded as if you were panicking about the extra resync and thought it would stop DLM from improving your line, which isnt the case.
it means DLM will not increase the Downstream Rate as quickly as hoped. Oh for crying out loud!
It shouldnt make any difference - have a read of unforced retrain (http://www.kitz.co.uk/adsl/DLM.htm#unforced_retrains).
What a peice of rubbish this Billion BiPAC 8800NL is!
They are usually quite stable and although I dont have one personally , they do seem about the best for stability.
It could just be one of those things, or it could have happened on the HH5 too. All Im trying to say is try not to get too worked up about it.
No harm done and we know that atm the DLM appears to be resyncing some days.
I'm in no doubt that your action caused a DLM scarlet situation (http://www.kitz.co.uk/adsl/DLM.htm#DLM_profile_changes) and is doing additional monitoring (http://www.kitz.co.uk/adsl/DLM_system.htm#DLM_additional_monitoring) on your line.
If anything watch the traffic lights - thats why tony put them there :)
-
You sounded as if you were panicking about the extra resync and thought it would stop DLM from improving your line, which isnt the case.
it means DLM will not increase the Downstream Rate as quickly as hoped. Oh for crying out loud!
It shouldnt make any difference - have a read of unforced retrain (http://www.kitz.co.uk/adsl/DLM.htm#unforced_retrains).
What a peice of rubbish this Billion BiPAC 8800NL is!
They are usually quite stable and although I dont have one personally , they do seem about the best for stability.
It could just be one of those things, or it could have happened on the HH5 too. All Im trying to say is try not to get too worked up about it.
No harm done and we know that atm the DLM appears to be resyncing some days.
I'm in no doubt that your action caused a DLM scarlet situation (http://www.kitz.co.uk/adsl/DLM.htm#DLM_profile_changes) and is doing additional monitoring (http://www.kitz.co.uk/adsl/DLM_system.htm#DLM_additional_monitoring) on your line.
If anything watch the traffic lights - thats why tony put them there :)
I have to admit, I probably went a bit overboard by saying that the Billion BiPAC 8800NL was "rubbish", it was one of my "not thinking before I speak" moments. :lol:
Again, thanks for your in detailed post, I really appreciate it.
-
You just can't hurry DLM. It's maddening, when this has happened to me in the past, it seemed to take forever. Just drink good Devon ale instead. Yum.
-
You just can't hurry DLM. It's maddening, when this has happened to me in the past, it seemed to take forever. Just drink good Devon ale instead. Yum.
Well, you say that but I've caused this so I shouldn't be mad. Though, looking at those FEC's, I wouldn't be surprised if the line would have got into this state anyway! I'm never going to touch alcohol! It's too expensive and too damaging! :lol:
-
I must add that in the past on my ADSL line a Billion BiPAC 7800N [Its in the loft now but still works] - which was IMO the most stable router I ever had so I do have a soft spot for Billion equip.
-
I must add that in the past on my ADSL line a Billion BiPAC 7800N [Its in the loft now but still works] - which was IMO the most stable router I ever had so I do have a soft spot for Billion equip.
Yeah, I mean to say the DSL light was on, it was probably an exchange syncronisation issue so a power cycle was the only way to sort it.
-
I am not convinced that your line uncapped will hit the 40Mbps (39999kbps) target at most it will get close to 37000 kbps there is to much going against you and that is distance and available tones
Edit : if William Grimsley
has blocked me on the forums you won't see this message and it would help me a great deal not to waste my time responding to your post if you have them blocked ;)
-
I am not convinced that your line uncapped will hit the 40Mbps (39999kbps) target at most it will get close to 37000 kbps there is to much going against you and that is distance and available tones
Edit : if William Grimsley
has blocked me on the forums you won't see this message and it would help me a great deal not to waste my time responding to your post if you have them blocked ;)
Are you mad? I'm not blocking anyone. Stop being so presumptive! Jesus! Yes, I had another DLM resync last night and some factors changed but the line is still banded. The Downstream Rate will increase to 40000 Kbps because it was at that before.
-
I wouldn't bank on your banded line returning to its original speed. Banding sometimes seems to 'stick' - for me for over a year, long after the original issue had been resolved.
It was only fixed via a DLM reset from a provider change. After that long, I assume it might have *never* resolved itself automatically.
-
It does look like DLM changed some settings overnight.
On the face of it, it looks like DLM has increased intervention level, rather than decreased it ... the INP level has changed from 48 to 54, and upstream G.INP has been turned on. The INPRein value has been turned on downstream too, though the delay value hasn't increased from 0.
I suspect that DLM thinks yesterday wasn't a good day. But it is hard to tell why.
We can see resyncs at 17:00 and 19:00 from the "uptime" chart, plus the DLM-induced one around 4:15. But who knows what went on in the missing 8 hours.
As for the potential speed ... When your speed is around 40Mbps, I reckon 3dB of margin is worth around 7Mbps. Your current SNR margin is 9.6dB, so you should be able to reach 40Mbps, if/when banding gets removed. That SNR margin is a lot lower than a few days ago, suggesting that the recent change by DLM has caused more bandwidth to be used for FEC protection; unfortunately, these parameters aren't logged by MDWS, so I can't tell.
-
That SNR margin is a lot lower than a few days ago, suggesting that the recent change by DLM has caused more bandwidth to be used for FEC protection; unfortunately, these parameters aren't logged by MDWS, so I can't tell.
Would it be worthwhile requesting that MDWS is enhanced to log these parameters?
-
Would it be worthwhile requesting that MDWS is enhanced to log these parameters?
It might be and they might already be in the database - if I knew what it or they were.
But there are possibly major problems if they are not. And even if they are in there - I tried showing some of the currently missing params a couple of weeks back but then discovered that only one of the two programs is actually uploading them.. .
-
It might be and they might already be in the database - if I knew what it or they were.
But there are possibly major problems if they are not. And even if they are in there - I tried showing some of the currently missing params a couple of weeks back but then discovered that only one of the two programs is actually uploading them.. .
I think we all need to talk more :)
-
It might be and they might already be in the database - if I knew what it or they were.
But there are possibly major problems if they are not. And even if they are in there - I tried showing some of the currently missing params a couple of weeks back but then discovered that only one of the two programs is actually uploading them.. .
I think we all need to talk more :)
:hmm:
-
Interesting. The interleaver depth decreased from 16 to 8 on Downstream though, so something positive has come out of it.
May I ask what is going on here?
(https://i.gyazo.com/8a6e3875c15ebac760e50350dd924cef.png)
Have I set something up wrong with the connection?
-
It does look like DLM changed some settings overnight.
On the face of it, it looks like DLM has increased intervention level, rather than decreased it ... the INP level has changed from 48 to 54, and upstream G.INP has been turned on. The INPRein value has been turned on downstream too, though the delay value hasn't increased from 0.
I suspect that DLM thinks yesterday wasn't a good day. But it is hard to tell why.
We can see resyncs at 17:00 and 19:00 from the "uptime" chart, plus the DLM-induced one around 4:15. But who knows what went on in the missing 8 hours.
As for the potential speed ... When your speed is around 40Mbps, I reckon 3dB of margin is worth around 7Mbps. Your current SNR margin is 9.6dB, so you should be able to reach 40Mbps, if/when banding gets removed. That SNR margin is a lot lower than a few days ago, suggesting that the recent change by DLM has caused more bandwidth to be used for FEC protection; unfortunately, these parameters aren't logged by MDWS, so I can't tell.
Now, that is interesting. I may have to get a DLM reset in a few weeks if the Donwstream Rate doesn't return to 40000 Kbps...
-
It might be and they might already be in the database - if I knew what it or they were.
The FEC and interleaving parameters are the R, D, I and N parameters from "--show" and "--stats"
- R and N show the amount of FEC overhead (R bytes in a block of N bytes is the extra parity data for FEC protection; it allows R/2 bytes to be corrected). 5% is low (old-style) or standard (with G.INP), 18-20% is standard old-style, 30% is very high.
- D and I show the amount of interleaving (depth and "width", aka interleaving block size). Multiplying D and I gives the relative scale of delays/latency.
- N should be a multiple of I.
I think we all need to talk more :)
:hmm:
I'm not sure what to add here, except how I go about things...
When I analyse someone's line, I'll tend to look at data in this order:
- Attenuation, incl pbParams - How "long" is the line?
- Hlog, QLN, SNR/tone and bits/tone ... Is the line acting right for that length? What is the noise environment? Crosstalk? UPBO?
- INP, INPRein, delay - What has DLM asked for? Is it light or heavy? Getting worse or better?
- R, D, I, N - What impact has the DLM settings had on the line settings? Bandwidth overhead and latency overhead
- Sync actual and attainable - Does this match with FEC overheads?
- BQM latency - Does this match with interleaving latency overhead?
- FEC, CRC, ES - What impact should we expect on DLM, old-style? Patterns across the day; 24 hour ES total
- RS/RSCorr/RSUncorr - If lots of FEC, I look at the proportions of these
- OHF/OHFerr - If lots of CRC, I look at the proportion of these
- rtx_tx, rtx_c, rtx_uc - How much retransmission is going on? How much re-retransmission? How much failure?
- LEFTRS, minEFTR - Is retransmission affecting the overall throughput?
When I look at the data, or charts of the data over time, I guess I'm looking for patterns, or trying to assess some items for quality. I wonder if we can figure any of that into our own KBD, or centre of excellence?
-
Well, this is interesting. No wonder DLM acted negatively on the line. There's no data!
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fi.imgur.com%2FxYnhFtU.png&hash=47ea81556c4a601a594b5f2c4ce2ba2dada8c40a)
-
Interesting. The interleaver depth decreased from 16 to 8 on Downstream though, so something positive has come out of it.
True - ironically a "worse" DLM setting can result in a lower interleaving depth. However, the scale of interleaving depends on the block-size too, which probably changed. In any case, interleaving has been added upstream, so there will be added latency in that direction too. Small, certainly, but still added.
May I ask what is going on here?
The router is doing some tests. However, the tests are run "per connection", and the first one (on mine) shows "Test the connection to your local network --- pppoa_0_0_38" with similar failures. But that connection is one targeted at ADSL; look at menu item "Status" -> "WAN" to see all the connections.
If you try clicking on "Next Connection" (possibly more than once), you'll eventually get to a page that shows "Test the connection to your local network --- pppoe_0_1_1.101.101.101.101" which is the connection used for FTTC.
That one will give a slightly better result.
I hae some more information. I just did a telnet using the adsl info --stats command on the Billion BiPAC 8800NL. Interestingly, there was no data recorded from the Billion BiPAC 8800NL before I powered down and powered up the Billion BiPAC 8800NL shortly after I came home last night. So, the line was completely dead before I power cycled the Billion BiPAC 8800NL. So, that's probably why the DLM resync was negative because there wasn't a lot of data.
My 8800NL just survived 101 days, before I rebooted it myself while trying to debug a faulty TV service. Over the last year, it has worked without flaw. If this happens to you much more, you might want to suspect it as being faulty.
-
Interesting. The interleaver depth decreased from 16 to 8 on Downstream though, so something positive has come out of it.
True - ironically a "worse" DLM setting can result in a lower interleaving depth. However, the scale of interleaving depends on the block-size too, which probably changed. In any case, interleaving has been added upstream, so there will be added latency in that direction too. Small, certainly, but still added.
May I ask what is going on here?
The router is doing some tests. However, the tests are run "per connection", and the first one (on mine) shows "Test the connection to your local network --- pppoa_0_0_38" with similar failures. But that connection is one targeted at ADSL; look at menu item "Status" -> "WAN" to see all the connections.
If you try clicking on "Next Connection" (possibly more than once), you'll eventually get to a page that shows "Test the connection to your local network --- pppoe_0_1_1.101.101.101.101" which is the connection used for FTTC.
That one will give a slightly better result.
I hae some more information. I just did a telnet using the adsl info --stats command on the Billion BiPAC 8800NL. Interestingly, there was no data recorded from the Billion BiPAC 8800NL before I powered down and powered up the Billion BiPAC 8800NL shortly after I came home last night. So, the line was completely dead before I power cycled the Billion BiPAC 8800NL. So, that's probably why the DLM resync was negative because there wasn't a lot of data.
My 8800NL just survived 101 days, before I rebooted it myself while trying to debug a faulty TV service. Over the last year, it has worked without flaw. If this happens to you much more, you might want to suspect it as being faulty.
That's interesting. I'll have a look at the FTTC connection page and see if it has a better result. Obviously, if my Billion BiPAC 8800NL starts to do this more often, I will send it back and get a new one.
Does this look better?
(https://i.gyazo.com/ac26ed39363d4a070f70e5ee654c7e9f.png)
-
The FEC and interleaving parameters are the R, D, I and N parameters from "--show" and "--stats"
The only ones currently in the database are B M T R S L which are ones I was playing with (see attachment) - adding others is not an easy task and you'd have to persuade BE and roseway to do this in the first place before anything else was attempted.
Plus I'm trying to partially rebuild the house which is occupying quite a lot of time to say the least :'( not to mention trying to support this as best I can.
-
The FEC and interleaving parameters are the R, D, I and N parameters from "--show" and "--stats"
The only ones currently in the database are B M T R S L which are ones I was playing with (see attachment) - adding others is not an easy task and you'd have to persuade BE and roseway to do this in the first place before anything else was attempted.
Plus I'm trying to partially rebuild the house which is occupying quite a lot of time to say the least :'( not to mention trying to support this as best I can.
Where do I go to show these figures are that area of the page you screenshoted looks totally different to mine. Good luck with the house rebuild. Remember, your home is more important than a donationware program!
-
Where do I go to show these figures are that area of the page you screenshoted looks totally different to mine. Good luck with the house rebuild. Remember, your home is more important than a donationware program!
Earlier post:
I tried showing some of the currently missing params a couple of weeks back but then discovered that only one of the two programs is actually uploading them.. .
This is on the dev system only and it does not work with DSLstats hence it isn't live.
-
Where do I go to show these figures are that area of the page you screenshoted looks totally different to mine. Good luck with the house rebuild. Remember, your home is more important than a donationware program!
Earlier post:
I tried showing some of the currently missing params a couple of weeks back but then discovered that only one of the two programs is actually uploading them.. .
This is on the dev system only and it does not work with DSLstats hence it isn't live.
Oh right, sorry. I didn't see that. Oops.
Ok, so DLM made that negative change to my line and no ES have occured on the line since. DLM is so tight. It likes to run before it can walk...
-
Low priority over sorting the house out, but...
The FEC and interleaving parameters are the R, D, I and N parameters from "--show" and "--stats"
The only ones currently in the database are B M T R S L which are ones I was playing with (see attachment) - adding others is not an easy task and you'd have to persuade BE and roseway to do this in the first place before anything else was attempted.
This might turn out to be just academic, but I started wondering what we could do with the parameters you do have access to.
I happened to notice that, on my line at least, we can construct one of the missing values - N - from the ones above:
N = B + R + 1
But this construction only works because M=1.
I wonder how many lines have M=1, or how it varies, and whether we can calculate N in other scenarios.
Having N probably allows I to be calculated, knowing it has to be a sub-multiple of N, and (IIRC) a prime.
I think you might have D in the database in another guise, as we can already plot the interleaving depth, can't we?
-
That works for me:
Bearer 0
MSGc: -6 26
B: 130 237
M: 1 1
T: 0 42
R: 8 16
S: 0.0518 0.3781
L: 21468 5374
D: 16 1
I: 139 127
N: 139 254
Q: 16 0
V: 14 0
-
Does this look better?
(https://i.gyazo.com/ac26ed39363d4a070f70e5ee654c7e9f.png)
Yes.
I get the same failure to ping the default gateway; I don't know why this is, but I suspect it relates to the IP configuration data that the ISP sends the router during establishment of PPP.
My ping to the DNS server works - but this may depend on the same thing with PPP, or it might be the way your ISP has set up their DNS server. I deliberately changed settings in my 8800 to stop using Plusnet's DNS servers, and to use Google's instead.
Those failures probably don't matter.
-
I think you might have D in the database in another guise, as we can already plot the interleaving depth, can't we?
If D is Interleave Depth then yes, it's INT in the summary stats at the top and also currently has a graph (or two if you include Bearer 1 where available). I can add that in as D eventually, once Eric has added to the upload which he is now kindly working on :cool: It'll be on the Wide graphs only.
-
DSLstats is already uploading D as interleaving depth, so you already have that value.
As mentioned in a PM, I'm now uploading the missing values, and I'll release a new version after you confirm that the extra items are in the right places.
-
Motivation to sort out my own logging properly. Must get the Pi working .... :-[
@roseway - identical framing data to my line.
-
Guys, just talking about something a bit more related to my problem. Ooo.
Is my line looking stable enough for DLM to get rid of my banding any time soon?
-
As has been said many times, it's impossible to predict if, or when your Banding might be removed.
It could happen within days or it might take months, it might even never correct itself (until a DLM reset) as happened to me.
Patience!
-
It might be and they might already be in the database - if I knew what it or they were.
The FEC and interleaving parameters are the R, D, I and N parameters from "--show" and "--stats"
- R and N show the amount of FEC overhead (R bytes in a block of N bytes is the extra parity data for FEC protection; it allows R/2 bytes to be corrected). 5% is low (old-style) or standard (with G.INP), 18-20% is standard old-style, 30% is very high.
- D and I show the amount of interleaving (depth and "width", aka interleaving block size). Multiplying D and I gives the relative scale of delays/latency.
- N should be a multiple of I.
Although I have this information listed on the linestat errors page (http://www.kitz.co.uk/adsl/linestats_errors.htm), because of the alphabetical layout, it perhaps doesnt make it quite so clear the relationship between those particular figures.
On reflection and after seeing wombats post, it may be a good idea for me to also add this on the interleaving page, where its not lost amongst other things like LoF or LoS.
-
I happened to notice that, on my line at least, we can construct one of the missing values - N - from the ones above:
N = B + R + 1
But this construction only works because M=1.
I wonder how many lines have M=1, or how it varies, and whether we can calculate N in other scenarios.
Having N probably allows I to be calculated, knowing it has to be a sub-multiple of N, and (IIRC) a prime.
I think you might have D in the database in another guise, as we can already plot the interleaving depth, can't we?
I wonder if M is actually a multiplier
Using these stats
MSGc: 154 -6
B: 0 0
M: 2 0
T: 2 0
R: 16 0
S: 6.4000 0.0000
L: 40 0
D: 3 0
I: 32 0
N: 32 0
Q: 0 0
V: 0 0
N = M * (B + R)
Stop
hang on no.. blonde moment.... that doesnt fit where m=1
-
@kitz
Those numbers started to do my head in! I couldn't work out how they could manage B=0 ... because that would imply that the entire frame was overhead.
If I try to read them logically, it seems to be saying
B=0 -> zero bytes in MUX data frame
M=2 -> two MUX data frames in RS codeword
R=16 -> sixteen bytes of parity overhead in RS codeword
N=32 -> thirty two bytes in an RS codeword
Would this be
a) N = R + (M*B)
or
b) N = M * (R+B)
Using the English language, I'd assume (a) was more correct. But (b) appears to pan out in real use. I guess these framing parameters are from Bearer 1. Perhaps the rules are slightly different there.
But back in bearer 0, with N=B+R+1, I couldn't honestly figure out why the "+1" should be there.
More thinking needed. I suspect I'll feel the need to dig out the spec again. I recall from last time that G.INP tied the base VDSL2 spec down to using more limited framing options.
Although I have this information listed on the linestat errors page (http://www.kitz.co.uk/adsl/linestats_errors.htm), because of the alphabetical layout, it perhaps doesnt make it quite so clear the relationship between those particular figures.
On reflection and after seeing wombats post, it may be a good idea for me to also add this on the interleaving page, where its not lost amongst other things like LoF or LoS.
I can see that it would be useful to see that relationship, at least for those wanting to dive into the depths.
-
As has been said many times, it's impossible to predict if, or when your Banding might be removed.
It could happen within days or it might take months, it might even never correct itself (until a DLM reset) as happened to me.
Patience!
Fine. But, I will have to ring BT soon to get a DLM reset if the profile is still stuck.
-
You cannot just call BT and ask for a DLM reset. It has to be requested by an Openreach engineer after they fix a suspected fault.
-
You cannot just call BT and ask for a DLM reset. It has to be requested by an Openreach engineer after they fix a suspected fault.
Great, so that means I'm stuck then?
-
Not at all. Banding is still one of the mysteries of Dlm and Banding getting stuck is pretty rare.
As with all things Dlm related, best thing you can do is sit and wait - it will probably work out ok on its own. The odd reboot of your router or occasional disconnection will also make no difference, either positively or negatively!
Be patient!
-
Not at all. Banding is still one of the mysteries of Dlm and Banding getting stuck is pretty rare.
As with all things Dlm related, best thing you can do is sit and wait - it will probably work out ok on its own. The odd reboot of your router or occasional disconnection will also make no difference, either positively or negatively!
Be patient!
Yes, I understand. I am trying to be patient, it's just frustrating how tight DLM is. Oh well, I've learnt my lesson! :lol:
-
@kitz
Those numbers started to do my head in! I couldn't work out how they could manage B=0 ... because that would imply that the entire frame was overhead.
If I try to read them logically, it seems to be saying
B=0 -> zero bytes in MUX data frame
M=2 -> two MUX data frames in RS codeword
R=16 -> sixteen bytes of parity overhead in RS codeword
N=32 -> thirty two bytes in an RS codeword
Would this be
a) N = R + (M*B)
or
b) N = M * (R+B)
Using the English language, I'd assume (a) was more correct. But (b) appears to pan out in real use. I guess these framing parameters are from Bearer 1. Perhaps the rules are slightly different there.
But back in bearer 0, with N=B+R+1, I couldn't honestly figure out why the "+1" should be there.
More thinking needed. I suspect I'll feel the need to dig out the spec again. I recall from last time that G.INP tied the base VDSL2 spec down to using more limited framing options.
Although I have this information listed on the linestat errors page (http://www.kitz.co.uk/adsl/linestats_errors.htm), because of the alphabetical layout, it perhaps doesnt make it quite so clear the relationship between those particular figures.
On reflection and after seeing wombats post, it may be a good idea for me to also add this on the interleaving page, where its not lost amongst other things like LoF or LoS.
I can see that it would be useful to see that relationship, at least for those wanting to dive into the depths.
@ wombat - Yes those other stats were g.inp bearer 1.
I attempted to do a little bit of digging last night, at first I was wading through some very heavy documentation that had lots of horrible equations that didn't quite seem relevant to the info we wanted. TBH some of them made my head hurt & my eyes blur, so I packed in.
I started to do a break down summary of what we knew and then I stumbled across a much more reader friendly power point presentation by Tim Clark of the VDSL consortium. A copy can be downloaded here (https://www.iol.unh.edu/sites/default/files/knowledgebase/dsl/VDSL_MCM_Simulation.ppt). Ive not finished digesting all the info in that ppt yet but thought I'd post how far Ive got with my summary.
Reed Solomon Parameters
MSGc = Number of bytes in overhead channel message
K = Number of bytes in the DMT Frame
B = Number of bytes in the data frame
N = NFEC = Length of codeword (N = K + R)
R = RFEC = RS check bytes / Amount of redundancy
S = Symbols per codeword
T = Number of dataframes in an OH subframe/ Data frames over sync bytes
Q = Number of RS codewords per DTU (g.inp)
V = Number of padding octets per DTU (g.inp)
Interleaving Parameters
I = Number of Interleaver branches / The interleaver block size in bytes. Should be a sub-multiple of N
M = Incremental delay / Number of Mux Data Frames in FEC Data Frame/RScodeword
D = Interleave Depth (D = M * I + 1)
L = LSYMB = Number of bits per symbol in the latency path / Number of bits in PMD data frame
Interleaving introduces a delay of M * I * (I-1)
Actual delay - ADSL shown in ms = [S x D]/4
Actual delay - If retransmission is used this specifies the actual value of the time independent component of the delay due to retransmission only.
Statements & snippets
T-REC G.998.4 Section 9.2 FEC
The interleaving used on Latency path #1 shall be a block interleaving. The interleaving block shall have a size of D1 × NFEC bytes, with NFEC being the length of the RS codeword, and D1 being the interleaving depth. If D1=1, then an interleaving block equals an RS codeword. If D1=Q (the number of RS codewords per DTU) then an interleaving block equals a DTU. Each byte Bk within an interleaving block (input at position k, with index k in the interval 0 to D1 × NFEC – 1) shall be located at the output of the interleaving function at position l given by l = i × D1 + j, where i = k MOD NFEC and j = floor(k / NFEC).
VDSL MCM Simulation
Note the relevant equations:-
N = K + R
D = M * I + 1
delay = M * I * (I-1)
We dont have a K value, but it does at face value appear it could to be related to B?
-
There's a Starship out there somewhere, missing some of its crew ........... #wellovermyhead ........ :) :)
-
There's a Starship out there somewhere, missing some of its crew ........... #wellovermyhead ........ :) :)
Not only that but William is obviously regretting forcing the DLM to take some action with his circuit! If he had left it alone, this thread would not have been started and so the Wizards would not have come out to play . . . :D
-
Ha ha ........... as we all know, there will only be one winner where DLM is concerned. ;) ;D
-
Not only that but William is obviously regretting forcing the DLM to take some action with his circuit! If he had left it alone, this thread would not have been started and so the Wizards would not have come out to play . . . :D
I would like to correct you there. This thread would have started whatever because MDWS wasn't uploading. This thread originally started discussing something unrelated to DLM. ;)
-
b*cat is duly corrected! :paperbag:
-
Thanks for the document, kitz.
It certainly looks interesting after a quick perusal. I'll start studying it more closely - the way it describes interleaving is a little different from what I expect, but its a 2D process, so is easy to have multiple views.
I did pick up one thing, which finally explains why we don't always see a round number of bits, such as 79997...
Bits are adjusted such that total number of bits fits an integer number of Reed-Solomon codewords
-
@kitz again...
I'd noticed that "M" seems to have a dual definition for interleaving, so started looking at that - starting with checking the definition on the GUI of my Billion ("# of Mux Data Frames in an RS codeword")
From that, I noticed something about T ("# of Mux Data Frames in an OH sub-frame") that T=0 in bearer 0, and T=2 in bearer 1. That made me realise ... No OH frames! That my bearer 0 appears to have no CRC checks going on. Lo and behold, bearer 0 shows zero OHF and zero OHFerror counts too. With G.INP in place, I guess the CRC checks are within the DTU rather than in an OH frame structure. I don't think I'd noticed this before.
That in turn brought me back to the formulae we were playing with yesterday; we had made no allowance for OH frames and the CRC that would be part of that. There is going to be a little more we need to consider there.
-
b*cat is duly corrected! :paperbag:
Wahey! :lol:
-
The extra stats are now available coinciding with the release of a new DSLstats version so if you are using DSLstats and want to see them you'll need to upgrade otherwise they mostly show zero! More on the post below.:
http://forum.kitz.co.uk/index.php/topic,17106.msg314386.html#msg314386 (http://forum.kitz.co.uk/index.php/topic,17106.msg314386.html#msg314386)
This is a first stab at them but I suspect there will need to be some changes...
-
The extra stats are now available coinciding with the release of a new DSLstats version so if you are using DSLstats and want to see them you'll need to upgrade otherwise they mostly show zero! More on the post below.:
http://forum.kitz.co.uk/index.php/topic,17106.msg314386.html#msg314386 (http://forum.kitz.co.uk/index.php/topic,17106.msg314386.html#msg314386)
This is a first stab at them but I suspect there will need to be some changes...
Just upgraded. Good job! How are my additional stats looking? :lol:
-
On the line, 100889 Downstream FEC's occured within a minute at 06:42. On the line, the Downstream interleaver depth is 8. Should I be concerened?
-
No, I don't think you should be concerned. Consider those 100,889 FECs DS to be "CRCs that never occurred", as the error detection and correction is working well.
DS Interleave depth of 8 confirms that the circuit is currently operating with a moderate degree of interleaving. Again, nothing to cause any concern.
Clearly the DLM considers that a moderate degree of interleaving is the most appropriate means of stabilising your circuit.
-
No, I don't think you should be concerned. Consider those 100,889 FECs DS to be "CRCs that never occurred", as the error detection and correction is working well.
DS Interleave depth of 8 confirms that the circuit is currently operating with a moderate degree of interleaving. Again, nothing to cause any concern.
Clearly the DLM considers that a moderate degree of interleaving is the most appropriate means of stabilising your circuit.
That's what I thought. So, would that mean if the Downstream interleaver depth was OFF then those 100889 FEC's would have been CRC's? So, the line would have dropped out?
-
If 100,889 CRCs had been recorded then I would definitely be looking for their source.
I would not like to predict how the circuit would have responded if those FECs had been CRCs!
You might be interested to take a look at a forum thread (http://forum.kitz.co.uk/index.php/topic,15781.msg293692.html#msg293692) that I started back in July 2015.
-
I thought the interleaving depth of 8 was just a typical value that goes with G.INP being enabled - the retransmission ability of G.INP provides far greater error correction ability than the interleaving depth of 8 does (which is a low value, especially for VDSL2).
-
Just had what I think was a DLM resync, but nothing on my line has changed except I got 1159 CRC errors. The line is clear. But, the last retrain was an RDI, what is that?
Line stats after resync:
Mode VDSL2
Traffic Type PTM
Status Up
Link Power State L0
Downstream Upstream
Line Coding (Trellis) On On
SNR Margin (dB) 9.0 6.4
Attenuation (dB) 25.7 0.0
Output Power (dBm) 12.0 5.5
Attainable Rate (Kbps) 42484 8935
Rate (Kbps) 35000 8495
B (# of bytes in Mux Data Frame) 73 97
M (# of Mux Data Frames in an RS codeword) 1 1
T (# of Mux Data Frames in an OH sub-frame) 0 0
R (# of redundancy bytes in the RS codeword) 6 8
S (# of data symbols over which the RS code word spans) 0.0666 0.3658
L (# of bits transmitted in each data symbol) 9610 2318
D (interleaver depth) 8 8
I (interleaver block size in bytes) 80 106
N (RS codeword size) 80 106
Delay (msec) 0 0
INP (DMT symbol) 54.00 43.00
OH Frames 0 0
OH Frame Errors 1159 0
RS Words 370220584 3239991
RS Correctable Errors 77897 137
RS Uncorrectable Errors 0 0
HEC Errors 0 0
OCD Errors 0 0
LCD Errors 0 0
Total Cells 416565096 0
Data Cells 2584488 0
Bit Errors 0 0
Total ES 44 0
Total SES 42 0
Total UAS 77 56
-
RDI = Rmote Defect Indication. :)
-
Ooo, I've had another drop out. G.INP and interleaving removed from upstream as well as a bit of G.INP from downstream, but my downstream is still banded! :(
Line stats after resync:
Mode VDSL2
Traffic Type PTM
Status Up
Link Power State L0
Downstream Upstream
Line Coding (Trellis) On On
SNR Margin (dB) 9.9 6.3
Attenuation (dB) 25.6 0.0
Output Power (dBm) 11.9 5.1
Attainable Rate (Kbps) 44538 8051
Rate (Kbps) 35000 8051
B (# of bytes in Mux Data Frame) 73 239
M (# of Mux Data Frames in an RS codeword) 1 1
T (# of Mux Data Frames in an OH sub-frame) 0 43
R (# of redundancy bytes in the RS codeword) 6 0
S (# of data symbols over which the RS code word spans) 0.0666 0.9472
L (# of bits transmitted in each data symbol) 9610 2027
D (interleaver depth) 8 1
I (interleaver block size in bytes) 80 120
N (RS codeword size) 80 240
Delay (msec) 0 0
INP (DMT symbol) 52.00 0.00
OH Frames 0 0
OH Frame Errors 1730 0
RS Words 229263944 3298142
RS Correctable Errors 320 0
RS Uncorrectable Errors 0 0
HEC Errors 0 0
OCD Errors 0 0
LCD Errors 0 0
Total Cells 257988759 0
Data Cells 1897917 0
Bit Errors 0 0
Total ES 55 0
Total SES 53 0
Total UAS 116 84
-
Ok, so it's been 6 weeks yes 6 WEEKS since I started doing the disconnects and my line has still not returned back to normal. This seems a little long to me. #Frustrated
-
My line just had 1 Upstream SES. Here comes another line fault...
-
Ok, so it's been 6 weeks yes 6 WEEKS since I started doing the disconnects and my line has still not returned back to normal. This seems a little long to me. #Frustrated
The only alternative is to find away to get an Openreach broadband engineer to visit your premises under the suspicion there is a broadband fault, and they will do the normal tests and that should include a line reset/DLM and this should fix your banding issue.
of course there is a 50/50 chance you will be charged so flip a coin and I bet you don't get charged this time :)
-
The only alternative is to find away to get an Openreach broadband engineer to visit your premises under the suspicion there is a broadband fault, and they will do the normal tests and that should include a line reset/DLM and this should fix your banding issue.
of course there is a 50/50 chance you will be charged so flip a coin and I bet you don't get charged this time :)
Oh, I wish! I have damaged some of my wires in the box which is Openreach property. I do have a friend who is an Openreach engineer. Maybe I should contact him? ;)
Is it possible that my line banding won't be removed?
-
Is it possible that my line banding won't be removed?
Well the DLM stuck me on the interleaving profile for most of my Infinity 1 life until and Openreach engineer did a DLM reset but thank god for G.INP as I was getting 2000 ES per day on fastpath.
So yes the DLM can become stuck even if the line has seen no issues for 3 -12 months
-
Hmmm, I might have to think about it then.
My new MDWS ID is WilliamG.
-
Is it possible that my line banding won't be removed?
It should do eventually... but by all accounts it would appear that you invoked ILQ of Scarlet which does appear to take longer to get rid of. We more or less know what causes DLM to take action, but what we are unsure of is the recovery process.
It certainly seems to use some sort of doubler method for ILQ red - Ive been ILQ red myself a couple of times after line faults and once when beta testing a new router... on all occasions it recovered by itself over the course of a week or so.
You really went in for the kill though by doing rapid and many disconnects - which is what triggers scarlet. Not only did you do it for one day, you did it for two in a row, so DLM will sense something really serious. :(
Ive seen a few cases in the past whereby people swapping routers has invoked DLM after about only half a dozen disconnects. adslmax is one of them, and iirc it took a couple of days for DLM to adjust back to normal and the MTBR has also been increased since then.
I dont think anyone has had the nerve before to go for the full 20 because we fully suspected that it could take a while for DLM to step back down. You were warned.
Whilst we are fully aware of what can trigger DLM, the missing piece of the jigsaw is recovery.... particularly in the event of MTBR & ILQ Scarlet.
-
Is it possible that my line banding won't be removed?
It should do eventually... but by all accounts it would appear that you invoked ILQ of Scarlet which does appear to take longer to get rid of. We more or less know what causes DLM to take action, but what we are unsure of is the recovery process.
It certainly seems to use some sort of doubler method for ILQ red - Ive been ILQ red myself a couple of times after line faults and once when beta testing a new router... on all occasions it recovered by itself over the course of a week or so.
You really went in for the kill though by doing rapid and many disconnects - which is what triggers scarlet. Not only did you do it for one day, you did it for two in a row, so DLM will sense something really serious. :(
Ive seen a few cases in the past whereby people swapping routers has invoked DLM after about only half a dozen disconnects. adslmax is one of them, and iirc it took a couple of days for DLM to adjust back to normal and the MTBR has also been increased since then.
I dont think anyone has had the nerve before to go for the full 20 because we fully suspected that it could take a while for DLM to step back down. You were warned.
Whilst we are fully aware of what can trigger DLM, the missing piece of the jigsaw is recovery.... particularly in the event of MTBR & ILQ Scarlet.
Thanks, that's really interesting.
I'm sorry for having to make you give up your time to write posts about something that I've caused, I feel bad. :/
-
William could I ask a question here was your sync rate banded before your started the forced manual disconnects ?
-
William could I ask a question here was your sync rate banded before your started the forced manual disconnects ?
No, it wasn't banded.
-
William could I ask a question here was your sync rate banded before your started the forced manual disconnects ?
No, it wasn't banded.
Ok I see well it's up to you now wait until your sync changes and if your like me days can seem like months & months are like years when your waiting for DLM to do something.
Oh the DLM does not hang about to intervene when the users actions or hardware is at fault it has been said here in the past the DLM is just way to sensitive when things go skew whiff over 24 hours.
-
One point I will make - DSL Stats are great, but to be honest when I had issues with my line, watching the stats all of the time was consistently getting to me.
Therefore, by just ignoring them and carrying on with things was better - the line eventually fixed itself. I don't know the full background into this thread, but it does seem like constantly watching and monitoring the line wont help it get fixed any quicker :)
-
. . . the last retrain was an RDI, what is that?
As mentioned, above (http://forum.kitz.co.uk/index.php/topic,17054.msg315745.html#msg315745), an RDI is a Remote Defect Indication.
I have found the relevant section of ITC-T Recommendation G.992.3 for you --
Section 8.12.1 xDSL line related primitives
. . .
Severely errored frame (SEF) defect: An SEF defect occurs when the content of two
consecutively received xDSL synchronization symbols does not correlate with the expected content
over a subset of the subcarriers. An SEF defect terminates when the content of two consecutively
received xDSL synchronization symbols correlates with the expected content over the same subset
of the subcarriers. The correlation method, the selected subset of subcarriers, and the threshold for
declaring these defect conditions are implementation discretionary.
. . .
Remote Defect Indication (RDI): An RDI defect is an SEF defect detected at the far-end and is
reported by the RDI indicator bit once per 15 to 20 ms (see Tables 7-8 and 7-15). The RDI indicator
bit shall be coded 1 to indicate that no SEF defect has occurred and shall be coded 0 to indicate that
an SEF defect has occurred since the last previous RDI indicator bit transmission. An RDI defect
occurs when a received RDI indicator bit is set to 0. An RDI defect terminates when a received
RDI indicator bit is set to 1.
. . .
A PDF copy of ITU-T Rec. G.992.3, which is entitled “Digital Line Systems – Access Networks (ADSL2)”, may be downloaded from this location (http://www.analytic.ru/articles/lib26.pdf).
(Although it was written for ADSL2, the basic principals are valid for VDSL2. One just needs to replace all mention of NSC=256 with NSC=4096. (NSC is the Number of Sub-Carriers.))
-
. . . the last retrain was an RDI, what is that?
As mentioned, above (http://forum.kitz.co.uk/index.php/topic,17054.msg315745.html#msg315745), an RDI is a Remote Defect Indication.
I have found the relevant section of ITC-T Recommendation G.992.3 for you --
Section 8.12.1 xDSL line related primitives
. . .
Severely errored frame (SEF) defect: An SEF defect occurs when the content of two
consecutively received xDSL synchronization symbols does not correlate with the expected content
over a subset of the subcarriers. An SEF defect terminates when the content of two consecutively
received xDSL synchronization symbols correlates with the expected content over the same subset
of the subcarriers. The correlation method, the selected subset of subcarriers, and the threshold for
declaring these defect conditions are implementation discretionary.
. . .
Remote Defect Indication (RDI): An RDI defect is an SEF defect detected at the far-end and is
reported by the RDI indicator bit once per 15 to 20 ms (see Tables 7-8 and 7-15). The RDI indicator
bit shall be coded 1 to indicate that no SEF defect has occurred and shall be coded 0 to indicate that
an SEF defect has occurred since the last previous RDI indicator bit transmission. An RDI defect
occurs when a received RDI indicator bit is set to 0. An RDI defect terminates when a received
RDI indicator bit is set to 1.
. . .
A PDF copy of ITU-T Rec. G.992.3, which is entitled “Digital Line Systems – Access Networks (ADSL2)”, may be downloaded from this location (http://www.analytic.ru/articles/lib26.pdf).
(Although it was written for ADSL2, the basic principals are valid for VDSL2. One just needs to replace all mention of NSC=256 with NSC=4096. (NSC is the Number of Sub-Carriers.))
burakkucat,
Thanks for the information. I really appreciate it. But, where does it say this is something to do with DLM or not? I am still confused as to if this was a DLM action or a LOS?
-
The DLM process is just a software entity whose sole purpose it to try to maintain a circuit in a stable and operative state.
G.992.3 makes no reference to the DLM process, for the latter is a higher level protocol which operates "on top" of the lower level procedures to which G.992.3 will apply.
From the above document it can be seen that a RDI is just a report of a SEF at the "far end" from that at which the observation has been made.
-
The DLM process is just a software entity whose sole purpose it to try to maintain a circuit in a stable and operative state.
G.992.3 makes no reference to the DLM process, for the latter is a higher level protocol which operates "on top" of the lower level procedures to which G.992.3 will apply.
From the above document it can be seen that a RDI is just a report of a SEF at the "far end" from that at which the observation has been made.
Ah right, so basically my line just dropped out twice on two consecutive days... Odd.
-
Ah right, so basically my line just dropped out twice on two consecutive days... Odd.
How healthy was your DS & US SNRm dB when the line dropped out ?
-
How healthy was your DS & US SNRm dB when the line dropped out ?
Healthy. I think Downstream SNR Margin was 9 dB and Upstream SNR Margin was 6 dB.
-
I've been banded at 43999 for over a year and DLM seems to have no intention of lifting it even though my SNR varies between 8 and 9
-
I've been banded at 43999 for over a year and DLM seems to have no intention of lifting it even though my SNR varies between 8 and 9
Was this a fault? If so, did you get an engineer visit and get him to reset DLM?
-
Just had 4 more Upstream SES on my line.
-
If you weren't checking the counts, would you have noticed anything?
-
Yeah, I noticed audio problems with Skype.
-
Skype is of course just the kind of application that you could very well expect to be sensitive to dropped packets.
-
Skype is of course just the kind of application that you could very well expect to be sensitive to dropped packets.
Exactly. Dropped packets = underlying fault.
-
I don't think 4 SES is grounds for reporting a fault and getting an engineer out, they could have been caused by almost anything, like a bit of electrical arcing as something is switched on but before the switch is fully closed.
-
I don't think 4 SES is grounds for reporting a fault and getting an engineer out, they could have been caused by almost anything, like a bit of electrical arcing as something is switched on but before the switch is fully closed.
Ooo, that sounds interesting. What's "electrical arcing"? Is this someone trying to bend the line? :lol:
-
It means sparks. It's more likely to happen when you switch something off - as the connection breaks, the electricity tries to keep on flowing, and arcs over the tiny gap. The slower the switch contacts move apart, the longer the period of arcing is. Arcing causes high levels of wide band radio interference.
-
It means sparks. It's more likely to happen when you switch something off - as the connection breaks, the electricity tries to keep on flowing, and arcs over the tiny gap. The slower the switch contacts move apart, the longer the period of arcing is. Arcing causes high levels of wide band radio interference.
Or transatlantic wireless transmission as Mr Marconi called it. :)
-
He did indeed :)
-
Ah, so it could be something switching off in the house that's starting to fail for example?
-
Ah, so it could be something switching off in the house that's starting to fail for example?
Like a lamp switch for example had this issue last year every time it was switched on in the living room at dusk with spikes of ES showing in dslstats at the same time.
then listened to the contact switch on the lamp when going into the on position which generated audible electric crackles/arching. replaced the switch and no more errored seconds from lamp ;D
-
I noticed the same with the switch from the exhaust hood in the kitchen. It could generate several hundreds or thousands of crc errors. Now with g.inp they are all corrected on the fly.
-
Ah, so it could be something switching off in the house that's starting to fail for example?
Like a lamp switch for example had this issue last year every time it was switched on in the living room at dusk with spikes of ES showing in dslstats at the same time.
then listened to the contact switch on the lamp when going into the on position which generated audible electric crackles/arching. replaced the switch and no more errored seconds from lamp ;D
I noticed the same with the switch from the exhaust hood in the kitchen. It could generate several hundreds or thousands of crc errors. Now with g.inp they are all corrected on the fly.
Ouch!
-
Why, oh why, oh why has my line just got in a mess again! There were no Downstream ES on the line! The only thing that has improved is my IP profile!
xDSL
Mode VDSL2
Traffic Type PTM
Status Up
Link Power State L0
Downstream Upstream
Line Coding (Trellis) On On
SNR Margin (dB) 10.9 6.3
Attenuation (dB) 25.6 0.0
Output Power (dBm) 12.0 5.4
Attainable Rate (Kbps) 45239 8043
Rate (Kbps) 34999 8043
B (# of bytes in Mux Data Frame) 166 239
M (# of Mux Data Frames in an RS codeword) 1 1
T (# of Mux Data Frames in an OH sub-frame) 0 42
R (# of redundancy bytes in the RS codeword) 8 0
S (# of data symbols over which the RS code word spans) 0.1517 0.9481
L (# of bits transmitted in each data symbol) 9229 2025
D (interleaver depth) 16 1
I (interleaver block size in bytes) 175 120
N (RS codeword size) 175 240
Delay (msec) 0 0
INP (DMT symbol) 48.00 0.00
OH Frames 0 0
OH Frame Errors 584 1216
RS Words 7380720 1193698
RS Correctable Errors 19 0
RS Uncorrectable Errors 0 0
HEC Errors 0 0
OCD Errors 0 0
LCD Errors 0 0
Total Cells 18980249 0
Data Cells 980574 0
Bit Errors 0 0
Total ES 11 882
Total SES 11 8
Total UAS 67 56
-
I've got two options. I either just live with my banded line (as that is what DLM wants to do) or I get an engineer visit.
-
What would an engineer visit do? I thought that if they don't make any changes to the BT network, they won't reset the DLM. So you'd possibly pay £129.99 for nothing (no fault found).
Isn't your other option to upgrade to an 80/20 service, even if you could at best only get slightly over 40Mb?
Your 35/8 speeds are still better than what many people can get on FTTC.
-
We know an engineer personally, so he would not charge us for anything even if there was no fault found.
Why would we upgrade to an 80/20 service? Isn't that a bit stupid? We wouldn't get any faster than what we get now... ::)
All I am saying, is that there's a problem somewhere.
-
Hi
The only problem that exists is you, wanting to test the dlam against all advice not too
I thought you said previously it was not an issue been on 35 ds
You keep changing your mind as become repetitive, asking the same question
Many thanks
John
-
Why would we upgrade to an 80/20 service? Isn't that a bit stupid? We wouldn't get any faster than what we get now... ::)
I thought that before, you are getting the full 40Mb, with the max attainable slightly higher, so you might get 42Mb on a 80/20 service, if you could find an ISP that would let you have it considering your estimated speeds. And I thought switching products resets the DLM.
Well, I suppose it's OK for you if you know an engineer personally, they can just use their laptop or an app on their iPhone/iPad or whatever to do the DLM reset. Tough luck for anyone else who doesn't know an engineer personally. I'm not sure the engineer would be strictly supposed to do that if they weren't visiting in an official capacity organised by your ISP, and of course, if it were an official visit organised by your ISP, you couldn't guarantee which engineer you'd get.
-
Why would we upgrade to an 80/20 service? Isn't that a bit stupid? We wouldn't get any faster than what we get now... ::)
I thought that before, you are getting the full 40Mb, with the max attainable slightly higher, so you might get 42Mb on a 80/20 service, if you could find an ISP that would let you have it considering your estimated speeds. And I thought switching products resets the DLM.
Well, I suppose it's OK for you if you know an engineer personally, they can just use their laptop or an app on their iPhone/iPad or whatever to do the DLM reset. Tough luck for anyone else who doesn't know an engineer personally. I'm not sure the engineer would be strictly supposed to do that if they weren't visiting in an official capacity organised by your ISP, and of course, if it were an official visit organised by your ISP, you couldn't guarantee which engineer you'd get.
That's a very good point. I don't really want to switch ISP. If the line does not recover to it's original state, then I will consider contacting him. Thanks.
-
if you know an engineer personally, they can just use their laptop or an app on their iPhone/iPad or whatever to do the DLM reset. Tough luck for anyone else who doesn't know an engineer personally. I'm not sure the engineer would be strictly supposed to do that if they weren't visiting in an official capacity organised by your ISP, and of course, if it were an official visit organised by your ISP, you couldn't guarantee which engineer you'd get.
ejs is correct.
1) There isn't any way of allocating or requesting a particular engineer to a job. If a new fault is reported then it just goes into a pool that automatically allocates. On required visits for same fault you are most likely to be allocated a different engineer. However I think there is something in place that an engineer who has previously visited for same fault can pick up again if they want. I know with my HR fault, I had about half a dozen different engineers, but the one who finally fixed it gave me a number to ring if there was any more problems over the next few days so he could pick up any requested revisit.
2) A reset can only be performed by a visiting engineer if he has found and corrected the fault. Openreach has a very strict stance on the reset procedure - all DLM resets are logged against the engineer who performed it and routinely checked for abuse. I'm sure that last year BS said last year or so that a new procedure had been put in place which specifically checked for abuse of DLM resets and that any found could result in disciplinary action for the OR engineer. :(
3) ejs was actually trying to help when he made the 80/20 suggestion - because that is the only way that we know of whereby a DLM reset could automatically be re-triggered.
A change of product ie 40/10 to 80/20 will cause a reset. Change of ISP doesn't.
-
A change of product ie 40/10 to 80/20 will cause a reset. Change of ISP doesn't.
Funny you should say that, because when I migrated I not only had a reset, I was moved to a different port - and that was 80/20 -> 80/20.
-
if you know an engineer personally, they can just use their laptop or an app on their iPhone/iPad or whatever to do the DLM reset. Tough luck for anyone else who doesn't know an engineer personally. I'm not sure the engineer would be strictly supposed to do that if they weren't visiting in an official capacity organised by your ISP, and of course, if it were an official visit organised by your ISP, you couldn't guarantee which engineer you'd get.
3) ejs was actually trying to help when he made the 80/20 suggestion - because that is the only way that we know of whereby a DLM reset could automatically be re-triggered.
A change of product ie 40/10 to 80/20 will cause a reset. Change of ISP doesn't.
I am sorry! But, I'm not going to get out a new contract and pay double the money for a DLM reset!
-
All I am saying, is that there's a problem somewhere.
The problem isnt with your line and I cant see any faults. Your errors are well within the acceptable range.
However the problem is Openreaches tough stance on DLM resets. IMHO it is a major problem that ISPs cant simply request a DLM reset themselves.
I have no idea why Openreach cant do something about this and why they cant put something in place so that NGA DLM resets can be requested in the same way that they can for 21CN.
I've been sat here for several minutes trying to think of any reason why they cant put something in place and the only thing I can think of is that it may be something to do with equivalence. With 20/21CN - DLM is owned by BTwholesale and the ISP makes any requests via BTwholesale because everything is wholesale side. The LLU providers obviously dont have anything to do with BTw.
DLM is one of those areas where things get a bit blurry between Openreach, BTw and another area of BT and who owns what. Ofcom regulation ensures that if they cant do something for the LLU ISPs then they aren't allowed to do so for the others. Im sure though that there must be some way of overcoming this for all.
-
Funny you should say that, because when I migrated I not only had a reset, I was moved to a different port - and that was 80/20 -> 80/20.
Out of interest would that migration be between BTw based ISP and an LLU ISP? Changing between BTw based ISPs certainly doesnt appear to trigger a reset.
-
if you know an engineer personally, they can just use their laptop or an app on their iPhone/iPad or whatever to do the DLM reset. Tough luck for anyone else who doesn't know an engineer personally. I'm not sure the engineer would be strictly supposed to do that if they weren't visiting in an official capacity organised by your ISP, and of course, if it were an official visit organised by your ISP, you couldn't guarantee which engineer you'd get.
ejs is correct.
1) There isn't any way of allocating or requesting a particular engineer to a job. If a new fault is reported then it just goes into a pool that automatically allocates. On required visits for same fault you are most likely to be allocated a different engineer. However I think there is something in place that an engineer who has previously visited for same fault can pick up again if they want. I know with my HR fault, I had about half a dozen different engineers, but the one who finally fixed it gave me a number to ring if there was any more problems over the next few days so he could pick up any requested revisit.
2) A reset can only be performed by a visiting engineer if he has found and corrected the fault. Openreach has a very strict stance on the reset procedure - all DLM resets are logged against the engineer who performed it and routinely checked for abuse. I'm sure that last year BS said last year or so that a new procedure had been put in place which specifically checked for abuse of DLM resets and that any found could result in disciplinary action for the OR engineer. :(
3) ejs was actually trying to help when he made the 80/20 suggestion - because that is the only way that we know of whereby a DLM reset could automatically be re-triggered.
A change of product ie 40/10 to 80/20 will cause a reset. Change of ISP doesn't.
There is actually a process called 'Named engineer' in place whereby the EU can pay more (I think it's £50) to get a particular engineer out.
Regarding DLM resets. Kitz is bob-on (along with other members inputs) in that we are strictly told not to perform a reset unless a fault is found and rectified. Now this is a grey area for me, as I only yesterday picked up a fault that had seen the EU go from a constant 40Meg down to 1.8Meg. It happened on just one day. After quizzing the EU, he mentioned that the very same day the electric board had been changing out a sub-station opposite his house.
Now all the expected tests passed, the installation was up to par ...... there was nothing to fault if you will. But experience obviously tells you that this was a one-off event and as such I did do a reset and he was back at 40Meg and completely CRC/FEC free on a 15min test.
Point I'm trying to make is we can do a reset whenever we choose, but to just do so nilly-willy may attract the attention of 'Them above'. Quite how well the reset system is monitored, I wouldn't know but in today's BT, there will be somebody sat there collating stats !!!!
-
I've been banded for over a year despite mydslwebstats being consistently green and my SNR being between 8 and 9. I'm afraid you may just have to live with it.
-
However the problem is Openreaches tough stance on DLM resets. IMHO it is a major problem that ISPs cant simply request a DLM reset themselves.
Do you know how long ISPs have had this capability on ADSL lines?
I thought it had been for quite a while but note that the September 2015 ISP Forum (https://www.btwholesale.com/assets/documents/Previous_Events/ISP_Forum/ISP_Forum_30_September_2015_slides.pdf) makes several references to customer control of DLM and a 'DLM Took Self Service Tool' which was being launched/rolled out last Autumn.
-
Out of interest would that migration be between BTw based ISP and an LLU ISP? Changing between BTw based ISPs certainly doesnt appear to trigger a reset.
BT -> Sky
-
However the problem is Openreaches tough stance on DLM resets. IMHO it is a major problem that ISPs cant simply request a DLM reset themselves.
Do you know how long ISPs have had this capability on ADSL lines?
I thought it had been for quite a while but note that the September 2015 ISP Forum (https://www.btwholesale.com/assets/documents/Previous_Events/ISP_Forum/ISP_Forum_30_September_2015_slides.pdf) makes several references to customer control of DLM and a 'DLM Took Self Service Tool' which was being launched/rolled out last Autumn.
Previously the ISP put in a request to BTw and then they had to wait for BTw to physically do it.
With the new self service tool the ISP can also directly control and adjust other things such as say the Target SNRm.
I think the main difference is akin to how we can say phone up or raise a ticket with our ISP and ask them to do something, which they then do. Or like it used to be with BE* users had direct access to a CP to directly make these changes themselves such as set 3dB margin or turn off interleaving without ever having to speak to anyone first.
---
I'm not certain, but from what Weaver, says it sounds like AAISP has taken the new tool one step further and built on it so that their customers themselves also have direct access and change the settings themselves. Ive never seen what options are available to the EU though other than Weavers mention of what is available to him via 'clueless'. Im unsure if the options within clueless automatically generates the change with BTw - or if it sends a request to AAISP to make the change.
Somehow I cant ever see BTretail/consumer doing this. Their average type customer would be changing settings without having a clue what they would be doing and possibly cause more harm :(
-
OT - I tried to look at your weather website, that's also 'dead'!?
-
OT - I tried to look at your weather website, that's also 'dead'!?
One, who is "OT" and two, that's 123-reg for you. Terrible. :lol:
-
OT isn't a person, it's short for "Off Topic".
-
OT isn't a person, it's short for "Off Topic".
Oh my, I should of known. Thanks, Eric!
-
I'd just thought I'd let everyone know that my line is still banded, but hopefully not for much longer. The 64 day cut off is only just around the corner! :D
xDSL
Mode VDSL2
Traffic Type PTM
Status Up
Link Power State L0
Downstream Upstream
Line Coding (Trellis) On On
SNR Margin (dB) 10.5 5.8
Attenuation (dB) 25.6 0.0
Output Power (dBm) 12.0 5.4
Attainable Rate (Kbps) 44733 8043
Rate (Kbps) 34999 8043
B (# of bytes in Mux Data Frame) 166 239
M (# of Mux Data Frames in an RS codeword) 1 1
T (# of Mux Data Frames in an OH sub-frame) 0 42
R (# of redundancy bytes in the RS codeword) 8 0
S (# of data symbols over which the RS code word spans) 0.1517 0.9481
L (# of bits transmitted in each data symbol) 9229 2025
D (interleaver depth) 16 1
I (interleaver block size in bytes) 175 120
N (RS codeword size) 175 240
Delay (msec) 0 0
INP (DMT symbol) 48.00 0.00
OH Frames 0 0
OH Frame Errors 584 1858
RS Words 2977327504 770245
RS Correctable Errors 2451038 0
RS Uncorrectable Errors 0 0
HEC Errors 0 0
OCD Errors 0 0
LCD Errors 0 0
Total Cells 1992255378 0
Data Cells 610378641 0
Bit Errors 0 0
Total ES 11 1406
Total SES 11 10
Total UAS 67 56