Kitz Forum
Broadband Related => FTTC and FTTP Issues => Topic started by: samwise78 on July 19, 2015, 10:18:26 AM
-
Hi there,
Long first post (sorry)
I've been having intermittent issues for months with my Infinity, on activation was getting sync of 79995/20000 and all looked fine, was performing brilliantly.. For a couple of weeks. Then the resyncs began for no apparent reason, DLM woke up and I ended up with a 25Mb sync speed - was running a Homehub 5 (Type A) at that point.
Raised multiple faults throughout the saga, had multiple engineer visits:
Visit 1 - Engineer installed new drop wire and SSFP, line test was clear, DLM reset, full sync restored - for a week or so
Visit 2 - Engineer attended while I was at work, replaced my Hub with one he had in his van (?!) This rebooted itself after an hour or so and never came back, factory reset wouldn't work, so mithered the helpdesk constantly until they sent me a Type B as a replacement (I'm on a Huawei cab)
Once that arrived sync drops reduced drastically, however monitoring the connection via the noddy Helpdesk page showed me huge noise margin fluctuations and changing attenuation, quiet line showed nothing, but sync speed was slowly dropping back to sub 40Mb - upload sync was <1Mb, logged another fault.
Visit 3 - "Engineer" visited, did a PQT and said he couldn't do anything. He mentioned aluminium, also tried to tell me my sub 1Mb US sync was "because it was half-term", claimed the sync speed at the time was the best it could be (43Mb) :lol:
Once I recovered from Visit 3 I escalated and got another appointment sorted.
Visit 4 - Boost engineer visited, tested line at my house and the pole, got a hoist out to replace a cover that was missing, still seeing a lot of errors, went to the cab and then sorted a lift and shift out due to a "faulty port"
Once this was sorted, here's where things get really weird (for me anyway)
He tested sync at the house while he was waiting for the lift and shift to complete, told me his JDSU had just had a firmware upgrade for vectoring, he got an 84Mb sync.. :o
When my "profile had been applied" got a seemingly solid 68/20Mb sync
Over the moon with that, considering the bull I'd been fed by the other engineers - although his 84Mb sync perplexes me..
Since then the drops have returned, but apparently only in the evening.
I can instigate one by picking up the phone and using it. Snap, crackle & pop obvious and gets worse and worse until sync is lost.
I can track the SNR loss on the "Helpdesk" page of the Hub, until it loses sync.
It will always then resync at an abysmal speed and then recover on its own a short while later.
See below:
After lift and shift
5. VDSL uptime: 0 days, 17:28:24
6. Data Rate: 19999 / 68206
7. Maximum Data Rate: 21945 / 68651
8. Noise Margin: 13.8 / 6.2
9. Line Attenuation: 0.0 / 16.6
10. Signal Attenuation: 0.0 / 0.0?
16/07/15 - HR fault? Resynced while on phone
5. VDSL uptime: 0 days, 00:14:01
6. Data Rate: 19999 / 47642
7. Maximum Data Rate: 18638 / 36771
8. Noise Margin: 3.9 / 2.0
9. Line Attenuation: 0.0 / 17.7
10. Signal Attenuation: 0.0 / 0.0
16/07/15 - resynced on its own 19:16
5. VDSL uptime: 0 days, 00:08:18
6. Data Rate: 19999 / 68776
7. Maximum Data Rate: 22393 / 69584
8. Noise Margin: 14.1 / 6.4
9. Line Attenuation: 0.0 / 16.6
Now, I suspect this is some sort of HR fault, it seems worse when it's wet too.
So, instead of raising as an Infinity fault this time, I've logged as a voice fault in the hope they'll be thorough enough to find the issue. Engineer is coming tomorrow (AM) so noise probably won't be present.
So (and if you got this far well done) how would our resident experts approach this, have I done the right thing?
Also, how would the boost engineer have got an 84Mb sync??
Cheers
Samwise
-
I suspect it was an 84Mb attainable sync.
-
are you sure it wasnt 84 attainable? as even on open profiles 80mbit is the max sync which typically would be 79999.
your issue with the calls definitely smacks of a HR issue. Swapping nte5 can fix these HR issues, but if that does no good an engineer will have to track it down.
-
My thoughts are that you have done exactly the right thing. Lets hope you now get a decent engineer ??
FWIW, regardless of whether the audible noise is or isn't present, I would demonstrate how the DSL drops synch when the landline is in use. This should be enough to get the dimmest of engineers interested. I would also humbly suggest that the 'HR' is likely to be on the D-side (From Cab to Pole). If it was on the E-side (Exchange to Cab), although the landline would still be noisy, it wouldn't cause a FTTC Broadband circuit to drop synch.
PS ..... welcome to the forum. :)
-
Thanks all for the replies and the welcome, good to get some validation on my thought process here.
We'll see how tomorrow's visit goes. :fingers:
Re the 84Mb attainable sync the boost guy got on his JDSU, why is my attainable "only" 70Mb if his was 84Mb?
Cheers
Samwise
-
Because your Homehub is controlled by BT via the BTAgent and they are "managing your expectations", perhaps?
-
Because your Homehub is controlled by BT via the BTAgent and they are "managing your expectations", perhaps?
I highly doubt that.
Perhaps the JDSU just performs better on your line than the HG612? Was the actual sync the same as previously or was that higher too?
-
Because your Homehub is controlled by BT via the BTAgent and they are "managing your expectations", perhaps?
I highly doubt that.
Because you're on TalkTalk, who follow you around the web checking the websites you visit.
-
I wish I could give you an answer to that.
Vectoring has only just started to be rolled out to three large-scale areas, and if the engineers JDSU previously had the Infineon SIM (as mine did), he would have had the upgrade to the Broadcom SIM.
With the SIM came a few sheets explaining what vectoring and G.INP technologies were all about, and a couple of pictures showing where the 'Vectoring on/off' options is, but that was it. It's now a steep learning curve as to how to use this new SIM and what it is telling us ?? I believe our Engineers Office are giving more info in their next quarterly publication ?
With that in mind, I only recently visited an EU on FTTC complaining of slow-speeds (2meg). Although a fair distance from the Cab, it was star-wiring causing the issue and once removed my JDSU reported a synch of 12.8meg with the attainable being ever so slightly more.
I proceeded to connect the Hub5 and with my works laptop connected via an Ethernet lead, I was surprised to see the circuit was only getting throughput speeds of approx. 8meg !! This was my last job of the day and I literally didn't have the time to delve deeper (ie: what speed the Hub was actually synching at), but when closing the job I noticed that for the first time ever, that the circuit had vectoring enabled ( a one-word notification listed under the DSLAM details).
My point is, I was left wondering if indeed I was seeing the full vectored speeds against my JDSU, and the EU was just receiving normal VDSL speeds ??
Now that I know when a circuit is actually vector-enabled, I hope to be able to spend a little more time 'buggering about' with my JDSU and the EU's equipment for comparisons. Alas, time is one thing we don't have in abundance at OR <stats-driven madness> :)
-
Perhaps the JDSU just performs better on your line than the HG612? Was the actual sync the same as previously or was that higher too?
I'm running a HomeHub 5 Type B only, no HG612
My sync was significantly better post lift and shift but the difference in attainable Hub vs JDSU is interesting.
I can't see G.INP being enabled making a 14Mb swing in attainable rate but then without a HG612 or another router I won't be able to see if G.INP has been enabled..
If it has been enabled what does this imply about the performance of the Hub given that it's deemed G.INP capable?
Cheers
Samwise
-
My HH5B synced at maximum 80/20 when G.INP was enabled.
Are you connected to a Huawei cabinet?
-
My HH5B synced at maximum 80/20 when G.INP was enabled.
Are you connected to a Huawei cabinet?
Yep, cab is Huawei and pre Type B I synced at the maximum for a couple of weeks.
Service was activated in March. Only ever saw maximum since then after 1st engineer visit and DLM reset.
As far as I know I was the first on the cab, so I expected an effect from new activations.
To be clear I'm not expecting the max now, any benefit from G.INP would be nice though.
If I can get this HR issue sorted I'll be happy - but the difference in JDSU attainable and Hub attainable is still an oddity that I'd love to know more about.
As Black Sheep pointed out, he's already seen something similar in the field - although a sample of one isn't definitive.
I'll try and get the HR sorted and will look into another router or HG612 to get some decent stats once resolved.
Cheers
Samwise
-
Do you know your approximate line length?
-
Do you know your approximate line length?
Boost engineer said it was quite short but the lookup on the Kitz cab checker states 649m.
I think that a 68Mb sync is pretty good to be fair, the issue being the daily drops and the HR fault.
Trying not to get wrapped up in the chase for full speed but the JDSU attainable is intriguing
Cheers
Samwise
-
thanks for the info BS as usual.
Although the fatc you had to use a broadcom chipset may not bode well for ECI peeps again :p
Can you reveal if the customer with the vectoring enabled was in a BDUK area or not?
-
thanks for the info BS as usual.
Although the fatc you had to use a broadcom chipset may not bode well for ECI peeps again :p
Can you reveal if the customer with the vectoring enabled was in a BDUK area or not?
No worries, Chrys ........... although there isn't much info to give I'm afraid :'( :)
We don't get any information regarding whether the DSLAM was commercial or BDUK installed, so I wouldn't know. The area is what one might call rural (ish) ..... so it may well be BDUK ?. Purely guesswork though.
-
Am also in a rural area (if it makes any difference - doubt it)
Service was enabled via Connecting Shropshire so BDUK too.
Will update thread tomorrow once engineer has visited.
Wondering now which BDCM based device I should look to get so I can monitor goings on a bit better?
HG612?
Don't much like the Billions
Netgear D7000 looked promising - but expensive and getting a mixed reception
Zyxels are rarer than hen's teeth
Anything better on the horizon that doesn't cost the earth?
Cheers again
Samwise
-
I recommend the HG612 v3B
-
Cheers, yeah just trying to find one on the bay that I don't feel robbed after buying, Adding £20+ to the price for unlocking them is insane given how straightforward it is..
-
Yeah, looks like someone on Ebay is passing off an ECI modem as a HG612 currently :(
-
Aye, saw that.. Not surprised it's got no bids, not hard to work out the difference is it :no:
A few on there that don't specify the variant of HG612 either, waiting on replies to clarify before I move on anything.
Given the symptoms on my fault I don't expect the HG612 to fix anything, but at least I'd be able to see what's going on..
Cheers
Samwise
-
Also, how would the boost engineer have got an 84Mb sync??
That would be perfectly feasible, following a DLM reset (circuit re-calc). At that time, the circuit would be operating to it physical limit. I.e. a totally "wide open" profile.
-
That would be perfectly feasible, following a DLM reset (circuit re-calc). At that time, the circuit would be operating to it physical limit. I.e. a totally "wide open" profile.
He saw 84Mb with his JDSU while we were waiting for the lift & shift processes to complete..
Immediately before which, the HH5B was connected and I could see the attainable rate (69-70Mb) but there was no sync.
When he unplugged his JDSU and reconnected my kit, the HH5B synced at 68Mb, it didn't sync any higher and drop down which I would have expected following a DLM reset - I'm making a leap though and assuming a DLM reset happens during a lift & shift.
If - as suggested by a few people this was the attainable rate as viewed by his JDSU - then the question still is, why does the HH5B attainable 'only' state (at times) 70Mb and not 84Mb? ???
Cheers
Samwise
-
Something doesn't add up here.
When we perform a 'Lift & Shift' on FTTC, we have to be at the Cab to prove that a) The new port actually synchs up, and b) That we can get dial-tone through the copper tie cables.
All new ports given have a default profile of 40Meg DS and 15Meg US. Once our DCoE confirm they can see the 40/15 profile against out JDSU, they immediately disable this profile.
Generally, the 'Lift & Shift' takes approximately 20-30 mins, during which time the old port will also be completely disabled. So the bit I don't get whatsoever is how the engineer could see ANY kind of synch speed during the entire process ?? It's impossible.
-
If - as suggested by a few people this was the attainable rate as viewed by his JDSU - then the question still is, why does the HH5B attainable 'only' state (at times) 70Mb and not 84Mb? ???
By the time that the HH5B was connected, the 80/20 Mbps profile had been applied to the circuit? Have we considered that the HST-3000c and the HH5B have different impedances and thus load the circuit differently? It is a difficult situation when one attempts to correlate absolute values between devices. Relative values with the same device are quite clear cut. :-\
. . . I could see the attainable rate (69-70Mb) but there was no sync.
If the xTU-R and the xTU-C were not synchronised, then there is no data exchanged between the two ends of the circuit. No attainable rate should be displayed. It is a physical impossibility. That must be due to a firmware defect of the HH5B.
-
Something doesn't add up here.
When we perform a 'Lift & Shift' on FTTC, we have to be at the Cab to prove that a) The new port actually synchs up, and b) That we can get dial-tone through the copper tie cables.
All new ports given have a default profile of 40Meg DS and 15Meg US. Once our DCoE confirm they can see the 40/15 profile against out JDSU, they immediately disable this profile.
Generally, the 'Lift & Shift' takes approximately 20-30 mins, during which time the old port will also be completely disabled. So the bit I don't get whatsoever is how the engineer could see ANY kind of synch speed during the entire process ?? It's impossible.
He did say something about 40/15 and did disappear down the road for a while during the process, I was in the room while he called someone to disable the default profile but my recollection of chronology may be skewed as I was looking after my 3 month old lad that morning, and he was onsite for about 4hrs in total :angel:
It did take around 30 mins to complete and he made a couple of calls during the process, he commented on the 84Mb figure before reconnecting my HH5B on his return to the house - but I didn't get to see his JDSU. Whether that was the actual attainable I don't know, makes sense as my first sync back in March (before the gradual loss of speed) showed an attainable of 95Mb, which soon evaporated..
I'm beginning to think it was the attainable, but can't figure out why JDSU would see attainable of X and why my HH5B would see attainable of Y (Y being X minus 14Mb)
If I'm honest I'll forget all about that if I can get the HR issue sorted, and get something I can actually check my stats on.. :)
Cheers
Samwise
-
If the xTU-R and the xTU-C were not synchronised, then there is no data exchanged between the two ends of the circuit. No attainable rate should be displayed. It is a physical impossibility. That must be due to a firmware defect of the HH5B.
All I was going on was the Helpdesk page of the HH5B while I waited for the guy to come back to the house which looked a bit like this:
6. Data Rate: - / -
7. Maximum Data Rate: 22231 / 69527
Whether this is a firmware bug or not I don't know, the Hub is on Software version v0.07.03.0814-BT and the latest version according to BT is V0.07.01.0235-BT ?? ???
Yet another reason I want to either ditch the Hub completely, or stick a HG612 in front of it.. :wall:
Cheers
Samwise
-
Certainly looks like BTAgent running things as I said.
-
Certainly looks like BTAgent running things as I said.
I must say that I have never heard of BTAgent affecting sync speeds.
-
Again as I said before, you're on TalkTalk so you wouldn't. As I am on Infinity and used a HH5 I have experience.
-
Again as I said before, you're on TalkTalk so you wouldn't. As I am on Infinity and used a HH5 I have experience.
Please could you go into more detail? I'm sure this would be very useful for other people.
-
About BTAgent? Ok, get a HG612 and turn it off. I use DSLstats with a custom command set to turn off BTAgent on a resync.
-
About BTAgent? Ok, get a HG612 and turn it off. I use DSLstats with a custom command set to turn off BTAgent on a resync.
And what affect does that have on the sync speed of the line?
-
I sync at full speed, but that isn't the question. The question is about max attainable.
-
I sync at full speed, but that isn't the question. The question is about max attainable.
Okay what affect does it have on the max attainable speed then?
-
I sync at full speed, but that isn't the question. The question is about max attainable.
Got a HG612 3B on the way, it'll be interesting to see if my attainable goes up as a result of disabling the agent.
I'm not saying it won't but I've not seen any other accounts of this happening.. :fingers: :)
Cheers
Samwise
-
With reference to the BTAgent (and I will try to be brief, as I do not wish to hijack samwise78's thread), if one looks back at the initial post to the thread where Wolfy (a.k.a. Howlingwolf) announced (http://forum.kitz.co.uk/index.php/topic,14262.msg267144.html#msg267144) his rebuild of the latest firmware for the HG612 the following can be seen --
In all builds, BTAgent will remain untouched and still active. However in builds which include the web interface, it will be neutered by disabling it's VLAN.
This can be re-enabled through the web interface by going to Basic --> WAN.
- Select ptm1.301 under Connection Name.
- In the config panel below that, Enable 'WAN connection' and submit.
This will give people the choice. Enable it to receive updates or disable it to prevent them.
The BTAgent uses the VLAN tagged with 301. If that VLAN is disabled (or deleted), the BTAgent has no means of communicating with the wider world. It is unable to report back the modem's status, it is unable to pull an updated firmware image and upgrade the device.
Fairly recently, in the Thinkbroadband fibre forum, I have noticed a "bout of chattering" on the subject of disabling the BTAgent, the redundant "do-nothing" tab that was in the original GUI interface (which Wolfy removed in his firmware rebuilds), speculation and guessing. And that is all I shall say on the topic. :-X
-
PTM 301 is used by BT Wifi.
-
So you're now purposefully avoiding the subject: is it because you're posting unsubstantiated claims?
-
I recommend you read the thread as all your questions have been answered at least once already.
-
The only forum member who has said the BTAgent has any effect on sync speeds or attainable sync speeds is you.
The only thing it does is to report your sync speed, as burakkucat quoted.
It's responses like this which make me doubt anything you say:
Because you're on TalkTalk, who follow you around the web checking the websites you visit.
It's almost like you're a troll.
-
The only thing it does is to report your sync speed, as burakkucat quoted.
I'm sorry, I haven't seen that said - ever.
-
I'm sorry, I haven't seen that said - ever.
I didn't say you did ???
Hence why I said he quoted somebody else...
-
I'm sorry, I haven't seen that said - ever.
I didn't say you did ???
Hence why I said he quoted somebody else...
Can you provide a link to where he quoted someone else saying this?
-
It is unable to report back the modem's status, it is unable to pull an updated firmware image and upgrade the device.
-
It is unable to report back the modem's status, it is unable to pull an updated firmware image and upgrade the device.
I'm sorry, that's not the same as
The only thing it does is to report your sync speed, as burakkucat quoted.
Not even close :no:
-
But you still haven't provided any evidence of your claim. Please show me data of an improved attainable sync by having the agent enabled.
-
OK..
This is great chaps but we're drifting OT a bit I think.
Back to the possible HR fault, just got off the phone for a 30 minute call to my folks and - while I had some noise in the first minute or so that I watched having a negative effect on my DS noise margin (6.4 to 5.5) it stopped after 10 seconds or so..
We've had a bright, warm day here today after a wet night. I'm wary of incurring a charge if the issue isn't present tomorrow when OR attend, or does anyone think describing the issue will be enough assuming it's not demonstrable?? :no:
Cheers
Samwise
-
My phone causes a reduction in SNRM, so I don't think that's a problem or a symptom.
However, noise on the line is a fault and when it disappears while on the call is one symptom of an HR fault.
-
The phone causing a noticeable reduction in SNRM is indicative of an HR fault. Do you ever get any crackling on the phone line?
-
The phone causing a noticeable reduction in SNRM is indicative of an HR fault. Do you ever get any crackling on the phone line?
Yep, has been regularly each evening for the last week or so whenever the landline is used (DECT phone)
Have tested behind the SSFP and with a BT corded phone to try and eliminate both the SSFP and DECT phone.
Noise still present on all tests which (until tonight) would lead to a resync and bizarre stats (see 1st post)
Starts out as crackle and popping which gets worse/louder until resync - been watching the effect on DS margin as it drops from 6.4 down to 5, 3, 1, then Hub reports NaN in the DS margin field and drops connection.
If I stay on the phone at that point - the noise clears temporarily, but then continues and the connection instability continues.
If I clear down the call, it stays at that sync for 15 mins or so and then resyncs back to the previous speed (near as dammit)
Cheers
-
The engineer shouldn't have a problem seeing that as a fault especially given you've had DLM resets in the past which have degraded.
-
I'm almost certain it's an HR fault then.
Any competent OR engineer would agree and track it down I would think.
-
Well, engineer has just left, got here shortly after 8.30am
His tester did show "high resistance on one leg" which he eventually tracked down to the UG chamber across the road.
He didn't do much to clear it, he put a tone on at the master and then tested from the chamber which apparently cleared it (?)
Replaced the SSFP as belt and braces too.
Hasn't affected my sync speed which to me says he hasn't made the line any worse, which is a positive.
Rudimentary stats as follows:
6. Data Rate: 20000 / 68715
7. Maximum Data Rate: 23341 / 69710
8. Noise Margin: 13.8 / 6.4
9. Line Attenuation: 0.0 / 16.4
10. Signal Attenuation: 0.0 / 0.0
Hopefully won't have any further issues, but I'm not 100% how the fault was resolved at the chamber, would he have to have remade the joint there?
Got a HG612 on the way too, so will at least be able to keep an eye on things a bit closer too.. :fingers:
Cheers
Samwise
-
So your stats before were
16/07/15 - resynced on its own 19:16
5. VDSL uptime: 0 days, 00:08:18
6. Data Rate: 19999 / 68776
7. Maximum Data Rate: 22393 / 69584
8. Noise Margin: 14.1 / 6.4
9. Line Attenuation: 0.0 / 16.6
Looks like your sync speed (data rate) is on fastpath upstream but a bit slower downstream and your attenuation has fallen slightly. The max attainable has increased too.
Is your phone line noisy? Dial 17070 option 2 for the Quiet Line Test and listen, it should be silent.
-
Quiet line test is clear and no negative impact on noise margin either.
I'd expect that anyway as I only had issues in the evening..
Will keep an eye on it as I'm still not sure how it was cleared by testing back from across the road..
Cheers
-
Yes, it will be good to get your HG612 running and your stats up on MDWS :)
-
Sounds like he did very little.
I'm sorry to sound negative but I suspect you'll be having issues again shortly :(
-
C'mon now ..... lets not go down the avenue of slating the poor engineer through naivety of what a telecom engineers job involves ;).
If he has found a HR at the joint in a UG chamber over the road, then it sounds like it was one of the many easily-accessible joints to open, and simply cutting back and re-making the pair of wires feeding the OP's circuit would take all of 10-15mins in total. That's including setting up of safety barriers and signage if required ???
To answer the OP's question ...... he would only have to re-make the whole joint if there were 'Blue-billy' connectors in place, or there was corrosion taking place throughout the joint. Other than that, we just work on the pair of wires reported faulty ..... otherwise we'd never get anything done. :)
-
In my own experience that I'm sure BS will remember very well, finding the actual HR location, especially if it appears intermittently is the hard part.
Fixing it, once located, is usually child's play.
It sounds like your engineer has done the necessaries.
Just testing at the joint will have involved disconnecting & remaking it, so it should now be good again.
Do you know if he requested a DLM reset/circuit recalc?
If not, DLM will hopefully detect a reduction in error counts & improve connection speeds in due course.
Regarding stats monitoring, I would recommend using HG612 Modem Stats for long term monitoring & DSLStats (with HG612 Modem Stats co-operation set) for the 'here & now' monitoring, allowing just one of them to upload data to MDWS.
-
Thanks all..
I can't complain about the engineer today at all, he did everything he could do and so far, so good. :fingers:
No DLM reset completed, but we'll see how things pan out once I deploy the HG612, thanks BE for the tip on monitoring.
Will update this thread again if there's any deterioration and once I've livened up the OR modem
Cheers
Samwise
-
Just to update the thread - have finally got the HG612 up and running..
Registered on MDWS as samwise78 and as far as I know have been uploading data. :graduate:
Looks like I've had G.INP enabled, couldn't say when to be honest, line has been fine since OR attended the other day.
I've finally hit a 70Mb sync despite the several OR guys telling me I'd be lucky to get above 40, let's hope it lasts. :fingers:
Can anyone take a look at my stats and advise how things are looking?
Cheers
Samwise
-
Just a quick update on this one, since my lift & shift was completed and the subsequent HR fault cleared AND deploying the HG612 in front of the HH5, my connection seems spot on.
Apart from a 19999 US sync that I don't appear to be able to get rid of in favour of the 20000 my OCD "demands" I think things are looking awesome so far.
Can anyone take a look at my stats on MDWS and offer any thoughts?
(Had a little break in uploading this week but should be back to normal now)
Cheers
Samwise
-
Your Hlog seems to suggest that you have a bridged tap.
-
Agreeing with Alec. :) There is something "not right" being displayed in the Hlog plot. :-\
It appears to be quite close to the transition from an US band to an DS band, with a minima somewhere in the region of tone 2600 - 2700.
-
Agreeing with Alec. :) There is something "not right" being displayed in the Hlog plot. :-\
Me too :-\
-
Thanks for the insights, sorry for the delayed reply, night shifts taking their toll!
What should I do about it though, as I'm not seeing any (obvious) performance issues?
Cheers
Samwise
-
All you can do is to follow the cabling from the point where it reaches your property all the way to the NTE5/A. Look with a critical eye and ensure that there are no "abandoned" sockets / lengths of cable connected. If there is anything suspicious or something you do not understand, take a photograph and make the image accessible so that we can view it.
-
Thanks burakkucat..
Well, there aren't any lengths of cable actually connected but during the life of the multiple faults I had, OR fitted a new cable with sausage and SSFP..
The original cable and extension despite being disconnected are still present.. See pics they should help explain what I mean (hopefully)
New cable is black..
Cheers
Samwise
[attachment deleted by admin]
-
Looking at those two images I can't see anything untoward. (It looks as if there is a redundant BT16 fitted to the fascia board just to the right of the bracket.)
Does the bottom end of that new cable go directly into the NTE5/A? Do you have any internal wiring connected to the NTE5/A; wiring that feeds extension sockets?
-
It does go direct to the Openreach SSFP the guy fitted the same day..
No internal wiring or extensions whatsoever now, there was when we moved in but I disconnected them on day one
Previous owners ran multiple extensions from the old master, but these definitely aren't connected to the new one..
Cheers
Samwise
-
Your Hlog seems to suggest that you have a bridged tap.
See the attached MDWS graphs.
Although the U2 band is not now visible in your own stats, probably due to poorer SNR than samwise78, the visible elements do appear slightly similar (in shape).
Could your own connection possibly have a slight HR/bridged tap somewhere?
It has been mentioned previously that your U2 Hlog graphs didn't look quite right, especially when some of the U2 data was visible.
It may be better to further discuss your own connection in the AlecR's woes thread though, rather than divert attention from samwise's thread.
-
Oh yes. There does appear to be a degree of similarity between the two separate Hlog graphs.
I would guesstimate that the minimum is between tones 2850 - 2900, for Alec's circuit.
-
Ok, so based on what we know how would I go about getting this resolved?
What other symptoms would I be able to spot or use to get a fault logged - given that the sync speed is well within tolerances?
Even then, if I get as far as an engineer visit, I'd have to show him the Hlog and hope he's bothered enough to sort it out.
What would be required in terms of resolving a bridged tap?
Cheers
Samwise
-
I suggest you pick up the phone, dial 17070 and run the Quiet Line Test. If you hear any crackling, it will be an HR fault.
-
Even then, if I get as far as an engineer visit, I'd have to show him the Hlog and hope he's bothered enough to sort it out.
What would be required in terms of resolving a bridged tap?
This JDSU document explains bridged taps:-
http://www.jdsu.com/ProductLiterature/sctpsbridgedtap_an_tfs_tm_ae.pdf
For anything between your NTE & the cabinet, you would have to rely on an engineer agreeing to check for & remedy any potential bridged taps.
You Hlog graph may assist in convincing him that it is worth checking out.
It is not unknown for bridged taps to have been left in place when D-side cabling partial pair swaps have been conducted over the years, probably from pre-broadband days when a new customer was connected to & the pair extended from a previously ceased connection & when it didn't really matter too much.
In your own home, it could be extension or wiring or even an alarm company having incorrectly connected to the line before or at the NTE.
Maybe a 'dodgy' faceplate or dangly filter could also have a similar effect in that the phone & DSL signals are not sufficiently 'separated'?
-
Even then, if I get as far as an engineer visit, I'd have to show him the Hlog and hope he's bothered enough to sort it out.
What would be required in terms of resolving a bridged tap?
This JDSU document explains bridged taps:-
http://www.jdsu.com/ProductLiterature/sctpsbridgedtap_an_tfs_tm_ae.pdf
For anything between your NTE & the cabinet, you would have to rely on an engineer agreeing to check for & remedy any potential bridged taps.
You Hlog graph may assist in convincing him that it is worth checking out.
It is not unknown for bridged taps to have been left in place when D-side cabling partial pair swaps have been conducted over the years, probably from pre-broadband days when a new customer was connected to & the pair extended from a previously ceased connection & when it didn't really matter too much.
In your own home, it could be extension or wiring or even an alarm company having incorrectly connected to the line before or at the NTE.
Maybe a 'dodgy' faceplate or dangly filter could also have a similar effect in that the phone & DSL signals are not sufficiently 'separated'?
I absolutely take your point, BE, but a bridged-tap on the actual D-side cable is extremely rare. It is more likely to be (as was in your situation), in the Cabinet on the Krone, Quante terminating strips. It can happen whereby the engineer won't notice there are a pair of wires already terminated on the EU's allocated termination. This is usually due to the amount of wire and position of the strip (generally low down and difficult to see), and they will inadvertently terminate their jumper-wire over the top of the existing wire. I know, as I've done it myself. :blush:
There is a possibility of a bridged-tap on the D-side cabling if the EU is on an extremely long line. We used to do 'Bunched pairs' for these rare situations as their landline would be reported as 'Faint'. As touched upon by yourself, it didn't matter with PSTN (Dial tone frequencies).
However, seeing as the OP is getting 70Meg, he must be close to the Cabinet and as such the situation I mentioned above is highly unlikely to pertain to his circuit. :)
-
That sudden
increase decrease in attenuation is just as likely to be due to an HR fault.
Is your line overhead?
-
There is a possibility of a bridged-tap on the D-side cabling if the EU is on an extremely long line. We used to do 'Bunched pairs' for these rare situations as their landline would be reported as 'Faint'. As touched upon by yourself, it didn't matter with PSTN (Dial tone frequencies).
However, seeing as the OP is getting 70Meg, he must be close to the Cabinet and as such the situation I mentioned above is highly unlikely to pertain to his circuit. :)
I knew you would recall the extensive avenues we went down in researching my line's issues a few years ago ;).
I admit we are possibly clutching at straws here & I would personally be more than happy to see anywhere near 40Mbps, never mind 70 Mbps, but I have seen quite a few user Hlog graphs lately that do indicate some sort of an issue (possibly relatively minor & not particularly service affecting), when compared with the ideal smooth graph shape.
-
Perhaps our views differ on this but if the graphs show a clear issue (which I believe the OP's do), I don't think it is unreasonable to believe that the issue should be fixed.
There's an argument that the average user wouldn't be reporting this as an issue but that is irrelevant. It is a service you pay for and it should be fault-free.
-
AlecR
Quiet line had a very very faint crackling for around 10 seconds but that was it..
Line is UG from cab to chamber across the road from me, then takes a pole-->pole-->house route (can chuck some more pics up later if it helps)
Bald_Eagle1
Thanks, I've read that doc before.
Am confident that there's no internal wiring connected, there are the remains of old drop wire and extension as visible on the pics I posted a few posts back - but I didn't think these would be the cause as they aren't connected to anything
Black Sheep
Line is 650m according to most resources.
I'm pretty happy with a 70Mb sync given my rural location.
Is it possible the Hlog "gap" is caused by anything else or is it likely to be another (or the original) HR fault?
Previous OR engineers told me I'd never get above 65Mb as there was ali in the cable run..
I notice that the SNR per tone also plummets to 0dB around Tone 2650 to 2795 which I assume is another marker for the same issue.
Thanks to all for the input so far, I'm weighing up the pros & cons of logging this out at the moment..
Cheers
Samwise
-
Crackling sound indicates an HR fault. Log it with your telephone provider.
-
You can use the automated line checker to see if a fault is detected https://www.bt.com/consumerFaultTracking/public/faults/reporting.do?pageId=21
-
No fault detected (as I expected)
I've just had an unexpected resync though:
Reason: 1 Remote Defect Indicator/DLM
-
The test does seem to reset the line, sometimes.
-
Don't think running the test cause the resync, resync happened a good 45 mins later.
Stats show massive burst of CRCs & noise margin nosedive :no:
I wasn't aware of the resync until afterwards so couldn't say if there was anything via quietline
Have re-opened the original HR fault ref with BT.
Curiouser & curiouser
-
Holy thread resurrection Batman :cool:
And a year later here we are still.
I've been so busy I never got to the bottom of this one, but after foolishly trying out the new BT "Smart" hub - realising the errors of my ways and redeploying the HG612, I have another fault logged and an engineer visit booked for Thursday.
Symptoms are still pretty much the same - although I'm getting sporadic bursts of errors through each day - as well as numerous resyncs - despite the noise margin appearing to hold..
I've been uploading to MDWS when possible - although it's only when this machine is logged in I'm afraid, hence the gaps.
Can someone take a look at my stats and advise best way forward? We still looking at a possible bridge tap?
Cheers
Samwise
-
We still looking at a possible bridge tap?
Tentatively, I'll say "yes". The certainly appears to be some infrastructure problem . . . a fault with the metallic pathway. :-\
-
Thanks burakkucat
Fingers crossed I get a diligent enough engineer to locate and resolve
The issue re-reared its head during the recent heatwave (another clue as to the issue maybe?)
Coupled with the testing and rejection of the Homehub 6, DLM stepped in and has banded my connection for good measure.
Cheers
Samwise
-
As you appreciate, the Hlog plot gives a very strong hint that something is not correct. As that obvious minimum is occurring at the junction of the US2 & DS3 bands and the higher frequencies of the US2 band are unusable, we are unable to fully quantify the frequency involved.
-
It is an issue that I'm hoping can be sorted on Thursday
Noticed my attenuation has also increased now from 16.6 to 19.2 as of around midday
Something not quite right!
-
Quick update following the Openreach visit yesterday..
They couldn't find any fault while at my property, reported PQT was good and passed all tests they ran on JDSU "really clean D side" apparently.
Mooched off down to the cab - on return advised me they couldn't get the full 80/20 at the cab which is a bit of an odd one - I'd expect them to get full sync?
Dismissed my suggestion it could be a bridge tap based on the dip on hlog, didn't push any further as they weren't the most receptive..
Also asked me what interleaving was, as they rang the DCoE for a DLM reset and were advised the diminishin sync speed was due to interleaving.. ???
When I queried them not being able to get full sync at the cab, suggestion was I should ask the CP to upgrade the line plant for more speed.
I know the BTw ADSL checker is theoretical - but it does state two ranges 1 x clean and 1 x impacted..
My range for clean is 80 - 64.8 and impacted is 65.5 - 35
If my D side cable is as good as OR are implying, shouldn't my sync be in the clean range?
I offered the possibility of my reduced sync being down to more subscribers at the cabinet but this was also dismissed by the engineer.
For more giggles I jumped on Live Chat with BT afterwards and relayed the suggestion from OR that the CP can pay for an upgrade to the line plant - and apparently I now have a boost engineer appointment for the 17th. I won't hold my breath - just hope it's not the same chap who came yesterday..
Wondering if it's really worth the effort, logically given the contradictory nature of the fault I want to get to the bottom of it.
Will switch on stats again later when I get home from work, laptop is currently sleeping away from my toddler's inquisitive grubby mitts
Cheers
Samwise
-
They couldn't find any fault while at my property, reported PQT was good and passed all tests they ran on JDSU "really clean D side" apparently.
Mooched off down to the cab - on return advised me they couldn't get the full 80/20 at the cab which is a bit of an odd one - I'd expect them to get full sync?
I'd expect that too. Some people on here have had cases of a faulty port on the DSLAM, and have needed to be shifted to a new port. I don't know if that applies to you though.
Dismissed my suggestion it could be a bridge tap based on the dip on hlog, didn't push any further as they weren't the most receptive..
Shame. It would have been interesting to see if his JDSU detected the same thing.
Also asked me what interleaving was, as they rang the DCoE for a DLM reset and were advised the diminishin sync speed was due to interleaving.. ???
Interesting. From MDWS, it looks like you originally had G.INP activated (INP=48) - aka retransmission - which comes with a small amount of interleaving. In your case this was a depth of 16. In general, G.INP is the best way for a line to be set up, and doesn't come with any particular reduction in speeds.
Your line stayed like that until 16:28 on the 11th August, when logging stopped briefly. Logging started up again at 16:49, but your line had, by then, put full interleaving in place (INP=3, interleaving depth=981). This might have been due to a DLM intervention (because of multiple resyncs, perhaps), and might have been due to a DLM reset (some types of reset cause this level of interleaving to be the norm, at least for the first 48 hours). However, in your case, this interleaving only stayed in place until 16:55, when logging stopped again.
Logging then started up again at 17:09, but this time it was without interleaving of either kind (so no G.INP retransmission either). Some types of DLM reset do this (and is what all DLM resets used to be until relatively recently).
Do you know if they did two resets? I'm wondering if all their investigations caused a DLM intervention to add interleaving, which the DCoE saw 5 minutes later as "reduced speed caused by interleaving", and they then did a reset.
Having said all of that (related to interleaving), it looks more like your line was actually banded, and had an artificial speed cap of 49/15 set on it by DLM. This will have been set try to keep it stable in the face of errors or resyncs.
The first DLM reset or intervention (that put full interleaving in place, alongside a hefty amount of FEC protection) looks to have removed the banding restriction, and allowed your sync to increase to 50.1/20; here, the speeds will indeed have been reduced because of the FEC protection that sits alongside the interleaving.
The second DLM reset (that took away all interleaving and retransmission) looks to have kept the banding restriction away too, and allowed your sync to increase to 53.8/20.
Because the first "DLM event" took away banding, rather than merely adding interleaving, I'd say it was actually most likely to have been a deliberate reset by DCoE rather than an automatic DLM intervention.
I know the BTw ADSL checker is theoretical - but it does state two ranges 1 x clean and 1 x impacted..
My range for clean is 80 - 64.8 and impacted is 65.5 - 35
If my D side cable is as good as OR are implying, shouldn't my sync be in the clean range?
The speeds used in both the clean and impacted estimates come from the 80th and 20th percentiles ... which means *most* lines that have similar properties (60% of them) fall within the estimates. 20% get a higher speed, and 20% get a lower speed.
If an engineer has attended, and given your line a clean bill of health, then you should indeed have a line that can be classified as "clean", and should indeed be able to compare your speed to the "clean" estimates. It doesn't mean that, automatically, you must be one of the 60% though.
It is worrying, though, that your line continues to exhibit the signs of the bridge tap (from the Hlog graph). The knock-on consequence (in the bits/tone graph) shows you are likely to be missing a chunk of speed ... but perhaps not enough to give you a huge boost - I'd estimate around another 5Mbps.
Note: From JDSU documents, this bridge tap is likely to 4 - 4.5m long.
I offered the possibility of my reduced sync being down to more subscribers at the cabinet but this was also dismissed by the engineer.
They're likely to know just how many subscribers are using the DSLAM, but it is hard to judge how many are affecting your line.
For more giggles I jumped on Live Chat with BT afterwards and relayed the suggestion from OR that the CP can pay for an upgrade to the line plant - and apparently I now have a boost engineer appointment for the 17th. I won't hold my breath - just hope it's not the same chap who came yesterday..
Wondering if it's really worth the effort, logically given the contradictory nature of the fault I want to get to the bottom of it.
Others can advise on that better.
However, it is noticeable that your rate of errors increased as of 9pm yesterday and further as of 7am this morning. As of 8:45 (when logging stopped), the Errored Second counter had reached high enough to ensure that DLM will intervene shortly. Whether it will add banding, interleaving, or G.INP is unknown.
Something is definitely getting errors onto the line ... but whether a boost engineer could fix it, I dunno.
-
They would NOT get a better speed at the Cab because your circuit is 'Banded'. Only if it was on 'Open profile' would the speed differ over distance.
There's only two places a 'Bridged Tap' can be (99.9% of the time) ........... the Cab or more usually, the house.
-
They would NOT get a better speed at the Cab because your circuit is 'Banded'. Only if it was on 'Open profile' would the speed differ over distance.
Doh - of course. Should have been obvious once I realised it was banded.
So banding actually makes an engineer's life harder when investigating faults. Another reason why it should be rare...
-
The gap in logging is because I have stats running on a laptop that frequently needs closing due to prying toddler am in the process of moving the install to an always on machine away from his grubby mitts..
Yes there did seem to be 2 resets before it settled down.
The Openreach guys seemed confused that they didn't get a full 80/20 at the cab, can't offer more than that.
I had a boost visit last year and was moved onto a different port then - the boost guy at the time got 80/20 on his JDSU while at my house I recall but for whatever reason when he plugged me back in the Hub didn't sync above 60 (before I used a HG612 that was)
I mentioned crosstalk from other subs as whenever there's a power cut I seem to resync quicker than those around me as my attainable shoots right up (this can be seen 5 days ago on MDWS)
At work now so will review rest of the points and comment further..
Thanks for the input it's good to get a more informed view!
Cheers
Samwise
Sent from my SM-G930F using Tapatalk
-
Doh - of course. Should have been obvious once I realised it was banded.
So banding actually makes an engineer's life harder when investigating faults. Another reason why it should be rare...
Hmmm ?? Again, this is question that can not be answered generically. It would depend on the engineers knowledge, and whether he/she applies this knowledge .......... ie: looking at the DLM history which gives lots of info including the current circuit policy .... as in if it is banded or 'open'. :)
-
They would NOT get a better speed at the Cab because your circuit is 'Banded'. Only if it was on 'Open profile' would the speed differ over distance.
They reported being unable to get full sync at the cab after the DLM reset had completed, and suggested I should raise it to the CP to "upgrade the lineplant" - but then in the same sentence told me my d-side was perfect..
Having said all of that (related to interleaving), it looks more like your line was actually banded, and had an artificial speed cap of 49/15 set on it by DLM. This will have been set try to keep it stable in the face of errors or resyncs.
Yep - I concluded I had been banded by DLM after foolishly trying out a new BT Smart Hub - which flapped like a pigeon in a greenhouse until I removed it a couple of days later and restored my current setup, the banding and the intermittent noise on the line led me to log another fault in the first place which led to the engineer visit..
Something is definitely getting errors onto the line ... but whether a boost engineer could fix it, I dunno.
I don't know where the errors are coming from, the phone line sounds fine now and was perfect while Openreach were in attendance. Before that and probably again - there's some crackling at the beginning of a call which disappears and reappears after a random period of time..
I'm wondering if old and unused external cabling could be having an effect here or if I'm clutching at straws, if it was an issue I'd hope it would have been picked up by any engineer during any of the previous visits over the last 12 months.
I'm beginning to think it could be a combination of crosstalk via increased takeup since my install (I was one of the first on the cab and happily chugging away at 80/20) - and some aluminium in the d-side somewhere.. Could that lead to more errors as speed increases??
Not necessarily bothered about hitting full sync if I'm honest, something still isn't right though and Openreach are struggling to figure out what it is..
Cheers
Sam
-
They reported being unable to get full sync at the cab after the DLM reset had completed, and suggested I should raise it to the CP to "upgrade the lineplant" - but then in the same sentence told me my d-side was perfect..
Then this is a very simple fix ..... it needs a 'Lift & Shift' to remedy the fault.
Now please don't take this the wrong way, but with over 30yrs experience in dealing with the public in Telecoms take it from me, it is very, very easy for the EU to misinterpret what has actually been said. I know from personal experience.
The reason I highlight this is because there is no reason on Earth to "ask the CP to upgrade the lineplant" ...... the CP doesn't own it, Openreach do. Did they actually mean ask the CP for a new DSLAM port ?? I've no idea ?? Either way, IF what is being stated here is the full unadulterated account of what happened ....... then the engineers should have requested a 'Lift & Shift' (a new DSLAM port) whilst at the Cab, IF they couldn't attain full synch on an open profile ??
-
Now please don't take this the wrong way, but with over 30yrs experience in dealing with the public in Telecoms take it from me, it is very, very easy for the EU to misinterpret what has actually been said. I know from personal experience.
The reason I highlight this is because there is no reason on Earth to "ask the CP to upgrade the lineplant" ...... the CP doesn't own it, Openreach do. Did they actually mean ask the CP for a new DSLAM port ?? I've no idea ?? Either way, IF what is being stated here is the full unadulterated account of what happened ....... then the engineers should have requested a 'Lift & Shift' (a new DSLAM port) whilst at the Cab, IF they couldn't attain full synch on an open profile ??
I won't take it the wrong way!
I'm reasonably up to speed with ownership of the infrastructure and demarc points along the way.
I work for BT (not Openreach) - they knew this too as we were discussing what I do for BT (Cisco network engineer), so I was amazed when they pointed me back to the CP/BT to progress, I was waiting for an "only joking mate" but it never came..
They mentioned a lift & shift / possible faulty port before heading down to the cab, but no mention of it again on their return - I'm a listener and let people work a fault onsite, it was their last job of the day so maybe they didn't fancy the work to fix? I don't know..
Don't think I'm missing anything out, I didn't record the conversation (!) but managed to get the job notes for the visit from a helpful live chat agent later that day, I'll post them later when I get home if it helps and happy to answer any questions if there's anything missing from my recollection so far..
-
Yeah ..... the job notes would be a great help, cheers.
-
Doh - of course. Should have been obvious once I realised it was banded.
So banding actually makes an engineer's life harder when investigating faults. Another reason why it should be rare...
A engineer with intuition would do a DLM reset "before" diagnosis, as DLM will not paint a true picture of the state of a line.
Of course this conflicts with what BS told us where engineers have been advised to only do a reset when a fault is fixed, but my install engineer told me he does reset on all lines he has a fault reported for.
-
This is where knowledge and experience count. Viewing WHOOSH (DSL data), checking out previous reports (if any), knowing the locality (cable make-up, previous REIN issues) is the fault an ELF (Early Life Failure), listening to what the EU is complaining of (sometimes it's just the wi-fi, not the connection they have trouble with) ….. etc …… all go into determining if I would perform a DLM reset before faulting.
There is NO hard and fast rule I abide by, but the reasoning behind the decision NOT to perform a reset willy nilly is there to prove to the EU a fault has been found. On EVERY task, we are expected to visit the EU's premises first and demonstrate the connection speed etc on the HHT. Then, if we find a fault like a bridged-tap or an unfiltered device etc …… by correcting the fault and performing a reset, we have proven to the EU an issue has been resolved.
There are a lot of dis-believing people out there, Chrysalis.
-
@Blacksheep - Clarification, sorry if I'm being thick. Is it the case that if you were to do a DLM reset first off, before actually investigating and making necessary changes, then it might misleadingly make it look to the user as if you'd fixed things even though you haven't really addressed the real cause of the problem? (Because doing a DLM reset might instantly improve the apparent performance stats, although the good stats wouldn't last long.)
-
You need to read here, Weaver …….. http://forum.kitz.co.uk/index.php/topic,18273.0.html
Right, I'm off out for a meal and copious amounts of ale, with t'wife and friends. :) :) :)
-
Like WWWombat, I would have appreciated sight of the results of a TDR scan on the circuit. :-\
Would it be possible that you could borrow a suitable device and then perform the measurement yourself?
-
Yeah ..... the job notes would be a great help, cheers.
Here are what I was given by BT chat later on, his notes don't align exactly with what he actually said to me but read into that what you will:
"On arrival all tests ok.
Pqt passed with good results.
Vdsl test passed with slightly below speeds at property.
Drove to PCP where speeds were still low, carried out a DLM reset and speeds did not increase.
Dcoe stated that the interleaves was preventing the speeds so has been removed.
Speeds now higher however I have advised Mr <samwise> that if he wants higher speeds then he
will need to discuss with his service provider about a more thorough diagnosis as the d side connection
is in very good condition.
Ltok on completion using eclipse."
Like WWWombat, I would have appreciated sight of the results of a TDR scan on the circuit. :-\
Would it be possible that you could borrow a suitable device and then perform the measurement yourself?
None of the ex-Openreach guys I know have a JDSU, and they're a bit steep to buy for this sole purpose - are there any affordable* devices you could point me at (make/model) that could fulfill the same function adequately?
*I realise affordable for one person isn't necessarily affordable for another..
Cheers
Sam
-
Doesn't user CrazyTeeka have a JDSU ? He/she will know how much they are/have tips on where to get one from. I suspect there's no substitute on the cheap, as these devices have a lot of costly hardware in them which is essential.
-
None of the ex-Openreach guys I know have a JDSU, and they're a bit steep to buy for this sole purpose - are there any affordable* devices you could point me at (make/model) that could fulfill the same function adequately?
Occasionally a Tester 301C will appear on eBay. (A simple TDR device, subsequently replaced by the Hawk, subsequently replaced by the JDSU HST-3000c or the Exfo AXS-200/365 -- to place it in the chronological sequence of the devices that have been issued to Openreach technicians.)
Another option would be a specialist equipment hire businesses . . . though I don't know what a day's hire would typically cost.
Of course there is always Walter's Wheelbarrow, if you are located somewhere in Surrey. :-\
-
Yes, hiring might be a great option. I hired a logic analyser once, that would have cost ~£15k to buy. (We kept hiring it for so long that they asked us if we wanted to just buy it eventually.)
-
Drove to PCP where speeds were still low, carried out a DLM reset and speeds did not increase.
Dcoe stated that the interleaves was preventing the speeds so has been removed.
Speeds now higher
I guess this shows the standard DLM reset is to put interweaving profile in place, but that DCoE was able to shift it to an open profile.
However, it still doesn't ring true...
Yes, interweaving + FEC does steal some of the line's speed and latency. However, a JDSU plugged in at the cabinet should easily cope with an 80/20 sync even with such a profile. The zero-distance open speed is probably 160/40... so plenty of headroom.
If they couldn't achieve 80/20 at the cab, something is wrong.
-
Hopefully the boost visit on Weds will be more productive - assuming it is actually a boost appointment of course..
Perhaps they'll be willing to view the hlog we can see to investigate further too.
If the guy/gal is receptive and willing I'll try and get a snap/snaps of the TDR test results to share
G.INP enabled overnight here and have now moved DSLstats to an always on PC so should be logging around the clock, I need to change a BIOS setting on the machine so it comes back after a power outage but apart from that should be good to go
Cheers all
Sam
-
aand just seen two resyncs within 10 minutes of each other, one preceded by US noise margin nosedive, second one by DS margin nosedive.
:-[
At work all day so can't really investigate
Grrrr
<edit>
On closer inspection checking the upstream SNRM per band shows U0 spiking upwards to 16dB just before the first resync and then to around 11dB just before the second, what would cause this?
Cheers
Sam
-
I guess this shows the standard DLM reset is to put interweaving profile in place, but that DCoE was able to shift it to an open profile.
However, it still doesn't ring true...
Yes, interweaving + FEC does steal some of the line's speed and latency. However, a JDSU plugged in at the cabinet should easily cope with an 80/20 sync even with such a profile. The zero-distance open speed is probably 160/40... so plenty of headroom.
If they couldn't achieve 80/20 at the cab, something is wrong.
Absolutely spot-on.
-
Absolutely spot-on.
Will see what tomorrow's visit reveals, fingers crossed they get to the bottom of it.
Just had another weird resync, US margin on U0 skyrocketed while DS went in the other direction..
Why would this happen and what would cause it?
Cheers
Sam
Sent from my SM-G930F using Tapatalk
-
Will see what tomorrow's visit reveals, fingers crossed they get to the bottom of it.
Just had another weird resync, US margin on U0 skyrocketed while DS went in the other direction..
Why would this happen and what would cause it?
Cheers
Sam
Sent from my SM-G930F using Tapatalk
Noise/harmonics on line.
Can you try to short your line for a few seconds?
-
It really could be down to anything ??? I like to stick to what we know, rather than what we don't ..... and that is the engineers aren't getting full synch at the Cab, which they should be able to do each and every time once the profile is reset to 'Open'.
This smacks of a) A faulty DSLAM port ....... b) A high-resistance (HR) fault on the Quante termination strips in the DSLAM Cab ..... or c) A split pair between the DSLAM Cab and the Copper Cab.
The resultant fix will require a 'Lift & Shift' should it be either of these three scenario's, as we don't have access rights to the DSLAM Cab.
This advice is obviously given, assuming the previous visit and the subsequent notes are correct. Fingers crossed for a result. :)
-
Thanks both
Agreed BS and thanks for the breakdown of possible causes (and the fix)
Will report back tomorrow afternoon following the appointment.
Cheers
Sam
-
So, my boost appointment was cancelled.
I only found out when the engineer didn't show up, checked the fault on the BT website and it had been closed.
After speaking with a supervisor via Live Chat found out that apparently there's a MSO for this area (although it isn't reported on any of the checkers) with a fix date of 19/08?
Somehow I think I'll still have the same line conditions/symptoms after that date and will need to make another appointment, but will happily be proved wrong..
-
So my line has returned to flappyville - had 8 resyncs in the last 24hrs all for LOS or RDI (last 5 today have all been RDI)
Seeing loads more errors and not really sure what's happening to the line, HLOG looks terrible.
Anyone got any ideas/advice?
Attached yesterday's HLOG graph and today's for a comparison..
Thanks
Sam
<edit> better make that 8 resyncs today - one at 14:09 Reason 8000 LOS???
Dread to think what action DLM is going to take, something is amiss though :(
-
Hmm . . . :hmm:
The Hlog plot of August 28th shows what we believe to be a bridging tap.
The Hlog plot of August 29th has the same underlying feature with added erratics. I speculate that intermittent contact to the circuit may perhaps be the origin. Intermittent contact by one or more wires that are either part of another working circuit or are "spares". :-\
-
Thanks burakkucat
Haven't had a resync for a couple of hours now - and Hlog is looking slightly better but still afflicted.
Noted that DLM has upped the DS interleaving to 16 and backed of G.INP to 48 from 52, now looks more banded at exactly 60/20
The mysterious sky-high Zyxel FEC count has returned too after being conspicuously absent over the last couple of days.
I have another boost visit arranged for a week Thursday (must be busy) - wonder if the symptoms will clear up just in time for the visit ;)
Cheers
Sam
-
Both the Hlog and QLN pots are only updated at the time of a (re-)synchronisation event. They do not undergo a constant update process.
-
Both the Hlog and QLN pots are only updated at the time of a (re-)synchronisation event. They do not undergo a constant update process.
Indeed, I am though comparing the view from my last resync around 4pm with the earlier screenshot from a resync around 1pm, attached for clarity
Thanks
Sam
-
So, boost engineer visit is complete and I'm very happy with the results.
Guy was very thorough (3.5hrs on site) and ended up sorting it by completing a pair swap for me onto what he said was the only copper back to the cab, seems all my issues were due to being on 300m of aluminium.
Just going to leave things well alone now and wait for things to settle down DLM-wise after so many retrains this morning - new stats are up on MDWS for all to see have included before and after HLOG plots below..
Chuffed to bits
Cheers
Sam
-
Much better. That is a good result. :)
[Edited to correct the spelling.]
-
Much batter. That is a good result. :)
It is amazing what a difference a good run of copper can make, I got lucky - am under no illusions there.
Big thanks to everyone who contributed to this thread, hoping I can draw a line under this now after a year!
Cheers
Sam
Sent from my SM-G930F using Tapatalk
-
It is amazing that 300m of aluminium can make roll similar to bridge tap roll.
-
It is amazing that 300m of aluminium can make roll similar to bridge tap roll.
I'm assuming the possible bridged tap still exists on that run of aluminium - but will happily defer to those better informed than me if it's an impossibility with aluminium..
Sent from my SM-G930F using Tapatalk
-
It is amazing that 300m of aluminium can make roll similar to bridge tap roll.
Indeed, yes. Previously, I would not have expected it but now we have seen the actual evidence.
(Of course there is still that slight abnormality visible at the high frequency end of the Hlog plot but that is best ignored. I don't think, under the circumstances, that the circuit could be improved any more. :-\ )
-
I think that this slight abnormality is caused by measurements errors. After one resynchronization event with target SNR margin 15 dB I had no slight abnormalities.
-
Indeed, yes. Previously, I would not have expected it but now we have seen the actual evidence.
(Of course there is still that slight abnormality visible at the high frequency end of the Hlog plot but that is best ignored. I don't think, under the circumstances, that the circuit could be improved any more. :-\ )
DLM should lower the interleaving depth and apply G.INP at a guess but am at almost maximum possible sync speed so I don't know..
Sent from my SM-G930F using Tapatalk
-
DLM should lower the interleaving depth and apply G.INP at a guess but am at almost maximum possible sync speed so I don't know..
The best course of action would be to just wait and keep watch. ;)
-
I'm assuming the possible bridged tap still exists on that run of aluminium - but will happily defer to those better informed than me if it's an impossibility with aluminium..
Sent from my SM-G930F using Tapatalk
The 'Bridged tap' IMHO, is most likely a contact fault with a non-working pair.
If it was a working pair, there would be either a battery or earth fault ..... size of which would be dependant on the resistance between the two pairs.
-
G.INP was applied 2 days after the boost visit and all is now looking very rosy indeed.
Sent from my SM-G930F using Tapatalk
-
Thank you for the latest update. :)