Kitz Forum
Broadband Related => FTTC and FTTP Issues => Topic started by: jid on December 22, 2014, 07:54:50 PM
-
It's been a while since I've been here! But I've a question relating to DLM (who doesn't!).
Recently moved to 80/20 fibre, and as expected, my line is taking to it well :'(
Couple of resyncs have it seems got the connection a banded profile (likely due to lots of ES). I have a very short line, the cab is only around the corner, and I know its all "good copper" when the engineer installed FTTC, unfortunately seems it also suffers from noise.
Mydslwebstats is certainly impressing me (which I'll be making a donation for soon! :) ) and its showing some spikes of noise which I am aware of already.
Mainly, will I ever get a recovery from the 60mbps banded profile the line now seems to be on? We just had a short powercut and the modem resynced at spot on the same sync speed as last night when DLM intervened?
Many Thanks,
Jamie
-
Mainly, will I ever get a recovery from the 60mbps banded profile the line now seems to be on? We just had a short powercut and the modem resynced at spot on the same sync speed as last night when DLM intervened?
Many Thanks,
Jamie
Your line has had 3 resyncs in the last 24 hours and 1 on the saturday and your ES/day climbed to 2433 so you must have gone past the DLM ES threshold in that 24 hours.
The Banded profile will not change even after a short power outage as the DLM has already taken action on your line from the 21st of december at 9.08am.
you will need keep the FTTC modem stable from here on (no power outages) for upto 14 days max, My guess you will resync higher than 60mbps after 1 week.
If this is a new FTTC install the DLM will take action on the 2nd day after activation so it has trained your line and see 60mbps as the optimum your line can handle.
-
you will need keep the FTTC modem stable from here on (no power outages) for upto 14 days max, My guess you will resync higher than 60mbps after 1 week :)
The intention is to leave the modem on continuously - it always is so hopefully we shall see if it does recover and as long as it doesn't keep going down, then all good :)
-
When was FTTC activated on your line ?
-
When was FTTC activated on your line ?
I've had FTTC for 2 years on a 38/2 package.
However I've had 80/20 for four days in total :)
-
However I've had 80/20 for four days in total :)
Ah I see going from 40/2 to 80/20 the line will go though the wide open phaze and then the DLM will then take control (DLM reset).
I need to ask you did you get a estimated throughput quote for the 80/20 ?
-
60 - 70 was the quote, however the line is quite unstable according the BTw check which I've attached. However they then changed their minds to anything between 79 and 44.
Crosstalk has also hit the line hard, I was the first 10 on the cab in 2012, and now its full I'm told :-[
-
The way I read it the high errored seconds you had put you on interleaved and it seems the errored seconds count has dropped after being interleaved as expected, unfortunately your graphs only start on Dec 21 so this is all we have to work from.
It's one of those waiting games to see if and when you get moved to non-interleaved and then have a look at you Sync speed.
-
Something is up with your line, you have not too bad crosstalk yet the DLM has decided to apply banding and interleaving. Either that or some bad local wiring/interference issues.
You use powerline adaptors?
-
You use powerline adaptors?
Always have since Fibre was installed and they've not caused problems in the past?
I do have a noisy line however from previous experiences.
-
Unfortunately no Powerlines isn't an option, stone walls mean Wifi is usless :(
I had a noisy line before using Powerlines so even though its possible, I'd need to find a way of being able to not use them for 7 days - something which will be difficult at best.
I see looking back you found removing powerlines solved issues, was it FEC errors they were causing?
-
Unfortunately no Powerlines isn't an option, stone walls mean Wifi is usless :(
I had a noisy line before using Powerlines so even though its possible, I'd need to find a way of being able to not use them for 7 days - something which will be difficult at best.
I see looking back you found removing powerlines solved issues, was it FEC errors they were causing?
Yes high FEC's at 200,000 min where related to my powerline adapters, all you need to do is wait and see, we can only give are estimates and previous experiences but as no two lines are the same it all go's out the window it up to the individual to see the results for themselves yet the FTTC DLM is predictable when you know your own lines capability and comes from months and years of looking at your stats.
-
I'd slightly changed the setup a few days ago (powerline next to modem plug) so I've adjusted it to how it was before - your hunch they're affecting things maybe right, attainable, snrm and others have increased since I moved them all so shall leave it settle.
These figures are now all flatlining (like they always used to) so I shall now monitor it over new year and see how it all goes.
Thanks for your input and advice on the DLM settling - it's put my mind at rest I may not be stuck this slow forever :)
-
All good now for a few days so shall see if the DLM progresses and removes that banded profile - I'm not overly worried about interleaving.
From what I understand, there needs to be a progression through the DLM Caution Counters before a change up will be made?
I swapped out the HG612 and the connection drastically improved. The TalkTalk Super router replacement arrived and its now an uptime over 2 days and low error rates so now it seems I play the waiting game!?
-
you need to stay out of red status for the length of caution counters, then it should take action. I am not sure tho if needs to be green or if amber is ok, kitz or someone else hopefully can tell you.
-
I'm also trying to determine if the FEC is considered at all during DLM's decisioning process (e.g. for positive changes). The ASUS gives out an unusually high FEC count when interleaved with a lower SNRM, but based on their technical explaination I think it's understandable - just different :(. I'm hoping FEC isn't considered, but I'm applying enough interleaving (INP/delay) to reduce standard error seconds my line produces on most modem chipsets anyway. Once a month has passed and no changes have occurred and I know nothing negative could've changed its decision further then I'll post an update to conclude whether or not FEC is really considered.
-
well as they use MTBE and FEC's are not errors they shouldnt be doing so.
-
you need to stay out of red status for the length of caution counters, then it should take action. I am not sure tho if needs to be green or if amber is ok, kitz or someone else hopefully can tell you.
I too am unsure of this, however, so far its green all the way.
-
Always have since Fibre was installed and they've not caused problems in the past?
NS is correct. We've seen several cases now where powerline adapters have been the definite cause of problems. In fact there's a couple of models that have been banned in Norway because of the noise interference they generate, yet they are still for sale in the UK
-link (http://forum.kitz.co.uk/index.php?topic=14695.msg274433#msg274433).
I am not sure tho if needs to be green or if amber is ok, kitz or someone else hopefully can tell you.
Its got to be green for an improvement. Amber keeps you at the same profile. Red puts you on a higher profile.
Dont forget that different ISPs may not all be using the same profile categories. (ie speed etc) http://www.kitz.co.uk/adsl/DLM_calculator.php
-
I'm also trying to determine if the FEC is considered at all during DLM's decisioning process
Ive spent hours and hours searching through documentation and no where (aside from the Zen website) have I ever seen mention of FECs. All the BT documentation says either just "Errors" or when they get more specific "Code Violations". FECs are certainly not code violations.
Ive also put out a few feelers and contacted several people - See here (http://forum.kitz.co.uk/index.php?topic=14598.msg275178#msg275178).
2 separate sources have confirmed E/S and SES.
Im still ploughing my way through all the DLM stuff but had to come to a temporary halt because of the huge amount of time this was taking to read through all the papers and documents and sort out what was relevant and what isnt. Its a massive project and far bigger than I imagined it would be when I first started. I think only someone like the ISPs or perhaps BS will understand just how hard it is to get information. Its there but it takes a heck of a lot of decyphering and wading through irrelevant information that there is so much of.
Ive also contacted someone to request the current BToR DLM MTBE, they promised they would get back to me with some figures or confirmation, but so far Ive heard nothing as the ASSIA case kind of dropped a bombshell and BT seem to be pretty stum now. :( All I can do is confirm that the figures that I had prior to the ASSIA case seem to have been the most up to date at that point. Ive no idea what has been changed (if anything) since.
Perhaps in the New Year, I may have time to do some more digging, theres bits of more info that I have yet havent yet penned, but anything that Im pretty certain of my facts on, will be going up on this page.
http://www.kitz.co.uk/adsl/DLM.htm
where Im attempting to methodically work through the whole process.
-
...
Ok thanks, that would make sense as different modem chipsets can produce different FEC values (in some cases, significantly different it would seem) - plus they are corrected errors and don't appear to truly represent the potential CRC errors either.
As quoted from ASUS:
Please note that the root cause of high FEC is Noise. Firstly, we assume that there is no Noise and the channel is perfect, the Receiver(Modem) get the constellation point is the exact point (we call it golden point for the time being) that the Transmitter(DSLAM) sent, so there is no FEC at all.
Secondly, there is slight noise and the channel is not perfect, the Receiver(Modem) get the constellation point is not the point that the Transmitter(DSLAM) sent, if Receiver(Modem) get the point is very close to the Transmitter sent than other constellation point, then the channel coding (such as RS code and decode) can correct it to the golden point, so FEC will be produced which is normal.
A little bit of broken English.
EDIT:
Only two things I've noticed on DLM so far since they restored it.
1) DLM seems to take action later in the morning than usual, typically between 7am to 9am here.
2) Minimum sync rate is now 128Kbps instead of approximately half of the maximum sync rate.
-
Its got to be green for an improvement. Amber keeps you at the same profile. Red puts you on a higher profile.
Dont forget that different ISPs may not all be using the same profile categories. (ie speed etc) http://www.kitz.co.uk/adsl/DLM_calculator.php
I know that I'm on "Stable" for IPTV - or at least I assume so considering TalkTalk mentioned TV customers are on a different DLM profile. So far since disconnecting the HG612 - which caused lots of errors - the connection is settling to 1 - 3 ES a day. Just a matter of waiting now I guess :)
Thanks for the reply, makes sense of a few more things :)
1) DLM seems to take action later in the morning than usual, typically between 7am to 9am here.
I've noticed this too, after 9am I had one.
-
Thanks for the info :)
1) DLM seems to take action later in the morning than usual, typically between 7am to 9am here.
Im not too certain if that is related to the ASSIA case or not. I noticed the change in October (slightly before the ASSIA court case) that any DLM changes could now happen at any time up to 11am - typically at 10am - rather than the previous wee small hours. In this thread (http://forum.kitz.co.uk/index.php?topic=14567.msg272804#msg272804) on the 25th of Oct I specifically commented on how much later changes to the DLM were now being made.
My fault occurred whilst BT were messing about with something on the backhauls - most possibly changing the SVLANs to do with the new MSE bRAS (http://www.kitz.co.uk/adsl/MSE_BRAS.htm)... because this was the time that I suddenly found out I was now routing via a neighbouring exchange rather than my own local exchange.
If you notice the first DLM change occurred during night time hours.. then suddenly they were all during daytime hours.
-----
Over the past few months BT have been doing a heck of a lot of re-routing and changes in relation to the MSE bRAS. This means (for me at least) the Element Manager (http://www.kitz.co.uk/adsl/DLM_system.htm#element_manager) for my FTTC DSLAM (which communicates the DLM changes) is no longer in my local exchange, but instead in the next town. The RAMBo box also wont be in my local exchange, so I suppose there could be an awful lot of boxes & element managers that are kept busier and monitoring more lines and making DLM changes later in the day. On the old system its possible that you could have had just one element manager for one MSAN.. now youre going to get element managers that are responsible for an awful lot of fttc cabs.
To me it would make more sense that the later DLM changes are more to do with the new MSE bRAS rather than anything to do with the ASSIA court case.
2) Minimum sync rate is now 128Kbps instead of approximately half of the maximum sync rate.
After reading through a lot of the court case notes, the one over-riding area in which ASSIA seemed to have a stronghold was that BT used caps & banding for the fttc system.
There also seemed to be some sort of issue with BT holding some sort of records and the use of banding. We know that the court case only affected the fttc system and therefore banding.. so I suppose this could be part of it. I dont see that ASSIA had a problem with SNR and Interleaving (OK they tried it - but BT counter claimed that this had been used elsewhere and considered normal adsl practice pre-dating the ASSIA patent).
-
It's one of those strange FEC things Interleaved and non-Interleaved when your Interleaved the FEC's will be higher than if you had a non-Interleaving line yet the errored seconds are higher on the non-Interleaved line than the Interleaved line, so those hidden FEC counts could be accumulated as FEC counts onto the errored seconds and the reason why non-interleavers have higher errored seconds :-\
-
Its not strange. Look at it this way.
Day 1
Line A & Line B & Line C are on fast path and all lines start getting lots of CRCs (which lead to E/S). This is bad because data has to be re-transmitted and the line feels laggy and pages can be slow to load. The DLM detects that all three go red for MBTE so it applies Interleaving to all lines.
Day 2.
Line A The line performs perfectly. Its now getting a few FECs but no ErrSecs. MTBE is green. DLM assumes that the previous day must have been a one off so removes interleaving.
Line B The line peforms a lot better, its now getting lots of FECs but that doesnt matter because through error correction the modem can recover most of the lost data. So theres less dropped packets, less loss data. Because its now getting FECs, theres not as many ErrSecs. The FEC count shows that Interleaving and Error correction is working as it should be, so DLM doesnt care. As long as MTBE stays amber then the DLM wont do anything and leave the level of interleaving as it is.
Line C The line performs better, its now getting lots of FECs but its still getting quite a lot of ErrSecs. The line doesnt feel quite as laggy but theres still periods in the evening where its dropping packets and therefore still slow. DLM detects that MBTE is still red so it increases the depth of interleaving again.
Day 3
Line A . DLM has removed interleaving. No FECs but theres now CRCs and E/S again. What the DLM does next depends upon its status. If it sufficient MTBE to go back to red then the DLM will reapply the interleaving. If its amber then the DLM wont do anything. *
Line B. Line is still getting lots of FECs but the MTBE is still amber. DLM doesnt care. Error correction working as it should. No action taken.
Line C. Line now has level 2 Interleaving. Its getting loads of FECs, way more than line 2, but MTBE is still amber. DLM doesnt care. Error correction is working as it should. No action taken. However if line continues to MTBE red, then DLM will keep applying further steps until it stays amber.
* note re Line A. The next time it goes MTBE red then the DLM will wait longer on the next MTBE green before removing interleaving. This is to prevent a line continually flapping between interleaved and non interleaved. After each episode of DLM intervention the line will have to remain stable for longer before it will consider removing interleaving regardless or not if MTBE is green.
The above is a cut down version for an example to try make it simple and doesnt take account for line monitoring during the MTBE green stage... otherwise Id be typing all night :D
The main thing though is DLM isnt bothered by FECs. Its ErrSecs that cause data to be lost and the line to drop. Too many ErrSecs then the DLM will take action. As long as the line stays MTBE amber then it just doesnt care.
-
Thanks Kitz. Although I assume DLM won't bring back up a banded profile like I'm on as quickly as a few days?
Caution Counters have to be green for 9 days for this to happen?
-
Thanks Kitz. Although I assume DLM won't bring back up a banded profile like I'm on as quickly as a few days?
Caution Counters have to be green for 9 days for this to happen?
Presumably for whatever length they are, they might not necessarily be 9 days if the original algorithm that Plusnet describes is still in use. This means if you've had a previous DLM intervention then it might take a bit longer than 9 days before positive changes are made this time.
-
Im not sure where 9 days comes into it.*
AFAIK Its supposed to work on a doubler method that I mentioned in the other big thread. ie the first time the DLM hits it will adjust you back after 1 day green, the next time it will take 2 days, then 4 etc. The idea behind this is to stop lines flapping between interleaved and non-interleaved. The recovery process is an area where I need to do a lot more digging and reading yet though.
When my line was hit by the DLM in October, it started recovery after one full day of MTBE green. It took a few days to recover completely as it went through each reduction in turn. I was hit quite badly with Err Secs after some changes BT made to the backhaul to the extent that I was MTBE red for several days before they fixed the fault.. so by the time they did fix it I'd got several steps to backtrack on. But it did and each day it would move one step closer to being completely removed.
ADSLMax/Golden Fibre is another member of this forum who was hit by DLM for the first time after he was messing with a new router and he also recovered after just one full day of MTBE & MTBR green.
*Only a guess, wonder if thats the old method from years & years ago. Ive seen people mention 9 days before, but its not in any of the documentation I've seen.
-
I'm currently 7 days from my last DLM adjustment, 8 days since the first.
Currently unable to run DSL Stats on the Super Router as the modified config file does in fact leave telnet open to the WAN.
However, I believe my old Super Router's power supply was causing noise, which led to the original issues. Currently I'm seeing no ES, however, lots and lots of FEC errors - not an issue, I don't want interleaving off.
Tempted to put the HG612 back on, but not sure if messing again will do me any help except to be able to retrieve stats. The Super Router also syncs higher than the HG612.
-
If you do, leave the modem cable unconnected for 30 mins, so DLM sees it as an unforced retrain (http://www.kitz.co.uk/adsl/DLM.htm#unforced_retrains).
-
If you do, leave the modem cable unconnected for 30 mins, so DLM sees it as an unforced retrain (http://www.kitz.co.uk/adsl/DLM.htm#unforced_retrains).
Yes left it for 45 mins, back on the HG612 now.
1million fec's in 10 minutes :( Not an issue in itself I know, but shows there's a lot of noise :-\
-
yeah its fixing a lot of errors.
-
yeah its fixing a lot of errors.
Isn't it sometimes Homeplugs which cause lots of FEC errors or other faulty equipment?
-
Homeplugs can be a source yes.
-
Sadly still playing the waiting game with the DLM changes low ES for 8 days and its still not removed my banded profile.
Sadly the game we seem to have to play with FTTC!
-
yeah its fixing a lot of errors.
Yeap Ronski's work line pumps out 100,000 fec's per minute thats been going for many months it must be some kind of electrical interference for him yet he's not banded just the line won't get moved off interleaving ;)
-
Not so bothered about interleaving to be honest, but annoyingly seems my old faulty Super Router caused so many errors it banded the profile ::)
-
yeah its fixing a lot of errors.
Yeap Ronski's work line pumps out 100,000 fec's per minute thats been going for many months it must be some kind of electrical interference for him yet he's not banded just the line won't get moved off interleaving ;)
Ronski isnt Interleaved atm.. despite 100's of thousands of FECs the day before on the 28th the DLM still removed Interleaving. His line if any should be proof that the DLM doesnt care about FECs.
Ronski's had interleaving removed a couple of times now in he past few months. Proof also that as long as you can get MTBE green for sufficient time then the DLM will eventually remove interleaving.
At first he was using the HG612, had had been interleaved for a looooooong time. In Sept he got a Zyxel and it took a while as he came down the various steps, but Interleaving was eventually removed in Oct and it was doing OK.
Unfortunately there was a single and isolated massive noise burst on the 10th of Nov resulting in 2461 E/S which took him just into MTBE red. As a result the DLM applied interleaving yet again. (see attached) The line has been fine since and DLM removed interleaving again on the 28th.
If you notice although the line isnt interleaved atm, its now generating circa 1300 E/S per day but touch wood the DLM is happy with this. Ronski's line seems to perform better with the Zyxel than it did with the HG612 and its just about keeping in MTBE amber, plus giving him a better sync speed. If it hadnt been for that single massive noise burst on the 10th of Nov, then its highly likely that his line would have remained non-interleaved since Oct.
-
Not so bothered about interleaving to be honest,
You must be the only one that's not bothered by being interleaved, as soon as a Kitz member gets interleaved it becomes a News headline on this forum :D
-
Not so bothered about interleaving to be honest,
You must be the only one that's not bothered by being interleaved, as soon as a Kitz member gets interleaved it becomes a News headline on this forum :D
I'd be glad to get my 69 meg back!
My first DLM hit switched on interleaving and I lost a few mbps sync, now this banded profile has cut nearly 20mbps from the speed - I just hope its not permanent as the line is noisy and will recover ;D
-
Sadly still playing the waiting game with the DLM changes low ES for 8 days and its still not removed my banded profile.
Sadly the game we seem to have to play with FTTC!
I've gone 19 days now since my last band change from 22499 to 24999. Even though ES stays below 300 nothing has changed since
Sent from my iPhone using Tapatalk
-
That's good to know kitz. I'm currently getting an average of between 8 to 12 ES daily with my settings currently at INP 4, delay 8ms, target SNRM 9.0dB, max/min sync rate 80,000Kbps/128Kbps. Interestingly my SNRM also dropped by around 1.5dB downstream and 0.5dB upstream today (this was sudden, not gradual) - a similar effect that some other people have been having recently too?
-
Ronski isnt Interleaved atm.. despite 100's of thousands of FECs the day before on the 28th the DLM still removed Interleaving. His line if any should be proof that the DLM doesnt care about FECs.
Kitz I am not disputing that the DLM ignores FEC's if your getting large FEC counts then there has to be a battle going on with interference/noise and what happens when your modem see's noise it becomes CRC's and ES that's what I am saying :)
-
I've gone 19 days now since my last band change from 22499 to 24999.
How long a period of stability did it take to get the band plan change?
Your line also concerns me a little as the SNRm oscillates quite a bit over the course of the day. From what Ive read if youve been banded/interleaved for a while and for several episodes then the wait out period keeps doubling each time.
During this time SNRm is also monitored to make sure it doesnt swing too high or low. Unfortunately Ive no idea what it considers as acceptable. If I had to guess Id say 3dB would seem a sensible figure, so you may be ok. :fingers:
As mentioned earlier up in the thread, I think the 8/9 days is a myth & hangover from the old system.. admittedly there are some lines that do resolve in 8 days, but that could just as likely be co-incidence of the doubling effect. There are some lines that correct the next day, whilst others take months.
-
I've gone 19 days now since my last band change from 22499 to 24999.
How long a period of stability did it take to get the band plan change?
Your line also concerns me a little as the SNRm oscillates quite a bit over the course of the day. From what Ive read if youve been banded/interleaved for a while and for several episodes then the wait out period keeps doubling each time.
During this time SNRm is also monitored to make sure it doesnt swing too high or low. Unfortunately Ive no idea what it considers as acceptable. If I had to guess Id say 3dB would seem a sensible figure, so you may be ok. :fingers:
As mentioned earlier up in the thread, I think the 8/9 days is a myth & hangover from the old system.. admittedly there are some lines that do resolve in 8 days, but that could just as likely be co-incidence of the doubling effect. There are some lines that correct the next day, whilst others take months.
It took 10 days for the first change which was to back off interleave then approx 3 days later the the banding was changed.
The problem occurred one weekend when I was away. Before I left it was syncing around 27m but on my return it dropped to 22.5m. Dlm had been reset approx 1.5 weeks prior to this
Sent from my iPhone using Tapatalk
-
Remember that millions of FEC's doesn't mean your line is necessarily going to have lots of CRC errors if you were on fastpath. ASUS pointed this out to me a short while ago, and as the device is capable is ignoring the downstream parameters set on the DSLAM - when I did go from interleaved to fastpath on various occasions I did observe that despite having millions of FEC's in a short timeframe that the CRC's were neglible.
It's something to do with the 'golden point', the time that the DSLAM (VTU-C) sends something and the receiving modem (VTU-R) finds that it's not the expected time, but can correct this and so records it as an FEC.
-
Remember that millions of FEC's doesn't mean your line is necessarily going to have lots of CRC errors if you were on fastpath.
Well I'll construct a scenario as a Interleaver, Homeplugs installed with FEC's at 200.000 per min and 3000 crc's and 1500 errored seconds the HG612 resync's and I am banded for 2 weeks, don't tell me the FEC count is worthless if so why is it part of all modem/router stat.
Let's be clear if you see 50000 - 200000 FEC's PER MIN you have a problem with interference (NOISE)
-
Remember that millions of FEC's doesn't mean your line is necessarily going to have lots of CRC errors if you were on fastpath.
Well I'll construct a scenario as a Interleaver, Homeplugs installed with FEC's at 200.000 per min and 3000 crc's and 1500 errored seconds the HG612 resync's and I am banded for 2 weeks, don't tell me the FEC count is worthless if so why is it part of all modem/router stat.
Let's be clear if you see 50000 - 200000 FEC's PER MIN you have a problem with interference (NOISE)
I'll quote exactly what ASUS said to me, make of it what you will, but all I can say is that I've had thousands to millions of FEC's on either the HG612 or ASUS (though the ASUS by far produces tons more) but only a few hundred CRC's daily on fastpath typically under normal conditions:
Please note that the root cause of high FEC is Noise. Firstly, we assume that there is no Noise and the channel is perfect, the Receiver(Modem) get the constellation point is the exact point(we call it golden point for the time being) that the Transmitter(DSLAM) sent, so there is no FEC at all.
Secondly, there is slight noise and the channel is not perfect, the Receiver(Modem) get the constellation point is not the point that the Transmitter(DSLAM) sent, if Receiver(Modem) get the point is very close to the Transmitter sent than other constellation point, then the channel coding(such as RS code and decode) can correct it to the golden point, so FEC will be produced which is normal.
Sure, some FEC's could well be CRC's if on fastpath, this is a matter where each line will have different results it seems. Presumably this is also another reason why the DLM doesn't consider the number of FEC's or FEC seconds in its decisioning process?
-
Ixel if i don't here from you, Have a Happy New Year :)
PS :-[ purchased an SSFP MK3 should be here tomorrow ::)
-
Ixel if i don't here from you, Have a Happy New Year :)
PS :-[ purchased an SSFP MK3 should be here tomorrow ::)
No problem, same to you - I'm here regularly though. Hopefully the MK3 SSFP will make an improvement on your line.
-
6:56 this morning DLM finally removed the banded profile!
Although did need to reboot the router to increase the speed.
One observation I have made is that the Super Router is much more stable as a modem than the HG612, gives a higher attainable rate and better sync speeds. I'm now on a 70meg banded profile from my resync to swap back to the Super Router.
I only moved to the HG612 for stats monitoring and it throws more ES and FEC errors than the Super Router.
-
End of Christmas - end of the neighbours faulty Christmas lights and hardly any FEC errors :dance:
Ended up back on the banded profile a night after DLM removed it, so now likely waiting again for it to recover >:(
On a positive note, my 200,000 fec errors a minute has reduced significantly tonight after the neighbours unplugged their outdoor christmas lights! Hopefully not a coincidence and the actual cause was them!
Happy New Year to all :)
-
Would be nice if jidavies could keep the logging to MDWS on for 14days as I am not getting the full story for jid's line it's what I call fragmented stats if you know what i meen.
-
Would be nice if jidavies could keep the logging to MDWS on for 14days as I am not getting the full story for jid's line it's what I call fragmented stats if you know what i meen.
Yep sorry the WiFi dongle on the Pi keeps dying so got it via cat5 now so shall leave it and hopefully will give good stats :)
-
Would be nice if jidavies could keep the logging to MDWS on for 14days as I am not getting the full story for jid's line it's what I call fragmented stats if you know what i meen.
Yep sorry the WiFi dongle on the Pi keeps dying so got it via cat5 now so shall leave it and hopefully will give good stats :)
Good Job jid, these Pi's are just the ticket for modem stats logging, jezz i remember the days of my fragmented stats when the PC was the only thing i had to harvest the stats and what a difference it makes to see 24/7 graphs.
-
Yes I've a few Pis around the house doing various things and the WiFi dongle on this one has failed it seems so should be good now!
-
Would be nice if jidavies could keep the logging to MDWS on for 14days as I am not getting the full story for jid's line it's what I call fragmented stats if you know what i meen.
I've got about 4 days of logging now and to be honest I can't see anything too serious on there, FEC errors have dramatically decreased since taking the Super Router out of the equation.
So as for why I got back to a banded profile I don't know, I went onto a higher band on the 1st and then on the 2nd it came back down when I put the Super Router back in (hence no stats).
All I can think is that the Super Router was causing noise and ES? We shall see now on Sunday if DLM follows the same pattern as before.
-
I suspect the super router may be to blame. My line has quite a few SHINE like events, some small and some with one or two SES. I have found that the TT super router does not seem to do well with these events and gives a much higher CRC and ES count when they occur. Enough to double or treble daily ES rates. It is a 63168 device and other 63168 modems are to varying degrees the same on my line. Of them the Billion 8800NL seems best giving only a 50% error rate over the HG612. I think it is unusual for a more advanced chipset to be that much worse than the older one and I wonder if the 63168 is designed to expect g-INP to be working. At the time of the 63168 release most of the worlds service providers were probably already implementing g-INP and if recent speculation is correct BT/Openreach may eventually do so.
-
My Billion 8800NL has lot of errors but ongoing connection for 43 days - strange - no DLM trigger yet!
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fs5.postimg.org%2F76rzm4ron%2FVDSL2_Stats_Billion_8800_NL.jpg&hash=da0501595afc273df80d853e6c624fe550347338) (http://postimg.org/image/9o3qtebkz/full/)
-
My Billion 8800NL has lot of errors but ongoing connection for 43 days - strange - no DLM trigger yet!
The DLM is only interested in Errored Seconds.. and for that your error rate is good.
Work it out like this. No of days uptime = 43. ErrSecs = 3065
3065/43 = 71 per day. You can then put this figure into the DLM calculator here (http://www.kitz.co.uk/adsl/DLM_calculator.php) But I can tell from that low figure that it will be green anyhow.
-
3k ES in 43 days and no SES, thats why no DLM, your billion doing good :)
I have a 70+ day uptime, although at the moment I cannot access stats as I cannot get access to the 2nd lan subnet on tomatousb firmware.
kitz do you think phyr is been used on the upstream?
-
I have a 70+ day uptime, although at the moment I cannot access stats as I cannot get access to the 2nd lan subnet on tomatousb firmware.
Unless you've checked the site you won't be aware that you've NOT been getting any data into MDWS for some time now as your modem logs that you are uploading are full of zeros instead of data so get rejected. Your username shows up in red for uploaders with this problem (as does spadge007). Your last valid upload was on Jan 7th 10:00.
-
Thanks Kitz. Interesting about DLM calculator. I was hoping my Billions stay connection for 365 days if all possible (without any power cut) but I know it not possible due to thunderstorms this summer will cause power cut off. It's would be very interesting what the ES rate are in 365 days.
-
kitz do you think phyr is been used on the upstream?
Probably - adslmax has FECs but no interleaving.
-
Kitz - I do remember plusnet staff told me that DLM is only counting on the downstream (not upstream) but I do remember a few months back when my DLM was hit on the downstream because of my own fault swapped over modem without wait for 30 minutes but interleaving was put on the upstream as well. I think it was INP 4.00 (upstream) and INP 3.00 (downstream) I found the screenshot below.
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fs5.postimg.org%2F5g8ykna5j%2FBT_Openreach_modem_under_dlm.jpg&hash=18ba8a867151889b7b9f34560c155ea9f6ae3fd9) (http://postimg.org/image/a252szvoj/full/)
-
I have a 70+ day uptime, although at the moment I cannot access stats as I cannot get access to the 2nd lan subnet on tomatousb firmware.
Unless you've checked the site you won't be aware that you've NOT been getting any data into MDWS for some time now as your modem logs that you are uploading are full of zeros instead of data so get rejected. Your username shows up in red for uploaders with this problem (as does spadge007). Your last valid upload was on Jan 7th 10:00.
obviously I wont be uploading if the lan access is cutoff :)
-
I have a 70+ day uptime, although at the moment I cannot access stats as I cannot get access to the 2nd lan subnet on tomatousb firmware.
Unless you've checked the site you won't be aware that you've NOT been getting any data into MDWS for some time now as your modem logs that you are uploading are full of zeros instead of data so get rejected. Your username shows up in red for uploaders with this problem (as does spadge007). Your last valid upload was on Jan 7th 10:00.
obviously I wont be uploading if the lan access is cutoff :)
But you ARE uploading as I said ....
Edit:
Or were until 12:53
-
I mean I wont be uploading useful data.
I disabled the task for now, to keep you happy.
Might be an idea for the tool to skip uploading if it fails to fetch stats.
-
plusnet staff told me that DLM is only counting on the downstream (not upstream)
Im afraid thats partially wrong. With 21CN/FTTC the DLM monitors both the upstream and downstream independently.
Many years ago when adslmax first came in DLM only monitored downstream. Downstream only monitoring is just on the remaining 20CN exchanges which cant get adsl2+ and fttc.
-
I mean I wont be uploading useful data.
I disabled the task for now, to keep you happy.
Might be an idea for the tool to skip uploading if it fails to fetch stats.
You need to ask BE1 to get that to happen but it is a problem I believe he is aware of...
I'm not unhappy, just trying to help you but won't bother again - but BE1 might be unhappy as he gets an email every minute telling him whenever this happens for a user
-
I found an option to turn of mydslwebstats so thats off now.
Currently messing with router still trying to get this to work. Now my pc can ping the billion but no telnet or http still.
-
Tony is fixed now, but I wont enable the mydslwebstats again just yet as still more network configuring to do.
-
Currently messing with router still trying to get this to work
Is there not an option (that works on some modems) "Route Modem IP"
If you are using the hg612 it will not work.
Ian
-
I mean I wont be uploading useful data.
I disabled the task for now, to keep you happy.
Might be an idea for the tool to skip uploading if it fails to fetch stats.
You need to ask BE1 to get that to happen but it is a problem I believe he is aware of...
I'm not unhappy, just trying to help you but won't bother again - but BE1 might be unhappy as he gets an email every minute telling him whenever this happens for a user
I just keep deleting the emails every now & then.
I haven't been around much of late as I've been really busy work-wise & also attempting to complete my 18 month home refurbs (now in year 12!!!!).
I had a dabble with HG612_stats.exe this morning, to hopefully avoid the "All Zeros" emails etc.
If no stats are being harvested at all, the best option would be to completely disable the every minute task.
Doing that would cease all attempts to obtain snapshot AND every minute data harvesting.
However, as some users may wish to continue with snapshot logging (local PC graphs stored only), but disable Ongoing logging, the attached version of HG612_stats.exe [v 4.0.0.8] & Upload.exe [v 4.0.0.0] used together should not attempt to upload anything at all to MDWS every minute when Ongoing logging is switched OFF.
-
Sadly after 9 days DLM didn't recover this morning so I'm thinking my caution count has now been increased?
What is the Open reach opinion on you having an unlocked modem, the original ECI I had two years ago is still sitting in the cupboard unused. Would I need to swap the unlocked one out when an engineer visits, as it's possible TalkTalk want to send one as I'm below the threshold for the line?
I now have a "spare" HG612, which I thought I'd test as its got a newer manufacture date - bad move, spurt of 200,000 FEC errors and 1000+ crcs, unplugged that mad one straight away!!
Can't see how that would cause an issue as I assumed the hardware is identical? Upstream SNR has increased too since the resync
-
Sadly after 9 days DLM didn't recover this morning so I'm thinking my caution count has now been increased?
What is the Open reach opinion on you having an unlocked modem, the original ECI I had two years ago is still sitting in the cupboard unused. Would I need to swap the unlocked one out when an engineer visits, as it's possible TalkTalk want to send one as I'm below the threshold for the line?
I now have a "spare" HG612, which I thought I'd test as its got a newer manufacture date - bad move, spurt of 200,000 FEC errors and 1000+ crcs, unplugged that mad one straight away!!
Can't see how that would cause an issue as I assumed the hardware is identical? Upstream SNR has increased too since the resync
Depending on how G.INP is implemented shortly, the ECI might be a problem unless it has received a firmware upgrade prior to G.INP being applied to your line. There's a possibility that without a firmware upgrade it might fail to sync. Pure speculations at the moment, but hopefully BT have allowed for that possibility and not made it an oversight or nightmare in itself.
I'm not sure if the engineer will either check or be bothered if the modem is unlocked (if you don't announce that of course), but somehow I doubt he/she will. Some people have found that if you're on an ECI cabinet and connect a HG612 then it will produce errors, where on an infineon chip such as the one in the ECI it will produce less errors (or so it would seem based on some feedback regarding DLM making negative changes on the HG612 with ECI cab, and positive changes eventually when going back ECI to ECI).
-
Depending on how G.INP is implemented shortly, the ECI might be a problem unless it has received a firmware upgrade prior to G.INP being applied to your line. There's a possibility that without a firmware upgrade it might fail to sync. Pure speculations at the moment, but hopefully BT have allowed for that possibility and not made it an oversight or nightmare in itself.
I'm not sure if the engineer will either check or be bothered if the modem is unlocked (if you don't announce that of course), but somehow I doubt he/she will. Some people have found that if you're on an ECI cabinet and connect a HG612 then it will produce errors, where on an infineon chip such as the one in the ECI it will produce less errors (or so it would seem based on some feedback regarding DLM making negative changes on the HG612 with ECI cab, and positive changes eventually when going back ECI to ECI).
I am on an Huawei cab, the double door type, so never have ever had problems with the HG612. I hooked up the new one I had expected improvements, and it made the stability worse!
On the other hand, is this one not reading correctly, and the new one was in fact correct and I was experiencing that amount of errors (hence the DLM isn't improving?).
-
Seeing as the roll-out is now in play .... I can now post up the following info engineers received. PS, the engineer would have no idea if your modem was unlocked or not. :)
'It may not be obvious that you’re carrying out a repair on a fibre ReTX enabled circuit with a retransmission profile applied. And it only becomes important if you have to replace a faulty Openreach modem. If the replacement modem is ECI (indicated on the box or base of the modem) it’s likely the firmware is incompatible with ReTX and a workaround needs to be applied.
An ECI modem with old firmware will appear to be in sync (the DSL light will be on) but the customer will not be able to access the internet and this will also be reflected in your GEA service test result:
For example “VDSL modem is not in sync”.
What you need to do…
If you complete a DLM reset it will remove the ReTX profile and allow the modem to sync up and then download the correct firmware before ReTX is reapplied by the system. As you will know, a DLM reset is only permissible when you have found and fixed a hard fault on the circuit - and a faulty modem is a hard fault.
It is important that you only use the DLM reset procedure, found here, when you clear a hard fault or experience a no sync situation after replacing a modem on a fibre repair task. The use of DLM resets will continue to be monitored and misuse investigated. '
-
So ECI do support via a FW update, that makes much more sense because clearly the chipset is capable as ECI cabinets use the same chipset.
So those ECI modems in the wild should get an automatic update and the issue should only be with ECI stock in engineer vans and BT's warehouse.
-
Seeing as the roll-out is now in play .... I can now post up the following info engineers received. PS, the engineer would have no idea if your modem was unlocked or not. :)
Unfortunately, my LEDs are turned off and the GUI disappeared after the last BT Agent update, likely I'd have to swap out? Unless theres a way by Telnet to re-enable them? ???
-
I take it Wolfys HG612 firmware ->
Software version = V100R001C01B030SP08
Software last change detected at 31/08/2014 at 17:37
Firmware version = A2pv6C038m.d24j
Firmware last change detected at 13/07/2014 at 01:00
CPU version = BCM6368
CPU last change detected at 31/08/2014 at 17:37
CFE version = 1.0.37-102.6
CFE last change detected at 31/08/2014 at 17:37
unlocked with webgui will be ok ?
-
unlocked with webgui will be ok ?
I unlocked with the original SP10 instructions and left the modem as is since 2012 to be honest.
Don't know what benefit if I any I would gain from swapping the old modem with the new one. The new one I've unlocked with sp08_webgui and caused a tonne of errors?
My only option would be to reflash my original 2012 modem with sp08_webgui
-
The new one I've unlocked with sp08_webgui and caused a tonne of errors?
My only option would be to reflash my original 2012 modem with sp08_webgui
There should be no reason for a tonne of errors on the HG612 with the new firmware, the HG612 has been very stable for over six months since the update/flash.
-
There should be no reason for a tonne of errors on the HG612 with the new firmware, the HG612 has been very stable for over six months since the update/flash.
Very strange, I'll look into it another day, i'm on a Stable speed profile and 5 retrains and I'm in Amber so don't want to go there.
-
So ECI do support via a FW update, that makes much more sense because clearly the chipset is capable as ECI cabinets use the same chipset.
So those ECI modems in the wild should get an automatic update and the issue should only be with ECI stock in engineer vans and BT's warehouse.
Yep thats what I said in the other thread
such as the native ECI modems. These should be automatically updated via the BT Agent thingy so if you've had one a while then it should be fine.... but no doubt there are some ECI modems which havent been upgraded yet (such as the one thats been in my cupboard for a well over a year and some on BT vans etc) and those are the modems that may not be able to attain PPP session.
-
So ECI do support via a FW update, that makes much more sense because clearly the chipset is capable as ECI cabinets use the same chipset.
So those ECI modems in the wild should get an automatic update and the issue should only be with ECI stock in engineer vans and BT's warehouse.
Yep thats what I said in the other thread
such as the native ECI modems. These should be automatically updated via the BT Agent thingy so if you've had one a while then it should be fine.... but no doubt there are some ECI modems which havent been upgraded yet (such as the one thats been in my cupboard for a well over a year and some on BT vans etc) and those are the modems that may not be able to attain PPP session.
Any idea if those which are unlocked (ECI) are likely to not upgrade? I presume BT agent has been disabled on them.
-
for Newt who may yet to pull a trigger on his 8800nl, the 8800nl does support phyr.
-
My profile has now been banded for over one month. From my stats which can be seen on mydslstats I do not really understand why a change has not been made - ES is below 250 and s/n is around 8db. I notice on the billion router there is a section in the settings for TR-069. Should I set this up? Would it help?
Connection time before I power cycled the router a few days ago (waiting 30 mins) was 29 days.
Sent from my iPhone using Tapatalk
-
I notice on the billion router there is a section in the settings for TR-069. Should I set this up? Would it help?
No, TR-069 is the protocol used for remote control of the device. ISPs use it for remotely upgrading the firmware in devices they've supplied (for example). It has nothing to do with the DSL performance.
-
I notice on the billion router there is a section in the settings for TR-069. Should I set this up? Would it help?
No, TR-069 is the protocol used for remote control of the device. ISPs use it for remotely upgrading the firmware in devices they've supplied (for example). It has nothing to do with the DSL performance.
Ok thanks that's what I thought. The only reason I asked was that when using the hh5 I would see a lot of TR-069 value changes.
Sent from my iPhone using Tapatalk
-
So ECI do support via a FW update, that makes much more sense because clearly the chipset is capable as ECI cabinets use the same chipset.
So those ECI modems in the wild should get an automatic update and the issue should only be with ECI stock in engineer vans and BT's warehouse.
I bought a spare ECI for contingency - am I right in thinking that that's now going to be a problem? If my live ECI modem gets a FW update does that mean that I'll have problems if I come to use my backup ECI in the future? If I'm right in thinking this and the FW can't be updated easily then there will also be a lot of duff ECI modems available on eBay etc. in the future.
Apologies if I'm reading about these changes and getting myself confused ???
-
My guess is if phyr is enabled on your line prior to you plugging in that ECI and it has firmware that doesnt support the mode, then you will need a DLM reset to get it working.
-
Yes that's how I've read things.
This won't make troubleshooting any easier. I bought a replacement ECI modem as ISPs often say to try a replacement when there is a fault!
Perhaps if BT hadn't locked the things down that would give people the chance to upgrade the firmware like they do for 'normal' modems/routers >:(
-
I notice on the billion router there is a section in the settings for TR-069. Should I set this up? Would it help?
No, TR-069 is the protocol used for remote control of the device. ISPs use it for remotely upgrading the firmware in devices they've supplied (for example). It has nothing to do with the DSL performance.
Im getting a little confused. On another forum a poster has written:-
"TR069 is used by DLM daily, without it DLM would not be checking your connection daily. If there are entries in your routers log (i guarantee there is and probably under "system log") then it is not disabled. Look for anything relating to "TR069" "Profile" "Change" "Update" and similar terms if there is not a filter for TR069 entries."
Using the Billion router, TR069 is not enabled. My DL speed has been banded for over 4 weeks with an average S/N of 8dB and ES of 230. What is stopping my banding from changing? I know when I was using the HH5, there were lots of entries containing "TR069 Value change" etc so clearly parameters were being changed by TR069.
-
Eric is correct. Tr069 is nothing to do with the DLM.
-
Finally ;D
I had an RDI at 12:10 midday - this I found very unusual for DLM ???
I've got the Zyxel coming but going to leave the HG612 on for a few days now to see how its coping, don't want to mess about just yet :)
If i'm correct, with my current sync, 69335kbps, likely that DLM is now going up the banding? So i'm now on a 70mb band? But with a 6.1dB SNR margin, may the line be at its limit?
-
In the latest, this happened earlier, attached, one of the upstream bands has no SNR at all ???
-
After having confirmation, TalkTalk use Standard for all customers, I'm possibly due another DLM change by Sunday. I'm assuming my caution count decreased from 14 down to 8.
Am I right in thinking that when the caution count of in my case 14 results in a profile change, then the count is decreased to the lower count level, i.e 8?
Further interest, here's my old BTW check:
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fi60.tinypic.com%2Frbjtkn.png&hash=114b079e210e0de1dee129d98b3f94ff405719db)
And now, here's my new one:
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fi60.tinypic.com%2F34ta7av.png&hash=e67d8966b1ebbbf6228d95fa7e8d73853a591d62)
Seems the ranges have dropped ever so slightly, by about 2mbps - joys of crosstalk >:(
-
Ironically my estimates have gone up slightly since a few months ago lol.
Also the DLM intervention time is odd, it used to be between 2am to 7am in the morning here, but recently it has been at other times (such as around 10am, and infact today a moment ago when upstream interleaving was removed it happened at around 11:30am~). I wonder what’s prompted the change in intervention time. G.INP still remains off however, I’m waiting for downstream interleaving to be reduced or removed given my ES+SES and resyncs are virtually non-existent. Hoping FEC errors aren't accounted for by DLM as the ASUS reports a stupidly high count.
-
I had a stupid idea yesterday and put the hh5 back in service. The result was additional interleave and an inp of 8 together with interleaved upload and an inp of 2.5. Guess the billion was doing an excellent job which is now back in service.
Sent from my iPhone using Tapatalk
-
Something nasty has been happening all day today, 500,000 FEC errors a minute and lots of ES :(
Either something in the house is firing a load of RFI (unplugged all the homeplugs and it still was happening) or something externally is incredibly messed up!
-
Something nasty has been happening all day today, 500,000 FEC errors a minute and lots of ES :(
Either something in the house is firing a load of RFI (unplugged all the homeplugs and it still was happening) or something externally is incredibly messed up!
You never mentioned your were using homeplugs, the two homeplugs will need to be removed completely from any electrical wall sockets/strips for the FEC errors to go back to normal.
-
Something nasty has been happening all day today, 500,000 FEC errors a minute and lots of ES :(
Either something in the house is firing a load of RFI (unplugged all the homeplugs and it still was happening) or something externally is incredibly messed up!
You never mentioned your were using homeplugs, the two homeplugs will need to be removed completely from any electrical wall sockets/strips for the FEC errors to go back to normal.
Did this for 3 hours earlier and made no difference. Never had the problem before?
Sent from my Nexus 6 using Tapatalk
-
Did this for 3 hours earlier and made no difference. Never had the problem before?
Sent from my Nexus 6 using Tapatalk
High FEC's like your having is more than likely to be caused by internal mains interference as your FEC's graphs are very high and it's good you removed homeplugs as a possible cause but there is still a mains issue somewhere closeby to your premises or your neighbours are the cause :-\
-
DLM is bound to have me :'(
-
DLM is bound to have me :'(
it won't as the ES got close but never went above the threshold this time as your line seems to like playing poker with the DLM there will be a day you loose your hand of cards ;D
-
DLM is bound to have me :'(
it won't as the ES got close but never went above the threshold this time as your line seems to like playing poker with the DLM there will be a day you loose your hand of cards ;D
Sadly it had me last night :(banded downstream and lost upstream sync ::)
Anything I can do to try source this RFI? I tried unplugging everything in the house except the modem, retrieved the stats and still had the errors, so guessing its outside my house?
I've now spoken to a manager and got a fault raised for this, don't know if it will get anywhere though.
-
Sadly it had me last night :(banded downstream and lost upstream sync ::)
Anything I can do to try source this RFI? I tried unplugging everything in the house except the modem, retrieved the stats and still had the errors, so guessing its outside my house?
I've now spoken to a manager and got a fault raised for this, don't know if it will get anywhere though.
I see you have 2222 errored seconds an still climbing on MDWS and the 24 hour period has not yet come to a close.
Your were right in thinking the DLM was going to take action :ouch:
-
Sadly it had me last night :(banded downstream and lost upstream sync ::)
Anything I can do to try source this RFI? I tried unplugging everything in the house except the modem, retrieved the stats and still had the errors, so guessing its outside my house?
I've now spoken to a manager and got a fault raised for this, don't know if it will get anywhere though.
I see you have 2222 errored seconds an still climbing on MDWS and the 24 hour period has not yet come to a close.
Your were right in thinking the DLM was going to take action :ouch:
Error rate has decreased since the DLM resync this morning but it'll probably take action again tomorrow due to the high errors.
A fault was showing though due to high error rate so it's been reported.
Go from there I guess, but its within acceptable limits still so their being awkward.
Sent from my Nexus 6 using Tapatalk
-
Further DLM hit this morning to down and upstream.
Errors have stopped but sync speed is now 5 2mbps.
I really want to try and work out what maybe the cause of this noise as the fec errors are still very high?
-
The only sure-fire way of checking that the problem is not being generated within you own environment would be to provide a temporary power supply for the modem & router -- a car battery or a power-tool's battery pack, for example -- and to use a laptop computer. Then use the main switch to isolate the building from the incoming AC power supply.