Drop in upstream sync

Hi,

After just randomly checking my connection this morning I noted a drop in upstream sync from around 9.9Mb/s down to 5.9Mb/s. This seems to have been accompanied by a reduction in upstream output power from circa 4.7dBm to 1.8dBm. A coincidence?

I span up DSLstats and note the linked bitloading graph, which seems a little unusual to me?!

Any advice welcome.

Paul

What do you think is abnormal?

There is nothing that really stands out as a major issue.

Yes I think you're right. On further reading, the tones seem normal, I just don't remember seeing the upstream tones split like that before. I expected them to all be on the left hand side as per ADSL.

That aside, would a drop in upstream output power typically result in a reduction in upstream sync?

Paul

I've had a response to my ticket from IDNet and they've stated there's a 'Battery Contact' fault in the line.
Have to disconnect my gateway and faceplate from the line for them to confirm, with a test. Can't do that remotely though unfortunately.

Paul

They have always been split and there is another upstream band between tones 1972and 2782. I also prefer to have the SNR graph on the same display - under <Configuration>, <Items to Monitor> check teh box under <Others> to display SNR per tone Included with Bitloading.

In reply to a post by youngsyp:

I span up DSLstats and note the linked bitloading graph,

Please be aware that service based on a Profile 17a G.993.2 connection has 4096 sub-carriers.

You have not configured DSLstats correctly, for it is only showing (approximately) the first 1386 sub-carriers on the plot to which you have linked.

Summat horribly wrong if the battery contact is on you extension wiring ... and it takes a true klutz to send voip dial tone back towards the exchange .....

so most likely you�ve a good old fashioned telephone line fault. Be aware that the engineer who clears the fault will not be performing a DLM reset, so you�ll have to wait for the upstream to return.

In reply to a post by burakkucat:

In reply to a post by youngsyp:

I span up DSLstats and note the linked bitloading graph,

You have not configured DSLstats correctly, for it is only showing (approximately) the first 1386 sub-carriers on the plot to which you have linked.

Thanks. Will have a look at the config this evening and correct where necessary.

Paul

In reply to a post by Zarjaz:

Summat horribly wrong if the battery contact is on you extension wiring ... and it takes a true klutz to send voip dial tone back towards the exchange .....

so most likely you�ve a good old fashioned telephone line fault. Be aware that the engineer who clears the fault will not be performing a DLM reset, so you�ll have to wait for the upstream to return.

Agreed but I guess it's just procedure for them to confirm where the fault is most likely to lie.

IDNet confirmed the fault was still there last night after I unplugged the gateway and faceplate and they re-ran the phone line test. So next step is for them to organise an OR engineer visit. Hoping I don't need to be at home but suspect I'll have to be.

Paul

In reply to a post by MHC:

They have always been split and there is another upstream band between tones 1972and 2782. I also prefer to have the SNR graph on the same display - under <Configuration>, <Items to Monitor> check teh box under <Others> to display SNR per tone Included with Bitloading.

Bitloading chart with the correct configuration in place and SNR per tone displayed.

Paul

Now you can see the problem ... U2 is totally missing! It does seem a little odd that only upstream is affected, down looks reasonable

Agreed, odd is the word I'd use too, even with my limited understanding. If anything, the downstream has a little more SNRM headroom than it would normally have. I'm sure it sits at around 6dB typically but now it's at around 7 - 7.1dB, increasing the attainable rate.
The upstream output power has taken a nose dive since I re-synced after the test last night. It's now at -7.2dBm.
I've just spoken to IDNet again, still not convinced by their customer service, and ran through much the same as I did last night. So hopefully an engineer visit will be arranged this time.

Paul

The power is the total power transmitted, so having a large number of bins with no data may suggest that they are being excluded for some reason. But why?

Can I suggest a power off and leave for an hour. Disconnect modem from the line, power it up and allow to stabilise before reconnecting. See if that changes it.

In reply to a post by MHC:

The power is the total power transmitted, so having a large number of bins with no data may suggest that they are being excluded for some reason. But why?

Can I suggest a power off and leave for an hour. Disconnect modem from the line, power it up and allow to stabilise before reconnecting. See if that changes it.

I'll give it a try tonight if I get the opportunity.

Paul

A battery fault shouldn�t need the engineer to access your property, unless you have a buried frontage tee joint .... even then it would only be to track and mark for a dig.

Well I got yet another call from IDNet today stating they need me to do something else to 'convince' OR to come out and investigate. This is all despite me stating twice now that I'd happily cover any costs incurred, should it be on my side of the DL.

