Kitz Forum
Broadband Related => FTTC and FTTP Issues => Topic started by: kitz on October 28, 2016, 11:17:02 AM
-
Anyone got any ideas what could be causing this? Normally the line is stable.
Background.
- The line went down at 04.45 19th Oct and was off for about 15 mins.
When the line came back up it displayed spikiness in SNRm and increased errors. - Having seen on several makes of routers that sometimes after a cab caused resync can cause erratic spikes I powered down my router, but this trick didn't clear it.
- At 04.35 on the 23rd Oct, the line went down again. Unsure how long it was down for as I had no logging (http://forum.kitz.co.uk/index.php/topic,18828.0.html).
When it came back up again the line was fine and all the nasty spikiness gone. - Then yesterday morning at 04.55 the line went down and the horrible spikyness is back again. Just done a reboot of my router but its not cleared.
I experienced something similar in July after what appeared to be work on the cab. It cleared itself after a day, but in the meantime the increased spikiness caused DLM to intervene and apply Interleaving which took a couple of weeks to get rid of.
Thoughts at first were something at the cab, but Im now also wondering about the possibility of a neighbouring line perhaps getting the 'after downtime spikiness' and causing some sort of RFI REIN to my line. Possible? Thoughts? Suggestions?
-
Looking in and say it's an issue withe DSLAM was 4 hours downtime enough :-\ I have had to turn off the modem for 10 hours to get rid of oscillating SNRM in the past
-
Dont think it was a full 4hrs downtime. I had no stat logging (http://forum.kitz.co.uk/index.php/topic,18828.0.html) during that period. Whatever happened caused my router to come back up, but at times duplicate instances of HG612modemstats can cause the Zyxel to refuse telnet.
The first time it was down for about 15 mins.
Just noticed that the line is throwing lots of errors right now, so may try yet another reboot in a bit.
-
Mine is a mess also, snr seems to be gradually moving downwards with attinable going down 200kbit sync/day.
My engineer confirmed the day I had the crosstalk introduced someone had a pair swap as their line rate had dipped extremely low, he says there is another 6 pairs that are going to be swapped as they got very low speeds and one of them may affect me. The cabinet is still full with a waiting list.
-
Not that it helps but I have lost 12mb on my ds sync over the last 3 months. Last resync cost me near on 4mb. Cross talker effects could be seen clearly on the snrm charts.
-
The erratic spiking is still ongoing. Admittedly Ive not raised a ticket because unsure if Openreach would do anything and TBH Im not sure if I have the will or time to battle with PN CS right now.
However tonight has been terrible trying to access the net and everything was really sluggish. I happened to look at my errored seconds.
Ooops DLM is really going to hammer me tonight.
Interestedly I noticed next door had Openreach out about 2 weeks ago. Unfort I had an appt so dont know what happened, but since her line was fixed, mine went downhill slightly more :(
---
ETA
Looking at my stats the errors started bang on 3pm and were averaging 18/20k CRCs per min.
Hard to check my Er/Secs as Ive rebooted to try get a bit more SNRm, but my total is about 20k :( Dont think DLM is not going to spot that.
-
Hello everyone,
This probably has no correlation to kitz's post but...
I noticed earlier this evening around 10PM-ish, that my upstream SNR is low at 4-4.1 db but my downstream is fine at around 6.5-6.7 db
That's a bit of a drop, both downstream and upstream are usually identical. I don't know when it plummeted for me and hasn't budged since. I usually check my stats once a day. It was fine yesterday.
I checked the landline for any noise and it was fine. I only have a HG633 supplied router from TalkTalk but it's been fine SNR wise up until now.
The low upstream SNR hasn't budged since. My max upload data rate says 18Mbps despite the fact I'm synced at 20 Mbps according to the stats- I'm confused. :-\
It doesn't seem sluggish to me at all (Luck?), I wouldn't have noticed if I didn't check my router stats and so far no re-syncs. :fingers:
My fibre cabinet is full too. (ECI)
Thought I'd add my experience into the mix.
-
>> It doesn't seem sluggish to me at all (Luck?),
This was what was causing my sluggishness - A large amount of errors that started at exactly 3pm.
Browsing was excruitonatingly slow and pages would take a long time to load. It was extremely noticeable and like being on dial up, you couldn't not notice it. I had in excess of 20k Errored Seconds, so I am fully expecting the DLM to do what it does some point before tomorrow lunch time.
This originally started after an over-night outage where I had no sync for about 15mins. Prior to that the SNRm would practically be a nice straight line with a very occasional shift in SNRm of a fraction of 1dB.
Now it can spike anything between 3db. Its behaviour is very pulse like. I attach a graph below which whilst only showing small fluctuations in the downstream, you can see the pulse effect quite clearly on the upstream. Sometimes its way more jagged than this, but I chose this snapshot because it was during a period whilst the line was more stable but you can see how regular the oscillations are.
This isn't really what I'd class as typical REIN behaviour, there's no sharp drops at certain times. It's not SHINE, it could possibly be PEIN. I guess I need to go buy a radio. There's nothing that switched on here at 3pm. In fact the only thing that would have been on at that time would have been the PC. Neighbour is away a lot, all I know is that she only has adsl2 and couldnt get sync for several days. My own line was more stable during the period she didnt have sync but it could just be co-incidence that mine started acting up again after hers was fixed. Occasionally it will clear when I reboot, mostly it won't.
The thing is it seems stable now, but DLM will still kick in regardless, just like it did last time.
-
I feel for you Kitz, if you read my post, my line has also recently been effected and after 10 days it recovered.
There seems to be a trend of ECI uses suffering from similar problems.
-
yes - look at the last couple of days on my eci line.. Fuzzy snr with wild swings in both ways it seems..
very poor attainable.
-
@skyeci - Yes your line behaviour with the SNR does seem similar to mine. Notice that you are also getting the spikyness and quite high error rate. Your atten is 14.3 so slightly longer line that mine, but not fantastic sync speeds for the length. :/
@Josh - remind me of your username on MDWS please :)
-
@skyeci - Yes your line behaviour with the SNR does seem similar to mine. Notice that you are also getting the spikyness and quite high error rate. Your atten is 14.3 so slightly longer line that mine, but not fantastic sync speeds for the length. :/
Openreach have been and investigated the eci cab again, at the moment they can't seem to sort it out. They changed a card and added a card and it made no difference. Several port swaps but still no good. In fact if anything its worse that it was before, don't seem able to figure out why the attainable is so poor and why the snr is dipping low as 4.8. My line has always suffered with high es. I am now in contact with someone directly at openreach who is trying to find out what is going on (has been for a couple of weeks). Back in june the sync was up to 77mb when the cab was repaired (as I was told), this has gradually gone down ever since. Even though I am under the sky advised minimum (just) they have washed their hands of it and closed all issues I raised..
I wonder if g.inp was re-enabled it would help.... I have asked if he could get it re-enabled just to prove it if helps my line as it did before it was switched off. Seemed like a no.. :( :(
I am waiting for further news but its not looking good right now
Wife and I thinking of moving next year to another local town which is all Huawei kit thankfully, very tempted I can tell you.. :-\
up and down like a yo-yo this morning
-
>> I wonder if g.inp was re-enabled it would help
Possibly, although I doubt it would help with the amount of errors that I got yesterday. I notice that you too are constantly hovering close to the limits.
I know that since this has started, Im at amber most days - its one of the reasons why I am loathe to swap to an ISP that uses Standard rather than speed. As expected, DLM took action this morning and applied INP3 so Im now syncing at 70Mb, but my upstream is still spiking.
-
Have been amber across all the profiles on the ds since march lol..
Sky released me but dont see the point of moving as its the same cab/copper etc... apart from being on speed instead of standard plus I do really need my fixed ip...
-
how do you know it isnt just bad crosstalk ? This is to skyeci.
I am running on a 4.6db snrm, my attainable is down, it went up again last week, down again now, but I havent raised a fault as it is in all likelyhood some new crosstalk that I have to deal with.
I am trying to hold out until march on this sync and hoping g.inp is incoming around that time. Then a 3db profile will at least recover what I had 6 weeks ago.
-
Only because the report came back that either this was card/harness and or cables between the cab and pcp. There is some distance between the 2 which is odd as most are close by. One of the engineers suggested the cables were reversed/mixed. Out of the 10 ports tested last week not one of them would provide 80mb at the cab which so I was told needed to be resolved..
I do feel now though this is a lost cause in getting it resolved only due to the length of time its been going on. Who knows maybe the cables between the cabs are damaged. They must go under the road surface and 2 pavements perhaps...
-
I powered down my router for half an hour at 4AM this morning hoping it would help maybe...It didn't. I lost 2Mb on my upload and 1Mb on my download. 18/69 from 20/70 sync.
My SNR on my upstream and the downstream are spiking between 6-7 (Both) - Up until recently were stable and barely spiked. Max attainable is just over 21, so in theory I could get my full 20Mbps sync again.
Guess it could be crosstalk. I would guess the SNR spiking/jumping ECI oddities some are talking about are what I'm seeing.
I have no knowledge at all on this stuff. Just assumptions is all. ::)
-
Hi
Cross talk will reduce SNR but usually it's a consistent reduction, not an up/down.
To Kitz, it wouldn't surprise me that some fault is causing someone's connected modem to sync/drop/sync/drop etc and they are a disturber with your line. Perhaps the downtime was due to some fault that caused damaged to one or more modems, and of course the ISP, if they've complained because they can't get online at all as the modem can't sync correctly, will of course told that person to leave everything connected.
Hopefully it will resolve itself soon. Oh for a future on fibre to the home where we should be rid of these issues. VDSL/ADSL is such a flaky technology.
Regards
Phil
-
@Kitz
Sorry for the late reply, just got off work. I am not in the position to monitor my line at the moment. The laptop I was using has packed in, I have ordered a long Cat5e cable, so will get things up and running soon.
What I can tell you is, being at this property almost a year now, it's normally perfect and my line seems stable most of the time, when I have monitored the connection, I have had very little errors and always been in the green.
I get spikes as you do and this causes DLM to interleave, it normally recovers after 10 days, I believe in the last 10 month DLM has taken action 3-4 times and that's it. But it seems to be totally random.
I know this doesn't help much as without any stats to look at and monitor it's hard to diagnose. But I believe I'm in a similar boat to you, and hope your line recovers soon.
-
I have been watching and following the events regarding Kitz' erratic line behaviour.
The very first case of SNRM oscillations was brought to my attention a couple of years ago. (If I am remembered correctly.) At that time, the only suggestion I had was to power-down the modem and disconnect it from the circuit, leaving it in that state overnight. Next morning, when the modem was reconnected and powered-up, the oscillations were gone.
I am, of course, referring to N*Star's circuit and as that circuit is connected via a Huawei MA5603T, not an ECI M41, the "solution" may not be relevant to Kitz' ongoing problem.
-
Hi Kitz
How odd, I was doing a quick Google on flapping VDSL SNR and came across a post in this very forum and to my amazement it was my own post with a very similar problem, and I had completely forgotten about it!
http://forum.kitz.co.uk/index.php?topic=13901.0
Regards
Phil
-
Hi
Cross talk will reduce SNR but usually it's a consistent reduction, not an up/down.
True but when the Crosstalker turns off their modem the effected users will see a sharp rise in SNR by 3-4 dB if that is your major one and a drop of SNR once the crosstalker turns on their modem
-
Guess it could be crosstalk. I would guess the SNR spiking/jumping ECI oddities some are talking about are what I'm seeing.
Crosstalk doesn't cause SNRm spiking. FEXT is a constant source of noise that will remain static as long as the disturbers line is synchronised.
Whilst it does affect SNRm - it reduces the Signal to Noise ratio - you only really see the affects when the other party connects/disconnects.
When they connect, the effects of FEXT are that it reduces your signal strength. Think of it like someone turning the volume down on your TV.
Sharp spiking is most usually some sort of EMI/RFI or occasionally a high open type line fault.
The very first case of SNRM oscillations was brought to my attention a couple of years ago.
SNRm oscillations are sometimes a 'feature' when a line has suddenly lost sync, most times it will occur after a power cut/power surge.
Its not unique to VDSL and can also occur on ADSL. Its been something I've been aware of for many years dating right back to the very early days of routerstats when I had a BT Voyager2100 so that has got to be well over 10yrs ago.
It would always occur after a powercut my end and it could randomly occur if something caused a remote sync. 99 times out of 100 a router reboot would fix the issue.
With the advent of VDSL I saw it also happening on some lines so even before I myself had fttc, I started suggesting to do a full power down of the modem and a new fresh resync and again this usually fixed the problem. I've many times over the years suggested a reboot to see if it fixes it.
I think because now we have MDWS we are more aware of it, back in 2005 there were very few people who ran routerstats 24/7 to see this happen. We also seemed to have far less remote syncs with ADSL than VDSL. BT would install a MSAN and it would remain untouched for many years unless there was a line card problem, but the MSAN itself would keep going.
-------------
My current issue though is different. Although it very first started after an exchange type outage, it does not always respond to a modem power down. Nor does it always take a resync to trigger it. There was no valid reason why the error rate should have shot sky high at exactly 3pm yesterday. During those periods, using broadband is difficult. Such high rates of errors mean that even just browsing is difficult.
I am now interleaved and have INP but thats just really masking things. I can see that the SNRm spiking is still there and I can see I am getting high peaks of FECs - far more than would be considered normal - see below for a bad one at 10.45 yesterday.
My QLN shows differences too. Theres been a change of floor level and its more spikey. The U2 band has changed shape.
The first graph shows signs of crosstalk in D2, the 2nd graph its masked by the spikeyness. D3 appears worst affected, although not confined soley to it.
Hlog is fine - possibly something going on at around tones 3300-3800 in D3 but its not anything that would cause undue concern.
HLog Floor level remains unchanged which is why I dont believe this is a physical line issue and instead its noise being introduced onto the line.
Since it started Ive gone from a stable 84Mbps attainable to now 70Mbps interleaved without any of the normal signs that would indicate crosstalk.
Also I think its highly unlikely that an engineer is going to be connecting a new user at 04.45 in the morning and causing me 15 mins downtime.
As I type this, according to DSLstats, my upstream SNRm is pulsating between 12.5dB and 8.2 dB.
btw, spoke to my neighbour last night, she says her problems started the same week as mine. She doesnt monitor but had noticed a reduction in speed, which continued to drop until she had no sync at all. Being she's with Sky they first sent out one of their own engineers to test her internal equipment, then decided to send Openreach.
She doesnt know what they did to fix it other than it was an external fault not in or on her premises.
VDSL/ADSL is such a flaky technology.
You aint wrong there.
-
I really don't know what to make of it. :-\
Thinking in terms of electronics, it is rather like a negative feedback automatic gain control circuit that has managed to get into an oscillatory state. :hmm:
Looking at the current 24 hours plot of the SNRM, we can see two distinct phases of the effect. That before 0730 hours and that after 0730 hours. :o
-
Openreach have cleared at the moment my spikey snrm on up and down which was much like kitz's - they ran a series of remote resyncs. The last one out of 7 seemed to clear it with it holding for now...sync rate still lower than it was though..
-
My upstream has yet again dropped to 4 SNR whilst the downstream remains fine. My upstream is connected at 20 but due to the low SNR, next resync will lower it.
A day ago my router did resync and I've been stuck on interleave since. Lost download speed but regained upload again...It's just doing a yo-yo at this point.
According to the HG633 the interleaved depth is 1877 but my upstream is fine at 1.
I don't get it. It was all smooth until recently. I don't understand it at all. ???
-
I had a similar snrm a couple of years ago but it only occurred at dusk and stopped at dawn. It seemed to coincide with an Xmas shop display and its flashing lights. It lasted for about 2-3 months. I guess lots of things could cause such issues.
-
Sorry if I appear to be swamping kitz's thread with my inept understanding of this whole thing. At least I'll learn something out of this.
This is only my second time being interleaved this year so I've been very lucky to have such a good line overall.
I was thinking perhaps Christmas lights would be a factor for me. But no one around my street nor shops has the typical flashing lights on display currently.
Taking a longer look at my stats as I'm typing this I noticed:
That my upstream SNR is staying static at 4.2 with a max attianble of 18 (Again) currently synced at 20.
My downstream SNR staying static somewhat at 6.5-6.8 with a max attainable of 91, currently synced at 64.
It's like my TalkTalk router isn't updating the fluctuating margins. Nor maximum data rates (Downstream never changes, Upstream varies maybe 0.20 Up/Down)
The other night my SNR margins for both were updating normally and doing those spikes/jumps. Maximum data rates were changing with them as expected
Is this an ECI issue maybe?
All I can take from this is that this isn't typical line behaviour for me...Probably not for you guys either.
Apologies for my lack of knowledge/ramblings, it flies over my head all of this. :-X
Stats from my HG633:
DSL synchronization status:
Up
Connection status:
Showtime
Upstream line rate (kbit/s):
20000
Downstream line rate (kbit/s):
64686
Maximum upstream rate (kbit/s):
18792
Maximum downstream rate (kbit/s):
91512
Upstream noise safety coefficient (dB):
4.2
Downstream noise safety coefficient (dB):
6.6
Upstream interleave depth:
1
Downstream interleave depth:
1877
Line standard:
VDSL2
Upstream line attenuation (dB):
0.1
Downstream line attenuation (dB):
6.7
Upstream output power (dBm):
2.5
Downstream output power (dBm):
13.4
Channel type:
Interleaved
DSL up-time:
1 day 12 hours 43 minutes 10 seconds
-
Nope its not typical behaviour at all, I'm not certain about it being the ECI's but it does seem like we've had a few similar of late.
Mine isnt related to xmas because of when it started.
Just to eliminate the VMG8324, I managed to get a VMG1312-B10D on ebay for £10.50 (different chipset).
Ive set it up this afty and unfortunately the problem is still there. Downstream stats are similar, upstream is less, and still seeing the spiking. :/
-
Oh blimey kitz, bad luck there. :no:
I was thinking of buying a new router/modem to replace my supplied HG633 but it looks like it won't make a difference.
The only connections I can make is some of us on ECI DSLAM's are seeing weird issues like sync speeds, snr, max attainable etc out of wack.
Hopefully there will be some resolve soon, it's annoying as we all know our lines are capable of much better. The fact these oddities are alien somewhat and popped out nowhere is a chin scratcher.
Interleaving is an add insult to injury for me as I'm a gamer. :'(
With you guys that are seeing these issues where are you located? I'm up in the North East.
I doubt locality will help us resolve the problem but may see if it's widespread or just dotted around the UK.
-
Well my line I think I wont hold out until g.inp time, it seems the modem has hit its fit stage with 95 days uptime (no longer responding to lan requests).
Regarding your line kitz I see two things.
1 - you seem to have a new crosstalker who turns their modem on or off, or electrical interference on and off.
2 - A secondary issue causing rapid minor fluctuations. No idea what that may be.
#1 issue is also affecting my line for about 7 weeks. Interestingly for my self tho when the crosstalk temporarily disappeared my attainable went higher than what it was 2 months ago.
--edit-- my modem is fine actually, was issue on my laptop with locked stats process.
-
I dont see any new crosstalkers. Since it first started though, Ive been DLM'd twice. Ive have also done lots of manual reboots to see if I can clear it. If you're looking at the SNRm, then any straight jumps is usually me trying to bring my SNR back up to stop errors......
Or me losing sync, like I just did whilst typing this. Thats not the first time today that my line has resync'd that was not my doing.
Scratch that, I dont think I really lost sync. Saw something on MDWS that said I hadnt uploaded, and DSLstats was flashing like it usually does when Ive lost sync, but I think it may have just been that data wasnt sent to MDWS on that occasion.
-
Hey guys,
I've came back home this grand very early (Lovely night shifts) morning. To pleasantly see...
Nothing has really changed since. I did a few manual reboots as I was bored and couldn't sleep. My downstream interleave level did drop from 1877 to 1863 . My upstream interleave level stayed at 1.
Sync is at 64/18.
Max attainable for downstream: 90 is a far cry for me. Probably due to the downstream interleave.
Max attainable for upstream: 18. The upload has been flaky for me since this issue.
Noise margin for downstream: 6 (Spikes from 6-6.5 sometimes 7)
Noise margin for upstream: 6 (I have seen it go to 6.1! Maybe a good sign?) I won't be surprised if it dropped back down to 4.2 again. I just expect it.
I'm seriously under the impression that my ECI cabinet is borked in some way.
^^^ That's my ahem..."Professional" opinion. :cool:
-
Well Im afraid the VMG1312 didn't last very long on my line. The underlying issue was still there so it proved a point that it wasnt my equipment. For some reason it looked like I kept losing sync approx every hour or so. Whilst I did drop sync a few times, that hourly thing may have been more to do with logging and failing to upload to MDWS. However that doesnt detract from the fact that I genuinely did lose sync several times that day.
Looking at my stats, errors were much higher with the VMG1312 despite the lower sync. I've always maintained that for my line the VMG8324 gives me far better speeds and a lower line rate, so this fact may not apply to all lines. The VMG1312 is still a bargain price router that probably performs better than some others out there. Its one of those suck it and see what works best for your line situations.
Anyhow after yet another resync I'd had enough. I left the line disconnected for a couple of hours because I was now on about my 8th sync of the day... and put the VMG8324 back on... and low and behold the vast majority of the spiking had disappeared.
Now over the past few months I have disconnected and I have powered down the modem for a period of time without any effect.
One thing that does spring to mind.. can some of you guys recall about ummm 7 yrs ago when there was a bout of faulty line cards on some MSANs which would cause some lines to flap. (Azzaka will definitely remember)
I'm wondering if theres been some (software) config changes to the line cards (why else would they disconnect for 15mins at 4am) that is making some lines flap. No proof - just another possible theory. The line is still spiking, but its less than 0.5dB and no where near as bad as what its been like for the past few weeks. Upstream is still messy.
-
@ DMZ
Ignore max attainable if the line is interleaved. RS overheads affect the max attainable speed, so the figures are unreliable.
Just out of curiousity if you can, try leaving the modem disconnected for a few hours.
-
Powering down the CPE, disconnecting it from the line and leaving it in that state overnight is something that I will recommend as a "last resort". Allowing the port on the line-card to "relax" does seem to help . . . in certain situations. I know that N*Star will agree. :)
-
Hey kitz,
That's a better result. Great to hear.
I did reboot my router again in the afternoon. The SNR is now 6+ for both, no longer spiking much nor has the upstream dropped to 4 again.
My upload returned to 20, max attainable is now 21+
My download seems banded at 64 still, max attainable now 90.
I know I shouldn't focus on the max attainables like you said. But my stats look better for me so far.
According to my HG633 stats:
Upstream Interleave Depth: 1
Downstream Interleave Depth: 1865
I think my downstream is in fact banded since my upload has returned. Looks like I will need to wait maybe.
If anymore issues arise I will turn it off overnight. Thanks for the tip.
It looks like we both have improvements today just having issues with opposite streams. My download, your upload and interleaved. ;D
-
As I have been diagnosing issues on my modem monitoring (hg612 stats crashing due to experimental security config) I have caught my line red handed with its attainable rate shot up (currently 74mbit), is tempting to do a resync but I think when it drops again to 66-667 that would be pushing the line stability wise.
-
Hey everyone, :)
@Chrysalis I've given into temptation in the past and 99% of the time it results in; "I think I made it worse." Territory.
I've been tempted to keep rebooting my router "In hope." I can get off interleaving. But I've left it be. As DLM works when it wants to from my understanding.
So far it's been up 4 days due to automatic firmware being downloaded and rebooting my router.
My problematic upstream has settled at exactly 6dB with an occasional swing to the lowest I've seen at 5.8dB, highest 6.1dB. Downstream is fine as usual.
I think I should have left everything alone when it first appeared (Low upstream SNR.) as everything was still stable on fastpath. I did restart, reboot and swap routers around. I'm probably at the state I'm in due to my own faffing around.
And saying that before and after it was always stable, I rarely ever have disconnections. I guess I'm lucky to have a good line even with all weirdness recently.
My line length is only 6.6; It's quite short. It's only up the street and around the corner from me, I can follow my line directly to the DSLAM. ::)
-
Powering down the CPE, disconnecting it from the line and leaving it in that state overnight is something that I will recommend as a "last resort". Allowing the port on the line-card to "relax" does seem to help . . . in certain situations. I know that N*Star will agree. :)
Being a retired HW/Sytems Engineer I have always been very sceptical of this theory. However a few months ago totally out of the blue one Saturday morning around 10 ish my upload snr began wildly fluctuating resulting in resynch with upload down to 1 to 2 Mbps (usual 11 to 12 mbps solid). A manual reboot would resynch at the usual rate for a few mins before again wildly fluctuating before resynching at the low value. This behaviour persisted with my usual Draytek 2760, an HG612, and a HH5A, throughout Sat and Sun. I went to bed on the Sunday night resigned to taking on BTs CS the following morning, so switched off the router pending a fresh start before making the call. Well, the problem completely cleared overnight with the router powered off and has not returned in the last 4 months. So I think I am now a convert! ECI cab by the way.
-
So I think I am now a convert!
The situation must have been just right. :D
ECI cab by the way.
Not the best but better than nothing . . . :(
-
Back to the low to mid 5s on my upstream. I feel it will drop to the 4s again. It's fluctuating. Still no audible noise on the landline.
What's the correct procedure to the overnight power off? I assume just turn off the router's power button and turn off the mains?
I don't know if I should wait out DLM as I'm still interleaved...Choices. :P
-
My was only it temp fix that lasted about half a day before it started playing up again. At least I know its not the VMG8324.
I just powered mine down using the off switch on the back. Then I unplugged it from the mains and pulled out the modem cable from the master socket.
-
Hmm . . . I've debated whether or not to mention the following . . . :-\
We know that the DLM process does not take any note of a modem's "dying gasp" but the MSAN most certainly does.
As the "power off overnight" technique was conceived in an attempt to clear "oddities" of the circuit's behaviour, it is recommended that the best practice is followed for the shut-down. So, as Kitz has mentioned, power off the modem and disconnect the patch lead connecting the modem to the external line.
For the "best" "dying gasp", just remove the PSU from the mains socket. The smoothing capacitors in the PSU will allow the low voltage to decay slowy and, thus, give a slightly longer "dying gasp". (It may only be a few ms but as a certain supermarket's slogan: "Every Little Helps".)
-
Oh dear kitz I was hoping it would have helped out more. Mine lasted just under 4 days before it started again.
Thanks guys for getting back to me anyhow,
My HG633 supplied by Talktalk is an all in one router/modem. I assume that process still applies.
I will do this soon and thanks again. :)
-
My HG633 supplied by Talktalk is an all in one router/modem. I assume that process still applies.
Yes, indeed. :)
-
Thank you. :)
Here's hoping this can help me. :fingers:
If it comes back with vengeance I will kick the ECI cabinet when I pass it. :lol:
-
My line is certainly taken hostage by DLM's interleaving:
Downstream Interleave Depth: 1858
Upstream Interleave Depth: 1
My actual downstream sync is: 64.020
My actual upload sync is: 20000
Upstream SNR: 6dB
Downstream SNR: 6.5-6.8dB
I again think I will be dropping below 6dB SNR eventually as my upstream SNR won't budge above the target SNR of 6.
I'm not taking into account of maximum data rates as I'm still interleaved.
The downstream interleave depth has dropped from 1865 which is a small start.
If anything (Too early to tell.) it hasn't made much difference. Downstream sync is slighlty less than it was before.
I will have to shake off interleaving if that's even possible. Up until last week I was on fast even when I was on 4.2dB.
As previously posted I should have not messed around as much as I did. As it's caught up with me.
Looks like I'll be in the same boat as kitz eventually. Whatever is causing these silly issues, I wish it would go.
We might just have to wait it all out. For me; getting off interleaving would be a BIG start, the SNR stuff...I don't know anymore.
Thanks again anyhow for the tips guys. :D
-
The interleaving depth dropping from 1865 to 1858 is not significant, and does not indicate that the DLM has reduced the interleaving depth. The exact interleaving depth, and the other framing parameters, and the exact speed, are likely to vary slightly each time the DSL connects. The DLM will set in the line profile a minimum INP value, and a maximum delay, and then it will be for the modem and DSLAM to work out the exact framing parameters (such as the interleaving depth, block size and amount of FEC data) to fit the INP and delay constraints while maximizing the bandwidth.
-
@ejs Thanks for the detailed reply. That makes more sense. :)
My upstream SNR is dropping again below 6dB. Downstream SNR still fine.
I'm kicking that cabinet now...
-
I see kitz is now back on fast path :) but at a lower sync speed previous to the mess on her line.
94 ES in 6 hours, so providing the ES rate is steady it shouldnt get DLM'd again.
SNRM is still very erratic.
-
doh! - back to oscillating snr today...hope it clears as quick as it came..
-
I see kitz is now back on fast path :) but at a lower sync speed previous to the mess on her line.
Yep. Prior to this mess starting my attainable was something like 83Mbps. Now interleaving has been removed Im currently syncing at 76Mbps, but my SNRm has gone down again so if I did a resync now I'd only get about 72Mbps.
My upstream is oscillating quite badly between 12.2 and 7.8, but I doubt Openreach would do anything because the upstream is still syncing at 20Mbps.
-
The behavior is very odd and puzzling. Currently apart from the snrm wobbles the line looks fine and it hard to say whether your reduced speed is the ever increasing crosstalk with FTTC take up of something else. When you had the error burst and went interleaved it looked like a real and severe impact but now it is just puzzling. I had severe error and snrm wobble response from xmas lights but not wobbles without horrendous errors, as you now have. Have you tried a very different modem like a HG612 and different PSU? Sampling with dslstats separate from MDWS at about 5s rather than 60s might show if the apparent 5-6mins frequency is an aliasing effect.
-
Great to see DLM let you go kitz!
I'm still stuck on interleaving, how long did you have to wait for DLM to release you from interleaving?
I understand it varies from line to line, my uptime is 7 days, 23 hours - Nearly 8. At least it's been stable. Guess I'm lucky.
After all of this I wish I never messed around with my router in the first place. I bet it'd be fine this very moment if I ignored my stats that night...
I miss my fastpath. :'(
-
The behavior is very odd and puzzling. Currently apart from the snrm wobbles the line looks fine and it hard to say whether your reduced speed is the ever increasing crosstalk with FTTC take up of something else. When you had the error burst and went interleaved it looked like a real and severe impact but now it is just puzzling. I had severe error and snrm wobble response from xmas lights but not wobbles without horrendous errors, as you now have. Have you tried a very different modem like a HG612 and different PSU? Sampling with dslstats separate from MDWS at about 5s rather than 60s might show if the apparent 5-6mins frequency is an aliasing effect.
The oscillations and drop in SNRm happened at about 4.30am after an outage of 15mins, so I doubt that at that time it would be a new crosstalker coming on line - nor would it account for the outage. Hence the topic title.
I bought a new but ex-Zen VMG1312-B10D on ebay to see how a different chipset performed. I didn't leave it on very long as the sync rate was lower (quite a lot on the upstream) and the error rate was higher. At least it ruled out the VMG8324.
I havent tried changing the sampling time as I have DSLstats running in compatibility mode. However I shall try it and see what happens.
Re errors - The line is running on amber E/Secs most days. It reaches amber MTBE for Standard profile by about 3-4 pm, and usually towards the end of the day for Speed MBTE although sometimes I may scrape through on green on the odd occasion. If I was on Standard profile, rather than speed the chances are extremely high that I would be permanently interleaved. I've tripped red a couple of times since this very first started.
how long did you have to wait for DLM to release you from interleaving?
Cant recall exactly as I have other stuff on and dont watch it every day. I think it was 10 days but I should be able to tell from MDWS.
----
ETA - Nov 29th to Dec 14th so thats 16 days.
I note you are with TT who use Standard profile. I'm with Plusnet who use Speed profile.
I was considering changing ISPs a few months ago, but I know that if I went with an ISP who used Standard then most likely I'd permanently trip the interleaved status.
-
Thanks for the clarification. From MDWS you lost most speed back on Sept 2 with what looked like cross talk. The wobbles in snrm started Oct 19th and have gone and then returned a few times since. The wobbles only seem to a give slight extra attainable reduction but about 5 times the errors and they, as you say, don't seem to be associated with a cross talk change. It may be worth trying the very different HG612 modem but I agree that if two modems work it is not likely a modem fault. If you used the same PSU when you changed Zyxels that PSU would be worth changing.
-
Seems I'm in a bit of a pickle if a standard profile won't revert back after being interleaved.
It's happened once before with TalkTalk and eventually went back to fastpath, back then I checked my stats a couple of times a week unlike now.
I will just have to sit tight and wait it out then. :fingers:
-
@les-70. Thanks for your input
The reduction in sync on 9th of Sept does indeed look like crosstalk and I accepted that. However it did come back up again to 80Mbps on Oct 5th after I did a resync after noticing I had surplus SNRm It stayed sync'd at 80Mb with 5.5 SNRM until the Oscillations first started on Oct 19th at 04.45am.
I know is several pages ago now but the times are documented in my first post (http://forum.kitz.co.uk/index.php/topic,18830.0.html) and how the spikiness came, then went after more down time. Then the spikiness re-occured after a remote sync that occured at 04.55am on the 27th and this is when they became permanent. The oscillations do certainly not appear to be related to crosstalk.
may be worth trying the very different HG612 modem
Unfortunately I dont have it atm after lending it out to someone on a Huawei cab that was given an ECI modem by Openreach at the beginning of the year when they got vdsl. I could get the HG612 back if need be, but I cba going round to swap it out with something else. Hence me picking up a VMG1312 to test with.
If you used the same PSU when you changed Zyxels that PSU would be worth changing.
Yes I swapped out the PSU and even the modem lead. Modem is sited right next to the SSFP. I have no internal wiring at all now.
Quiet Line Test seems OK when tested with both my cordless.. and an old corded phone.
Sampling with dslstats separate from MDWS at about 5s rather than 60s might show if the apparent 5-6mins frequency is an aliasing effect.
As you suggested Ive just done an hours worth of logging every 6 seconds. The oscillations are definitely cyclic and occur every 5 mins 30 seconds. - See below.
I've attached break downs of both upstream and downstream tones, showing that U2 is the most severly affected.
I had previously noticed that it only affected D1, D2, D3 and U2 but wasnt quite sure what to make of that. Obviously though both U0 and U1 have PSD masks applied.
Ive also included the graph showing effects of the oscillations on my sync speed which is 68Mb to 76Mb.
-
I can't think what might give such a strange and regular impact. ??? In desperation i would be inclined to wonder about powering down each evening and up again in the morning. If that does anything is would seem that it must be the DSLAM or your equipment.
-
I'm back onto fastpath after 12 days. I am seeing snr spikes/jumping of 0.5dB on the downstream, upstream seems ok.
I'm happy that DLM was kind enough to give me my line's potential back. Downstream jumped from 64Mbps to 68 Mbps.
Perhaps there's room for more improvements in future for my line.
-
My line resync'd by itself at exactly 8am this morning. When I saw the notification email and because I dont look everyday at the stats but know Ive been sailing close the the wind for MTBE since this started, my first thought was DLM and interleaving.
However, it wasnt DLM nor has there been any major f/w updates still on xx206. The line is still showing the cyclic oscillations, but now they are negligable on the downstream 0.1-0.2 dB and about 1dB on the upstream which is a heck of a lot better than the previous 3dB down and > 6dB on the upstream. Rather curious why a remote sync should occur at spot on 8am which has cleared a lot of it. Errors are still higher though than before this started in Oct and I dont appear to have regained the lost sync.
I very nearly submitted a ticket to PN a couple of days ago as the error rate was quite high one day - noticed because I was trying to stream something and it kept buffering. A speedtest to TBB gave me a ridiculous 1.57 Mbps, but just as I was typing something out my speed came back up. It was late at night and outside any times I'd expect to see congestion, so Im assuming it was the E/Secs that was affecting it. I was half expecting to be DLM'd but I must have just scraped through by the skin of my teeth.
Anyhow whilst not perfect nor as good as it was, it is better than it has been for many weeks. I doubt it would be someone taking their deco's down either at spot on 8am as I dont see that would cause a resync.
-
SNRM oscillating is still there it just has less amplitude since your last resync so the line card fault is still there it won't go away unless you get moved to a different card or the faulty line card is renewed :hmm:
-
Yep. I don't know if I have the will to battle PN and Openreach though over it. I know they will say its performing within acceptable parameters (ie the figures quoted by BTw) and that was even the other night when things were bad to the point of the buffering a prog I was trying to watch :(
Its even less likely they would act on these lower oscillations. All I can do really is monitor. It's not anything here, but the fact it stop starts after remote syncs Ive no idea. The only time Ive seen anything remotely like this is a batch of faulty line cards that were on some adsl MSANs about 7-8 years ago which caused SNRm flapping.
-
I completely understand and don't like calling my ISP to report faults but they are there to help if they can and the phone call is free it's the Openreach side that cheeses me off, they come and do a number of tests and pass the line as ok.
Well I have had 63 modem resyncs in 15 days with Vodafone and made two fault reports in each case they wanted to send a engineer but I declined saying it was not a line fault but it was the modem and the ISP, Imagine if move back to EE and the resyncs are still occurring I am going to look very stupid by not giving them a chance to fix the issue.
-
kitz you look well within DLM limits, unless they have reduced them in recent times.
-
The line is still showing the cyclic oscillations, but now they are negligable on the downstream 0.1-0.2 dB and about 1dB on the upstream which is a heck of a lot better than the previous 3dB down and > 6dB on the upstream.
I always have a "default" circuit to monitor via MDWS and with N*Star's absence, as a result of the (now cancelled) Vodafone service, my default has been your own circuit. The resynchronisation event and the following reduced amplitude oscillations were noticed earlier today. It is definitely better than the recent past -- on one day I measured a peak-to-peak swing in the US SNRM in excess of 6 dB -- but it is still not correct. :-\
-
kitz you look well within DLM limits, unless they have reduced them in recent times.
Its ok today, but thats after whatever happened this morning. Im currently showing amber, amber, green for MBTE. (stable, standard, speed) .
Since it started there have been quite a few days when Ive looked at the traffic lights and theyve been red, red, amber or red, amber, amber.
I've mentioned it several times that it was one of the reasons why I wouldn't want to migrate to an isp using standard profile or I'd find it difficult to get de-interleaved. I was last interleaved in Dec due to the higher error rate, but luckily it did relent after a few weeks.
Must admit that I don't look every day, but before this started it used to mostly be green, green green. Hence me saying quote "Errors are still higher though than before this started in Oct"
-
Its ok today, but thats after whatever happened this morning. Im currently showing amber, amber, green for MBTE. (stable, standard, speed) .
Since it started there have been quite a few days when Ive looked at the traffic lights and theyve been red, red, amber or red, amber, amber.
I've mentioned it several times that it was one of the reasons why I wouldn't want to migrate to an isp using standard profile or I'd find it difficult to get de-interleaved. I was last interleaved in Dec due to the higher error rate, but luckily it did relent after a few weeks.
Must admit that I don't look every day, but before this started it used to mostly be green, green green. Hence me saying quote "Errors are still higher though than before this started in Oct"
My line is amber all the time not been interleaved for ages
-
my noisy eci line is always amber, amber, red by the end of each 24 hour period these days.
ES have risen lately but still holding on to fastpath. Probably not helped by my attainable being 3-5mb under sync which is always the way it seems..
-
I think everyone who has gone interleaved via errors and not resyncs has achieved a daily total of more than 2880/1440/720 depending on whether they were on speed/standard or stable. If your on fast/speed profile amber for fast is one tenth of the error rate needed to go interleaved. I think it is best to just worry about the red values. If your on fast/speed then red for stable is probably OK but red for standard mean a margin of less than 50%. If on speed/fast it might be useful if MDWS could email when the ES/day first goes over 1440.
-
yep amber covers 90% so its a large range.
I do remember that stormy day when I hit over 2700 ES :) cleared DLM by skin of my teeth, was amber,red,red
-
Here we go again Kitz your line has seen 11 thousand errored seconds and back to interleaved have lost count is this the third or forth time this has happened, still the SNRM is oscillating but it's better than 5-8 resyncs a day :mad:
-
Hi Kitz
I don't suppose you know anyone else on your cab to see if they are seeing the same issue? Could be a problem at the cab if other people see the same, or if just you, points towards perhaps a faulty port you are connected to.
Regards
Phil
-
Hi Kitz
Think I've joined your club, with erratic SNR. I've gone from being a flat line to all over the place.
This morning there were several brown outs and I heard my UPS clicking on and off battery, this gave rise to a couple of peaks of increase in SNR. This wasn't due to running on battery and UPS and being off the mains as I can turn the mains off and run on UPS and the SNR is unchanged, so either the brown outs knocked another modem off (so I had less cross-talk) or the cabinet was running on battery and that was making a difference.
Anyway this stopped after about half an hour or so and all was normal until I checked the graph later, so the brown outs may be irrelevant and just a co-incidence.
My SNR is now showing swinging fluctuations, see the attached graph that shows the start, with an increase in margin before the fluctuations kick in. Luckily the troughs are a bit higher than my normal flat line. My modem hasn't resync'd at all.
The second graph shows the slight peaks during the several brown outs we had this morning, but as can be seen by the chart, the wavy fluctuation in SNR didn't start until several hours later.
Regards
Phil
-
Hi
Further to this, just been told by partner there are road works/traffic lights by our FTTC cabinet, and just checked on Roadworks.org and sure enough two sets of traffic lights are labelled there with work by BT laying ducting, starting yesterday. I walked past yesterday lunchtime and no one was there then, but the fluctuations started happening about an hour after I walked past.
Will walk past later and have a look. Perhaps it is a generator running the traffic light lights causing the fluctuation in SNR! From the fact it is listed as 8 metres and 1 metre of ducting, that suggests from the PCP up the road a bit, then 1 metre across the pavement to the cabinet. So perhaps more capacity being added and they need more pairs between FTTC and PCP, although I would have thought they would have put it in originally with space to spare.
Regards
Phil
-
Hi
Just an update. There was indeed a generator and traffic lights right by the FTTC cab, so perhaps that explains the varying SNR. They were digging up the trench that runs from the PCP to the FTTC. I've had no interruption in service and SNR has gone back to being a flat line again.
The roadworks.org puts the work as "Install 1m of 1 way poly duct in Footway, Install 8m of 1 way poly duct in Carriageway", so perhaps they just needed more capacity between the PCP (opposite side of road) and FTTC to add more pairs or are adding a second cabinet to increase capacity, although the current one doesn't show as full.
Just goes to show how susceptible VDSL is from mundane things happening near the cabinet, whilst my connection rode the noise okay there will be other customers that might have been knocked off completely then had DLM knock their speeds back.
Regards
Phil
-
.... and here we go again.
Line has been quite bad over the past 2 days and a couple of periods of loss of sync. Browsing very noticeably affected and unable to surf as pages fail to load.
Speed test 1.9 Mbps. Unable to stream as it keeps buffering.
Going to have to take the bull by the horns and raise a support ticket. This has been going on too long. DLM will hammer me tomorrow.
-
It seems as if a continuous period of CRCs, between 2338 hours (GMT) yesterday and 0325 hours (BST) today, accounted for the the massive number of ES accumulated. :o
The only suggestion I can make is to power-down the modem/router, disconnect it from the circuit and leave it in that state until late tomorrow morning.
-
I sent a copy of those E/Secs with my fault report. There's been plenty of times in the past when a power cycle is only a temp fix for at most a couple of days.
Knowing my luck, if I did that then it would clear nicely in time for an Openreach visit and be back again the day after.
Aside from that powering down means I cant stream. Whilst pain and lack of use of my arm is affecting typing etc, streaming is one thing I can still do. I intend to head off to bed soon and do exactly that as sitting in front of the PC to submit a fault report hasn't helped the pain any and I have a few appts next week, one early tomorrow.
I think there's enough history now to prove something is going on. Got really fed up with it this evening and its taken me about 2hrs to submit the fault report so I'm definitely going to go through with it this time. Not exactly convenient timing but it needs to be sorted.
-
Understood. :'(
I just can't understand what is going on. ???
The SNRM plot shows oscillations that vary in "intensity" or "depth".
The FEC plot shows a low level just for the US, nothing abnormal there.
The CRC plot shows that intense period of between 16,000 - 18,000 per minute.
The Hlog is not perfect but is quite acceptable.
The QLN plot shows distinct "fuzziness" in all three DS bands.
-
Kitz there is some sort of fault on your line it's the SNRM that says it all and the cycle of those high errored seconds seems almost a monthly occurrence it's like you have two faults on your line, lets hope your ISP sends out an OR Enginners ASAP.
-
Ideally it would be Black Sheep (Special Agent, First Class), who would be called from his normal area, to take on the task.
-
BC you have made me think FTTC cabinet/line cards you rarely see any OR engineer working at the FTTC cabinet so there must be only certain individuals allowed access to that cab :-\
-
. . . FTTC cabinet/line cards you rarely see any OR engineer working at the FTTC cabinet so there must only certain individuals allowed access to that cab :-\
Ah, yes. That is a very good point.
The contents of any "fibre" cabinet (the twin to a PCP in a FTTC area) is deemed to be "exchange equipment" and, thus, is in the domain of Operate technicians and not that of the Openreach techicians.
-
fully understand why you reported fault kitz, please keep us updated how it progresses
-
kitz eric's dslstats has a nice feature where you can see bitswaps per tone, it might be a good idea to migrate to his tool at least temporarily and observe what data you get for those measurements as it may point you to a specific set of problematic tones as further evidence.
http://dslstats.me.uk/features.html#Bitswaps
-
kitz eric's dslstats has a nice feature where you can see bitswaps per tone, it might be a good idea to migrate to his tool . . .
I'm sure Kitz will tell me if I have remembered incorrectly but I believe she uses both utilities (HG612_stats & DSLstats) concurrently, in parallel.
-
Yes I use both. I'd already noticed and said on a report I'd started making that the "bitswap increases inline with the oscillations. Far more bit swap in the lower frequencies."
Engineer is due tomorrow, but typically the line seems to be on one of its better phases atm. If you notice that started immediately after the remote resync for DLM. :/
Plusnet have referred it straight to Openreach. The response to my ticket was results of the GEA test, Radius report and the following notes
Downstream speed 68.1 Mbps
BT estimates: 69.1 to 80
Summary: Will need engineer, sync has dropped below estimates and previous performance.
Then all the usual blurb about please state your 3 prefs for a timeslot and the £65 fee if fault is on my premises.
-
well given you failed the GEA test as far as openreach been motivated to do stuff thats a good thing, straight fail due to been below the estimate?
-
Yep
-
Mr Openreach man came. Tests showed HR fault and failed between the UG JB and BT66.
Testing from the UG joint box showed HR on 4 out of the 5 pairs. Guy phoned up to request a new lead in but this was declined by his boss because there was still one spare pair, which is what Im now on. Full DLM reset done. This line doesnt sync quite as high as the old one, but whilst he was here it wasnt throwing any errors so its classed as ok.
He said he wouldnt be too surprised if that failed at some point either as that only just was classed as within acceptable params, but nothing more he could do without Openreach installing a new lead in which would mean digging up parts of the pavement and my drive.
-
Is a lead in to replace the cable bundle or something? Quite shocking the manager said leave the bad 4 pairs in place because one works.
But obviously as far as you are concerned you just want the stability issues fixed, so if the new pair works its job done, this all happened pretty quickly since you reported the fault.
Your symptons seem weird for a HR fault, so I guess time will tell now if it fixes the oscillating issue over time.
-
Mr Openreach man came. Tests showed HR fault and failed between the UG DP and BT66.
Testing from the UG junction box showed HR on 4 out of the 5 pairs. Guy phoned up to request a new lead in but this was declined by his boss because there was still one spare pair, which is what Im now on. Full DLM reset done. This line doesnt sync quite as high as the old one, but whilst he was here it wasnt throwing any errors so its classed as ok.
He said he wouldnt be too surprised if that failed at some point either as that only just was classed as within acceptable params, but nothing more he could do without Openreach installing a new lead in which would mean digging up parts of the pavement and my drive.
Some bizarre behaviour here, or things don't add up right ??
Talking in general terms, as I'm obviously not on site ...... if you have a BT66 there's a fair-to-middling chance your property is fed via duct from the joint-box outside your premises in the pavement ?? Of course, there's always exceptions to the rule.
To add to the picture, 5pr cables are what were always used 'back then' to feed ducted premise, so my money would be that you do indeed have duct feeding your house.
Our remit has always been that we don't swap pairs in this kind of 'feed cable' as it is easy enough o pull another cable through the duct and re-joint at both ends. Assuming of course the duct hasn't collapsed.
If you had the other kind of 'feed' which was the older armoured cable led directly in the ground (DIG), then a pair change would be acceptable but this would usually be followed up by new duct-work being installed and a new cable being run to your premises.
So, something isn't quite adding up from a remote perspective ?? The only thing I can think of is that you do have the older DIG cable, that has been worked on in the past with newer 5-pair cable jointed to it by way of a repair ?? Thus giving the impression it is the newer ducted installation ??.
Either way, I have never in my entire faulting history had to request the permission of my boss with something as simple as this. The engineer n-site makes this decision as to whether it needs a new length of cable installing, and then will run through with you the best way fro our contractors to attack this. The easiest option is to dig in 'Soft' (Grass/mud), but these guys are very, very good at what they do and any surface dressing will be replaced 'The same as or better' than what is was found in. :)
-
I've just had an afterthought as I hit the enter button.
I've changed my mind as to how your premises is fed. I'm now betting it's the older DIG cable with a newer 5-pr cable jointed to it from a previous repair ??? The reason I say this is that it is very odd for 4prs of a 5pr cable to go faulty and not all 5 !!!
The older DIG cable is only worth 2prs, so I would humbly suggest he is measuring 3prs that actually won't be going anywhere as they have nothing to be jointed through to. There will only be the 2 prs available, one of which is faulty, which means the other won't be so far behind at all.
It needs a new feed putting in via duct, as mooted above in my first reply.
-
Yes BT66 and UG joint box in the pavement. - My fault I typed DP rather than JB on the first sentence, I will change it to avoid further confusion.
He said it needed new armoured cable. He most definitely said 5 pair and of the 4 he tested were faulty. The one I'm now on just about passed as being acceptable. He also said something about 4 volts and 7 volts if that makes any sense to you? He said he was going to ring his boss to ask about a new lead in cable. He went to his van and was speaking to someone on the phone and I dont know what was said other than he came back and said he'd been told to use that final pair.
When he came back he told me to monitor because he thought that one may fail too as which point they would have to put a new lead in. He said about having to dig up my drive and that it could take a month before it was done or approved (bit hazy about the month so I may have misunderstood that bit. )
When he swapped them in the JB he then also swapped something at the BT66, it was peeing it down so I didnt go look. After he'd swapped we noticed that this pair sync'd slightly lower than what the old pair did before it started erroring (about 2Mb) but he sat here for about 15 mins checking for CRC errors of which there were hardly any.
I have noticed though that already its displaying some SNR bumpiness on DSLstats and now throwing CRCs and Err/secs although still acceptable to DLM.
The other thing that may or may not be worth pointing out to you is that the same week this fault originally started (back in Oct last year) was exactly the same week that my neighbour had to call out Openreach because her broadband was also faulting.
-
@Chrys. No the behaviour didnt look like typical HR fault to me, but what can I say if when he pulls out his JDSU and straight away it tells him there is a HR fault?
He then looked at something that looked like an app on his mobile phone which told him the distance which is why he said its somewhere between the BT66 and the joint box.
@BS. Ive just been out there to take a pic. It does look like there may be some sort of duct in place. I scrapped away the top layer of gravel so you can see it. That 6 inch wide strip of gravel is only at the side of the house where the cable comes in. The driveway is flagged, the edge of which you can see in the photo. He has obviously done something at the BT66 as you can see he's left some copper wire tails there that he must have cut off.
-
Quick reply as going out in 10mins.
If he is picking up fault voltages, be it 4v or 7v or any volts for that matter, then your circuit has to be in contact with another circuit. If you only have the one circuit working at your premises, then the fault could never be in the actual lead-in ??.
I'm afraid the info is too vague to give a definitive answer. For example, if it is armoured cable (DIG) it is highly unlikely to have 5prs ........... the cable will be concentric and the only ones I've ever worked on is 2pr, 7pr, 15pr, 30pr, 50pr ....... etc
So I can't make a call based on what he is telling you, Kitz. It sounds to me like he's relatively knew to UG faulting ??.
The only thing we know is the issue is at the 'far end' near your house, and the likelihood is groundwork will need to be performed to rectify this situation. :)
-
The plot thickens, that is indeed duct-work ???. It sounds to me like a simple task has been complicated, but that said, until you are there 'on-site' you don't know what you will be confronted with ?? #sgtblackman ;) :)
Righty-o ..... will catch you laters, Kitz. :)
-
I dont have a clue whats going on then. Wondering if Ive been fobbed off if he didnt want to pull a new cable through in the pouring rain?
Yep re the hashtag he did mention ;)
Have a good evening out - enjoy :) :drink:
-
Looking at the picture of the BT66, I notice that the fixing screw for the cover has not been tightened up.
A small detail which is probably irrelevant but something which would make me wonder why? Too much rain? A grey squirrel ran off with the screwdriver? :-\
-
Yes I noticed that myself when posting the image. I'd quickly taken the pic as is was still raining slightly when I took it and was more concentrating looking for a duct.
Damnit... It will have to wait. The guy could clearly see I only have the use of one arm atm and certain things are difficult. >:(
-
If I ever needed a thread to remind me that I know nowt about faulting on copper, it's this one. I'm thoroughly baffled, but I have to say that the SNRM graph since the fix doesn't look especially brilliant. Better, bu not good.
Incidentally, has anyone noticed how MDWS visualisation seems to change radically as you go from a "10d" view to a "20d" view?
-
Is erratic snrm technically a fault within openreach? I expect not.
I guess the issue now is that the new pair passes tests on the JDSU.
Sync is now above min speed for GEA to pass.
Still is no harm for fault been passed back to plusnet, another online test carried out to see if it picks anything up.
-
its getting worse gradually, if it carries on it wont be any better than the old pair. I guess all kitz needs to do is wait for it to throw a fit again, DLM reduces speed and then report fault again as it will be below speed estimate.
-
Yep Im not convinced this pair is that much better. Its now in open DLM and syncing at 73.7 Mbps. When the old pair didnt have INP/Interleave it would sync at 76Mbps.
Nowt I can do though if it passes his tests. I remain unconvinced because those oscillations are still there, as are the errors. We know that its not normal behaviour and its also not really like typical High Open behaviour.
Although saying that, Ive used the landline a couple of times and its been quite noisy. Yet that in itself is intermittent - Saturday afternoon it was bad, yet a QLT last night was perfect. ???
Its not even midday and ILQ is amber - same yesterday. Based on performance so far, this line is erroring more on a normal day than the old pair did.
-
Have noticed the DS SNRM starts to go steady into a quieter period 0900 to 1900 now if I have learnt anything from your forum a HR fault can allow external interference onto your line as the pairs are out of balance.
As for the current errored seconds with a 120 day window open on MDWS it has not changed that much anywhere from 154 to 409 ES per day except for those monthly bursts were is that coming from :-\ and TBH I am not impressed with your last OR Engineer as it's obvious all your UG pairs have degraded because of water ingress (rusted and brittle) UG feed needs upgraded.
-
well its happened again, so tomorrow the new fault report can go in after DLM brings the line below the min estimated speed.
-
To say Im a tad mad right now is an under estimate.
Ive just been told that the goal posts have shifted and my min guaranteed speed is now 62.57 Mbps.
Plusnet have run a GEA test and according to them all is ok so they cannot raise a fault and refuse to do anything further.
I dont have time to do anything more about it right now.
Sync speed is currently
Bearer: 0, Upstream rate = 20000 Kbps, Downstream rate = 68017 Kbps
-
Have you tried any other modem apart from the Zyxel ones?
I had similar oscillations (but only on D1 tones) which were driving me mad, I was using brand new Zyxel 1312. I tried everything and eventually there was nothing left to try but replace the Zyxel with HG612 - and the oscillations went away and have never come back.
-
Only been using Zyxels because of monitoring. I lent my HG612 out to someone who had been given an ECI and not got it back.
The Zyxel was previously ok and still using the same stable f/w. I purchased a new 1312 but that was worse so I went back to the 8324.
-
kitz I was thinking they may pull that stunt on you, there tends to be a habit of moving estimates downwards for a line if a fault is reported.
I would push the argument that you dont care what the estimate is now, what counts is what it was at the point of sale. Also if you noticed any stability issues make sure you make that clear as well.
-
I can tell when the modem/router has re-trained during a "faulty phase" by looking at the Hlog plot.
If the Hlog plot shows a "tail end droop" at the high frequency end then the circuit is misbehaving.
-
Plusnet refuse point blank to do anything further as the line is now performing above the MGAL of 62.57 Mbps.
I now cannot report this line as having a broadband fault until it drops below 62Mbps.
End of.
So moral of the tale.
Engineer can 'fix' your line for 2 days after which point the line is now syncing even lower than when the fault was first reported.
-
PS attaching results from the BT performance tester.
The MGAL appears to be linked to (but slightly lower than) the downstream handback threshold.
The downstream handback is when the EU should be refunded any connection fees, rental fees and not charged any cease fees in the event of a line underperforming and unable to be improved. Which for the EU isnt much use unless you have a cable provider nearby where you can go to.
VDSL Range A (Clean) 80 69.1 20 20 63.1 Available
This btw is an email earlier this year. It wasnt really a new line, they'd swapped my account over to try resolve a billing issue.
Account username: xxxxx
When you signed up for Plusnet Broadband, we gave you an estimated line speed. Now that your broadband has been active for 14 days, we thought we'd let you know the speed as it stands today, by way of comparison.
Estimated line speed: 70.2Mbps to 80Mbps
Current line speed: 67Mbps
Estimated line speed: This is an estimation of the range of speeds you're likely to see based on the line check made when you signed up or upgraded your broadband service. This shows the maximum speeds your line is capable of; although you may have chosen to buy a product which runs at slower speeds.
Current line speed: This is a measure of the actual line speed you are now receiving based on the product you have taken.
Line speed is dependent on:
This is from my ticket today. Should say they did phone me up on my mobile, but I wasn't in a position to be able to say anything at that particular time.
I am sorry you are unhappy with our previous response but unfortunately as the services is working within the expectations for your line we will not be able to investigate this further at the moment.
I think 1) Openreach engineer has fobbed me off as line is no better
2) Just right now I have far too much on my plate to even attempt to take it further :(
-
:cool: Hi, first post in this forum...
Reading this thread compelled me to join up incase there is anything I may add or gain as I have a very similar issue (except mine actually drops as well and only bounces on download SNRM) and guess what... I am on an ECI cab too.
Leaving everything off overnight gets me a couple of days service max but you can guarantee that the bouncing SNRM will return and once triggered will continue through multiple re-syncs.
Interleaving, INP and probably banding are applied by DLM on download and 2 BT OR engineers have found my line results are perfect.
I talked one engineer in to a port and card swap at the cabinet which he did but still the same problem and I have rewired and replaced NTE & faceplate twice, tried 3 modems and I have no extension wiring, I've run modem/router on car battery with mains in house off and monitored on laptop and exactly the same and I've spent hours monitoring for any trace of REIN on a communications receiver scanning 0.5-30mhz and nothing which leaves me to believe that there is a hardware fault at the cabinet but nobody is listening to me :-X
Saga ongoing since at least December and really is quite depressing now :'(
I think I may pay some local youths to steal a car and drive it in to the ECI cabinet, no internet for a while but hopefully a new cabinet will cure the fault :lol:
^^^ Tempting as it is, that last sentence is a joke!
Next plan is... there is no plan, I am just going to continue in the hope it will fix itself one day or I just get fed up and cancel the DD. Maybe a better technology will develop in the next few years and it will work?
-
Hi there and welcome to the forum. ^-^
There's a few of us who have the SNRM oscillations - and all appear to be on ECI's. Its so damn annoying that previously the line was very good and rock steady.
I dont really see what much else I can do. One thing that just happened is that my line has just resync'd a few mins ago and came back up without interleaving.
A full reset by the engineer has obviously put me back at square one DLM so after one full day without err secs its removed INP.
However I notice a very nasty spike of 1.6 million CRCs just after it came back up so will have to wait see what happens next. :(
Leaving everything off overnight gets me a couple of days service max but you can guarantee that the bouncing SNRM will return and once triggered will continue through multiple re-syncs.
Yes sometimes it will clear it. Sometimes it wont. The fact alone that having to do this tends to make me feel it is something more related to the linecard/cab.
My symptoms arent typical of normal HR faults and as Ive mentioned elsewhere another time I did see similar type of behaviour was many years ago when there was a problem with a certain MSAN line card. It was years ago and I cant recall the DSLAM make - Azzaka from Zen may remember as they were passing quite a few faults over to BT back then which had this problem. However I cant say for sure if it is the line card, its just the only time Ive ever seen something displaying similar symptoms which wasnt REIN.
Like you I have no plans what to do next. :(
----
btw I noticed yesterday when I was going to the chemist to pick up a prescription that there was a lot of digging going on next to my cab. I asked what they were doing and they said they were laying new fibre between my cab and the one across the road.
They were also putting new foundations down for the PCP which will have a shiny new case.
-
Thanks for the welcome.
I have a theory but remember I am in no way an expert in these systems but do have a solid background in electronic engineering etc...
Having walked past these cabinets you can hear the fans inside and feel the cabinets are warm to the touch.
We all know heat is a major contributor to and indicator of component failure.
My theory is that possibly through age or otherwise something in the cabinet, perhaps the port/card we are connected to is breaking down (could be as simple as a slow cooling fan or blocked air flow?) and when there is heavy data use over a period of time on your connection the card heats up and starts throwing a wobbly creating these strange oscillating SNR issues but there is nothing to indicate this to an engineer until it breaks totally. Simply disconnecting your modem overnight is enough to let whatever it is cool down and then when you reconnect the modem it starts operating normally again until is gets hot over a period of hours/days.
This would explain why simply re-syncing straight away would not clear this problem as the faulty component would still be hot?
Don't shoot me, I'm running out of ideas and patience too :fingers:
-
All idea's and theories are most welcome, and that may be the case in some circumstances ......................... but Kitz's issue (from what we read), appears to be the UG (Underground feed) to the premises.
PS ..... welcome, almostgivenup. :) :)
-
I think that's an unlikely cause of your issues, however plausible it sounds. The DSLAMs are fitted with variable fans and a whole bunch of heat sensors/temperature alarms, and will automatically shutdown if the temperature of any of the components got too high.
We also know that the ECI cabinets were retro-fitted with heat pads to prevent the temperature getting too low and to stop condensation forming. The ECI shells are the most vented also, probably the reason the heat pads were needed.
-
kitz i sent pm
Sent from my SM-G930F using Tapatalk
-
@Chrys - got it thanks - replied.
@BS - Im still not 100% convinced it is a HR fault between the BT66 and JB. Ive never seen a HR fault cause such regular oscillations before. If anything it looks more like REIN symptoms than a high open. Its like something on the line is pulsing and quite often there is a very regular pattern to it. HR usually cause more erratic spiking.
Then again Im not an engineer so have to bow to you guys better knowledge when it comes to cables and wires. I can only go off what stats are showing me. Ive been using dslstats and similar for way over 10 yrs and if someone showed me some of my graphs without any background knowledge then all my instincts would be screaming REIN or PEIN.
-
I'm now about to enter theorise mode so don't take as gospel proof of anything.
These are facts.
- Openreach know and have admitted that the ECI cabs when updated with g.inp have been displaying far more errors on some lines. Obviously they will know this because RAMBO keeps count of error rates.
- My error rates and the oscillations first started after a 15 min outage at the cab at about 4.30am one morning. (exact time date/details earlier in thread). A 15min cab outage at that time indicates some sort of possible software update.
- A remote sync can very often clear the line for a short while. A resync at this end wont always clear it unless its left out of service for a certain amount of time.
Whilst RAMBO will monitor error rates, it does not see the constant SNRM oscillations because it does not have the ability to graph individual lines in such detail.
Thus Openreach are likely unaware of rock steady flat lines suddenly becoming something that more resembles a seismometer recording a continual earth tremor.
They may be able to detect the low and high points on SNRM (like you can perhaps see on a JDSU) but because the oscillations swing between say 3dB then it may be dismissed as usual atmospheric changes.
The thought crosses my mind is I wonder what SNRM graphs would show for those lines which have been throwing out more errors. I know my line certainly is and its why the DLM takes such interest in it of late.
Below I'll show
[1] Typical graph showing signs on a HR fault.
[2] Typical graph showing line entering a period of REIN
[3] Typical graph showing crosstalk
[4] My line over a period of time.
Thought BS may be interested in these as its not normally something he would see. This is the good side of routerstats monitoring where it helps us to identify types of faults.... and not the OCD type behaviour that may occur with certain people whereby they worry if things change by 0.1 dB ;)
-
In my opinion, your circuit is doubly troubled.
The first, which has been fairly clear to me for some time, is a physical defect in the metallic pathway. The indicators are the fuzziness shown in the QLN plot and the high frequency droop (which comes and goes) shown in the Hlog plot. In the plot, shown below, the droop is currently not so pronounced.
The second, which was giving some trouble in terms of how to express it, is as you have just theorised . . . the curse of the ECI Hi-FOCuS Mini-Shelf M41 MSAN.
-
@Chrys - got it thanks - replied.
@BS - Im still not 100% convinced it is a HR fault between the BT66 and JB. Ive never seen a HR fault cause such regular oscillations before. If anything it looks more like REIN symptoms than a high open. Its like something on the line is pulsing and quite often there is a very regular pattern to it. HR usually cause more erratic spiking.
Then again Im not an engineer so have to bow to you guys better knowledge when it comes to cables and wires. I can only go off what stats are showing me. Ive been using dslstats and similar for way over 10 yrs and if someone showed me some of my graphs without any background knowledge then all my instincts would be screaming REIN or PEIN.
Hey Kitz ..... you know your circuits performance better than anyone, so as an engineer I always listen to what the EU has to say. Of course, you also have the graphs to back up your suspicions.
I was simply trying to form an opinion based around what you were told by the engineer, that is was the UG feed causing problems.
If the new pair he has connected you to is also ready for the knackers yard, then it won't be able to reject what we perceive to be REIN in your graphs, but may just be slightly higher-than-normal noise levels that a perfectly balanced pair would reject ??
Our BRAT (Repair tool) systems nearly always report a HR as REIN. TBH, you need another engineering visit to determine whether the first engineer did as he should. :)
-
TBH, you need another engineering visit to determine whether the first engineer did as he should.
... and therein lies the problem.
The engineer has reported that the new line is working satisfactory and PN are refusing to send out another engineer.
When I first reported the fault my line had dropped below 69Mbps which was the BTw range at the time.
Now PN are saying my MGAL is 62.57 and unless the speed drops below that then they wont consider a fault.
Hey Kitz ..... you know your circuits performance better than anyone, so as an engineer I always listen to what the EU has to say.
Just thought you may be interested in seeing some graphs to show what gives us an indication of whats going on. :)
The line had been playing up for a while but until it dropped below 68Mbps there wasnt anything I could do. Now Im going to have to wait until it drops below 62Mbps :(
Basically stuffed. The line is underperforming what it should do for the length, but obviously not performing badly enough. His promise of monitor for 30 days and if no better get back to us was meaningless because now I cant.
This new MGAL thing has screwed a lot of EU's over. It doesn't appear to take any account of previous individual performance, just a percentile of the worst performing lines of similar length. Those worst performing lines could be screwed by all manner of things including ali, self install messups, star wiring/bridge taps. My line physically isnt in any better state than when I reported the fault. In fact this one syncs slightly lower.
Wish I'd never bothered getting him out - its been a total waste of my time... in fact on the odd occasion I can even hear noise on this line - last Saturday it was pretty bad, but now its ok. Not sure if that could be weather related at its been ok whilst its been dry.
Like b*cat says.... and as I said above I suspect there's 2 things going on here. The physical line isn't 100% right plus there's either something akin to REIN/PEIN or ECI nastiness.
-
Considering that Plusnet are refusing to get involved, is it worth firing an email to the OR CEOs office? If this is a more widespread issue among ECI cabinets, it is something that they may be able to fix nationwide.
-
Any engineer that says to "Monitor for 30 days" and then re-report it if need be, is not to be trusted, in my opinion.
It's ironic that a) The engineer 'Repeat Report' analysis is based around 30 days for each engineer. If you have a RR within 30 days, it is frowned upon .......... and b) We have similar engineers on my patch who say the same thing to our EU's. The same similar untrustworthy engineers. :no: :-X
Alas, I have no idea how ISP's operate, what their own trigger-points are to raise a fault, whether there's wriggle-room within those parameters etc etc ....................... I just know when someone is being blagged, and you are being blagged when you are being told to wait 30 days !!! Not acceptable. >:(
-
See it so easy to say get OR to visit your premises for a second time but you need your ISP to grant that wish the last OR engineer Kitz had let it slip the UG feed has degraded to the point it will fail sooner rather than later.
So maybe an email to CEO is your only option and if your anything like me this will only be as a last resort.
-
It is one of the things I have considered tbh.
Without going into too much personal detail, it's a bit time consuming and awkward for me right now.
Same reason as why Im not posting so much, why I waited so long to report it, and same reason why I didn't kick up too much of a stink when PN called me.
I reported it due to the fact that the errors made streaming from i-player nigh on impossible (buffering). TBB speedtests were 1.5 to 1.9 Mbps during the few hours of the high error bursts. I had hoped that behaviour would clear from this line but it hasnt... as evidenced by DLM taking action just in 2 days after the supposed fix.
When I have a clear day I may do so. Under normal circumstances it would have already been done by now ;)
-
SNRM has been steady since an upward spike yesterday at 13:34 crosstalker reboot so unless it fixed itself which I doubt or Walters wheelbarrow found it way to your location to early to judge which one it is.
-
Yep I noticed it too yesterday. Looks like a typical crosstalker reboot and then problem disappeared. The SNRm since has flatlined at 6.4dB
I do mean flatlined as its not even moved by 0.01dB since and is solid. It proves that the line can behave.
The last time it was like this was Feb half term. By co-incidence its now Easter holidays.
http://forum.kitz.co.uk/index.php/topic,19200.msg343444.html#msg343444
I don't think its my direct neighbour as she is home and not away this time. In fact with it being school hols she is more likely to be at home during the day.
I actually had a look around some of my further neighbours but cant see any signs that any of them are away and most had signs of activity yesterday so this is puzzling me. There is a school quite near the cab but Im clutching at straws now.
-
. . . so unless it fixed itself which I doubt or Walters wheelbarrow found it way to your location to early to judge which one it is.
Perhaps someone gave the (ECI equipped) cabinet a good kicking? :-\
-
kitz you planning to try that new ex zen router a test? i am curious if its worse than the 63168
Sent from my SM-G930F using Tapatalk
-
There's a couple of other points.
- My SNRm is at 6.4dB and stable, yet my max attainable hasn't increased. Power is still the same so its not that either.
- Its still generating ErrSecs. Obviously within limits and Im NOT concerned. The reason I mention it is because it's a damn good job Im with an ISP who uses Speed profile.
After the noise burst last week, it only took DLM one full day to remove interleaving. Even today with stable and surplus SNRm I would be on amber if with an ISP who used Standard... and that interleave would never be removed.
Those extremely high error rates in to 10's of thousands do happen from time to time and if history is anything to go by, the next one will be within days of whatever it is causing it being switched back on or re-appearing.
-
kitz you planning to try that new ex zen router a test? i am curious if its worse than the 63168
I already did as soon as I got it last Dec.
I didn't leave it on long as it was worse than my VMG8324. I think the results are earlier in this thread, the error rate was higher and I lost sync a couple of times. You will have been able to see the results on MDWS. It was during one of the really bad periods though.
I have always maintained that the VMG8324 works so much better on this line than anything else - it really does and that's including the HG612.
There's only the TPlink TD-W9970 that has come anywhere near, which oddly contains the same chipset as the VMG1312-B10D, but then again that was tested when all was well on my line and Ive not tried it whilst the line has been misbehaving. Although you can get a fair amount of info with the TDW9970 the lack of live monitoring with DSLstats/MDWS means I dont bother.
-
ok thanks for the info, hopefully your line doesnt revert to the oscillating.
-
... and here we go again. Extremely high amount of CRC's and E/s this morning.
I'd posted on here earlier and everything was fine, then gone to get showered and ready to go out. Just before I went out I tried to use the internet but pages were failing to load and extremely sluggish. A quick look at DSLstats immediately showed me the reason why.
I did a quick retrain to see if it cleared it, but it didnt look like it had and on top of that my power had dropped to a very low figure. So rather than leave it erroring I switched the router off.
Although Ive not hit 2880 Err/secs for the day, after subtracting my downtime then the MBTE is going to be close.
Power is still very low for this line - usually around 6-6.5 - now 4dBm. Co-incidentally just noticed power also briefly dropped to ~4dBm on 26th of March which was one of the other high error periods. Before all this started it was 14dBm.
Finally as I was driving to my appt, drove past my cab and there was the PCP internals bare to the elements of wind and rain surrounded by about 4 or 5 contractors, 2 white contractor vans and a dug up pavement. Looks like that new PCP casing was going in today. Didnt come back home that way this eve, but presumably by now they will have finished.
-
Finally as I was driving to my appt, drove past my cab and there was the PCP internals bare to the elements of wind and rain surrounded by about 4 or 5 contractors, 2 white contractor vans and a dug up pavement. Looks like that new PCP casing was going in today.
That is a little puzzling for I am aware that the PCP, through which your circuit is connected, is not a "legacy" cast-iron "GPO" cabinet but the more modern (1980s ??) pressed-steel construction. Could it be, perhaps, that another "fibre twin" is planned and that more space is required in the PCP for the extra tie-cables? :-\
-
btw I noticed yesterday when I was going to the chemist to pick up a prescription that there was a lot of digging going on next to my cab. I asked what they were doing and they said they were laying new fibre between my [PCP]cab and the one across the road.
They were also putting new foundations down for the PCP which will have a shiny new case.
Only going off what I was told. The guy who I asked said it was nice someone was interested rather than moaning about the fact they were blocking the road or pavement and actually knew what a PCP was. I specifically asked if they were doing anything to my FTTC cab and they said no. (Yes I was thinking a Huawei twin would be nice). Where they had dug up was leading away from the PCP towards the exchange rather than towards the FTTC cab but I guess that means nothing. There was what looked like a new casing there this morning, but because of the parked vans and additional traffic I was more concentrating on the road.
There is a PCP across the road, in fact there's several all within about 50m from each other as they branch out in various directions so Im not sure exactly which one he meant but I think he meant the nearest.. and if so then there was some delays & oddness with that particular cab. It part serves a newish estate and despite supposedly being live in 2002, I know someone who lives on that estate who was a bit peeved that he couldnt get VDSL until about 2 yrs after me. The estate is about 250m from the exchange (built on land practically smack bang opposite it) and they were not EOLs. Thinking back to a few years ago they ended up partially blocking off the main road for a week or so and excavating one massive hole.
I may go have a wander down there sometime when traffic isnt so busy.
-
Yep definitely shiny new PCP case - all be-it a bit dusty so you can practically see the contractors handprints still on it. :D
Its wider than the old one. Work complete and the barriers that have been up there for the past week all now removed and gone.
Dug up part of pavement leading to cab on opposite side of road. Unlikely they would dig in that particular direction to install a twin unless they were going to put it in the middle of the road? They appear to have dug from the standard 3 slab JB in front of my PCP to some sort of 2 slab manhole/duct at the kerb. You will soon have mail. You can see from the photo where they've dug and also can see that its in the general direction towards other PCP across the road which is also in the photo. Anyway see what you think.
-
Ah, I had replied to my e-mail message before I read your latest additions to this thread. So I'll have to have another think.
I asked what they were doing and they said they were laying new fibre between my [PCP]cab and the one across the road.
:hmm: Hmm, that doesn't read quite right. PCPs will not be linked together with an optical fibre.
-
kitz you not alone, I had a shed ton of errors yesterday 8am to midday, they happened at normally a quiet time of day so out of the blue. Interleaved later today I expect.
Given you witnessed them doing works, I wonder if all the other occasions was them fiddling?
Roberto on TBB once witnessed someone fiddling in his cabinet, the guy only had to slightly touch his wire with his finger and it triggered a error fit on the line.
I did setup dslstats to email me when the ES exceeded a configured rate, which would allow me time to shut down the line to prevent DLM, it worked as expected (thanks eric), however I didnt see the emails until about 5 mins ago as I was playing a game at the time and I didnt setup one of my high priority accounts that go to my phone.
Looks like silent noise on my line, snrm, bitswaps and other metrics none of them budged during the error bombardment. I could exceed the 25% loss in a short time metric as going from 3db fast path to 6db interleaved.
I checked your line and wow, both our lines started their noise burst at 8am, the same hour.
-
i think i got banded as still fast path
-
I think/hope I may have managed to catch it in time. I roughly I worked out that if by the end of the day I managed to stay under ~1500, after allowing for my downtime my MTBE may just scrape through. :fingers:
I was lucky to notice it as I was just checking something before I went out and noticed the wading through treacle symptoms and pages failing to load. If it happened a bit later I would have been out and not noticed until DLM caught up with me. According to MDWS my total was 1376 but there may also have been a few that didnt get uploaded so it's touch and go.
Since all those errors yesterday, my oscillations are back. Ive just noticed that my extreme noise bursts have been every 8th day for the past 3 weeks.
>> i think i got banded as still fast path
You shouldnt go straight to banding without fastpath from 7k E/S. Ive had occasions where I was at >20k E/S and got INP=3
Ive seen DLM changes occur up to 2pm so there is still time yet. It may also have been something local so may come under a Wide Area Event.
I dont think youre banded as your syncs have been 67919, 67500, 67660. The default Target SNRm is 6.3dB now for a lot of people (including me).
-
im guessing its 74mbit banding kitz which is too high to affect my line
the first resync today wasnt me was initiated by the dslam
-
Why would it band you higher than you can sync... and not apply INP? That doesnt make sense.
I didnt get away with it yesterday. Ive just had a resync at 11:50 and INP 3 applied. :(
-
PS what happened on March 21st? Youve been syncing since then with a 3db SNRm? Didn't think they were doing that on ECI cabs yet? Was that a crosstalk situation.
-
had a powercut and synced up before crosstalkers, i have before been banded higher than my sync.
-
I didnt get away with it yesterday. Ive just had a resync at 11:50 and INP 3 applied. :(
If having the PCP innards open to the weather affected many lines, you'd expect that a "wide-area event" would be triggered, and the ESs ignored.
That this didn't happen seems to suggest that the impact was not widely spread, so might have been restricted to you. Could it point to suspect joints in the PCP?
-
. . . Could it point to suspect joints in the PCP?
To me, yes, it does.
-
If having the PCP innards open to the weather affected many lines, you'd expect that a "wide-area event" would be triggered, and the ESs ignored.
I doubt my high error rate was anything to do with it, it happens often enough without any other cause that I know of. Its been happening every 8 days for the past few weeks and been going on for too long. Although saying that it also entered into a spell of high errors when the DLM struck so no definite pattern. Connection currently feels very laggy at times more so than I'd expect from interleaving, but the E/S seem ok now that INP has been applied.
I just mentioned the PCP casing replaced as a PS as I was curious what they are doing. It appears that the cab across the road is also getting a new shell too.
-
Kitz it will turn out to be a fault on the D-SIDE anywhere from PCP cabinet to your UG feed under the driveway, I just wish we could start the ball rolling by replacing the UG feed 1st and then see how your line performs.
-
. . . I just wish we could start the ball rolling by replacing the UG feed 1st and then see how your line performs.
If only Black Sheep could park his van on Kitz' drive, one afternoon and Walter's Wheelbarrow trundles its way to Blackpool, collecting me from Bury St Edmunds as it passes.
With all the equipment thus available, we could soon get that UG service feed replaced . . . ;)
-
I just wish we could start the ball rolling by replacing the UG feed 1st and then see how your line performs.
Unfortunately all hopes of that has now failed. Line is now performing less than BTw estimates, but since whatever the OR guy did the other week, PN now say they cant re-raise it as a fault because Im currently syncing higher than this new figure MGAL of 62Mbps. As I said earlier I think I was a bit fobbed off with "monitor for 30 days". I did not know at that time, that my reportable figure would drop from 68 to 62Mbps. :(
The thing is what happens if I do manage to get Openreach out again and then what happens if it behaves like it did for several days last week where the SNR never budged.
Then I have things a couple of days last week where its throwing 10's of 1000's of errors and trying to do anything is impossible.... or it could be like it is right now and oscillating by 1dB which could be seen as within normal parameters. You and I know that the regular pulsing of 1dB as seen on MDWS isnt right, but would OR treat it like a perfectly normal 1dB swing that we could expect to see on any line over the course of the day. Swings are OK, pulsing isnt so good.
I really, really do have a lot on right now and Im not on top form which is why I haven't taken it further. I do feel that with hindsight I was fobbed off by the engineer because I had no idea that my min reporting figure would drop. This line Im on now is no better than the one I was on last month. In fact its worse - at least when I was going through a good patch I could sync at 75Mbps. This one wont sync higher than 72Mbps.
ETA
Attaching MDWS graph showing SNRm over past 10 days showing that upstream has taken a bit of a hammering too.
-
If only Black Sheep could park his van on Kitz' drive
If BS had a 444B with him that would be great. The symptoms look very REIN like in some respects, but Ive no idea where it could be coming from.
-
Ha ha ..... I've been parked literally a hundred or so meters away from kitz's driveway, a few times over the last 12 months. ;)
I do have a 444B as well. It would need me to be seconded over there again though, to be able to utilise it ??.
I still think (from what we read), that the faulty UG plant needs replacing in order to give the circuit a fighting chance at rejecting the 'noise'. A fully functional twisted pair may well show a different graph to the one that appears to be REIN ? :)
-
I still think (from what we read), that the faulty UG plant needs replacing in order to give the circuit a fighting chance at rejecting the 'noise'. A fully functional twisted pair may well show a different graph to the one that appears to be REIN ? :)
I agree. As does N*Star and many other kitizens. :)
-
kitz we may found out now if im banded is another power cut
--edit--
yeah I appear to be banded at 74mbit.
It appears when DLM takes action it looks at the SNRM, and if its low it will apply banding instead of interleaving. This happened to me twice in similar situations so I dont think its mere coincidence.
74mbit may be a happy medium, as at 4.5db snrm, errors should hopefully never flip DLM and I still have a higher sync speed than normal.
-
I've been watching what DLM has been doing to my line. With having had a full reset Ive started with a clean sheet.
1st offence - Applied INP 3. Removed after one full day of ILQ green.
2nd offence - Applied INP 3. Removed after 10 days of ILQ green
It appears when DLM takes action it looks at the SNRM, and if its low it will apply banding instead of interleaving.
DLM monitors for MTBE and MTBR (not the SNRM). That definitely hasn't changed. It should apply INP before banding. There is one exception where the line may go straight to being banded and thats if your line goes ILQ scarlet from excessive MTBR, but Im sure you would know if that happened.
Unless Im missing something I can not see any indication from your stats to indicate that the line is banded at 74Mbps, but rather ~74Mbps is the physical limitation of your lines max sync speed. I cant even see anything on your Max Attainable which shows the line is capable of syncing at more than ~68.5 Mbps under normal circumstances.
Bear in mind the 'new' Target SNRM for most lines is now 6.3dB. The only reason youre managing to hold a higher sync rate if you come back online fractionally before your disturber, which then causes your SNRm to dip to circa 4.5 dB.
What looks like to me is happening is that you are syncing up seconds before your disturber, which is why you appear to start at 4.5dB. DSLstats isnt managing to catch your actual stats at sync time and by the time the first stats are harvested your disturber is also already back online.
-
Bear in mind the 'new' Target SNRM for most lines is now 6.3dB.
Glad you noticed this because no way can I manually re-sync the modem to exactly 6.0dB on the downstream like we used to it's always 6.+ dB
-
Kitz welcome to Atmospheric line conditions where the SNRM lowers in the evening now all the engineers i've had say my pair balance is excellent via this JDSU but they have never hooked it up in the evening time when the SNRM drops cause the OR engineers don't attend a customers premises at 6pm to 10pm.
If they did they would see a big difference ;)
-
We are able to clearly see when the metallic pathway is behaving in "defective mode" (whatever that may be).
Take a look at the high frequency end of the Hlog plot. I attach a screen-scrape, from just a few minutes ago, in which we can see a significant "droop" at the highest frequency sub-carriers. :o
At other times, we have seen a perfectly normal shape to the curve for those highest frequency sub-carriers.
Such a change should not be seen, as it is indicative of physical changes occurring to the metallic pathway.
-
kitz I simply looked at the QLN for the current sync and compared it to my previous sync during the power cut, they both every comparable, and this QLN is actually better (then my previous 79999 sync). On the previous power cut I synced at 80mbit, on this power cut I am at 74mbit.
The other occasion when I got banded it was in exactly the same circumstances, the line was synced at significantly higher than the attainable, it breached the ES threshold, and was banded (which lasted until I had the DLM reset remotely by the openreach support desk).
I accept what you saying about what the DLM monitors, however the two events are incredibly coincidental. We also know that we dont know everything about DLM as e.g. some people get banded, others get interleaved for seemingly similar events.
I have asked sky to send me a line test result to confirm the banding. Whether they do or not remains to be seen, as their tech support is dumbed down for the masses.
So this is what I know about the events on my line.
I breached the DLM error threshold by a large amount.
The morning after, my line profile was changed, as the dslam initiated a resync. None of the visible parameters had changed tho, the only parameter not visible is the banding.
There was then a power cut shortly after.
During the sync event after the power cut QLN is marginally improved from the previous power cut which managed a 80mbit sync.
The new sync is around the amount expected for a 74mbit banded line.
Your suggestion is that 3 fluky things happened?
1 - I escaped DLM action.
2 - The resync the morning after I breached DLM error thresholds, a resync occured for another unknown reason.
3 - by coincidence I just happen to have synced just below 74mbit.
-
I still say it doesnt make sense to band above what the line can sync at. If you look at your max attainable, you can see its not possible to sync at a higher speed.
If you were banded, then your max attainable would be higher. Banding has no effect on max attainable sync speed in the same way that 80Mbps has no effect on max attainable. There is something else going on with the ECI cabs.
>>> During the sync event after the power cut QLN is marginally improved from the previous power cut which managed a 80mbit sync
Have you looked at your power output levels recently? I keep meaning to make a separate post about this. There's some really weird stuff going on with the ECI cabs and power levels which I suspect may be limiting our speeds. Huawei cabs do not appear to be affected and have much higher power output. Then look at what those on ECI cabs have been going through.. Gradual erosion which in theory will affect our max sync speed.
Last year my power output was always crica 15dBm. Then it dropped to circa 6dBm, now its only at 4.4dBm.
Look at ronskis stats, look at les70's - in fact a lot of the regs on ECI cabs have severely had their power reduced.
Why Ive no idea. What I can see though is when I took that first big hit to my power, was the same day that my sync speed took a loss down to 75Mb. Those on Huawei's dont seem to be affected and still have power circa 13dBm +
So not only do we not have g.INP and no prospect of vectoring, now weve had our power cut back drastically for some obscure reason.
Go through the list on MDWS and look at power levels for the Huawei cabs and you will see they havent changed. Then look at the figures for those on ECI's, we are only getting a fraction of the output power compared to what we used to get.
-
Kitz welcome to Atmospheric line conditions where the SNRM lowers in the evening now all the engineers i've had say my pair balance is excellent via this JDSU but they have never hooked it up in the evening time when the SNRM drops cause the OR engineers don't attend a customers premises at 6pm to 10pm.
If they did they would see a big difference ;)
Mine definitely isnt atmospheric. It pulsates too regularly and can be very cyclic. Its far more symptomatic of REIN/PEIN if anything.
See sceencap below from DSLstats which may show a much clearer picture than on MDWS.
Also it doesnt cause the huge amounts of Err/Secs that occur in a massive block very suddenly. Its some sort of massive noise burst introduced on to the line. :( What the cause of the noise is Ive no idea.. It could be from a high open, it could be REIN or it could be a faulty line card.
-
no worries kitz lets wait to see what sky say, here are my "theories" :) I have learnt to not insist I am right.
Bear in mind attainable should be based on the target snrm so the modem reports what it believes attainable should be based on the targer snrm which is circa 6.3db. So during a power cut event the line still syncs at that snrm but when disturbers come online the actual snrm will drop to a lower number with the crosstalk but the attainable doesnt adjust for that. This explains why my attainable is not a high number.
I agree the fact I have no access to live stats during the sync, not only due to the dslstats not tallying at that exact moment but also that most of my network equipment would be disconnected following the power cut, I actually had no access to stats for quite a while due to my pfsense unit issue. However QLN is generated at the sync and doesnt update so I could still check the QLN data.
My line without any crosstalk should easily be able to get a 80mbit sync and should be able to get in excess of 100mbit as was the case when I first had FTTC, granted this is a different pair but this pair the characteristics actually are better than the original pair.
Now the 2 points you raised, the point of banding above what my line can achieve at 6.3db and the power levels?
The one purpose of banding the line the way they have done I expect is to prevent a line from syncing at a unstable rate following a power cut, the exact event that caused my line to sync so high, we know openreach have wide area event detections in place, so my theory is that somehow their systems can put it all together and determine that banding is beneficial, in which case I think DLM has actually done its job well, my line as it turned out did eventually have excessive errors at the 3db margin, after a second power cut its now synced at a more modest speed giving me around a 4.5db margin which should be more likely to not have the same problem. This is of course assuming I am banded.
With the ECI power level issue, my only theory is that if they are actually reducing power output (and its not a reporting bug) then they have determined it reduces errors to prevent DLM interleaving lines and as such is beneficial. Sync speed isnt everything, quality of service comes into play such as line stability and latency. If they have been reducing levels, then hopefully they will revert it after g.inp is working.
:)
-
Mine definitely isnt atmospheric. It pulsates too regularly and can be very cyclic. Its far more symptomatic of REIN/PEIN if anything.
See sceencap below from DSLstats which may show a much clearer picture than on MDWS.
Also it doesnt cause the huge amounts of Err/Secs that occur in a massive block very suddenly. Its some sort of massive noise burst introduced on to the line. :( What the cause of the noise is Ive no idea.. It could be from a high open, it could be REIN or it could be a faulty line card.
yeah that to me is electrical.
Ironically I found out by accident when I turned my pc speakers on last night a usb power hub (cheap china unbranded unit) was omitting interference, I unplugged it to fix the speakers and at the same time my snrm jumped 0.2db.
I expect your interference is very likely to be local, but pinning it down is hard, I know you have a thoery its could be ECI chipset related but I think its local REIN.
-
So not only do we not have g.INP and no prospect of vectoring, now weve had our power cut back drastically for some obscure reason.
Go through the list on MDWS and look at power levels for the Huawei cabs and you will see they havent changed. Then look at the figures for those on ECI's, we are only getting a fraction of the output power compared to what we used to get.
Isn't this merely buggy reporting, where it shows downstream transmit power equal to upstream transmit power? I thought this anomaly was spotted when the cabinet firmware changed from 0xb204 to 0xb206. The transmit power stats per band may look more likely to be accurate.
-
It pulsates too regularly and can be very cyclic. Its far more symptomatic of REIN/PEIN if anything.
See sceencap below from DSLstats which may show a much clearer picture than on MDWS.
If that SNRM was a simple signal level, then I'd say it looks like an interference pattern or "beats" between two other signals, where the difference in frequency resulted in the period of 335 seconds - a difference of 0.003Hz.
BUT the single SNRM is, I guess, really a combination of SNRM across many tones. I wonder if you'd still see the same patterns that way?
Do you see much difference in the SNRM-per-tone graphs at the times of the peaks and troughs?
-
Those of us who have studied the behaviour of Kitz' circuit in the past . . . before the "oscillations" . . . will recall that the SNRM plot would just show two "ruler-straight" lines with the occasional little "pip".
However (physical) things have now changed. The relevant PCP has been re-shelled and internally, what was an array of hooks, from which pairs of wires would hang (somewhat messily), has been replaced with Krone (or Krone-like) blocks (all neat and tidy) . . . without a break in service. The latter statement does not seem possible but it is the case. (It can be done with extra jumpering and implies that, for a time, there will be double jumpers linking the "left-hand side" with the "right-hand side".)
I attach, below, the last 24 hours SNRM plot from Kitz' circuit. Notice the difference from what I described, above? The two "ruler-straight" lines have now been replaced with those that show a 24 hour cyclical effect; the SNRM drops during the hours of darkness and then rises once again in daylight. And it is to that which I believe N*Star was referring with his "Kitz welcome to Atmospheric line conditions where the SNRM lowers in the evening . . ." statement.
-
Bear in mind attainable should be based on the target snrm so the modem reports what it believes attainable should be based on the targer snrm which is circa 6.3db. So during a power cut event the line still syncs at that snrm but when disturbers come online the actual snrm will drop to a lower number with the crosstalk but the attainable doesnt adjust for that.
It does. Its basic DSL theory that any changes to the SNRM is reflected in the max attainable. We see evidence that the attainable rate mirrors the SNRM every day in MDWS.
Whilst not the best example I attach a copy of mine doing it this week. Note Apr 20th 14:36 my SNRM spiked from 6.0 to 6.9dB as what looks typical of one of my disturbers rebooting their modem. At exactly the same time my max attainable rose from 81365 to 84779. There are plenty of better examples - Erics line does it often as he usually comes back up before his disturbers.
To be strictly correct the calculation uses the real SNR, minus the SNRGAP ... which is effectively the SNRM.
See screencap below from T-REC G.993.2 showing the formula for calculating the attainable.
It uses the current SNR, the SNRGAP and the Target SNRM
My line without any crosstalk should easily be able to get a 80mbit sync and should be able to get in excess of 100mbit
So should mine, but it never-ever does any more, no matter how quick I come back up. My max attainable used to be ~110 Mbps :(
The one purpose of banding the line the way they have done I expect is to prevent a line from syncing at a unstable rate following a power cut, the exact event that caused my line to sync so high,
They have a param on the DSLAM which is supposed to do that - MAXSNRM - which should then adjust the power accordingly.
I'm not saying that you arent banded, just that it doesnt make sense for them to do this, nor can I see any firm evidence that you are.
Isn't this merely buggy reporting, where it shows downstream transmit power equal to upstream transmit power? I thought this anomaly was spotted when the cabinet firmware changed from 0xb204 to 0xb206.
Thank you. I must have missed that. I only noticed it fairly recently and meant to make a separate post querying this, but never got around to it. I shall have a look at the individual bands later.
ETA
Forgot to add attachments.
-
If that SNRM was a simple signal level, then I'd say it looks like an interference pattern or "beats" between two other signals, where the difference in frequency resulted in the period of 335 seconds - a difference of 0.003Hz.
BUT the single SNRM is, I guess, really a combination of SNRM across many tones. I wonder if you'd still see the same patterns that way?
Do you see much difference in the SNRM-per-tone graphs at the times of the peaks and troughs?
Already been there. It appears to affect U2, D1, D2, D3. See attached graphs below from when I was doing the intensive logging and it shows up very clearly. I pondered in an earlier thread why D1 is affected, being smack bang in the middle of U0 & U1 which arent. The only possible difference I can think is U0 & U1 have PCB and PSD masking, but how that should effect Ive no idea. The cycles were exactly every 5 mins 35 seconds.
U0 does sometimes get affected. U1 is hardly ever affected. U2 always shows the most extreme effects
D1,D2,D3 are almost always equally affected.
-
See screencap below from T-REC G.993.2 showing the formula for calculating the attainable.
It uses the current SNR, the SNRGAP and the Target SNRM
I think I know what the screencap is, although it hasn't actually appeared at the time of me writing this, please read the paragraph preceding that formula in the G.993.2 document. That formula is an alternative, simplified method for calculating the ATTNDR during loop diagnostic mode. That formula won't be used when in the normal "showtime" state.
They have a param on the DSLAM which is supposed to do that - MAXSNRM - which should then adjust the power accordingly.
Any MAXSNRM parameter would only do anything if the SNRM would be above it, which generally would imply that the line bandwidth had already reached the rate cap. The rate cap would still very much be needed first.
-
yeah that to me is electrical.
Ironically I found out by accident when I turned my pc speakers on last night a usb power hub (cheap china unbranded unit) was omitting interference, I unplugged it to fix the speakers and at the same time my snrm jumped 0.2db.
I expect your interference is very likely to be local, but pinning it down is hard, I know you have a thoery its could be ECI chipset related but I think its local REIN.
Ive said from the start it looks very REIN /PEIN like. I cant recall ever saying its anything to do with the ECI chipsets. :no: There have been a couple of others on ECI cabs may have said they are seeing similar to me.
I have said as an alternative theory, that the only time I have seen in the past something similar which was when there were a batch of faulty line cards. It was years ago though and unfortunately now I cant recall which manufacturer line cards they were. If Azzaka from Zen is around he will remember for sure. There were a lot of people getting REIN like symptoms that were resolved when transferred to another port on the DSLAM.
-
If that SNRM was a simple signal level, then I'd say it looks like an interference pattern or "beats" between two other signals, where the difference in frequency resulted in the period of 335 seconds - a difference of 0.003Hz.
I wonder if it could be the result of an overloaded amplifer input stage due to a defect in an AGC circuit failing to stabilise the overall gain. Or something similar. (Whatever any of that may mean . . .) :-\
-
I think I know what the screencap is, although it hasn't actually appeared at the time of me writing this, please read the paragraph preceding that formula in the G.993.2 document. That formula is an alternative, simplified method for calculating the ATTNDR during loop diagnostic mode. That formula won't be used when in the normal "showtime" state.
Any MAXSNRM parameter would only do anything if the SNRM would be above it, which generally would imply that the line bandwidth had already reached the rate cap. The rate cap would still very much be needed first.
Are you therefore saying that attainable doesnt move when the SNRM does. Because this is contary to everything we have ever seen. Attainable does adjust in line with the SNRM both when disturbers come on and offline.
Do you see any evidence that Chrys's line is banded or could be syncing higher? Why would DLM apply banding without first ever applying INP first. It does not make sense nor follow anything we do know about DLM.
Sorry I forgot to add the screen caps - will do so in a mo. Whilst the ATTNDR is calculated during loop diagnostic mode... it also says.
The attainable net data rate shall be calculated by the receive PMS-TC and PMD functions during
loop diagnostic mode and initialization. The measurement may be updated autonomously and shall
be updated on request during showtime. The attainable net data rate shall be sent to the far-end VME
during loop diagnostic mode and shall be sent on request to the near-end VME at any time. The
near-end VME shall send the ATTNDR to the far-end VME on request during showtime.
-
Are you therefore saying that attainable doesnt move when the SNRM does. Because this is contary to everything we have ever seen. Attainable does adjust in line with the SNRM both when disturbers come on and offline.
No, I am saying that the actual ATTNDR calculation is going to be more complicated than that formula. Of course the ATTNDR varies with the SNRM.
Do you see any evidence that Chrys's line is banded or could be syncing higher? Why would DLM apply banding without first ever applying INP first. It does not make sense nor follow anything we do know about DLM.
I took the decision to not register with MDWS, so I don't see any evidence because I'm not looking at anything. It's a shame there aren't more devices like the FritzBoxes which prominently report the rate caps, then there would be less guessing. However, the DLM applying banding without INP is akin to increasing the SNRM, still without INP. So I suppose it depends on what the DLM is trying to protect against. If the DLM is trying to increase resilience against sources of constant noise, then it might increase the target SNRM, or cap the rate, which both achieve the same result. Alternatively, if it's trying to protect against pulsed noise sources, either isolated pulses, or repetitive (REIN), then it could set INP. Also, it wouldn't surprise me if BT try to avoid any form of INP to avoid the equipment using slightly more electricity from doing all that extra processing.
-
attainable moves with snrm but i didnt reply before as i think may be a misunderstanding, given i currently have a 4.5 db snrm it is expected to see a lower attainable than my current sync and my existing crosstalk levels mean we cannot see what the crosstalk free attainable is
-
Chry if you do a manual resync of the modem what does your SNRM show after it ?
-
not going to newt as I want to keep my current sync speed. It will very likely sync at around 6.3db tho and around 68mbit speed.
-
. . . without a break in service. The latter statement does not seem possible but it is the case. (It can be done with extra jumpering and implies that, for a time, there will be double jumpers linking the "left-hand side" with the "right-hand side".)
Yes, that is indeed what happens. I thought this was what Openreach refers to as being T'ed (or is that Tee'd?).
It tends to happen when OR are working on many lines, without anyone reporting a fault, and is done to keep service in place when a break in service is not expected.
(OT: There was a brief scene in the "Dial B for Britain" programme, where they cutover a new exchange. A row of engineers pulling whole columns of breakers in the MDF, so lines were instantly changed from old exchange to new one).
the last 24 hours SNRM plot from Kitz' circuit. Notice the difference from what I described, above? The two "ruler-straight" lines have now been replaced with those that show a 24 hour cyclical effect;
Ah, right. I was looking at kitz' own pictures, where the cyclic effect was the 5 min 35 sec. But yes - strange for a line to change from having no diurnal changes to having a significant one. Something has opened the line up to EMI that it plainly wasn't susceptible to before.
-
Already been there. It appears to affect U2, D1, D2, D3. See attached graphs below from when I was doing the intensive logging and it shows up very clearly.
Interesting to see the differences, and that band aren't affected equally. I really wanted to see different graphs though - the ones that show the SNRM for each individual tone - the 4th graph in the "Tones" tab in DSLstats.
The swings of 6-7dB in those SNRM-per-band graphs should show up as significant difference between one graph timed when the composite-SNRM is peaking vs one graph when the composite is troughing.
-
I wonder if it could be the result of an overloaded amplifer input stage due to a defect in an AGC circuit failing to stabilise the overall gain. Or something similar. (Whatever any of that may mean . . .) :-\
:idea:
....
Oh, wait....
I've no idea what any of that meant :doh:
I know what the words signify, but I haven't the foggiest what the impact would be on a copper line. It's all that analogue stuff, right?
-
However, the DLM applying banding without INP is akin to increasing the SNRM, still without INP. So I suppose it depends on what the DLM is trying to protect against. If the DLM is trying to increase resilience against sources of constant noise, then it might increase the target SNRM, or cap the rate, which both achieve the same result.
Simplistically, it is equivalent.
However, I think banding is (in a broader sense) considered to be a newer, superior DLM mechanism than increasing the target SNRM, and is described as such in NICC's document on DLM. This might relate back to power settings, and might not fully apply to BT's model.
Alternatively, if it's trying to protect against pulsed noise sources, either isolated pulses, or repetitive (REIN), then it could set INP. Also, it wouldn't surprise me if BT try to avoid any form of INP to avoid the equipment using slightly more electricity from doing all that extra processing.
If BT were that worried, surely they wouldn't have bothered with G.INP, where all that extra processing is turned on anyway?
-
I thought retransmission wasn't enabled by default, it's switched on as and when the DLM decides.
It also occurred to be that people can tweak the SNRM (or try to), but mostly can't override a rate cap (well, they can set their own rate caps, but only lower). And that people may not want the extra 8ms or however much latency interleaving adds.
The NICC document (1513) does say (TRA being Tiered Rate Adaptation, banding):
Simulation has shown that use of TRA for DSM Level 1/DLM has the potential to reduce power
consumption on DSL lines. However, this is one particular aspect of the analysis that merits deeper
investigation using experimental techniques on real equipment in order to better quantify these
potential benefits. This would be a useful area in which NICC could encourage further work.
-
(or is that Tee'd?).
To me, "tee'd".
(OT: There was a brief scene in the "Dial B for Britain" programme, where they cutover a new exchange. A row of engineers pulling whole columns of breakers in the MDF, so lines were instantly changed from old exchange to new one).
Ah, so you also spotted the "pulling of the wedges".
But yes - strange for a line to change from having no diurnal changes to having a significant one. Something has opened the line up to EMI that it plainly wasn't susceptible to before.
So much for a neat and tidy PCP! ::)
-
It's all that analogue stuff, right?
Yes, indeed. Otherwise why would every modem(/router) have an analogue front end (AFE)?
[off topic]
Many years ago (about 40 - 45), I was making adjustments and balancing the various inputs to an amplifier system in a church. A very big, resonant, space . . . drop a hymn book from greater than three feet in hight and hear an echo tuned to E flat minor. Having got everything "just so", I went around to each location where a microphone was installed and opened them all to the input mixer. And listened. Very slowly, it became apparent that the system was just on the cusp between stability and oscillation. And then it happened. (Probably a very low frequency rumble, from a lorry passing on the main road, was the trigger.) Rather than the usual feedback howl, the system exhibited a pulsed "woop", "woop", "woop" symptom. Each "woop" was at the same, lowish, frequency and appeared to correspond to the natural resonant frequency of the building. It was a perfectly stable state of pulsed "woops" . . . I could go to any one of the microphones and supply further input to the system, which was reproduced but had no effect on the system's pulsing state.
[off topic 2]
Q) What would you get if you dropped a grand piano down the main pit-shaft of a coal-mine?
A) A flat miner.
[/off topic 2]
[/off topic]
-
You can see what's involve https://en.wikipedia.org/wiki/Analog-to-digital_converter (https://en.wikipedia.org/wiki/Analog-to-digital_converter)
-
Sorry, there was a bit of tongue-in-cheek to that "analogue stuff" statement...
Before I got into software, one of my hobbies was electronics, so I know plenty about analogue electronics. It's just that digital stuff took over, and even now, I can play with embedded systems where the two sides meet - arduinos, pis etc. Working in telecoms, and PCM-encoded speech, you get very involved in A-to-D and D-to-A - and in my early days, that included the signalling too.
However...
I only know enough to be dangerous. The theory of electronics, up to but not including inductance, coils, and resonance. I understand the basics of motors, generators and transformers ... but not the stuff where RF engineers earn their crust.
Because of that, I don't have the skills to deal with analogue when it gets tricky, and isn't working correctly. To troubleshoot properly.
So I would know what an AGC was for, and could describe why it was beneficial to a system (especially to us on the digital side). I might semi-understand the circuit diagram for one, but I couldn't design one, and couldn't begin to fix it if it went wrong.
I went in the direction of TTL, CMOS, logic, bits and bytes instead.
Edit: But I'm impressed by the feedback in the church. Just to prove that analogue stuff can be weird!
-
So much for a neat and tidy PCP! ::)
I don't believe that the PCP itself could possibly be the source of that amount of interference from the re-arrangement.
I am prepared to believe, however, that the PCP work introduced a fault that made the rest of the line susceptible to picking up that interference.
On the other hand, I just admitted that my troubleshooting skills were lacking in this area ;)
[for the avoidance of doubt, I'm talking about the diurnal variation in interference here, not the short-duration variations]
-
[off topic 2]
Q) What would you get if you dropped a grand piano down the main pit-shaft of a coal-mine?
A) A flat miner.
[/off topic 2]
[/off topic]
Was his name Stanley? ;D
-
I thought retransmission wasn't enabled by default, it's switched on as and when the DLM decides.
You're right, but reality is slightly more complex than that...
It seems to me that BT really want to have G.INP switched on by default, as it offers a very good improvement to lines in general (*).
However, practical problems involving device compatibility means that G.INP has to be turned off by default - because simply syncing (for everyone) is more important than achieving best stability (for 99%).
BT's compromise then seems to be that DLM will turn on G.INP "by default" unless it sees a reason to do something different. Even if DLM isn't yet optimal in this regard.
It also occurred to be that people can tweak the SNRM (or try to), but mostly can't override a rate cap (well, they can set their own rate caps, but only lower). And that people may not want the extra 8ms or however much latency interleaving adds.
It seems to me that, while BT allow a CP to ask for a line to be in one of 3 "stability" states, they are missing the "try not to add latency to gain stability" setting.
The NICC document (1513) does say (TRA being Tiered Rate Adaptation, banding):
That will indeed be the stuff I had seen a while back.
(*) - I've attached two graphs that depict the improvement attained from widespread activation of G.INP.
The two were gleaned from BT without verbal explanations, so you have to figure out the meaning yourself.
-
Just a quick update. Line goes through some periods of stability, but does still have periods where the SNRm fluctuates and the odd period where the Err Secs go into many thousands.
Thought I'd share my observations what the DLM has been doing
1st offence INP3 for 2 days. (Apr 4 - Apr 6)
2nd offence INP3 for 10 days (Apr 13 - Apr 23)
3rd offence INP3 for 14 days. (May 18 - Jun 1)
-
I have been "looking in" on your circuit's behaviour, once every day, and in general it seems to have stabilised. The diurnal change in the SNRM is no longer seen. However the "tail end droop" of the Hlog plot remains and the QLN plot still appears to be "fuzzy" (or "furry").