Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[tiffy]

40/10 VDSL-2 service with Plusnet, quite a long line to Huawei DSLAM cabinet, DS G.Inp (ReTx low) active.
Normal DS synch, 40 Mbps.
Normal US synch, approx. 6 Mbps.
Line normally very stable with very low US & DS error rates.

Modem/router monitored 24/7 via DSLStats on RPI 3B.

Last night (06/04) had a re-synch @ 19:45 hrs., this resulted in a considerable loss of US synch speed to 1.6 Mbps., DS synch speed remained as previous, both SNRM's increased considerably and started to exibit substantial noise as recorded on their respective graphs.

Attached, SNRM, bit loading graphs and basic stats. from post re-synch, the SNRM graph displays the event before & after state.
DSLStats graphs are on a 4 day "X" axis with 120 sec's. sample time.

Will attach further graphs which should clarify my line current status in subsequent posts due to the forum attachment limits.

Tried a controlled re-synch, modem/router re-boot this morning which produced a small improvement in US synch. speed and bit loading but my line still looks unhealthy by comparison to original.

Any suggestions as to possible cause, remedial action welcome.

[tiffy]

Attached, my SNRM, bit loading graphs & basic stat's. pre-event for reference.

[burakkucat]

Those two traces in the SNRM plot are clearly showing that something is not right. The US trace is appalling.

The only suggestion I can make is for you to power down the modem/router and disconnect it from the incoming line. Leave it like that overnight and let the DSLAM port have a chance to "relax".

[tiffy]

@b*cat:

Many thanks for the response.

Was just about to add my before & after HLog & QLN graphs, analysis of these I know is your "forte", even I can see there are substantial differences pre & post event.

Attached, my normal, pre-event HLog & QLN graphs.
 

[tiffy]

For reference my post-event (current) HLog & QLN graphs.

Also attached my current SNRM graph now with a 1 day "X" axis and 60 sec's. sample rate.

[burakkucat]

Unfortunately no "smoking gun" can be seen.

However the "after" Hlog plot does show some very minor "raggedness", especially in the US1 band. The change in the QLN plot is more obvious to see -- a significant change in the noise distribution.

I wonder if some major rearrangement of the physical location of the tie-pairs to D- & E-side cables has taken place within the PCP and your circuit has reacted badly to its pair's new environment?

I will be interested to know if allowing the DSLAM's line-card port to "relax" for a number of hours would terminate the violent SNRM oscillation.

[Chrysalis]

either a broken UPBO or some severe US signal integrity issues, either way not good.

I agree with the idea of letting it rest for a bit.

[tiffy]

Thanks to both for your input.

As per advice I shut the system down overnight.
Re-synch this morning has produced marginal improvement in US synch speed with associated average decrease in US SNRM, unfortunately, the SNRM oscillation remains the same.

I wonder if some major rearrangement of the physical location of the tie-pairs to D- & E-side cables has taken place within the PCP and your circuit has reacted badly to its pair's new environment?

As I monitor my line 24/7 and can positively identify that the re-synch event occured at 19:45 hrs. would think that it's unlikely, but not impossible that any local activity (PCP/DSLAM) was taking place at that time.
The PCP/DSLAM is located at the end of my road not within visual range of my residence.

either a broken UPBO or some severe US signal integrity issues, either way not good.

Pardon my ignorance, UPBO ?

Am I correct in assuming that it's unlikely that the issue could be local, ie. within my equipment/installation ?
I do have alternative hardware which I could substitute but really don't think this would be worthwhile ?

Is my ISP (Plusnet) likely to be interested in this issue especially as DS speed has not been effected, have not contacted them to date.
Have a very long standing administration issue with Plusnet but, although not recently required, have found their tech. support to be good.

Attached, SNRM & Bitloading graphs post latest re-synch. for reference.

[j0hn]

I'd have recommended the same as B*cat, resting the line overnight.

Try another modem and make sure it isn't that.