So I now have to plug a phone in and check the line.

IDNet continue to go down in my estimations and I'll be jumping back to Uno as soon as I possibly can.

Paul

Edited by deleted (Thu 04-Jan-18 13:51:57)

A screen shot showing U2 being totally empty should be enough to persuade IDNet and BT/OR that there is a problem.

IDNet have a screen grab of it now so we'll see what they say. Not much I suspect!

I'll try your suggestion of disconnecting for an hour tonight too as I'll have to unplug everything again for the phone test anyway.

Paul

Can you also get a text/screen grab from DSL Stats of the pbParams page especially the section which says:

Bearer: 0, Upstream rate = 19999 Kbps, Downstream rate = 80000 Kbps
Bearer: 1, Upstream rate = 0 Kbps, Downstream rate = 0 Kbps
Discovery Phase (Initial) Band Plan
US: (7,32) (871,1205) (1972,2782)
DS: (33,859) (1216,1961) (2793,3970)
Medley Phase (Final) Band Plan
US: (7,32) (871,1205) (1972,2782)
DS: (33,859) (1216,1961) (2793,3970)

Do one BEFORE you disconnect and one once you have reconnected.

If it tests battery, then they should just raise it as an issue with Openreach ... why are they dragging their heels ?

Do you get your voice services from them too ?

In reply to a post by MHC:

Can you also get a text/screen grab from DSL Stats of the pbParams page especially the section which says:

Bearer: 0, Upstream rate = 19999 Kbps, Downstream rate = 80000 Kbps
Bearer: 1, Upstream rate = 0 Kbps, Downstream rate = 0 Kbps
Discovery Phase (Initial) Band Plan
US: (7,32) (871,1205) (1972,2782)
DS: (33,859) (1216,1961) (2793,3970)
Medley Phase (Final) Band Plan
US: (7,32) (871,1205) (1972,2782)
DS: (33,859) (1216,1961) (2793,3970)

Do one BEFORE you disconnect and one once you have reconnected.

Unfortunately, I didn't see this response before I disconnected so only have the data from post re-connect,

adsl info --pbParams
adsl: ADSL driver and PHY status
Status: Showtime
Last Retrain Reason: 0
Last initialization procedure status: 0
Max: Upstream rate = 9807 Kbps, Downstream rate = 59618 Kbps
Bearer: 0, Upstream rate = 9807 Kbps, Downstream rate = 55000 Kbps
Bearer: 1, Upstream rate = 0 Kbps, Downstream rate = 0 Kbps
Discovery Phase (Initial) Band Plan
US: (7,32) (871,1205) (1972,2782)
DS: (33,859) (1216,1961) (2793,3959)
Medley Phase (Final) Band Plan
US: (7,32) (871,1205) (1972,2144)
DS: (33,859) (1216,1961) (2793,3813)

The US sync recovered post re-connect (coincidence?!), with US power now at 3.8dBM and some but not all of the U2 tones are now showing in the linked chart.

I performed a quiet line test and there was a distinct hum on the line but oddly, there was also a distant and faint alarm, like when the phone is left of the hook. This has all been reported to IDNet now and an engineer is booked for Monday. They'll be visiting the premises as well apparently.

Paul

In reply to a post by Zarjaz:

If it tests battery, then they should just raise it as an issue with Openreach ... why are they dragging their heels ?

Do you get your voice services from them too ?

