Kitz Forum
Broadband Related => FTTC and FTTP Issues => Topic started by: roseway on June 03, 2017, 11:40:05 AM
-
Over the last few days my target SNRM has fallen from 6 dB to 3 dB (ish) in three stages, and my downstream connection speed is up to 78630 kbps, from a previous low of ~69000. It happened in three stages (all dB values approximate):
29 May 17:00 6 dB --> 5 dB
31 May 16:00 5 dB --> 4 dB
3 June 11:10 4 dB --> 3 dB
If you look at my stats on MDWS, don't be misled by the fact that the SNRM was ~4 dB before 29 May. This was the aftermath of a power cut some weeks earlier, when my modem reconnected at a higher than normal speed, before several crosstalk disturbers came online and dropped the SNRM to ~ 4 dB.
-
Looking back 90 days, to see the previous "normal" speed, it looks like you have jumped in steps of
69.4Mb -> 71.4Mb -> 74.8Mb -> 78.6Mb
Not quite as much as my "rule of thumb" would suggest, but the reductions seems to be mainly in the first leg, and circumstances could easily have changed in those ~90 days.
Your line looks susceptible to accidentally "running low" (low SNRM, I mean) - a natural side-effect of crosstalk taking effect sometime after the initial sync. When targeting 6dB, there's some buffer to cope. When targeting 3dB, there isn't a lot of headroom, so lots of errors could happen "innocently". I wonder how DLM will cope with such scenarios: will it figure that one simple resync will solve the problem, or will it drop a line into an unnecessary banding or interleaving configuration?
-
The "running low" situation happens here every time there's a power cut. We don't get them very often, but I tend to cherish them for the beneficial effect on my connection speed afterwards. As you say, it will be interesting to see what happens next time.
-
Interesting.
I wonder how DLM will cope with such scenarios: will it figure that one simple resync will solve the problem, or will it drop a line into an unnecessary banding or interleaving configuration?
Although forcing a resync would be the ideal situation, I doubt DLM is clever enough to detect that the low SNRM could be an effect of resyncing before crosstalkers.
If DLM decides that some action is necessary, then the logical process would be to reverse the target SNRm steps.
Actually whilst typing this, I just recalled that I think that may have been what it did on Williams line. TBH I didn't pay much attention as it was whilst I couldnt type much at the time, nor was he uploading to MDWS for me to be able to independently verify what he said he was seeing.
He reckoned he had been capped, but TBH I doubted that because the sync speeds werent any of the figures I would expect to see if the line had been capped.
----
ETA -Just checked the emails - No the sync speeds don't look like capped, more like increases in target SNRm
-
@Kitz I am currently bouncing between 3 and 4dB. Been going on for weeks now DLM keeps trying 3dB but ES shoot up into 1000s then DLM puts me back to 4dB with hardly any ES. Happened just yesterday DLM applied 3dB but after about half a day reverted to 4dB.
-
thats a horrible situation looping between 3 and 4db so the green range is too big
-
Apparently so Chrys. as soon as my sync gets to 74 I get loads of ES but when it drops down to 70 I hardly get any ES so must be on the cusp of some noise somewhere.
-
That's a bad bit of design in DLM then. It would seem that your best option would be to cap your connection at 70 Mbps, if your modem supports it.
-
thats a horrible situation looping between 3 and 4db
What actual problems is it causing? You could just ignore the stats and leave it alone.
-
Over the last few days my target SNRM has fallen from 6 dB to 3 dB (ish) in three stages....
Mine has done exactly the same thing and it has gained me 5 Mbps (40 - 45) on the DS side . The US has stayed at 6dB and the speed is pretty much unchanged.
My error stats haven't changed much so I'm keeping my fingers crossed that it'll stay that way.
Clearly Openreach are rolling this out widely right now.
:)
-
Interesting.
Although forcing a resync would be the ideal situation, I doubt DLM is clever enough to detect that the low SNRM could be an effect of resyncing before crosstalkers.
It is indeed interesting. It wouldn't take much for DLM to identify that a simple resync is enough - it just needs to check whether the recent actual SNRM is significantly below the defined target SNRM (be it 6, 5, 4 or 3dB). But ... I don't think DLM has historically collected the SNRM data to be able to make that decision from.
If DLM decides that some action is necessary, then the logical process would be to reverse the target SNRm steps.
Actually whilst typing this, I just recalled that I think that may have been what it did on Williams line.
As banger has subsequently replied, his line does indeed seem to reverse that final step - and does so quite nicely. I have been relieved to see that it seems to take this reversal step within its stride.
I imagine, therefore, that DLM has to now try to keep a green/amber/red status for each of the possible target SNRM values, so it can identify what to step back to, and for human-based (engineering centre of excellence?) intervention.
William's line was the first (visible) line that got the XdB treatment during the trial, and followed a pattern of 6-5-4-3-6. At the time, I wondered whether the step back to 6dB was a poor "undo" function, or if it was a deliberate pre-stage to see what the line was capable of at each target, rather than proper live functionality.
-
thats a horrible situation looping between 3 and 4db so the green range is too big
It might indicate a problem with hysteresis. In this case, that 1dB step is enough to get the statistics to jump from zero ES to over 1,000. What else could DLM do? Beyond learning over a longer period that 3dB seems to be never viable, and to try it less often?
@Banger's line looks good enough to hold the 70Mbps speed, but the SNRM graph is not perfect. Whatever target is set in place, the ongoing operation seems to show that SNRM can suddenly drop by up to 1dB (ie this isn't a "normal" diurnal variation).
If that imperfection ever gets ironed out, then who knows? Perhaps the line could work at 3dB ... and you'd expect DLM to try it out at some point.
-
I am happy with 70, but will just let DLM do its stuff and was wondering if it will settle on 4dB or keep trying 3dB but it looks like 3dB is on the cusp of some noise. It doesn't seem to last long on 3dB as ES goes up to 1000s and virtually zero on 4dB. Just wondering if it will settle after so many tries?
-
What actual problems is it causing? You could just ignore the stats and leave it alone.
The problem is network outages for the resync.
Thats why amber is a very large range to stop DLM moving between 2 profiles.
-
It might indicate a problem with hysteresis. In this case, that 1dB step is enough to get the statistics to jump from zero ES to over 1,000. What else could DLM do? Beyond learning over a longer period that 3dB seems to be never viable, and to try it less often?
@Banger's line looks good enough to hold the 70Mbps speed, but the SNRM graph is not perfect. Whatever target is set in place, the ongoing operation seems to show that SNRM can suddenly drop by up to 1dB (ie this isn't a "normal" diurnal variation).
If that imperfection ever gets ironed out, then who knows? Perhaps the line could work at 3dB ... and you'd expect DLM to try it out at some point.
It could learn so e.g. 3 failed attempts blacklists the line from 3db until a DLM reset. Stability is king over performance.
Notice how I didnt throw a fit when my line got banded at 74mbit, as I know it failed at 80mbit, but 74mbit is stable. I am happy to be banded as it ensures my line doesnt sync at an unstable rate.
-
How long has it been looping for? Ive tried to look on MDWS but it doesnt got back far enough.
Does the length of time before it puts you back down to 3dB increase?
EG - My line has some sort of weird noise error. It can be fine for a while then it will kick off with a high error rate for a few hours and DLM intervenes.. and then it will be ok again for a while.
What I have noticed is that each time its taking slightly longer for DLM to remove INP.
-
It could learn so e.g. 3 failed attempts blacklists the line from 3db until a DLM reset. Stability is king over performance.
In my case Im glad that it doesn't. The errors only seem to reach exceeding high rates for a few hours every month or so. I haven't found an exact reason why it should do this, but on several of them it has either been after a remote resync or a cross-talker resync.
The length of time before it removes INP is definitely increasing though, so I guess there still is a possibility that at some stage I hit a point where it may not reverse. :/
-
@Kitz my 5dB target started at 10 am April 25, and reduced every 3 days to 3dB but then went back up to 4dB and stayed up for about 12 days before trying again. Then 3dB for about half a day then back to 4 and the cycle repeats. Doesn't stay long on 3dB because of the amount of ES.
-
Yeah that would drive me nuts and make me report it as a fault, as I cannot have my line dropping out like that.
Thankfully I am banded so if this ever comes to ECI and if I stay banded, then the line wouldnt sync below 4db anyway.
-
In my case Im glad that it doesn't. The errors only seem to reach exceeding high rates for a few hours every month or so. I haven't found an exact reason why it should do this, but on several of them it has either been after a remote resync or a cross-talker resync.
The length of time before it removes INP is definitely increasing though, so I guess there still is a possibility that at some stage I hit a point where it may not reverse. :/
I think you should be banded at 67 and you keep fast path all the time then :) I see you back on fast path now synced at just under 74mbit.
Of course Openreach fixing whatever is causing the error surges on your line is the best option but I think banding is second best option.
-
DLM doesnt always work like that though. Most times if you are banded you are also lumbered with INP too... or at least for a good portion of the time. :(
With the error rate only going through the roof for a few hours per month, I would much rather DLM left me alone. By the time the DLM has taken action, the line has usually sorted itself and errors are back under control again. Its one of the reasons why I wouldnt like to be with an ISP that uses the standard profile otherwise I would be unlikely to get rid of INP.
Currently the line blips with errors for say an hour or so, it corrects itself and is ok again. Next day DLM takes action because it detected a large amount of errors for those 2 hours. Is does not take into account that error rate is back to normal. Instead I have to wait for 'x' stable days before it removes it.
Banding wouldnt help. I suspect because the errors do run into many 10's of thousands that it would still affect me if I was banded.
-
DLM hit me today, not quite sure why tho.
1 - I didnt exceed the ES rate (changes afoot on DLM systems?)
2 - was caused by a storm wide area event
Of course I agree with you on the delayed action thing, which I have always agreed with, DLM doesnt act whilst the ES are high, acts the next day instead and then delays whilst there is no ongoing problems, I expect I will be back on fast path in a couple of weeks, but of course have lost the 74mbit sync which I wont get back without another power cut.
--edit--
web browsing noticeably slower, awaiting fast path again.
-
Dropped to 5dB in Feb but it lowered again this last week. However IPProfile is not increasing as much as it should be and on the 10th the thoughput was reduced aswell causing a double wammy.
SNRM Max Sync IPProfile Throughput Date
ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ
6.3 71284 70470 (3.31%) 68.14 (3.61%) 65.76
5.3 71212 75379 (3.42%) 72.88 (3.34%) 70.52 21 Feb 2017 00:33
5.3 74032 74791 (8.85%) 68.71 (2.82%) 66.82 08 Jun 2017 14:41
4.2 77192 77899 (8.75%) 71.63 (7.21%) 66.81 10 Jun 2017 05:02
3.3 80812 79999 (7.96%) 74.1 (3.73%) 71.43 12 Jun 2017 05:16
Last time I had full sync was 2012:
6.3 81196 79999 (3.31%) 77.43 (2.77%) 75.34 26 Jun 2012
I believe max IPProfile for a G.INP enabled line is 77.35 but I'm sitting at 74.1 instead.
Not too bothered about the few meg of missing throughput but if the IPProfile is lower than it should be then DLM is getting a false reading of the line performance. I'm worried it will throw a complete wobbly if the IPProfle decides to sort itself out.
Anyone else seen their IPProfile lower than usual with these lower SNRM targets?
-
So DLM is toying with me and put my target inexplicably back to 5dB with a couple of sync loss of sync. Can't understand no disconnections ES DS is zero but US ES is about 10 a day so maybe that is why?
-
Anyone else seen their IPProfile lower than usual with these lower SNRM targets?
I missed this earlier, but the lower IP Profile percentage will probably be due to a "Retransmission High" profile rather than directly due to the lower target SNRM. See here (http://forum.kitz.co.uk/index.php/topic,19853.0.html) for example.
The DLM will not be using the IP Profile value to measure the line's performance.
-
So DLM is toying with me and put my target inexplicably back to 5dB with a couple of sync loss of sync. Can't understand no disconnections ES DS is zero but US ES is about 10 a day so maybe that is why?
Could it be that a crosstalker has been added and this is what to expect when on the Xdb profile
-
This 6-3dB target margin profile is giving me doubts about a certain VDSL modem Billion 8800 we know this modem does it's best to gain extra sync from the SNR Bits/tones, Just looking at a few 8800NL since they got 3dB the SNRM has become very spiky 1-3 dB.
It could be just me seeing something that is quite normal and yes the DS SNRM does jump about a bit on the 8800 by 0.3 to 0.7dB is the billion firmware up to the job for lower SNR target margins ?
-
@NewtronStar not sure if a cross-talker has affected it but I would expect to see DS ES if that is the case which I do see if the target goes to 3dB then ES in 1000s. But it has been quite stable at 4dB with zero ES and a fairly good sync of 71 then it all changed with sync dropping to 67 and target going up to 5. No ES for days now, strange.
I can't imagine an installation on a Saturday when the sync dropped but who knows.
-
lets see when my line go's FTTC active from a change of provider it occurred in the small hours from 4am to 5am the last one happened at 2pm so it can be at anytime.
-
I know but a new cross-talker would require a connection in the cabinet and that would most likely be in daylight hours not talking migration from provider to provider. That doesn't require physical work at the cabinet just the flick of a virtual switch as far as I am aware.
-
Remember a cross-talker is only added when a modem reaches sync and starts transmitting. It isn't necessarily when a connection is changed in the cabinet - self-install could just be when a subscriber gets home from work. And it doesn't have to be someone new - it could be someone returning from holiday. Or just getting up in the morning.
A modem reaching sync can have different impacts on other subscribers. It can cause an increase in noise, or an increase in errors, or both. Or nothing.
In this case, it isn't clear why DLM has made a change, but it might be because there was a resync the day before.
I'm approaching the XdB implementation with an open mind as to how DLM will have changed to cope, but I do expect to see some different behaviour. After all, the whole premise of using 3dB can make any line more susceptible to fast-developing changes in the environment ... so I expect DLM to have tricks up its sleeves for a faster response.
One open concern I have is this: How will DLM react if it has inadvertently made a line a little less stable - such that it causes resyncs rather than errors. I expect to see signs that DLM falls back by 1dB if it is "pressured" at all.
I can imagine a plausible method where DLM has had a hint that a line is less-than-perfectly-stable (ie after a resync), where it sets the "target SNRM" to XdB and a (new) "next target SNRM" to X+1dB in case there is a further resync.
With such behaviour, today's 5dB target might have been because there was a resync yesterday at 4dB and a further resync today.
-
yeah that can explain the instances when we see crosstalk start at odd times, as we forget self install is simply when the modem is first powered up.
-
I know but a new cross-talker would require a connection in the cabinet and that would most likely be in daylight hours not talking migration from provider to provider. That doesn't require physical work at the cabinet just the flick of a virtual switch as far as I am aware.
I believe when chaging ISP's actually involves a physical port change at the cab. Something to do with making it equivalent for each provider.
-
Changing ISP definitely involves no work at the cabinet. All the port assignment work is done remotely. Changing the port during an ISP switch would make no difference.
If the cabinet has spare capacity then even cancelled lines are left connected to the cabinet so they can be turned back on remotely.
-
Changing ISP definitely involves no work at the cabinet. All the port assignment work is done remotely. Changing the port during an ISP switch would make no difference.
If the cabinet has spare capacity then even cancelled lines are left connected to the cabinet so they can be turned back on remotely.
Then explain how people have placed migration orders only to find on the day they switch, there's no spare capacity. Their old port isn't able to be used.
It also explains why you can't change ISP if the cab is full or awaiting additional capacity.
-
@lee111s, I think you are talking about the exceptional cases, while @j0hn is talking about the usual cases.
There needs to be spare capacity at the time of the order, which has been explained away as for reasons of equivalence. Agreed.
However, I'm not sure I've come across a case where the order fails in this way on the day of migration.
-
There's no changes at the cab during migration. If migration involves one of the MPF ISPs then there will be physical changes at the MDF -> LLU Tie for telephony. As far as the FFTC goes then the SVLAN has to be remapped at the headend exchange.
>>> Then explain how people have placed migration orders only to find on the day they switch, there's no spare capacity.
I think those instances may be more to do with a failure in the SIM provide process. In order to ensure that both services go through on the same day, the gaining ISP should place the FTTC SIM provide before the MPF SIM provide.
We do recommend that you place the FTTC Provide part of the SIM provide order before the MPF/WLR Provide order to make sure that the migration of both the FTTC and the underlying WLR/MPF are matched together. Obviously, we all want to avoid the end user being without broadband service for several days (which can happen if the two migration orders fail to be matched within Openreachs systems).
>>> It also explains why you can't change ISP if the cab is full or awaiting additional capacity.
When the ISP places the FTTC provide part, I'm assuming the system doesnt know that point it will be a SIM provide and therefore rejects the FTTC provide part due to the cab being full. :/
---
ETA... wombat was typing same time as me.
-
My line has been sat on 6b SNR since the trial.
Since Friday DLM has forced a resync each day with the SNR dropping towards 3db each time. one more to go I think, hopefully.