Failing that I would be tempted to report the upstream speed drop on the Plusnet forums along with images of the oscillating SNRM.

Hopefully the drop in upstream sync is enough they would count it as a fault.

[tiffy]

@j0hn:

Many thanks for your input, much appreciated.

Try another modem and make sure it isn't that.

Yes, suppose I should really as process of elimination if nothing else, don't wish to overly upset DLM with too many re-synch's so will wait until tomorrow.

Failing that I would be tempted to report the upstream speed drop on the Plusnet forums along with images of the oscillating SNRM.

It's really difficult to contact PN at present, in a way understandable with the current country/world crisis, however, it has been impossible to raise a support ticket, use chat line or contact telephone support without very long waiting times for a considerable time pre-covid-19 crisis.
Yes, tech. support staff on the PN forum used to produce fairly quick results with technical issues, does not appear to be the case at present, again, perhaps understandable with current reduced staffing levels.

The only option deemed viable to me at present was to raise my issue with PN via a "complaint" ticket, that gets it documented, provides a reference number and is then easier to update as long as the ticket remains live.
Have requested a line check but not really hopeful on any issue being identified.

[burakkucat]

Your most recent Bit Loading plot show that the US1 band is now more healthily populated, though not to the extent as shown in the initial, control, plot.

I do not like the still ongoing SNRM oscillations. 

[Chrysalis]

tiffy Upstream Power Back Off.

Lines will usually have that either in the US1 or US2, short lines should have it in US1, to protect longer lines, and longer lines should have it in US2 which wont affect them much as they cant use that range anyway, but if longer lines by mistake get it on US1 it can be devastating, I think Ronski had this problem on his old VDSL line.

[tiffy]

@b*cat:

Your most recent Bit Loading plot show that the US1 band is now more healthily populated, though not to the extent as shown in the initial, control, plot.

Yes, both manual re-synch's I have instigated to date have produced a slight US bit loading improvement and associated increase in US synch speed, don't wish to re-synch too frequently of course to incur the wrath of DLM..

Although the US average SNRM has decreased with the last re-synch the oscillation amplitude & period remain more or less the same.

@Chrysalis:

Upstream Power Back Off

Ahh, many thanks for the clarification.
Certainly food for thought, your suggested (possible) scenario could explain exactly what I am currently experiencing, my line certainly falls into the "long" catagory @ 26.6 dB, DS attenuation.
Remembering also that I'am not experiencing any increase in error rates of any description from that recorded on pre-event stat's., still very low.
Is that significant ?

I have raised a ticket (as a complaint) to Plusnet and awaiting response.
Would UPBO being incorrectly applied to US1, should this be the case, be likely to show up on a line test carried out by PN ?
If I request a DLM reset, assuming PN agree, would that be likely to fix any possible UPBO issues ? 
 

[burakkucat]

I had hoped that you would have tested a different modem/router (CPE), power supply and patch cable (that links the CPE to the incoming line) before reporting the problem to your ISP/CP.

Whilst an alternative modem/router is being used it might be worthwhile opening up your normal device (if possible) and checking the capacitors for any bulges &/or leaks.

[tiffy]

@B*cat:

I had hoped that you would have tested a different modem/router (CPE), power supply and patch cable (that links the CPE to the incoming line) before reporting the problem to your ISP/CP.

To be honest I remain more convinced that the issue is external (quite possibly incorrectly) but do intend to substitute the hardware on a controlled time scale for process of elimination if nothing else.

Thought it best to start the investigation process off with Plusnet as soon as possible, certainly lately, they have not been noted for their speed of response, can't imagine that will have improved considering the current country/world situation.

Whilst an alternative modem/router is being used it might be worthwhile opening up your normal device (if possible) and checking the capacitors for any bulges &/or leaks.

Yes, I do have a very much hands on electronic background so that will be easily accomplished when taken out of service.

Many thanks for your continued support.