Yes, IDNet also provide the voice service (that we don't use). They seemed to be hung up on plugging an actual phone in and testing the line. Like you, I can't fathom why if they've proved there's a demonstrable fault on the line.

Paul

Just to update this one:

A very helpful OR engineer arrived promptly yesterday morning and got straight to work, first testing from the NTE out. I got a little nervous at this point as he couldn't find an issue. That didn't seem to deter him though. Leaving the CPE un-connected, he first re-terminated where the wire from the pole connected to the house wiring. The went off up the road to take a look at the cab. Around 3 hours later he came back and was confident he'd traced the issue to a footway box just down from our house, where an aluminium cable (eek) connected 2 poles.
Apparently when he got to the cab, he plugged in his 'new' tester and it didn't register anything. He then plugged in his 'old' tester that he trusted more and it spiked up to a 10v contact detection, then dropped back and went back up and dropped back and so on. So the fault was intermittent, but frequent.

This is his transcript:
=== === QBC Summary Start ===I completed the ring ahead with the end customer xxxxxxxx and progressed to their premises.End customer advised there is a broadband issue.The line was noise free.I have not identified any issue in exchange or DSLAM.No number porting issue is identified.DeltaR / Autoprotective PQT test performed at NTE back plate.The test failed due to resistance outside permissible range for voice on 08/01/2018.Unable to complete TDR.I have resolved the fault located at the D-side including aerial cables and lead-in / block terminal.There was a fault outside the end customer's curtilage caused by general wear and tear.The fault was fixed by clearing in joint.No additional work was carried out on the end customer's wiring / equipment beyond the NTE at their request and within TRC banding.Final DeltaR / Autoprotective PQT performed at the NTE back plate.The test passed with resistance within permissible range for voice on 08/01/2018.Final PQT performed at the NTE back plate.The test passed on 08/01/2018.Final FastTest completed.The test passed on 08/01/2018 10:27:57.=== QBC Summary End ===.

Admittedly, due to the intermittent nature of the fault, I've not seen a real difference in my connection but maybe DLM has a part to play in that. Will leave all alone for a week or so and see if anything happens.
Now to fix my BQM that is reporting 100% packet loss!

Paul

�They� say that QBC (question based closure) provides clear and easily understood notes for the service providers and their customers ....

And there you go, proving that to be utter nonsense.... it says a lot, but tells you nothing ...

Progress (sigh)

There's also some fabrication in there too. He didn't call ahead for example and the part where it states "there was no additional work carried out on the customers wiring/ equipment at their request", I didn't request anything, neither additional work nor not to do additional work. He just stated it was fixed, grabbed a cup of tea for the road, and left. These are both very minor observations though as I worked from home especially because of the OR visit and had a time slot when they would be there and I didn't need anything other than the fault rectifying.

That aside, when the OR engineer arrived and we begun chatting, he stated that the call was a XXXX (four letter acronym that I forget) which made it sound as though I had insisted on an engineer coming to my house, via the ISP, to look for a possible fault. Not that a fault was found by the ISP and they'd requested his attendance to fix it.

All in all, this has been yet another experience to the detriment of IDNet. They just seem to be a bunch of amateurs who don't communicate amongst themselves, which leads to the customer being badgered for information they've already given.

Paul

In reply to a post by youngsyp:

. . . he stated that the call was a XXXX (four letter acronym that I forget) . . .

Possibly an SFI2, maybe?

That�s the issue with QBC as I see it ... when closing tasks you are offered a choice of pre-populated answers .. none exactly fit the bill.

I suspect the XXXX you mention was a CDTA, conscious decision to appoint... so the service provider can detect no fault on remote testing, yet their customer insists there is one. So I wonder why they ignored the original battery contact they thought they detected ?

It�s all a bleedin� game these days .... and the only folk who suffer in the end is Joe Punter.

Errrm, he said a four letter acronym ?

SFI2 would be three letters and a number

Big sigh!

Edited by burakkucat (Tue 09-Jan-18 18:21:35)

In reply to a post by Zarjaz:

That�s the issue with QBC as I see it ... when closing tasks you are offered a choice of pre-populated answers .. none exactly fit the bill.

I suspect the XXXX you mention was a CDTA, conscious decision to appoint... so the service provider can detect no fault on remote testing, yet their customer insists there is one. So I wonder why they ignored the original battery contact they thought they detected ?

It�s all a bleedin� game these days .... and the only folk who suffer in the end is Joe Punter.

That's the one - CDTA. As to why the fault, observed under two discreet tests, was ignored, I can only put that down to IDNet being inept. I'm just glad the OR engineer was so determined to find and fix a fault otherwise I suspect I would have been charged.

ETA: Cycling the 'Block WAN IP' setting on my Billion seems to have fixed the issue I was having with BQM. The Billion seems to be quite temperamental around that area when the sync is removed and reinstated. At least the method above is simple to work through.

Paul

Edited by deleted (Wed 10-Jan-18 13:19:19)

What does your Bit Loading graph look like now?

Can you post another link - and to save searching back, links to the previous versions too.

No worries.

Here's the pbParams:

xdslctl info --pbParams
xdslctl: ADSL driver and PHY status
Status: Showtime
Last Retrain Reason: 0
Last initialization procedure status: 0
Max: Upstream rate = 9875 Kbps, Downstream rate = 59966 Kbps
Bearer: 0, Upstream rate = 9875 Kbps, Downstream rate = 55000 Kbps
Bearer: 1, Upstream rate = 0 Kbps, Downstream rate = 0 Kbps
Discovery Phase (Initial) Band Plan
US: (7,32) (871,1205) (1972,2782)
DS: (33,859) (1216,1961) (2793,3959)
Medley Phase (Final) Band Plan
US: (7,32) (871,1205) (1972,2160)
DS: (33,859) (1216,1961) (2793,3875)
VDSL Port Details Upstream Downstream
Attainable Net Data Rate: 9875 kbps 59966 kbps
Actual Aggregate Tx Power: 3.8 dBm 12.8 dBm

Bitloading 030118
Bitloading 040118
Bitloading 110118

Paul

U2 still looks a little low, I would have expected the low end of U2 to be at maybe 4 bits/tone dropping to 3, 2, 1 at the high end.

I couldn't offer any comment on that as it's a little beyond my understanding I'm afraid. I will say the line is performing well again though and is as stable as ever. Every time I re-sync, the US sync seems to improve too. So I'll leave it alone now and fingers crossed it'll get back to it's best of 9999 kb/s actual and 10xxx kb/s attainable.

Paul

Just re-sync once a day and if you can, get another screen shot of bitloading - interesting to see if U2 improves.

My bitloading is almost identical.
https://ibb.co/hPJomm

Hlog cuts off about the same tones.
https://ibb.co/bDhymm

My entire line to the cabinet is only about 5 years old.
I think it's just a result of being so far from the cabinet, and so far from the exchange.

Just reset and I've lost ~ 100kb/s (wow!!) on the upstream but I'm putting that down to the time of day. I also unchecked the PhyR on the upstream as it didn't seem to do anything (checked it before the last re-sync). Probably just coincidence...

Anyway, these are the pbPrams:

xdslctl info --pbParams
xdslctl: ADSL driver and PHY status
Status: Showtime
Last Retrain Reason: 0
Last initialization procedure status: 0
Max: Upstream rate = 9781 Kbps, Downstream rate = 59622 Kbps
Bearer: 0, Upstream rate = 9781 Kbps, Downstream rate = 55000 Kbps
Bearer: 1, Upstream rate = 0 Kbps, Downstream rate = 0 Kbps
Discovery Phase (Initial) Band Plan
US: (7,32) (871,1205) (1972,2782)
DS: (33,859) (1216,1961) (2793,3959)
Medley Phase (Final) Band Plan
US: (7,32) (871,1205) (1972,2178)
DS: (33,859) (1216,1961) (2793,3949)
VDSL Port Details Upstream Downstream
Attainable Net Data Rate: 9781 kbps 59622 kbps
Actual Aggregate Tx Power: 4.1 dBm 12.7 dBm

And this is the bitloading chart.

A slight difference but don't know about improvement.

ETA: latency is looking good. I just pinged the BBC and it's coming back at 10ms.

The Billion doesn't seem to like it when I change a WAN > DSL setting and re-sync. I have to toggle 'Block WAN PING' to get BQM working again every time.

Paul

Edited by deleted (Tue 16-Jan-18 13:33:42)

After this mornings re-sync, which coincidentally was triggered (by me) at the very shortly before the gateway restarted.

pbParams:

xdslctl info --pbParams
xdslctl: ADSL driver and PHY status
Status: Showtime
Last Retrain Reason: 0
Last initialization procedure status: 0
Max: Upstream rate = 9807 Kbps, Downstream rate = 60066 Kbps
Bearer: 0, Upstream rate = 9807 Kbps, Downstream rate = 55000 Kbps
Bearer: 1, Upstream rate = 0 Kbps, Downstream rate = 0 Kbps
Discovery Phase (Initial) Band Plan
US: (7,32) (871,1205) (1972,2782)
DS: (33,859) (1216,1961) (2793,3959)
Medley Phase (Final) Band Plan
US: (7,32) (871,1205) (1972,2148)
DS: (33,859) (1216,1961) (2793,3847)
VDSL Port Details Upstream Downstream
Attainable Net Data Rate: 9807 kbps 60066 kbps
Actual Aggregate Tx Power: 3.7 dBm 12.8 dBm

And bitloading chart.

SNRM seems to be at it's highest in the morning (the opposite of what it was with ADSL), so I'll re-sync early to try and bring the US sync back up again.

Paul

In reply to a post by youngsyp:

I also unchecked the PhyR on the upstream as it didn't seem to do anything (checked it before the last re-sync). Probably just coincidence...

PhyR does indeed have no effect, checked or unchecked.
It's Broadcoms own proprietary version of G.INP/retx and Is not used on FTTC/VDSL2 in the U.K.
The same goes for SRA, which isn't used by Openreach.