Kitz Forum
Broadband Related => FTTC and FTTP Issues => Topic started by: broadstairs on May 24, 2016, 09:31:09 AM
-
Around 12:30 yesterday, just after we had gone out till around 18:00, my line went berserk with snrm dropping to silly negative levels (nearly -2) and DLM intervening as well with some silly speed negotiations giving 403kbps upstream and less than 40000kbps down. DLM intervened several times yesterday and once again this morning around 7:30 which has put me back approximately to where I was before.
My problem is trying to determine what happened as we were not here when it all kicked off. I checked the phone which does cause snrm drops but there were no calls during the afternoon when it was going really crazy. Something must have happened but I dont know what. I checked on possible thunderstorms but the nearest were 50+ miles away and besides we have had them recently almost overhead and had nowhere near this kind of grief. There are no obvious signs of roadworks near here or the cabinet (about 300yards away). This morning it seems to have calmed down.
By the way I did check the other day to see what happens if the line is called with all internal wiring to the master socket disconnected and the snrm does indeed drop although not as much as when the phone is connected and nowhere near the drop yesterday.
Long shot but any suggestions?
Stuart
-
I just wandered through some of the MDWS graphs.
I note that your attenuation increased in a couple of steps, while your SNRM decreased crazily. Rather like @daveesh1's line, in this thread (http://forum.kitz.co.uk/index.php/topic,17741.0.html) going on at present.
Your Hlog graph also shows some glitches at different times; Using the "Historic" option, compare the one on "24th May 00:00" (smooth) with the one on "23rd May 18:00". It isn't as dramatic as @daveesh1's, but it does seem to indicate a physical problem with the line that triggers intermittently.
-
Just had another hit by DLM when it came back my upstream speed has dropped to 788kbps with downtream being just over 41000kbps and snrms being both around 5db.
Stuart
Just raised a thread on the TT forums about this but I wont hold my breath....
-
Just had another hit by DLM when it came back my upstream speed has dropped to 788kbps with downtream being just over 41000kbps and snrms being both around 5db.
DLM isn't doing anything. You are staying at INP=3, delay=8 all the way through this.
Your attenuation just increased again, and your Hlog has gone funny. The resulting changes to SNRM is what is causing your speeds to drop.
That change to the upstream speed is pretty extreme, and I haven't figured exactly why. However, when things happened yesterday, you can see the outcome in the "bits/tone" graph. Using the "Historic" setting again, you can compare the tones used for upstream at 1pm, 2pm and 3pm yesterday ... as I've added to this post.
-
So what is causing the resyncs then if not DLM trying to stabilise the line?
Stuart
Just checked DSLStats and the SNRM upstream is going up and down like the proverbial person of the night's undergarments!
-
The regular behaviour of a DSL modem. It is the normal behaviour of DSL to trigger a resync to stabilise the line too.
A resync will happen if SNRM goes out of bounds; while we don't know what the bounds are, the values are defined as part of the line profile. It wouldn't be a surprise if the threshold was set to 0dB.
A resync will also occur if one ends loses track of the framing data that surrounds the user-data. If the modem loses confidence that it can even work out where the start and end of the user data lies in the bitstream, it will give up and force a resync.
When lines are being problematic, these types of resync are *much* more likely than a DLM intervention. Oh, somewhere in amongst the sequence of resyncs, you might *also* see a DLM-induced resync - as it tries to stop all the other ones from happening. I don't think your line has seen one yet - you would see INP/delay value changes.
People have a habit of looking at the resync reason code, seeing a value of 1, and assuming it means DLM. Unfortunately, it really signifies "RDI", or "remote defect indicator" ... which tells you that the DSLAM didn't like the bitstream it was receiving from you.
-
Thanks for the explanation, you you are right some of the indications can be a trifle misleading initially.
Stuart
-
Least I am not the only one with crazy going things going on.
-
Just checked DSLStats and the SNRM upstream is going up and down like the proverbial person of the night's undergarments!
Its still doing it.
Do you hear any audible noise on the line at all?
I think it is worth doing the same step as @daveesh1 - get onto support, to log a fault. Doing so while it is happening is probably worthwhile too.
-
wow the line looks whacked, I checked the snrm per tone graph and there is almost nothing there on the US channels, and the line is still hanging on with sub 4db snrm on both up/down right now. Get an engineer sharpish.
I think the extremely low US speed alone will get openreach's attention.
Also ask your isp to do a GEA test, if the rules havent changed then your line should fail due to a loss of speed of over 25% in one go.
-
I have opened a thread with their Community forum, I just dont want to call their support as it is usually useless.
Stuart
-
I have recently made a post (http://forum.kitz.co.uk/index.php/topic,17741.msg324298.html#msg324298) in daveesh1's thread . . .
Series capacitive effect, maybe? :-\
b*cat wonders what WWWombat thinks?
-
I just read your post b*cat, possible although our road is comparatively quiet so not much traffic to shake it, however it is a good catch and certainly will keep it in mind. As yet no response from TT community ...
Stuart
-
I wonder if both daveesh1 and yourself have unmodified, newish, pole-top "coffins" . . . :hmm:
-
Not sure - how would I tell since I can see the pole top from the window infront of me here at my desk. On this side I can see 3 boxes, on looks like about 10-12 inches long, not able to see width clearly from here. One about6inches by 3 inches and a smaller one which might be 3 inches square. The other pole is across the raod, not sure which one is the master of the two as I need to go take a look outside later.
Stuart
-
I have now been out to the pole right outside my house and indeed the cable from the underground duct comes up from a box in the footpath directly in front of said pole and as far as I can see into the largest box on the pole top. The other pole opposite is slaved off my pole but my connection is directly off the master pole, that would appear to come off the second largest box.
After another resync around 18:21 tonight my speeds are back up to 61000+ kbps down and nearly 17000kbps up with snrm of around 6db or so down and 10+ db up. Now to see how long it lasts. Last night it all settled down around 18:00 or so somewhat and all hell broke loose again this morning. All very strange.
Stuart
-
This morning DLM did intervene and pushed up INP to 3.5, so far the trouble from the past couple of days has not started again and if it does not then TT probably wont find any errors on the line >:(
Stuart
-
Needless to say TT cannot find any errors now on my line. However I do get noise on the voice line which is still present when only using a corded phone at the master test socket and this has been reported to TT. Strange that now practically any phone use drops sync and this only started this week, although the phone has dropped SNRM for awhile now but no way as badly as it is now.
Stuart
-
The crucial test, with noticeable audible noise, is whether it is still present when all xDSL equipment is disconnected from the circuit.
Basically if the noise is still present when only a wired telephone is connected across the pair then that is a fault which should be reported to the telephony service provider.
-
The crucial test, with noticeable audible noise, is whether it is still present when all xDSL equipment is disconnected from the circuit.
Basically if the noise is still present when only a wired telephone is connected across the pair then that is a fault which should be reported to the telephony service provider.
Yes and it is present with a corded phone in the master test socket and nothing else in the house connected, not even the router. This has been reported back and I am waiting on their reply. After reconnecting everything my SNRM is all over the place again with the U1 upstream SNRM now at zero again - see MDWS.
Stuart
-
Yes and it is present with a corded phone in the master test socket and nothing else in the house connected, not even the router. This has been reported back and I am waiting on their reply.
That's good to know. :)
Would you be able to describe the noise? Is it a rushing sound? A hissing sound? Clicks? Plops? Crackles? Hum? . . .
After reconnecting everything my SNRM is all over the place again with the U1 upstream SNRM now at zero again - see MDWS.
:(
-
Its odd pops and crackle which can be heard over the dial tone and when I press a key to stop the dial tone there I would say a rustle type sound in the background as well as the odd pop or crackle.
Is there a quiet line test which should work on a TT line?
Stuart
-
Its odd pops and crackle which can be heard over the dial tone and when I press a key to stop the dial tone there I would say a rustle type sound in the background as well as the odd pop or crackle.
They are the symptoms of a failing or otherwise defective joint. It should be a straightforward task to find and eradicate.
Is there a quiet line test which should work on a TT line?
No, unfortunately. :no:
-
I have had a couple of texts from TTon my alternate contact number asking me to call their 0800 number which is their fault line but when I entered my TT phone number it said that there was not a fault reported against that number! Talk about left hand not knowing what the right hand is doing :o >:( Ofcourse calling them on the landline caused a re-sync again >:(
Stuart
-
I have recently made a post (http://forum.kitz.co.uk/index.php/topic,17741.msg324298.html#msg324298) in daveesh1's thread . . .
Series capacitive effect, maybe? :-\
b*cat wonders what WWWombat thinks?
Over on @daveesh1's line, the effect on the Hlog graph is very pronounced, and does indeed look just like the one shown in the JDSU slide. A low-frequency drop-off - across the first 250 tones or so.
However, over here on Stuart's line, it doesn't look as clear cut. The symptoms - in the SNRM chart - look very similar, and are now, if anything, getting worse. But Hlog doesn't show the same "simple" drop-off. I've attached an MDWS comparison of the two lines.
Now, Stuart's line is definitely showing something. There is certainly a whole set of "squiggly" readings from tone 150 through to 400, and the entire dataset seems to be around 3-5dBm lower when things are going wrong. I've attached a separate comparison of Stuart's line - one from "before" (midnight on the 24th May), and one from "during" (11am on the 24th May). There are noticeable effects on U2 too.
Unfortunately, I couldn't say what these symptoms mean.
Strange that now practically any phone use drops sync and this only started this week, although the phone has dropped SNRM for awhile now but no way as badly as it is now.
IIRC, SNRM reductions when calls are in progress or when ringing are an indication of an HR joint somewhere - corrosion setting in perhaps.
-
My line once again was not bad overnight but right now my upstream U1 snrm has dropped to zero once again and the sync rate is 1836kbps on a 20mbps line! I'll try to call the TT network team again this morning, I did manage to get it to say there was a fault last night but there was a 20 minute wait to speak with anyone, so gave up and will try again this morning.
Stuart
-
Well my line has been tested by TT's network team and an engineer has been booked currently for Tuesday 31st but that may change if they find an earlier appointment.
My U/S is rubbish now down to 371kbps and D/S at just over 40000kbps on an 80/20 service >:(
Really strange that it seems to clear up overnight which it seems to do most days. Maybe whatever is causing it is temperature sensitive.
Stuart
Edit: Recently had 3 cold calls from some idiot and now I have only U0 band with non-zero snrm, U1 and U2 both gone awol!
[Moderator edited to change the second occurrence of U/S to D/S.]
-
fingers crossed fault is found and fixed for you.
-
Using the landline forced a re-sync again and all three U/S SNRMs came back again so hopefully it will behave again tonight. :fingers:
Stuart
-
Been watching this thread for a while! Sounds messy! Hope your line is fixed soon!
-
I woke up this morning to find that DLM had intervened on my line with INP of 5 and a Delay of 10. Now this is only on the downstream which is not the direction which is causing trouble, it is upstream which is the problem. This seems to me to be a somewhat lacking implementation in DLM trying to fix a problem by hammering the downstream when it is NOT in trouble, I can understand that more often downstream can be problematic but to ignore the upstream when changing the parameters seems to me to be a flawed implementation.
Because of the situation at home this week I have had to delay my engineers visit to Thursday afternoon so I'm going to have to live with this for some time yet, but if DLM continues to hit downstream I dread to think what it will be like by Thursday.
Stuart
-
DLM has intervened again with a delay of 13 d/s but the U/S is suffering once again. Bottom line is that DLM is not making things better..... u/s gets worse and d/s gets penalised....
Stuart
-
Your downstream is just as broken as the upstream - the sync speed adjustments mirror each other perfectly. Yes, your upstream speed drops to almost zero at these times, so is worse /relatively/, but the two are failing in tandem.
If I look at the behaviour, and the ES rates, I'd say that DLM is responding to the number of resyncs you are getting, rather than the ES rate. In fact, looking at the raw CRC count instead of ES, you can see that CRCs appear as spikes - but only at the precise point that a resync happens too. The graphs only show downstream CRC's, even though the ES graph suggests upstream ones must be happening too - I can't reconcile that.
The SES graph also shows a lot of behaviour, where downstream is worse than upstream. SESs are likely to influence DLM too, but we have insufficient data or evidence to figure this out, as they happen relatively rarely. Suffice to say that these, when they happen regularly, are bad news.
Whatever is going wrong with your line, it isn't your bog-standard REIN or SHINE. And that's why DLM isn't handling it too well - it is designed to cope with those phenomena, but not the kind of problem your line is exhibiting.
I just hope it keeps showing the problem when the engineer turns up...
(Edit: Add graph showing CRC vs resync, and up/down mirroring)
-
Your downstream is just as broken as the upstream - the sync speed adjustments mirror each other perfectly. Yes, your upstream speed drops to almost zero at these times, so is worse /relatively/, but the two are failing in tandem.
I was just investigating this aspect further ...
Yesterday, I looked at the Hlog graph, and could see that, when things went wrong, it was roughly 3dB down across the spectrum. Not enough to lose almost all of the upstream.
Just now, I looked at the bit-loading for two occasions (midnight 27th May, and midday 27th May) - times that were largely "perfect" and "terrible". The bitloading downstream is roughly 2 bits lower in D1 and D2, and 1 bit lower in D3. This is about right for the change in Hlog.
However, upstream gets a much worse deal - it loses as much as 4 bits from U1 and 6 bits from U2, leaving U0 as the only loaded spectrum. That is very disjoint from the alteration in Hlog, so I set about figuring why.
There appears to be no change in QLN, so it isn't down to extra noise.
However, there are large variations in upstream power. Sometimes dropping by around 10dBm. *That* would have a large impact on upstream speed.
Power variation normally occurs as part of the upstream power backoff mechanism, which prevents nearby modems from drowning out distant modems. I could expect slight power increases when attenuation increases - but we're getting the opposite here (although we do see power increase sometimes).
Can anyone else offer an explanation?
-
Whatever is going wrong with your line, it isn't your bog-standard REIN or SHINE. And that's why DLM isn't handling it too well - it is designed to cope with those phenomena, but not the kind of problem your line is exhibiting.
Remember too that DLM is designed to respond to errors and resyncs, and not to excessively low speeds. Upstream is causing some errors, but perhaps not enough to invoke DLM. When a resync happens, upstream ends up on a low speed for unknown reasons - but that isn't enough, by itself, to trouble DLM further.
-
when is engineer coming? if not then get it booked.
-
when is engineer coming?
This coming Thursday afternoon, if I have correctly understood what Stuart has written.
-
Correct ;)
Stuart
-
I decided tonight to put my HG635 back instead of the ZyXEL for a couple of days just to make sure these problems were not the router. I dont think they are but I though trying another router would not be a bad idea. It is still running DSLStats to MDWS.
Stuart
-
Time will tell. All looks ok at the moment
-
Yes but it usually is not too bad overnight. I am having a few issues with the HG635 getting stats, for some reason DSLStats is failing to login some times, dont know why - maybe Eric might have an answer. The real test will be during the day today and if it still gives me grief then I'll put the ZyXEL back in.
Stuart
-
Correct ;)
Stuart
live webcam during visit?
-
Well my line is going down hill like before so it's not the router. I'll put the ZyXEL back later today.
Stuart
-
Since the fault was still there with the HG635 plus some unusual errors with it the ZyXEL VMG8924-B10A is back up and running.
Stuart
-
I suggest you stop swapping kit round in the days leading up to the visit, so they cannot blame that for your issues.
-
I suggest you stop swapping kit round in the days leading up to the visit, so they cannot blame that for your issues.
With the saved graphs from DSLStats I'd like to see them try .... ;) NO more swapping now anyway, the HG635 has issues trying to cope with the errors and it has an old f/w version in it and although it was not dropping the line it did give some strange errors to DSLStats. Its probably a year or so since I last used it and I know there was a f/w update put out by TT which may have a be needed to cope with any changes in the ECI cabinet, it worked pretty well before though. Anyway the ZyXEL is back now and will be staying.
Stuart
-
Despite me changing the date of the OR engineer to 2nd June I just had a text from OR to say they are coming on 31st May. Just typical dont know who is to blame as I had confirmation from TT that the date was changed. Anyway I've told TT that I wont accept any changes due to a missed appointment. If the engineer turns up tomorrow he is unlikely to find us which is why I changed the date!
Stuart
Fortunately there is someone there in TT today who has sorted it hopefully .. I'll wait and see what happens.
-
I thought this might happen.... for the past couple of days my line has not been behaving very badly although it is still not running like it was before probably due to the DLM intervention. I'm hoping it will behave badly once again before the OR guy comes on Thursday. One thing I was wondering about is whether the issue is weather related, namely mainly temperature because some days it got worse later as the day warmed up and recovered somewhat as it cooled overnight, the last couple of days have not been warm and sunny, and the outlook weather wise is not brilliant for the rest of the week, the cabinet is positioned on the N side of the road facing S so it will be in the sun for quite a bit of the day.
I was chatting to my neighbour opposite on Sunday and asked him if his internet was behaving OK, he is off the same master pole as me although off the slaved pole on the other side of the road, but he said although his speeds are well below what he thought he should get (he gets about 36mbps I think) he is not seeing any drops or speed degradation, he is with BT not TT. I assume he is supplied from the same cabinet as me.
Anyway time will tell....
Stuart
-
I am in a quandary this morning about what to do over my line and the OR chap coming tomorrow now.
My line is behaving pretty well now although speeds are below what they should be this I think is down to the DLM intervention that happened while it was bad. Also the hiss and crackle which was evident on the phone has gone as well.
Do I cancel the OR guy this morning and wait and see if it goes bad again or do I let him come on Thursday and hope he finds something wrong, but with no apparent errors on the line will he even take a close look despite me having the evidence from MDWS and DSLStats?
What do folks here think is the best option?
Stuart
-
Yeah I was wondering if it was weather related as mine has also behaved since Friday as it was quiet warm and has been overcast since. Boost eng or line engineer attending ?
-
Boost eng or line engineer attending ?
I have no idea and no idea what you mean ;) TT just said they booked an OR guy to come.
Stuart
-
From my experience of BT there seems to be two types of visit a fault visit and a broadband boost visit. Boost visit may well reset DLM regardless and a fault visit can only reset DLM if they find a fault. I would think it will be a fault visit hope he's better than the one that came to me last week all he did was plug his test phone in and said yeah that's fine all working. He wasn't interested in the issue we have been having recently.
-
if its weather related its still a fault, probably a leak somewhere dampening a joint or something, no way should rain have that kind of impact on a line.
-
I dont think its rain in my case it started to go wrong not when it rained but when the temperature started to go up, its been fine over the previous couple of days when we have had rain and damp overcast conditions.
Stuart
-
I read somewhere that only BT/Plusnet use 'Boost' engineers - the other ISPs (the large ones anyway) have opted not to do so.
-
I decided to take a look at my weather station and compare the data against MDWS and discovered that we had 11.7 mm rain over the 3 days prior to my line starting to misbehave on the 23rd May, subsequently it was mainly dry until yesterday when we had 4.6 mm, and today we have just had quite heavy rain with 1.5 mm in the past 20 minutes or so.
So I guess it could just be rain related in that something somewhere got wet and took several days to dry out and caused the problems while it was doing so.
Stuart
-
Hmm, sounds very much like water ingress, we had this problem years ago and it got so bad we had very limited service for weeks...
-
My line is behaving pretty well now although speeds are below what they should be this I think is down to the DLM intervention that happened while it was bad. Also the hiss and crackle which was evident on the phone has gone as well.
Yes, the speed reduction will be down to the current level of DLM intervention.
The problems, though, do seem to have cleared up. For 48 hours, there have been no more jumps in attenuation, no more shakiness to the SNRM, and very few FEC, CRC, ES or SES.
Me, I'd let the engineer turn up anyway. He might find something anyway.
-
Yes I ma coming round to that anyway. Unfortunately my wife is never keen on people turning up and tramping round the house in their size 10s, especially as the master socket is in the eaves behind the bed in the front bedroom!
Stuart
-
Well I'm very glad I decided to leave the OR guy on for the visit. I just used the landline and immediately the line dropped with upstream U1 SNRM now zero and the U0 and U2 SNRM at 2.9 and 1.7 respectively, so I guess it is rain ingress somewhere between the cabinet and my master socket although that is completely dry so I guess realistically it must be as far as the pole top. Lets hope it does not dry out before tomorrow PM.
Stuart
-
I would not cancel for sure, right now the speed drops will be logged on openreach systems which an engineer can view, if you left it for a while and tried to fix again at a later date they would be squashed from the records.
-
I'm not touching anything until the OR guy has been tomorrow PM.
Stuart
-
Always good to recreate a fault that disappears. At least you can try using the landline again tomorrow if need be.
A graph like this might help persuade that *something* has gone wrong recently...
-
The engineer is here now and says there is an HR fault, he's up the telegraph pole right now and discussing it with another OR guy. Apparently TT booked this as a phone fault so he can resolve that but not the broadband fibre if it needs sorting!
Stuart
-
The OR guys (there are two now) are still here. They have left an oscillator on the line and are working down the road between here and the cabinet. No phone or internet now for quite a while. Using my phone and a hotspot at present to get on the net. No word as to what might be the problem yet. Lets hope they do fix it.
Stuart
-
Well I now have a line up and working which the JDSU says tests OK and no HR fault exists. All I need now is for TT to request a DLM reset to remove the restrictions it is causing as my U/S sync is 9995 kbps and D/D 55893kbps wich is far below what it should run at and was prior to all this trouble.
Now waiting on a response from TT.
Stuart
-
do the stats stay stable during phone use?
-
Well at least your engineer has found something just a shame they can't arrange DLM reset.
-
The DS&US SNRm look very steady for 1 hour your DS SNRm is showing 6.3dB were is the extra sync going to come from via a DLM reset yes once interleaving is removed then less overheads but the line does not seem to be capped in anyway :-\
-
Yes so far the stats have been stable when the phone has been used. Apparently TT reported this as a phone fault so the guy who came said he cannot do anything about broadband. As to where the speed comes from well prior to my line having all these issues it was syncing D/S at about 65000kbps which is what I expect it to return to as D/S attainable is 71000kbps, U/S attainable is 24000kbps and was running at a tad under 20000kbps prior to the issues and now has 16db snrm. So I do expect it to return to pretty much what it was before and if it does not I shall be asking why. While I had G.INP I got a sync of about 70000mbps D/S, my U/S was always pretty solid at about 19995kbps. I'm on an 80/20 contract with TT.
Stuart
-
I can see now BStairs well that looks like a fix to me but JDSU says no fault found no HR fault then what the heck did they fix ?
-
They fixed HR, most HR wont be detected by JDSU.
-
They fixed HR, most HR wont be detected by JDSU.
Have been reading the JDSU manual it should pick up and display the exact HR fault in meters
-
That's certainly good that they found *something* and stayed around to fix it. Now it's a matter of keeping fingers crossed that they found the right thing, and did the right fix ... and we can only tell that by leaving things running for a while.
Attenuation currently looks fine, we'll have to judge everything else tomorrow.
As for the speeds?
Right now, it looks like DLM has gone for some ultra-heavy intervention settings for downstream, so I imagine your line is carrying a heavy FEC overhead alongside a long interleaving latency. I can't see the full framing information on MyDslWebStats, but it would be fair to assume that your eventual speed (without DLM intervention) will pan out to be roughly half way between the current and the attainable value.
Upstream speed looks to have been banded - in hindsight, it might have been banded for a while, at 17Mbps, then 15Mbps, and then 10Mbps.
-
I have heard from TT this morning who assure me that the BT systems will reset DLM within 48 hours of the fault being fixed. Now I've not heard that before but am willing to leave things 48 hours, but if nothing happens after that I will get back on to them. Does anyone here know if this is the way BT systems work?
Stuart
Edit: Further update from TT suggesting the BT systems have changed and now set a max attainable rate on reset and if this is lower than the rate I was getting rpior to the problems then they can raise a fault with BT to ask why. Be even more interesting to know if this is known about by anyone here?
-
Theory why no DLM reset was done by the engineer is that he was called in for a voice fault, officially a engineer doing a voice fault cannot mess with the broadband specifically. He did what he could I expect, sort of like when I had a voice engineer fix my adsl sync several years ago, but doing a DLM reset would have stood out like a sore thumb on a voice visit.
-
I fully understand that and he did explain all that.
I'm really wondering if what I'm being told by TT is a load of waffle or whether something really has changed and the DLM stuff will happen in 48 hours (I presume from the fault fix time) so it should kick in by teatime on Sunday.
Stuart
-
I've not heard anything as you described in the edit - the stuff about a new max attainable that could be less than before. It'd be interesting to see what this means in practice, if true. I'm not sure that anything other than the existing DLM reset process makes sense, though.
The part about an automatic reset after a voice line fix does actually make sense, but again, I've not heard of it.
-
I am content to wait the 48 hours as requested by TT BUT if nothing happens by then OR I am left with a lower max speed than I was running with before all this kicked off then I WILL complain LOUDLY and see what happens. It is good to know that running DSLStats and MDWS gives me quite a lot of actual evidence about how my line was behaving prior to all this.
Stuart
-
BT systems will reset DLM within 48 hours of the fault being fixed.
That is just a fancy way of saying wait for the DLM to adjust your line don't understand the 2 days wait that is normally reserved for a DLM reset open profile like a new FTTC line which would start off on fastpath
-
DLM re-sync this morning and now at 12000kbps up and 55844kbps down. Not good enough and I've told TT this is unacceptable. Now to see if they will do anything.
Stuart
-
It looks like the upstream banding changed from 10M to 12M, but no change on the downstream settings. That still looks to be limited by the FEC/interleaving settings (but I'm guessing - MDWS doesn't have the full set of data to check this).
This looks more like standard DLM recovery, in small gradual steps, rather than some new-fangled DLM reset.
-
Yes gradual steps... another this morning with up at 14993kbps and down still hit by interleaving. I have complained to TT about this. When a fault on the line is fixed in my view they should set the line back to the same state it was in prior to the fault rather than this ridiculously cautious approach. Dont know if they will do anything but at this rate it cold take several more days before it gets back to what it was before. Error rates are still very low and there is a lot more it cold cope with easily in my view.
Its also interesting that each time DLM intervenes I see a burst of CRCs and ES right on the minutes the re-sync happens, dont know why but I'm guessing the router is a bit puzzled by whatever DLM does to drop the line.
Stuart
-
What if the line is dropping because of these errors and not DLM?
-
What if the line is dropping because of these errors and not DLM?
The evidence of the graphs on DSLStats does not support. DSLStats shows a light coloured line on the rising side of the graph and solid colour line on the falling side of the line. This tends to indicate that there are showing as the line is coming back, if they were happening prior to the error the line would show the other way round. Also we are not talking huge numbers, plus these ONLY happen at the exact minute after the line drops and the error rate at other times is very very low. The re-sync is detected at 7:42 and the errors show at 7:43. Also if DLM was intervening because of these errors I would NOT expect it to increase line speeds etc.
Stuart
-
As the errors are happening after the resync they are therefore not responsible for the resync. If they are the same ones I see I think they are a normal event after a resync anyway and I usually ignore them, but from your description I thought they weren't.
-
Sorry I probably didn't explain it as well as I could have the first time.
Stuart
-
Its also interesting that each time DLM intervenes I see a burst of CRCs and ES right on the minutes the re-sync happens, dont know why but I'm guessing the router is a bit puzzled by whatever DLM does to drop the line.
Yup - that's notable too. Similar sized bursts of CRC, ES and SES each time. Can't be a co-incidence ... and I reckon it is indeed the modem being confused by the resync, or the manner that DLM brings it about.
You've got to wonder why DLM is choosing to relent on the upstream, but making no adjustments to the downstream - both look worthy.
And, while it is academically interesting for us to watch the improvements happen, this is surely is a case where TT ought to be asking for a DLM reset - even if it needs a broadband engineer to perform it.
-
It is crazy that the DLM is not reset automatically when a voice fault is repaired, as surly a large proportion of voice faults would have affected the broadband connection.
-
Surely that's down to the often repeated mantra when reporting a voice fault of, "don't mention the broadband"? How is the technician supposed to know you have broadband?
-
Openreach organise the engineers, surely they (OR) know what services they have on a line.
-
If they know then why the advice not to mention broadband?
-
Come on Dray, most people on here know that if you have a fault on your line and it's affecting the voice side then you need to report it as voice fault as it will almost certainly fix the broadband side of things, and it's much easier to get a voice fault fixed.
-
its openreach policy ronski, to treat both services separately on faults.
is it stupid? yes
only openreach know why they handle it like this.
-
IMO it is more to do with getting past the guardians of the gates of hell (aka first line support at the ISP). There are less hurdles to jump for voice-service faults.
As for Openreach might know if you have fibre-based broadband on the line, but perhaps not exchange-based broadband. And they can certainly only affect DLM on FTTC, not on any of the exchange-based services.
Also IMO, it isn't particularly stupid to treat the two services separately ... so long as the "coping mechanism" on one service (aka DLM) will properly "cope" with faults that get fixed on the other service ... but this is what it turns out to be not so proficient at.
-
Well TT have said there is nothing they can do to get BT to reset or affect DLM in any way. I am not going to accept this and will try to pressure them. As for the engineer he knew I had FTTC but he said I am not allowed to do anything as it was reported as a voice fault. This is complete and utter crap. BT know they have fixed a fault and as sucxh should without question put the line back in the state it was in prior to the fault happening. I am not going to let this go and will make a nuisance of my self with TT initially. If that gets nowhere I will see what OFCOM says. If I now moved service provider my line would be set back to a vanilla line which is what without question BT should do when they fix a fault. Doing it this way just makes a mockery of BT, they are being allowed to take no responsibility for anything supplied to the end user. I think that TT are in breach of contract if they do not take action as I have evidence my line was capable of much better speeds etc even before the fault got so bad.
Stuart
-
I have decided initially to ask TT for an explanation as to why this was reported as a phone only fault when I explicitly told them I had a broadband fault. They can be in no doubt whatsoever that the fault was reported as a broadband one, they were the ones who asked about a noisy phone line, which it was slightly but perfectly usable, the broadband was not working within spec and dropping frequently. My understanding was that had a broadband trained guy attended he would have been able to reset the line once he fixed the fault.
Once I have that explanation I will take things forward.
Stuart
-
Will be interesting to see what response you get, Stuart. Good luck. :)
-
The response from TT ;
The broadband shares the same line as the phone services. If there is any noise on the line this can and does impact the broadband, so the line issue has to be addressed, This will require a line engineer and if line tests fail then this is the type of engineer that BT will dispatch.
BT broadband engineers no longer perform DLM resets as standard, as a recent change to the way their system works means that the system will set the max obtainable rate based on line conditions, so in essence will reset itself usually within 24 - 48 hrs of a fault being cleared. As mentioned, if the speed of the line then falls within what BT consider to be the acceptable speed range for this particular line, then there is considered to be no fault and no further action would be taken.
So as far as TT are concerned they did what was required by BT to report a fault. Now if true that BTOR have two sets of guys one line trained and one BB trained then this is just daft, it makes no sense at all from either a common sense point of view or a business point of view. I would be interested if Black Sheep know whether or not this is true. I can understand a progression through training which might mean that guys start as a line engineer and progress to broadband but to be honest the other way round makes no sense as line conditions can and do affect broadband but not always does it adversely affect voice and as such I believe broadband engineers should be doing line tests otherwise how would they fix a fault? The other issue is that if broadband guys need a line guy to sort that what's the betting a second appointment would be required leading to even more dissatisfaction?
We know from others here that lines remain in a lower speed state for ages after a fault fix which is leading to the lowering of satisfaction with BTOR.
I just think this is becoming an untenable situation where the end user has a contract with the ISP but no coome back against BT as the supplier to the ISP, plus it seems that the ISPs don't have any come back against BT either which in my view renders any contract to supply broadband impossible to enforce and therefore worthless.
Stuart
-
I can understand a progression through training which might mean that guys start as a line engineer and progress to broadband
Now imagine a career path where the guy started as a line engineer a decade before anyone invented broadband. There was no way to train in broadband techniques at the time... and some remain unconcerned about such training.
Don't worry about how BT support individuals through their careers ... just stick to your line.
-
It was just an observation about training... I fought many such battles during my time working trying to get bean counters and managers to understand what was needed.
My main concern is the way things currently operate and whether or not I will be able to get it sorted.
Stuart
-
The problem appears to stem, not from training of engineers but from four problems ... almost orthogonal problems.
The first is that Openreach want faults to be reported, and handled, as either voice or data, not both, where demarcation is decided prior to any technical investigation, let alone impact assessment or resolution.
The second is an insistence that a DLM reset can only happen within a fault labelled as broadband, even when an engineer can see that a voice fix has impacted broadband performance.
These two combine to ensure that broadband connection can be left suboptimal, needlessly, because of simplistic administrative labeling.
The way around this problem is to order a separate broadband job. The third problem then turns up - Openreach are unwilling to take this on when the suboptimal operation still meets minimum standards.
No problem if DLM was seen to recover at some reasonable point in time. Leaving it to automation is a good answer. The fourth problem is that automation isn't doing the job here. The premise behind problems 2 and 3 - that DLM automation will recover - is turning out to be a false one. IMO banding is just too sticky right now.
-
That sums it up perfectly, unfortunately that does not solve the issue or enhance ORs reputation. Very short sighted in my view.
In future I shall insist on both being reported and see where it gets me. For now the only way to try to get this resolved if in a few more days DLM has not recovered the line will be I think to complain to the CEO's office at TT once again as their community staff will not do anything.
Stuart
-
Why not go straight to the OR CEO, pointing out the short comings and problems it causes.
-
IMO it is more to do with getting past the guardians of the gates of hell (aka first line support at the ISP). There are less hurdles to jump for voice-service faults.
As for Openreach might know if you have fibre-based broadband on the line, but perhaps not exchange-based broadband. And they can certainly only affect DLM on FTTC, not on any of the exchange-based services.
Also IMO, it isn't particularly stupid to treat the two services separately ... so long as the "coping mechanism" on one service (aka DLM) will properly "cope" with faults that get fixed on the other service ... but this is what it turns out to be not so proficient at.
which is what I meant really, they are 2 separate services and will have separate fault systems, the issue I have is where they forcefully draw a hard line not allowing a fault team to deal with faults on the other side if they related.
-
I know getting line rental and broadband together is more and more common as the big ISPs bundle products together but guess there must be quite a few who still have separate suppliers - and I guess a broadband supplier wouldn't be to happy for Openreach to fiddle with 'their' product for a voice fault they know nothing about..
-
The problem is that whoever you get your broadband from (except in Hull) if you receive it over your phone landline then you are using BT's infrastructure at least back as far as the exchange so OR can fiddle all they like with your landline - they own it. It is unlikely that a landline line fault will not affect your broadband anyway.
Stuart
-
after speak to an OR engineer recently my understanding is they are indeed split into line engineers/fibre engineers. he actually said that the engineers who enabled fibre were the newer, less trained staff. no idea if this also applied with fault fixing fttc, but he certainly said the newly trained staff start off enabling fttc. don't know if it's the same for both OR and Kelly's.
-
This is far, far too complex to cover in a post. There are many and varied skills within OR, most of which the average EU will never see.
The ones you are likely to bear witness to, are of course customer facing. These can come in all guises depending on how long they have been in employment with OR, whether they are multi-skilled (mostly by choice), or are single-skilled, or indeed one of our contractors.
Single skilled engineers can be CAL/OMI, who basically do from the top of the pole into the house, or from the BT66 (on underground feeds) into the house. They do also perform the Cab work.
There are also single-skilled UG (Underground) engineers who are very unlikely to enter the EU's premises unless it's a fault proven into a DIG cable.
Multi-skilled engineers will either usually have 1) CAL/OMI and UG skills ................ or, 2) CAL/OMI, UG and Broadband skills.
We then have the new starters (ex-MOD and NOTV - National Operation TV), who start off doing basic stuff, then progress onto FTTC installs as they're deemed quite easy to perform as a whole, hence most being a 'Self-install' product for the EU to perform.
The scenario's really do go on and on, it depends on the need of the extra skills in the locality and/or the engineers want of personal development which the business will usually back.
So, as with Broadstairs issue, you can have a line fault identified and repaired by a CAL/OMI engineer, a UG engineer or even a multi-skilled engineer ....... but if he isn't BB trained he is highly unlikely to have the ability to perform any kind of DLM reset.
Yes, I do agree that there should be some kind of 'flag' that alerts both the ISP and Btw/OR ..... so that a simple DLM reset can be performed.
However, as it stands this is not the case and the engineer is not to blame.
-
So I cold end up in the same boat if my line is found to be faulty (which I know it is but help desk still say line to property is fine) and repaired but my speed will be effected and will potentially have to wait 10 days for another fault to be raised for a boost end to do a DLM reset madness and no customer satisfaction there at all.
-
................ or you could have a broadband trained engineer and everything will go fine ??. Massive customer satisfaction.
-
"Help desk says that line to property is fine", but is that always necessarily so? For my personal convenience I had the cable (DIG) rerouted after a fault by a kindly engineer. The length increased, so an on premises fault was actually in the street. Databases are not always accurate.
-
I know getting line rental and broadband together is more and more common as the big ISPs bundle products together but guess there must be quite a few who still have separate suppliers - and I guess a broadband supplier wouldn't be to happy for Openreach to fiddle with 'their' product for a voice fault they know nothing about..
that is a valid point, I forgot about a scenario where the voice and broadband provider are different.
This is a good reason as well to have openreach as the sole supplier to end users for the line itself.
-
Why not go straight to the OR CEO, pointing out the short comings and problems it causes.
Good idea, that's what we did when our fault wasn't sorted.
-
@BSO that's what I am hopping for then all done in one go.Does the sheep want to lose his way and end up in Northamptonshire ;D
-
Ha ............ with the way our 'Works Allocation Manager' operates, a nearly 400 mile round trip can never be ruled out !! ::) ;) ;D
-
Well for a number of reasons I'm going to let this ride for a week or so and see what happens. I still see s slight dip in the SNRM values when the phone is in use both up and down in the U1 and D1 bands. The error rate is currently exceptionally low so I would expect DLM to intervene and improve things BUT will it?
Stuart
-
Ha ............ with the way our 'Works Allocation Manager' operates, a nearly 400 mile round trip can never be ruled out !! ::) ;) ;D
maybe there should be a code word that can be used when booking that ensures the job gets allocated to BS :P
http://xkcd.com/806/
;)
-
Ha ha ...... nice linky. As an aside, one can actually request a certain engineer attends your premises, for a premium as always ::).
I still don't think they'd allow me to travel 200miles off-patch though ? :) Thank you though.
-
maybe there should be a code word that can be used when booking that ensures the job gets allocated to BS :P
http://xkcd.com/806/
;)
I thought the two word phrase was sheep dip? :D
-
^^^^^^^^ ;D ;D ;D ;D
-
Well my line has gone pear shaped again upstream this afternoon. Cant see a reason.... will have to wait to next week to raise with TT again.
Stuart
-
Well TT just said because my SNRM seemed to have recovered reboot the router! Anyway I'm not letting this go with them or OR. Today I had a phone call at 11:31 which caused my SNRM to drop dramatically and reboot the router which has resulted in the U1 SNRM dropping and staying at 0. First thing Monday TT will be hearing from me, and this time they can get OR to send a broadband guy or perhaps a phone guy as well but since the phone itself works I think the BB person is needed.
Stuart
-
A short while ago I took a look at the various plots via MDWS. The three that I attach, below, quite clearly tell of a defect in the metallic pathway. Unfortunately that defect is intermittent and, thus, difficult to trace. :(
-
Well this is now back with the TT Network Team for investigation ....
Stuart
-
Well this is now back with the TT Network Team for investigation ....
:thumbs:
Regarding my statement "clearly tell of a defect in the metallic pathway", I failed to say that the defect is located between the port on the DSLAM's line card and the NTE5/A. Essentially I am stating that the fault is within the D-side of the telephony network.
-
I did try to make that clear and have asked for a broadband guy to attend, however I wait to see what transpires. Currently I do not have a problem with the phone like I did before with noise etc.
Stuart
-
Any information back from there network team ?
-
Not yet. I noticed another SNRM drop this afternoon which was not caused by the phone being used. I have poked them but yet to hear back.
Stuart
-
Update from Community is that there is no update yet from the Network Team. I suspect they are puzzling over it because the problem is intermittent and although my U1 SNRM is zero still that's probably because there has been no re-sync and no dlm intervention, even with U1 being 0 the other two dropped violently yesterday afternoon around 16:30 for about 10 minutes. The downstream SNRM also took a hit the same time. I double checked as we were out at the time but there were no phone calls on the landline at all.
Stuart
-
That was an interesting event, yesterday afternoon. I attach a composite image of the relevant section of the SNRM plot, below.
We can see a discontinuity in the the SNRM plot. The last data before the discontinuity, with DS SNRM of 10.6 dB & US SNRM of 22.2 dB, was at 1631 hours and the next data after the discontinuity, with DS SNRM of 6.9 dB & US SNRM of 6.5 dB, was at 1635 hours. The latter margins were maintained until 1641 hours when they suddenly increased to DS SNRM of 10.6 dB & US SNRM of 22.5 dB.
Puzzling. ???
-
Not sure why that shows, there was no re-sync registered by DSLStats and there is a gap in the other SNRM graph on MDWS as well although the graph continues to plot no data shows between 16:31 and 16:35.
Snapshot of DSLStats event log
21 Jun 2016 16:32:04 Alert: Downstream FEC/min rose to 18074.00
21 Jun 2016 16:32:04 Alert: Downstream CRC/min rose to 120.00
21 Jun 2016 16:33:04 Alert: Downstream SNRM fell to 2.80
21 Jun 2016 16:33:04 Alert: Downstream CRC/min rose to 21853.00
21 Jun 2016 16:33:04 Alert: Downstream ES/hour rose to 60.00
21 Jun 2016 16:34:04 Alert: Downstream CRC/min rose to 23095.00
21 Jun 2016 16:34:04 Alert: Downstream ES/hour rose to 120.00
21 Jun 2016 16:35:04 Alert: Downstream FEC/min rose to 1178631.00
21 Jun 2016 16:35:04 Alert: Downstream CRC/min rose to 22454.00
21 Jun 2016 16:35:04 Alert: Downstream ES/hour rose to 179.00
21 Jun 2016 16:36:04 Alert: Downstream FEC/min rose to 99137.00
21 Jun 2016 16:36:04 Alert: Downstream ES/hour rose to 179.00
21 Jun 2016 16:37:04 Alert: Downstream ES/hour rose to 179.00
21 Jun 2016 16:38:04 Alert: Downstream ES/hour rose to 179.00
21 Jun 2016 16:39:04 Alert: Downstream ES/hour rose to 179.00
21 Jun 2016 16:40:04 Alert: Downstream FEC/min rose to 41130.00
21 Jun 2016 16:40:04 Alert: Downstream CRC/min rose to 1793.00
21 Jun 2016 16:40:04 Alert: Downstream ES/hour rose to 185.00
Looking at the DSLstats SES graph there were 60 SES per minute at 16:31 16:32 16:33 16:34 and 16:35 plus another 10-20 at 16:40, then it all cleared.
Stuart
-
Not sure why that shows, there was no re-sync registered by DSLStats and there is a gap in the other SNRM graph on MDWS as well . . .
My apologies for not mentioning that the intense blue line, configured to show in my version of the plots on MDWS, is the resynchronisation event indicator. As you mention, there was no such event. (Such an event could be triggered by the equipment at either end of the VDSL2 circuit, the DLM process or human intervention.) I can only assume that the DLM did not consider those SES to be worthy of its intervention.
Still very puzzled. ???
-
Not sure what went on as we were out when this happened. Nothing is set to activate in the house at this time which does not run anyway like fridge/freezer, and no calls registered by the phone network either. Could the ES and other errors have prevented recording to MDWS during that gap which shows?
Stuart
-
My feeling is that there is a definite defect in the metallic pathway. On the D-side, between the DSLAM line card port and the NTE5/A. The abnormal Hlog plot is a good indicator of such a defect.
However the failure of MDWS to receive any data in those four minutes (1631 to 1635 hours) and the evidence from DSLstats confirms that although there was no failure of synchronisation, CPE <--> CO, there was an obstruction to the data flow at a higher transport level.
I'm just throwing ideas up into the air, to see how they fall or if anyone catches one . . .
Could there be a problem with the port on the M41's line card?
Could there be a problem with the M41's line card further upstream in the circuitry than the port but still confined to your circuit?
Could there be corrosion of the connectors of the M41's back-plane?
Could the salty sea air have accelerated the know corrosion problem suffered by all M41 DSLAMs? (The fitting of electrically heated warming pads was supposed to fix the corrosion problem.)
-
It would be good to know if any of my neighbours who are probably connected to the same cabinet have issues, however I know form talking to two of them they would have no idea at all and unless their connection dropped at a time they were using it they would be totally unaware of any issues. I do know one guy across the street has speed issues with BT as his ISP but again he is not a techno nerd ;) like some of us here ;) so I have no idea what anyone else may/may not be seeing.
Stuart
-
My boss actually lives just down the road from your cabinet, I know he has FTTC, but I also know that no one in his household would have a clue :no:
-
Slightly OT but I suspect BT and most ISPs rely on the fact that 99.9% of end users would not have a clue on what might or might not be happening to their line. Most folks will only complain if their line is no active when they are trying to use it from their Ipod or perhaps when it take 15 minutes to get to a website. They probably hate those of us who monitor our line to within an inch of its life and complain when it is 10% less than what we expect and are paying for.
However having said that my response is TOUGH, I will complain and I will insist I get what I pay for, especially when I have the evidence that it was working before whatever went wrong.
Stuart
-
I can only assume that the DLM did not consider those SES to be worthy of its intervention.
No MDWS at the moment, so I'm guessing...
I'm not sure DLM would respond quickly to them. Wouldn't we really expect the modem or DSLAM to react at first, reporting LOS or LOF and triggering a resync? Or that whatever noise is causing the SES would also knock SNRM below zero - which ought to trigger a resync too?
-
Overall SNRM did not hit zero, looking at one of the u/s bands it went to 0.8db. Overall at present the SNRMs are quite high so have a long way to fall, if they had been at pre-fault levels then they would likely gone to 0 and triggered a re-sync.
Stuart
-
Chased them again this morning - still no update from their network team. Told them if I don't hear something positive by close of business Friday 24th I will want to escalate. I thinnk they have had long enough to get OR involved now as I don't see it being something they can resolve.
Stuart
-
Well with a bit of encouragement I now have them agreeing to an OR guy attending. Their caveat as ever is that I have to agree to a £65 change if no error is evident when the OR guy attends. Bascically I have no choice, no agreement no OR attendance. However we know I do have an issue on my line and I hope it might happen while he is around (don't have the appointment yet). The problem is that IF I get a chanrge it will simply be added to my bill which has to be collected by DD, so I will have to argue for a refund if I get charged. They simply do not acknowledge that there are folks around who understand this stuff and can indicate a fault does exist and happens on a number of occasions. If they cannot or will not fix this bug then I will move ISP as I believe my contract may be close to ending if not already ended.
Stuart
-
@broadstairs,
maybe you should get MDWS up & running so you can send them proof?
Who could you send the proof to though?
-
Yeap. Been there when I had to supposedly accept a charge when I knew I had a fault. I loaded hg612 stats on my laptop aand showed the engineer the problems I had encountered over a few weeks. The result was a pair swap and no charge. The historical data was the key.
-
There is an issue on your broadband circuit anyone with MDWS looking in would agree it's getting OR to also see the issue using their JDSU which as we know does not collect stats over 24 hours it's just a 5 - 10 minutes test
How can the Engineer know the end-users line with just a 10 minute sample, anyway if the problem shows up clearly with the JDSU then it can be found and fixed (high resistance joint) on the copper circuit but you had a HR fault on the telephone side which was supposedly fixed yet your Broadband is still showing signs of a HR issue :-\
-
It is "all change" following the resynchronisation event at 1753 hours, earlier today.
-
Yes I did a manual re-sync since I was fed up with it sitting there at such a low u/s speed when the SNRMs had recovered and been stable and it was after TT had said they could see no current fault. This way when/if the bug hits it is likely the SNRMs will fall enough to cause a re-sync but with the margins it had prior to my re-sync it would be far less likely to drop. Anyway that's my logic to why I did it.
Now to wait and see when they can get an engineer out.
Stuart
-
you might have an argument for agreeing under duress if push comes to shove.
-
Well something gave me a re-sync at 10:11 this morning when DSL connection dropped and re-sync alert raised on recovery at 10:12, have no idea why.
Engineer coming next Tuesday 28th in the afternoon. I will get a whole bunch of graphs to show him from MDWS etc.
Stuart
-
I think this 30 day composite helps show things well.
I * think* your problem occurs each time following this kind of profile:
a) The problem is a physical fault, but most noticeable in the graphs as an increase in attenuation.
b) At the same time, noise (inaudible) increases and SNRM plummets enough to cause a resync. If it didn't resync, you'd likely see loads of errors - and you do seem some small spikes in error counts if the resync isn't triggered instantly.
c) The amount of noise means the resync results in very low speeds.
d) Because of the very low speeds, a low error rate happens.
e) When the physical error goes away, the noise disappears, and the SNRM shoots sky high. A resync is not triggered, so speeds stay low
f) While SNRM stays high, the attenuation stays high too. Not obvious why.
g) When a resync is initiated manually, the resync allows the attenuation to restore, and the SNRM to target 6dB again. Speeds recover - either totally or partially
h) If speeds recover only partially, DLM has likely banded the speed.
Over the long period of this graph, you can show that process happening multiple times (and more on longer period graphs) before the fix, and returning now.
-
The resynchronisation event of this morning was preceded by a disturbance in the US SNRM . . . though there was significant elapsed time between both events to rule out a direct connection.
-
Whatever it is which is causing my problems just hit again at 14:02 today with a re-sync and 479kbps up speed!!!!!
Stuart
-
Yes, I have noticed. :o
Yet again, the Hlog plot is showing signs of a metallic pathway defect. :(
-
BT guy has just left, been here about an hour and run all sorts of tests but of course as we all know intermittent faults don't play ball and he could find nothing. Anyway I did show him several graphs and sets of stats to show the issue. The last thing he did was a full DLM reset which has removed interleaving and put my speeds back to some semblance of normality. Now to wait and see. He did say that they are getting a number of issues now G.INP has been removed where a full reset seems to fix things. Anyway I wont hold my breath just yet.
Stuart
-
Will be interesting to see what happens over the coming days.
-
Well its 10 days since my line was reset and it is behaving pretty well now as it was prior to the issues.
Initially the first OR guy found and fixed a phone line fault but told me he was unable to do anything about resetting the broadband part. As the issues continued I managed to get a second OR visit this time for a broadband fault. This second guy confirmed that the phone line was still fine so after running a number of tests the last taking several minutes he finally reset the line completely from a broadband perspective. Now it has been behaving perfectly, well at least as well as it was prior to all the issues and I'm still on fastpath.
His comment to me was (as I already mentioned elsewhere here) that in his experience removing G.INP on ECI did not work well and that several lines needed a full reset to get them working properly, and in my case this certainly seems to have been true. So it does seem at least for some that there is a problem after the removal of G.INP which nothing will fix other than a complete reset, certainly fixing the phone fault did not fix the problem at all.
Stuart
-
Thank you for the update and for passing on the Openreach technician's observations. :)
-
I had a DLM re-sync for mis-detection this afternoon, still at more or less the same speed and fastpath.
Stuart
-
Now my 10 days since the reset have expired and my line seems fixed I have sent the following to TT
OK so since the last OR guy reset my line it has been fine.
As I explained this second OR guy said that in his experience some lines on ECI cabinets seem to need a complete reset following the removal of G.INP in order for them to behave as they should and this certainly seems to me to be the case with this line. There was a phone fault but repairing that on the first OR visit did not fix the broadband problems.
In my opinion if you have a phone fault AND a broadband fault then the OR person should be able to do a complete reset of the line once the phone fault has been fixed. It is not sensible from either the EU or OR's point of view to have to send two engineers out just so the second one can do the required reset, it is a waste of OR resources and does nothing for customer satisfaction.
This issue could have been fixed on the 2nd June if the first visit had reset my line, because this OR guy was not a broadband engineer he was unable to do this. So I've had to wait a further 26 days till the 28th June for the second OR guy to simply reset the line. This is completely unacceptable and in my view a complete waste of OR's time and mine waiting in for the second visit not to mention the 26 days of further problems.
I'm not sure it will get anywhere but I do feel strongly about this and believe that the way this currently works if not sensible.
Stuart
-
If the ECI DSLAM was the culprit to your up and down SNRM which still looks like someone using this command on a compatible VDSL modem adsl configure --mod v --maxDataRate xxxxxx xxxxxx xxxxxx then there could many end-users like yourself that need a engineer DLM reset since G.INP was removed.
That does not bode well for G.INP coming back on ECI cabinets unless you already have IPTV my prediction of G.INP being enabled by the end of July is slowly fading away into the dark
-
I used to use the xdslctl configure command to limit my connection to 65000kbps but have not had that set up for over a year now so it was not in use when G.INP was turned on and is not in use since. I have no idea why I only see the speeds I am getting now, prior to all this they were a little higher, the problem is that they will not consider any bug now because my speeds are within the limits suggested by the Wholesale checker. I am certainly not using any command to limit it.
Stuart
-
that in his experience removing G.INP on ECI did not work well and that several lines needed a full reset to get them working properly
Definitely an interesting comment from the OR guy. That suggests the rollback method, the way of putting the network back to how it was before, wasn't that good either.
That does not bode well for G.INP coming back
I always doubted that G.INP would be back by July - the mere choice of implementing rollback after a month meant there was no trust in what was deployed. To regain trust will have meant not only finding and fixing the issue(s), whether they exist within ECI or DLM (or both), but performing a large amount of regression testing.
Looking now, BT will not allow a rollout to even start without allowing room for a complete (new) rollout and a complete new rollback (in case) to happen well clear of any Christmas freeze. If we don't see signs of it by the beginning of September, I doubt we'll see anything until February.
-
I have had a reply from one of the TT OCEs to my recent update about why it needed two visits to reset my line which unsurprisingly says nothing.
I wonder if Black Sheep might be able to shed some light on what is and is not allowed when a phone guy finds and fixes a fault which can also be demonstrated to interfere with broadband and why a reset cannot be at least requested if not performed by the phone guy?
Stuart
-
I have had a reply from one of the TT OCEs to my recent update about why it needed two visits to reset my line which unsurprisingly says nothing.
I wonder if Black Sheep might be able to shed some light on what is and is not allowed when a phone guy finds and fixes a fault which can also be demonstrated to interfere with broadband and why a reset cannot be at least requested if not performed by the phone guy?
Stuart
I can't say I've seen anything 'set in stone' that a network engineer can't perform a DLM reset, but their 'Job standards' (which are like the bible) do not make mention that this is a requirement. They also won't be in possession of the relevant numbers, or system access to do the reset. An easy fix I hear you say, but if they do perform a DLM reset and the circuit doesn't come back into synch ..... they're screwed, as they won't know where to start ?.
However on a broadband fault it is a job standard requirement if, and only if, a service affecting fault has been located. I suppose the red-tape side of it is, the network engineer cannot conclusively prove that his remedial work has resolved all DSL issues ?? He will only be working to dial-tone if you like.
I'm not taking sides here, and this is just my personal opinion ................... the powers that be really do want DLM to be a hands-off system unless absolutely necessary.
-
Thanks BS. I'm sure that you can understand my frustration when following a line fix I have a further 26 days of problems which are then fixed by a reset on a second visit when all he does is that reset. 26 days of continuing less than optimal broadband for no good reason at all. If the attending OR guy cannot do the reset why should he not be able to request a reset by some back office person where it can be logged and tracked to prevent misuse? I do find it hard to believe that a physical line fault will not affect the broadband connection in the vast majority of cases.
I can understand the concerns in some ways but it does not seem to me to be an insurmountable problem and I feel can contribute to some of the less than optimal views people hold about BT OR. If a genuine fault is fixed on the line I honestly believe a reset is not likely to make things worse, agreed if there is another underlying issue then it may well not fix it but then nothing really has been lost and in that case if the attending OR guy is unable to do more he should be able to organise someone who can work on the issue without the EU having to play silly b***ers with their ISP to arrange a second visit.
I also understand that fixing this issue is well above your pay grade ;)
Stuart
-
I tend to agree with you about the problem of needing the two separate visits. And it especially hurts when it is all related to the G.INP mess.
There is, however, something of a proviso that needs to be built in:
without the EU having to play silly b***ers with their ISP to arrange a second visit.
a) When Openreach want to be able to take ownership of the fault, and have the ability to "route around the silly Bs at the ISP", the ISPs vetoed that possibility. The likes of Sky and TalkTalk don't want BT to be in any form of control of their subscribers.
b) The game of playing silly B's with the ISP is a consequence of buying a service from an ISP known to be lacking in the service arena. Their policy of making you wait N days before they bother to pay attention amplifies the problem with (a), which forced the back-and-forth via the ISP, making total delays longer and longer. When the service is sold with an underlying Openreach residential care policy that adds days onto each service request, you get what you got.
You're right that the problems aren't insurmountable - but it takes two to tango. If one party stays resolutely seated, the dance doesn't happen.
It sucks, but it's cheap. Thanks Ofcom.
-
You mean these two, per-chance W3 ??? ;) ::) :)
As we get closer to Ofcom's next publication on their Digital Communications Review (DCR), we expect more media and press speculation. Sky and TalkTalk are again talking to the media and making their case for Openreach to be separated from the rest of BT. ...... quote from Clive (CEO)
-
Well I spoke too soon about my line being fixed IT IS NOT! I just had my snrm on upstream drop through the floor once again for no obvious reason and a re-sync which has dropped by upstream speed to 431kbps and the U1 & U2 bands with zero snrm, downstream has also dropped in speed to 49080kbps which is a drop of some 13000kbps.
I have just told TT that I need another visit from OR and this time they must take it seriously that there is an intermittent fault somewhere between the cabinet and my master socket and it needs fixing.
Stuart
-
This intermittent fault would be hard to track down, it needs to happen when the engineers JDSU is in place and if not then no fault would show up as you noticed from the last OR visit all they did was a DLM recalc and no fault found.
PS a fault like yours can take up to 6 OR visits to finally trace and fix it
-
6 months here... several engineers, cabinet repair (not the cards in the end) Finally synced at 77mb. Hope it lasts after all this work..
-
In fact this time it seems to have gotten worse as usually it was only U1 band which went to zero but this time U1 & U2, if U3 goes as well I wont get a connection at all!
Stuart
-
Your DS SNRm has been gradually falling over 4 days since the DLM reset to me that's odd it has become a big thread has anyone suggested testing with a different modem surly the TT script would have ask this.
-
The dBm power has dropped to a negative number, does that have any relevance?
-
Ugh.
The usual problem shows on attenuation - another increase at the same time as things go wrong; yes, @ronski, power goes funny too -sometimes negative, sometimes not.
Fingers crossed it stays faulty when the engineer is there.
-
In answer to the modem/router, yes when it happened before I tried the HG635 from TT but it happened using that as well as the ZyXEL, also happened using the master socket with all internal wiring disconnected (although there's not much of it now).
Looking at DSLStats and you can see it on MDWS at around 20:05 tonight the U2 band came back at around 20+db and U0 jumped to around 17.5db with U1 still zero, I have no idea what happened then but there was no re-sync - I was out at the time.
When I got back tonight I did a manual re-sync tonight and it has come back with normal speeds but the U/S snrm/band is a bit off in that U0 came back at nearly 9db with U1 & U2 both around 6.7, U0 has subsequently been dropping but not yet down to U1 or U2 level.
I could dig out my HG612 and try that in bridge mode to the ZyXEL but I'll leave that for now.
Stuart
-
Looks like both the US & DS has developed what I call SNRm Jitter this is normal for longer lines as the modem tries to combat the effects of noise you won't see this happen where lines have very little noise on the circuit and the SNRm remains very steady over 24 hours
-
I understand about the jitter and that I probably have more noise recently however these wild swings in SNRM and drop to zero and far form normal, togther with the other indications I am fairly sure it is not my router but a problem with the line between here and the cabinet which is intermittent.
Stuart
-
The dBm power has dropped to a negative number, does that have any relevance?
My understanding is that as the unit is dBm -- decibels relative to one milliwatt -- then the negative sign just indicates that the reported power is less than one milliwatt.
-
Heard back from TT this morning, guess what? They want to wait and see if it happens again before doing anything! Unbelievable, they cannot argue that my line is working within estimate when up drops to 430kbps. I have tried to insist but dont know if it will do any good.
Stuart
-
You mean these two, per-chance W3 ??? ;) ::) :)
As we get closer to Ofcom's next publication on their Digital Communications Review (DCR), we expect more media and press speculation. Sky and TalkTalk are again talking to the media and making their case for Openreach to be separated from the rest of BT. ...... quote from Clive (CEO)
Now you mention it, it has spooky parallels with what just happened with the EU referendum.
-
Well it dropped again at 12:26 today. Now asked TT for immediate action, however they have not yet responded to my earlier update.
Stuart
-
My line seems to be getting worse so if I could only get an OR guy out now he might stand a chance of fixing the problem. My D/S is not good and has loads of errors now but the U/S is 288kbps with only the U0 U/S SNRM band with a non-zero value, plus the power is -4.4dbm.
Stuart
-
If I was tasked with resolving this elusive intermittent fault, knowing the back-history and with sight of the three plots, attached below, then I would be looking for a "one leg dis".
-
That modem is really doing well, your line is hammered!
-
Well with 1000's of errors I decided a power down/up was needed and s*d the 30 minute wait, so now I'm back with my normal speeds for now until I suspect DLM kicks in because of all the cr*p today. If I dont get someone out to fix this quickly there are probably two CEO's who might get emails ;) note I said MIGHT, I'll give them one ore chance.
Stuart
-
I am as peed off as you Bstairs your line should have been fixed during that telephone fault of course we never got what was fixed during that time yet someone here said it was an HR issue then fixed that was fixed on the E side but you still have fault on the D side.
So all i can think of your line had two faults and one is fix E side the other is not fixed D side.
-
The more I think about it, the more I can see a similarity to Bald_Eagle1's problem of some years ago.
In his case, one of the copper conductors of the pair in the "tail" cable (which links the pole top DP to the underground D-side cable) had fractured. The PVC insulation held the two ends close together and the circuit "sort of" worked, albeit with degraded performance. The circuit's performance was better in mid-winter rather than mid-summer due to the change in the PVC insulation's properties with temperature. (Softening.)
Essentially the circuit behaved as if there was a parallel resistor/capacitor shunt connected in series with one leg of the pair . . . which acted rather like a high pass filter. The defect was also vibration sensitive. So whenever the pole was climbed by an Openreach technician, the modem - DSLAM resynchronised.
-
I might do a bit of 'vibration testing' on the pole tomorrow ;) 4lb lump hammer would be useful ;) reminds me of my days as a hardware engineer when we used to also do a bit of environmental testing with a can of freon spray and a hair dryer :lol:
Stuart
-
Right now the problem is still happening and the TT Network Team are now investigating so I might get somewhere now. I'll leave my 4lb hammer in the shed for now ;)
Stuart
-
Well I've now had two days of the TT Network Team supposedly investigating but no feedback, I asked on the community yesterday but they just said no feedback yet. My line is not recovering at all now. The U1 SNRM band is staying at zero. Just to be safe I dug out my HG635 yesterday and put it on for a while to see if it did any better and eliminate the ZyXEL (which I'd done before but hey better safe than sorry) but no it was just as bad so back to the ZyXEL now as the wi-fi is better. This morning after a manual re-sync the U1 band is still zero although the error rate (FECs apart) is very low but U/S sync is 800kbps.
Now I have to wait till Monday to be able to get any feedback as I doubt there will be anyone investigating end user issues in their Network Team over the weekend.
Stuart
-
I've come to the conlcusion that DLM is downright stupid, I got hit again this morning by DLM adding more interleaving by the looks of it but still only 800kbps U/S sync with no U1 band. Whoever designed DLM seems to think that all errors or re-syncs must be caused by downstream problems when the vast majority of my problems are upstream, so all it does is make downstream worse and has zero effect on upstream, someone needs to design some more realistic options into DLM and do it fast.
Stuart
-
Right now I am quite surprised my line is working at all looking at the available tomes and the QLN and Hlog, I have only one SNRM band working up and loads of errors down. As I expected no updates from the TT Network team as I suspect they dont work much at weekends. I will be raising merry hell with TT on Monday morning.
Stuart
DLM intervened and QLN and Hlog now look better although still only one up SNRM band, the re-sync was caused by d/s SNRM going to -0.6db!
-
Right now I am quite surprised my line is working at all looking at the available tomes and the QLN and Hlog, I have only one SNRM band working up and loads of errors down. As I expected no updates from the TT Network team as I suspect they dont work much at weekends. I will be raising merry hell with TT on Monday morning.
Stuart
DLM intervened and QLN and Hlog now look better although still only one up SNRM band, the re-sync was caused by d/s SNRM going to -0.6db!
That one word speaks volumes? :P ;)
-
:lol: my awful twyping ;)
Stuart
-
Just looked at my U/S SNRM and at 19:44 U0 was 1.9 and U2 was 0.5 by 19:45 U0 was 24.2 and U2 was 23.3. A sudden jump of that magnitude with no re-sync seems very strange to me. U1 band has remained at zero.
Stuart
-
Can someone please explain to me (or point me at a document) how the bands are allocated to either u/s or d/s and whether or not my u1 snrm band being permanently 0 is because of a fault or something DLM has done to prevent the equivalent band being used. My line now looks like it is restricted to 40000kbps down and 800kbps up possibly by DLM because of all the issues I've been having and now wondering if the problem has gone away for now or being masked by the restrictions DLM has put in place. My attainable speeds show 70311kbps down and 23288kbps up. I have an OR guy coming tomorrow afternoon.
Stuart
-
Bandplan
The frequencies in each band are fixed. The ANFP specifies that we use bandplan 998ADE17-M2x-A, which is one of the 17MHz profiles.
Details of the bandplans, including the specific frequencies for the various bands, can be found here, on page 5:
http://www.joepeesoft.com/Public/DSL_Corner/Docs/Publications/PUB_2009_10_TNO35092_SpM_VDSL2_FreqAllocations.pdf
The decision whether or not to use any tone comes after the Hlog and QLN have been measured; the available SNR (plus the target SNRM of 6dB) must be above a certain threshold. This, I think, os the outcome of the "medley phase" visible in "--pbParams".
Allocating bits to tones
Then comes the process of allocating bits to tone, until the "maximum speed" has been reached. This "iterative water filling" mechanism tries to maximise speed while minimising potential errors (ie trying to keep SNRM as high as possible on each tone) as well as trying to minimise power (the upstream power backoff mechanism). This algorithm can be pretty complex (eg http://file.scirp.org/pdf/CN20110400003_95057946.pdf )
From looking at many lines, my guess is that U1 tends to be used less than it could because of the upstream power backoff mechanism. But this probably applies more in cases where the line is running at the full package speed, or the full "banded" speed.
Your U1 band
In your case, it looks much more like the modem didn't like the Hlog readings: there is nothing there in that graph, while the QLN graph looks normal. The end result is no bits, and not even any SNRM readings. I suspect U1 has been left out of the medley .... can you show us a "--pbParams" before the next sync?
Having said all that, your line looks to have recovered somewhat today, and a resync will probably restore speeds. Bad timing with OR arriving tomorrow...
-
Here is the current pbparams data today. The last re-sync was just after 8am today which I did as I was doing some testing of filters etc.
adsl info --pbParams
adsl: ADSL driver and PHY status
Status: Showtime
Last Retrain Reason: 1
Last initialization procedure status: 0
Max: Upstream rate = 23374 Kbps, Downstream rate = 69527 Kbps
Bearer: 0, Upstream rate = 800 Kbps, Downstream rate = 40000 Kbps
Discovery Phase (Initial) Band Plan
US: (6,31) (882,1193) (1984,2770)
DS: (33,857) (1218,1959) (2795,4083)
Medley Phase (Final) Band Plan
US: (6,31) (882,1193) (1984,2770)
DS: (41,857) (1218,1959) (2795,4083)
VDSL Port Details Upstream Downstream
Attainable Net Data Rate: 23374 kbps 69527 kbps
Actual Aggregate Tx Power: 5.2 dBm 5.2 dBm
====================================================================================
VDSL Band Status U0 U1 U2 U3 U4 D1 D2 D3
Line Attenuation(dB): 1.7 22.7 34.2 N/A N/A 12.1 28.5 45.0
Signal Attenuation(dB): 1.6 22.5 34.1 N/A N/A 16.0 28.3 44.9
SNR Margin(dB): 31.2 0.0 23.5 N/A N/A 10.3 10.2 10.3
TX Power(dBm): -5.5 -24.2 4.8 N/A N/A 9.6 7.3 7.4
>
Stuart
-
Don't know what to say broadstairs and spent some time looking through your on line stats on MDWS but it looks the same issue Starman had for months in 2015 and now his line is stable again after fault found and corrected by Openreach engineer.
My fingers are well crossed for you :fingers:
-
Ah, I think those params will have lost what I was looking for. Never mind.
What I seemed to miss this morning is that the upstream attainable jumped, and the actual sync recovered, but only a little. It looks to be banded at 0.8Mbps.
-
Ah, I think those params will have lost what I was looking for. Never mind.
What should I look out for in future if/when the problem recurs?
Stuart
-
Well about an hour ago an OR guy called me to say he was coming to install a new phone line :o ??? I explained that this was NOT what I expected and I've asked TT to confirm the guy coming will be a broadband guy and not a line man. Heaven knows where the communication went wrong!
Stuart
-
I can guess .................... we (OR), work to instruction given by the CP/ISP. ;)
-
Yes I can believe it was TT, I think the person ho called to arrange the appointment was from their Indian call centre.
Stuart
-
What should I look out for in future if/when the problem recurs?
Changes to the "Discovery phase band plan" and the "Medley phase band plan" figures.
-
Well the OR guy came today, stuck his JDSU on the line and told me its working OK, well I guess that looking at the stats. I suggested he reset the line again but he said he would go to the cabinet to do some more diagnostics and that I'd see a line drop, well I didn't see any further line drops and when I drove past the cabinet he was nowhere to be seen. He tried to tell me that there is a probable issue with TT equipment in the exchange causing this and that each customer has their own fibre connection back to the exchange from the cabinet. Now I don't really believe that the fibre is run for each user, my basic understanding was that FTTC was like extending the exchange to the cabinet - I can't see each end user having their own bit of fibre. The guy that came did not seem the slightest bit interested in the evidence I have of an intermittent fault.
So I'm left with a line capped at 40meg down and 0.8meg up which is woeful and well below what I am paying for and the line is capable of, even the wholesale line checker says impacted I should get 55meg down I think. OK now I have a fight on my hands because I know TT will say wait for DLM to recover the line and will say anything else is beyond their capability to affect. I will see what response I get on the TT forum but I expect to have to contact the CEO once again. The biggest issue this time was the delay caused by their network team who sat on this issue for days before doing anything about sending OR out, Had they been quicker the OR might have come while the fault existed.
Stuart
-
Engineer No3 and no fault found and your modem is showing your line has been in sync since 8:01am 20/7/2016 when they test with this JDSU do they not take the modem offline during the tests and then plug the modem back in after all is done and this would show up as new resync
-
Yes, the EU's modem/router would need to be unplugged for a minimum of 10mins whilst the mandatory 'PQT' and 5 minute 'DSL Close out test' were completed.
Chances are it would usually be slightly longer as the engineer explains the results to the EU, but as I say ....... minimum of 10mins.
-
Cheers BS any idea why the engineer would say he was going to the cabinet to check and then from broadstairs beady eye's he never showed up in that location
-
I wouldn't know, NS ............ with respect to Stuart, one can't monitor the synch status of the router whilst driving to the Cab at the same time ?? Maybe something happened during the crossover point ?? It seems that the monitoring stats haven't picked up on the engineers need to test at Stuarts premises, maybe the engineer did break the circuit down again at the Cab and it's not been picked up again on the stats ??
The problem with intermittency or a miniscule fault that our test systems won't pick up on, is that the engineer stands a high chance of getting a 'Repeat report' against him if the EU raises another fault. As the Cab is the piece of equipment that sees the most footfall from engineers, and lots of messing around in them, it is good practice to perform a visual inspection in there for signs of accidental damage.
All guess work.
-
Lets get something straight here over timings. The initial testing started at around 14:26 and finished at about 15:25 and I reconnected the router while the engineer was with me and showed him the re-sync stats. Now if he was going to do some testing it would take him probably 5 minutes to get to the cabinet park up (which is not easy where my cabinet is situated), then open it and cause a disconnect which would have lasted more than a minute which means that neither DSLStats or my router would have missed the disconnect - IT DID NOT HAPPEN. So IF he went to the cabinet and did anything it DID NOT cause a disconnect and re-sync - so frankly my interpretation of what he said which WAS that whet he was going to do WOULD cause a disconnect is bull***t as I suspect was his description of how FTTC works. This guy was in my opinion significantly less than effective than the previous broadband guy who at least viewed my graphs and agreed I had a problem which he agreed had probably gone away but at least he did a reset which put me back to around 65mbps d/s and 20mbps u/s which lasted for about 11 days!
So now I am left with a line which is connected at less than the worst speed which the Wholesale Speed tester says I should get if impacted and well below what it has been performing at prior to all this happening. TT are probaly goping to say that DLM will over time put it back but previous experience says it will not happen.
Yes believe me I am only too well aware from personal experience when I was working as to how difficult it is to try to fix intermittent faults but that does not mean you do a test and GIVE UP, which is what OR are doing in my opinion. OK it does not help at all when TT do not take these issues seriously and try to get OR on site while the simply MUST be able to see an issue is live. If this were the first call out I might accept it but this is the third call on the same issue and has not been resolved. None of this is acceptable and I will not put up with this situation. Believe me TT and OR do not know what will hit them if they don't take an indisputable issue seriously.
Rant off ;)
Stuart
-
I can offer no advice as how to progress this fault to a satisfactory resolution . . . but will follow this thread with a significant degree of interest. :-\
-
I'm confused ............. NS states .................
"Engineer No3 and no fault found and your modem is showing your line has been in sync since 8:01am 20/7/2016 when they test with this JDSU do they not take the modem offline during the tests and then plug the modem back in after all is done and this would show up as new resync"
Yet Stuart states the circuit was out of synch during .... "The initial testing started at around 14:26 and finished at about 15:25"
The two are contradictory.
-
Forget what MDWS may show as the router was not shutdown but the OR guy simply pulled the plug, so believe me in what I said and I have the DSLSTats Eventlog to prove it, the router was disconnected at 14:36 and the first and so far only re-sync was at 15:25 so that was about the time the OR guy left to go to the cabinet. I was with him the whole time. There is NO ambiguity about this.
Stuart
-
Not being one who uses MDWS, it appears that there is ambiguity when reading the various comments. I can only pass comment on what is asked .......... which in effect was, is there any modem downtime during the engineers tests ??
There is, and from your own comments a whole 50mins of it. Is it normal for MDWS to miss this amount of time ??
-
Taking a close look at B*stairs' circuit data on MDWS, I see that there is a recorded uptime of just over 6 hours. That fits into the time frame which Stuart has reported. :)
-
NS .............. were you looking at MDWS through a blindfold, mucker ?? :P ;D
-
NS .............. were you looking at MDWS through a blindfold, mucker ?? :P ;D
I seen the uptime and it showed 0.4hrs but my focus was on Resyncs MDWS is still showing 20-7-16 08:01 which is kind of confusing to me.
-
MDWS has a slight issue with re-syncs, it relies on DSLStats on the other monitor to tell it there has been one. In my case DSLStats could not do this because the OR guy simply pulled the plug and then I stopped DSLStats recording and filling up its event log with No DSL connection messages. In fact it also had a slight hiccup and so I closed the program and restarted it with recording stopped until such time as the router was in sync therefore no reporting to MDWS of a re-sync. I think this is an issue for Eric and Tony to review and perhaps record monitor start ups but that is for them to decide.
I'd still like a view on this OR guys description of each end user having their own piece of fibre - just does not make sense to me. Also should one expect diagnostics to be done at the cabinet and should those always cause a disconnect?
Stuart
-
Absolutely not ...... you have your own port, but not your own fibre.
Diagnostics at Cab ?? Absolutely yes ......... capacitance readings between A-E and B-E are better monitored on a 'dead' pair of wires .... ie: Cab to NTE .......... also 'Tapping' fault conditions that a one-shot test like a PQT may miss can be observed, this (obviously) will cause a dis-connect.
-
I can understand the confusion.
The mode of operation of MDWS, to detect resynchronisation events between the modem and DSLAM, relies upon the metallic pathway being contiguous immediately prior to and post the event. If the metallic pathway has "just disappeared", as in this case, then a resynchronisation event may be logged but it is not possible to update the database. We must remember that there is a two stage process involved before any of us third parties can see the data as graphical plots . . . the harvesting software (DSLstats, in this case) and the database updating & displaying software (MDWS).
Perhaps I should also add that just like a physical broadband service, DSLstats, HG612_stats & MDWS are "best effort" software services. We have to accept that what can be deduced may need to be a compromise after the consideration various basic data sets.
-
Sounds a bit like the trouble I had... One of the main issues was poor sync rates. several visits by fibre engineers were unable to diagnose the issue and from the tests done said the line was normal. The last engineer only spotted an issue when the port at the cab was not giving out an 80mb sync after a lift and shift.. could not figure out what was wrong with it so referred back to noc who passed it to pcr engineers.
My line was never at fault.
-
Thanks BS
I suspect the cab visit was more bulls**t since he obviously did not cause any disconnect, plus the fact that about 10-15 minutes after he left I drove past the cab and there was no sign of him or his van, and this cab is by double yellows on a corner and the road is usually full of cars where parking is allowed. Obviously I cannot prove this BUT I do feel it was highly unlikely he did anything.
Stuart
-
Very helpful indeed thanks broadstairs and burakkucat into how the stats up-loader can miss resyncs
-
MDWS has a slight issue with re-syncs, it relies on DSLStats on the other m to tell it there has been one. In my case DSLStats could not do this because the OR guy simply pulled the plug and then I stopped DSLStats recording and filling up its event log with No DSL connection messages. In fact it also had a slight hiccup and so I closed the program and restarted it with recording stopped until such time as the router was in sync therefore no reporting to MDWS of a re-sync. I think this is an issue for Eric and Tony to review and perhaps record monitor start ups but that is for them to decide.
Thanks B*cat...
The 'Uptime' value shows your router actually resynced at around 14:57 but you didn't restart DSLstats until 15:25. If you had restarted DSLstats within 15 mins of sync being established, the resync would have been caught. And, as noted, no guarantees mind you as there are too many variables involved in running the system for it to be totally reliable. MDWS already does way, way more than I had ever envisaged but isn't and never will be infallible so please don't expect it to be.
I could add in the record manually if you want, the reason in the data is '1 RDI'
-
You are indeed correct Tony about the timing however it still does not show any subsequent re-syncs or the AS time would be different.
Stuart
-
Correct, no subsequent resyncs.
-
I can offer no advice as how to progress this fault to a satisfactory resolution . . . but will follow this thread with a significant degree of interest. :-\
I'm in a similar vein here. I can offer the following:
Spotting when the line is bad:
The current banding means that the *speed* is no longer a good indicator that things are going wrong with the line. Similarly a "non-standard-but-flatish SNRM" doesn't tell us much. Every time I look across all the graphs, the best indicator I can see that correlates to "fault-being-present" is a higher-than-normal attenuation value. A secondary indicator is a variable-jittery SNRM.
Getting Openreach to attend when the line is bad:
Openreach can only fix the fault if the line is bad at the time they attend ... which is obviously delayed from the point you first notice the issue. In one sense you are lucky - because your fault tends to stick around for some period once it has occurred. However, TalkTalk are getting in the way here, because the fault doesn't hang around long enough for their incessant pauses and delays.
What will help you most is if you can get Openreach to attend ASAP after the fault is first noticed. Bypassing the TalkTalk delays as much as possible.
What you probably need to do, as an outcome from this visit, is to talk to the TT team, and get them to agree
- Your fault is intermittent.
- That, when it occurs, there is a window afterwards when Openreach could detect and fix it.
- That it needs an appointment arranging as soon as you can see it next occurs.
- That your fault remains open, so that the pauses and delays can be bypassed next time.
- That you will monitor, and phone as soon as you see the problem re-occur.
- They will arrange an appointment without delay.
If anyone else can add something to speed up the TT-delay -> Openreach appointment time, please add it...
MDWS already does way, way more than I had ever envisaged but isn't and never will be infallible so please don't expect it to be.
I agree. I tend to not bother looking for the resync indications added by the monitors, and just look for disjoint data: sudden jumps in SNRM, sync speed, attainable speed, or power.
Or I look for "gaps" in data - which might show as a physical gap in the graph (as in broadstairs "SNRM" graph), or it might appear as a sloping line that shows on the graph, but can't be hovered over in the normal way (showing "dots with data"; such as the "Sync Attainable" graph). In latter cases, hovering only produces a "dot" at the extremities of the slope.
however it still does not show any subsequent re-syncs or the AS time would be different.
I concur. There is no sign of anything other than the one disjoint period.
but that does not mean you do a test and GIVE UP, which is what OR are doing in my opinion.
Unfortunately, this is one of the consequences of Ofcom's version of "competition", and the dash for "pile it high" cheap services. I suspect the desire for a "known appointment time" is a significant constraint on flexibility. Altogether, there is a need for appointments to be constrained, with little time for "engineering perfectionism" in the face of a potential wild goose chase.
OK it does not help at all when TT do not take these issues seriously and try to get OR on site while the simply MUST be able to see an issue is live. If this were the first call out I might accept it but this is the third call on the same issue and has not been resolved. None of this is acceptable and I will not put up with this situation. Believe me TT and OR do not know what will hit them if they don't take an indisputable issue seriously.
One aspect of support that works really badly is dealing with complicated faults that run over multiple calls/appointments. Our current model of interaction between ISP and wholesaler makes this horrible - especially when you encounter an ISP whose procedures force more delays.
I'm pretty sure you'd have a better experience if this were going via AAISP's support group. It wouldn't be fixed in one go, but it would run around the cycle faster.
-
As for what the last attending Openreach technician did at the PCP, it is an unknown . . . other than it did not cause a resynchronisation event.
I think we can all imagine the following (having noted Stuart's description of where the PCP is located) . . . The van pulls up, with the two nearside wheels on the pavement, over the double yellow lines at the corner with hazard lights and amber beacon operative. Openreach technician opens the PCP and sees similar to that below, then notes a "jobsworth" traffic warden homing in on the van, whilst sucking in her cheeks, ticket book all ready for action. The PCP doors are slammed shut, locked and away goes the van . . .
[attachment deleted by admin]
-
Look at all those gel crimps how the hell could a engineer find a users pair in that BLEEP :o
-
Use one of these:
http://www.ebay.co.uk/itm/BT-Engineers-Tone-and-Probe-Deluxe-Set-Openreach-Virgin-Media-87J-109J-17A-/272297244062
Attach the oscillator to the line at the customer end, and take the probe to the cabinet. When the probe is within a few cm of the right cable, it will let you know.
or, of course, use the cabling records ;)
-
Lets get something straight here over timings. The initial testing started at around 14:26 and finished at about 15:25 and I reconnected the router while the engineer was with me and showed him the re-sync stats. Now if he was going to do some testing it would take him probably 5 minutes to get to the cabinet park up (which is not easy where my cabinet is situated), then open it and cause a disconnect which would have lasted more than a minute which means that neither DSLStats or my router would have missed the disconnect - IT DID NOT HAPPEN. So IF he went to the cabinet and did anything it DID NOT cause a disconnect and re-sync - so frankly my interpretation of what he said which WAS that whet he was going to do WOULD cause a disconnect is bull***t as I suspect was his description of how FTTC works. This guy was in my opinion significantly less than effective than the previous broadband guy who at least viewed my graphs and agreed I had a problem which he agreed had probably gone away but at least he did a reset which put me back to around 65mbps d/s and 20mbps u/s which lasted for about 11 days!
So now I am left with a line which is connected at less than the worst speed which the Wholesale Speed tester says I should get if impacted and well below what it has been performing at prior to all this happening. TT are probaly goping to say that DLM will over time put it back but previous experience says it will not happen.
Yes believe me I am only too well aware from personal experience when I was working as to how difficult it is to try to fix intermittent faults but that does not mean you do a test and GIVE UP, which is what OR are doing in my opinion. OK it does not help at all when TT do not take these issues seriously and try to get OR on site while the simply MUST be able to see an issue is live. If this were the first call out I might accept it but this is the third call on the same issue and has not been resolved. None of this is acceptable and I will not put up with this situation. Believe me TT and OR do not know what will hit them if they don't take an indisputable issue seriously.
Rant off ;)
Stuart
sadly openreach are just doing what they agreed with ofcom and the CPs as acceptable.
Ofcom accept it because they only cared about low wholesale pricing, even if quality went down the gutter.
It stinks, they basically only checking for voice quality compliance, but openreach will just see it as they complying with what they have contracted with the CP. Occasionally engineer's show up who have pride in their work and will go above what they need to do, but is luck of the draw. I think CPs can order engineers that will do more than just the sin compliance checks but of course this costs more money, and they probably wont tell you if they doing that.
-
I think this is an issue for Eric and Tony to review and perhaps record monitor start ups but that is for them to decide.
I haven't been ignoring this, but I'm afraid that personal circumstances are such that it's difficult finding enough time to do jobs which are already on the list...
-
B*Cat ....... we are told one is not allowed to use 'hazards' and 'rotating beacon' at the same time, it's one or the other. Also, there are agreements in place with local councils that we are allowed to park on double-yellows so long as we display the required notification on the van dashboard ..... ie: arrival on-site time etc etc ..... :) :)
NS ...... as W3 points out, we can use a manually applied tone and amp set to identify a circuit, alternatively we can apply an automatic tone by using our mobile phones, rather than having to use the manual set. Both send a low-frequency tone (like a beep-beep noise ) down the line, and our amps (Amplifiers) can hone into which pair of wires it is on.
However, before either method is deployed, simply using the counting technique will bear fruit in 95% of cases ....... the pair of wires in the very top left hand corner are allocated as E and D1, then working towards the bottom of the strip which will be E and D100. The 2nd strip then starts at the top as E and D101 ............... and so on ................
There are different kinds of Cab terminations though and 'Counting' can become impossible on the much-hated 'Midland Shelf Cabinets' ......... nasty b'stard things they are >:(.
-
Eric no worries, this is a minor issue and now we have cleared the air about re-syncs and recording them in MDWS I don't believe it warrants any urgent attention I suggest add it to the list of things to do IF/when you get time ;)
I just had DLM intervene this morning now back at 54564kbps down and 20000kbps up, so for once DLM has done something right :o and now to see how long before it lowers interleaving which is 2003/1 and delay of 11 and of course how long before the problem hits once again ;)
Stuart
-
RESYNC SOLUTION
Rest easy Eric :)
Having stared at the code for several hours (I need some sleep), I've worked out a way to hopefully get sight of resyncs that occurred some time back when the line was down, hours, days or even weeks possibly. Each uploaded data log from the modem contains the info for the last resync so this can be done. It hasn't been because I need to write the database query completely and that I have now done.
So now, when a line comes back up the resync check looks back a period of time to see if there are any unrecorded resyncs that are later than the last recorded one for each user. For now it's just 4 hours (rather then 15 mins as currently) but it is running as of 07:40 and hasn't generated additional resync messages which was a worry. I'll increase it once it all looks like it's working, probably to 24 hours initially.
-
Sounds like a plan Tony... thanks
Stuart
-
the pair of wires in the very top left hand corner are allocated as E and D1, then working towards the bottom of the strip which will be E and D100. The 2nd strip then starts at the top as E and D101 ............... and so on ................
The principle is the same as cabinets with Krone strips, though, isn't it?
That the E-side pairs end up located somewhere known within the cabinet, provided you know the pair number. Same with the D-side pairs.
And that a job to connect any one subscriber to the exchange entails adding a shortish length of jointing wire, so as to connect the right E-side pair with the right D-side pair. It just looks messy...
The obvious next question ... in an existing cabinet full of gel-crimps, what happens to FTTC tie pairs? Do they get krone strips added? Or do they end up relatively loose like the D- and E-sides?
-
To answer your question about FTTC 'Ties' ....... it is totally random. In the picture posted above in this thread, I can tell just by looking that the FTTC ties are on the far right hand strip. As this is a 'Gel crimp' Cab, it would follow to make the new 'Ties' exactly that as well.
However, in many other instances the 'Gel crimp' Cab will see the new 'Ties' presented on BICCS/Quante strips, or NON-IDC strips .......... there doesn't seem to be any rationale to it, just what the planner/installer has decided upon at the time !!.
To answer your other question, yes indeed ...... we run one piece of Cab jumper wire to connect up the 'Copper' E side to 'Copper' D-side if the EU is wanting ADSL or simply a PSTN connection ............. if they are wanting FTTC, then we have to run two jumper wires to cross-connect the services.
It matters not whether it is a 'Gel crimp' Cab or a typical IDC Cab ....... they still end up looking messy ....... I suppose the 'gel crimp' one does have the edge though, when it comes down to it. ;) ;D
-
Attached, below, are two images of within PCPs which each have an associated "fibre twin" cabinet.
The first image shows one pair of tie-cables at the right hand side of the cabinet. Each tie-cable has a "cabinet-height" length of outer sheath removed, the respective wire bundles grouped together (with cable ties) and hanging from appropriately placed hooks. When a circuit is enabled with a G.993.2 (VDSL2) service, the D- & E-sides have the existing gel-crimps removed and the relevant pair from each tie-cable crimped to the afore mentioned freshly isolated D- & E-sides. (For those who are considering the total number of crimped joints per G.993.2 enabled circuit in such a cabinet, it is doubled.)
The second image shows one pair of tie-cables terminated onto Krone strips. (Note the legend above the Krone strips . . . someone had accidentally terminated the pair of tie-cables in the incorrect positions.) When a circuit is enabled with a G.993.2 (VDSL2) service, the D- & E-sides have the existing gel-crimps removed and are extended (with blue/yellow jumper cable) across to the Krone strip field. (For those who are considering the total number of crimped joints per G.993.2 enabled circuit in such a cabinet, once again, it is doubled.)
(My thanks are due to Walter for providing the two original high resolution images from which the attachments have been created by cropping and scaling.)
[attachment deleted by admin]
-
Ta.
I wonder why there isn't a straight policy about whether the tie pairs should be in strips.
Do strips ever get retro-fitted in PCPs? Is there any sort of "tidy everything up" policy?
-
Considering the amount of working circuits in any one Cabinet, it's surprising there aren't a plethora of faults raised every time we enter such a structure. It's a fact that 'Human intervention' in any part of the network, has a potential to inadvertently affect other circuits ........ but we don't have as many Cab faults as you would maybe imagine ?.
That said, there are always anomalies ........ and we have a system in place called 'Play your Ace' whereby every month a high-fault node will be identified and submitted to our other departments for an uplift ........... not just Cabs, it could be a faulty length of cable, a weak joint etc etc .......
As with any business, there are always budgets ............ and the money has to be appropriated to where there will be maximum gains. It works, by the way. :)
-
Well there you go that's were crosstalk comes from inside the PCP cabinet
-
That said, there are always anomalies ........ and we have a system in place called 'Play your Ace' whereby every month a high-fault node will be identified and submitted to our other departments for an uplift ........... not just Cabs, it could be a faulty length of cable, a weak joint etc etc .......
Haha - we would have something similar.
The code we wrote was in systems that had longevity - so stayed around for a long time, being added to again and again. Each new project would spend (of course) the bulk of time & money developing the new features that the marketing people had figured was best - though we always had to figure out how to add that in ways that stayed maintainable. But we also had some budget that we were allowed to spend on fixing our own blunders. Something that didn't turn out too well in a previous project, or something that was getting a lot of attention in the maintenance group.
As one of the architects, one aspect of my job was to figure out the candidates in our subsystem, and justify to the managers why it was worth spending some money on it. It even worked sometimes, but boy - did the marketing guys try to keep pushing that stuff out again!
-
Well there you go that's were crosstalk comes from inside the PCP cabinet
Crosstalk between lines is inversely proportional to the distance between the lines. That is, crosstalk is worst when the wires are squished together tightly, next to one another, and least when the wires run separated by a gap.
The air gaps in the PCP help reduce crosstalk; wires running next to each other within one cable are worse; in fact wires running next to each other within a subgroup of a cable (aka a "binder"; for example, a 100-pair cable is probably internally sub-divided into 4 binders of 25 pairs) is worst.
The worst place for crosstalk is likely to be a pair in the middle of a binder surrounded by pairs that are all carrying VDSL2 too ... which would be in the tie cables between PCP and DSLAM. Thankfully, the tie pairs are fairly short - which helps limit crosstalk. Yes - crosstalk is another reason why the PCP and FTTC cabs shouldn't be far apart!
Take a look at this crosstalk "heatmap" of a 100-pair cable, subdivided into 4 binders:
(https://s32.postimg.org/77xt3e8o1/Adtran_Crosstalk_Heatmap.png) (https://postimg.org/image/77xt3e8o1/)
You can see the worst crosstalk happens between pairs in the same binder (the "squares" apparent on the diagonal).
If a second 100-pair cable was pulled into the duct in parallel to this one, there would be very little crosstalk between pairs in the separate cables. There would be just too much of a gap between the,.
-
Well DLM seems to have its act together at the moment :o it intervened again this morning reducing the impact of interleaving again. I hope I'm not being too optimistic to think it might reduce further over the next couple of days ;)
Stuart
-
Going to have to keep an eye on my line as the phone still causes a glitch on both u/s and d/s SNRM, not huge but certainly noticeable, had a call at around 09:30 today which shows up the glitch.
Stuart
-
Just had DLM intervene a while ago to reduceinterleaving again but now my u/s sync has gone silly again with U1 & U2 bands at zero and a sped of just over 400kbps.
Stuart
-
And again attenuation rises.
Strangely, when looking at the line attenuation figures for the individual bands, they all follow this increase except U1, which does the opposite.
Time to push TalkTalk.
-
And try to get the OR Engineer to run one of those CIDT tests (Copper Integrated Demand Testing) on your line
-
Well I did get a unsolicited text from TT this afternoon saying they knew I had a problem so that might just be hopeful. I have not yet rattled their cage as there is usually no one there at weekends unless I speak to the Indians (not something I want to do really!)
Stuart
-
And try to get the OR Engineer to run one of those CIDT tests (Copper Integrated Demand Testing) on your line
A CIDT test should be run at the 'Fault reception' level.
-
Another re-sync tonight and all 3 u/s bands have come back but my speed is well below what it should be at 6586kbps.
Stuart
-
DLM intervened again this morning and u/s back to normal d/s at just under 60000kbps and fastpath. So looks like the problem has cleared again --- for now.
Stuart
-
Yes, it looked like the line cleaned up around 6am, and the removal of FEC+interleaving bumped speeds up to a 60/20 banded speed, with attenuation back to the normal level (a drop of 0.5dB from Sunday's level).
However, things went wrong again at 08:52; attenuation jumped by the 0.5dB amount (so still not up to the "fully bad" level), and SNRM was haywire. Then another resync 5 minutes ago.
-
Yes both these latest re-syncs coincided with incoming phone calls on the landline, one annoyingly from a scammer claiming to be TT.
My problem with these calls is because I might get a genuine TT call I have to answer all calls. Currently there is no way to easily identify these scammer as too much information about TT users is out there. I have written to Dido Harding about this today in the hope she will try to do something, I suggested a while ago that they allow users to set a calling password or phrase on their account which TT must user if they call which would help.
Stuart
-
Yet another re-sync now back to only U0 U/S SNRM band in use, no phone calls this time.
Stuart
-
If the line goes bad again, and you arrange an engineer, and then the line appears "fixed" shortly before the engineer's arrival, can you just keep making calls into the line to trigger it back to "bad"?
-
Well I did try that before but it did not work, worth a try again certainly though.
Stuart
-
Well the line has recovered and yes looks banded at 60/20 which is not bad if it is reliable although I'd prefer it not banded. Once it recovered I did try yesterday phoning home to see if it still hit the SNRM and yes it does but so far no enough to cause a re-sync, I'll see what happens later today and whether or not it goes bad on its own or whether from phoning home.
Stuart
-
Well while we were out today it all went pear shaped once again around midday and recovered by about 14:00.
Now to see what TT's network team will say this time.
Stuart