Packet Errors

[#1]

Thanks for the support. I have some troubleshooting experience as, while I haven't formal training, one of my hobbies is the repair of old electronics and making valve amplifiers. I can probably be relied on to fix and align a 1950s domestic radio in accordance with the service manual, but my experience of creative RF engineering and telecomms practice is minimal!

I was under the impression we were looking for a reduction in SNRM as I believed the line was expected to have ~6dB.

The house setup is peculiar as quite serious self-build renovations and rebuilding started shortly before Covid caused significant delays. The master socket was temporarily placed loose at the end of ~20ft of normal 4-pair by our local engineer, as the original wiring (the broken pair fault he was called out to fix) was considered too onerous to repair in-situ when it was going to come out anyway, and the master socket and incoming electricity supply relocated somewhere more convenient.

That temporary solution has been in place ever since, but has been reliable and undisturbed. The master socket is connected to the orange/orange-white pair. This pair goes straight back to a junction box under the consumer unit where all the house wiring appears through the floor.

The router lost the connection because I was unplugging all the cabling to reroute the wires. It's possible the spikes are flicking the circuit breakers. The resolution is 30 seconds a point, so I wasn't looking to pinpoint spikes as the line's jittery anyway, and was rather seeking if any changes made a significant change to the average reading.

Since my last post the plot has been roaming between 10 and 11dB, as attached. The router appears to have remained connected, too...

[#2]

---

@Fat_Leonard wrote:

I was under the impression we were looking for a reduction in SNRM as I believed the line was expected to have ~6dB.

That is ultimately correct, but not at the moment.  I think you will largely get the following given your background and interests.

SNRM is not an absolute measure, but one relative to the background noise.  The expectation for a normal line is that it should operate stably at a 6dB margin above the background noise.  At that level the speed will be whatever can be delivered over the length (attenuation) of the line.  At re-sync the line speed will be that which delivers the target margin over the background noise present at the time of the resync.

There then follows a number of complicating factors to be considered when looking at line metrics in a situation such as yours.

1. Resync in the presence of noise - if at the time of the resync there is noise of say 6dB the line will sync at a speed which delivers a 6dB MARGIN - if that noise later vanishes, the observed margin (SNRM) will be 12dB
2. A problematic line (one which experiences disturbances greater than -6dB this causing a disconnection) might have its target SNRM incremented in 3dB steps (with an associated decrease in speed) in an attempt to attain stability - this is know as banding - the DLM should manage this up and down dynamically as conditions change ... unless it is chronically banded which needs supplier intervention

You plots clearly indicate the presence of RFI - possibly two sources.  One is generating the square wave appearance (down the noise is present, up it is off) the other is more random and is causing the jitter.

The junction box near the power consumer unit does not sound ideal.  I would look to see how tidy that is - a break in the twists (a length taken out to make a joint) could be an "injection point" for noise, especially if next to the distribution board ... and some electrical device is injecting noise.

Cheap switched current "transformers" are a common culprit for this.

Way forward...

• Make sure that there are no long ends on the phone circuit which could act a aerials - get the wire away from mains as much as possible
• Are there any extensions, either off
  • the back of the master socket
  • the front of the master socket
  • or (really bad) off that junction box near the consumer panel
• Change the sample interval to as low as it will go and the plots per graph that required to plot 2 hours - we are looking for short spikes which are greater than 6dB which with a normal SNRM target will have caused a disconnection
• Keep hunting for the source of the square wave and the fuzz (hum!) but switch things off individually so that the switching event does not trash the sync session

Keep the graphs coming!

[#3]

Thank you for the thorough explanation, it's much appreciated. I can see I was fixated on the margin, rather than the margin ratio, but it's clear now. I've spent the last week trying to track down the RFI source. I attach a picture of the board where the telephone line arrives, which you can see is not ideal. I'm tempted to run a very short cable from the junction box and test the router with only that shorter length between it and the incoming feed, in case the length of cable is an issue. Although as it's been reliable all the rest of the time with the same cable I'm not hopeful that would make a difference.

There are no extensions or otherwise - the black wire comes in under the floor, goes to the junction box where it is spliced to the white twisted pair cable that leaves the junction box. The other end of that white cable is the master socket with the router and telephone base station plugged in.

Despite turning everything on and off I cannot work out what on earth is regularly switching every 20 minutes or so and causing the square wave. It's consistent day and night. See today's plot (10s logging rate, 2h per screen capture). I'll keep looking and poke the radio outside. The only other thing I can think of is that there is some kind of plant associated with a septic tank that may go on and off at all hours.

Routerstats says the connection has been 'up' for 7 days, so it hasn't been dropping. The connection speed and maximum data rate are reported as completely flat lines all week. However, the connection from a user perspective has been poor, with highly fluctuating pings and lost packets.

Running some command line pings to the BBC website over the last few hours has resulted in 27ms - 300+ms within the same four-packet test, and many where 50% of packets are lost. The telephone line quality isn't notably noisy. The router event log has numerous entries of the form "OUT: BLOCK [65] First packet is Invalid (Invalid tcp flags for current tcp state:..."

[#4]

That looks like some level of progress.  Though there is still clearly something switch off and on (on more than it is off) it looks as though some background noise has been removed.

That incoming line is about as bad as it could possibly be - wrapped around the inbound mains tails and close to the street fuse!!

Do you feel comfortable moving that junction box to the far right of the cupboard and tacking the inbound cable well away from the mains feed?  It is pre the master socket, so technically BT Openreach's exclusive domain.

What is that white box with the red light on - the meter?

Do you have router stats plots for the time of the last resync (6+ days ago)?  Does the router log go back that far?

Resync SNRMs should be 6, 9, 12 or 15dB etc in 3dB increments.  Yours are not on a 3dB interval so either...

• There was significant noise when the last resync was performed (9dB has risen to 10dB and 12dB to 13dB)
• The last resync was mid evening and the line is suffering from continental interference (can plague ADSL lines) and would match that SNRM shift
• The line is chronically banded, so the DLM will not auto recover the line sync speed - but you have not yet had 10 days stability

This thread started as a packet errors issue, but is currently clearly a restricted line issue, possibly arising from connection instability ... which you might have rectified.  Would be good if you could locate the source of the off / on RFI (look when the SNRM is at its lowest).

Next stage I think is to request a new line check and a DLM reset ... and see of things stay stable.

Sync speed will remain constant throughout the duration of the xDSL session.  Max Data speed might vary according to the variability of the current SNRM.

[#5]

Thank you - lots to be getting on with. Yes, the white box is the meter. I'm happy to move the telephone stuff around, especially as it will all be moved in toto in the future. I'll attempt to attain a more stable line using your advice and then I understand I need to ask Plusnet to check the line, as the auto-recovery will not improve matters until the line is classified differently.

I haven't got a plot, but I have got log entries from the last resynch. I can't see a way to export them as text, so I've got a screenshot of the period around the connection being made in case that makes sense for you.

[#6]

Exporting from the router log is not easy!

That is exactly what I was looking for - the resync is at "odd" SNRMs which infers the line has been banded.

The line looks chronically banded so will need a manual DLM reset.

[#7]

I moved the junction box out of the cupboard entirely, and mounted the socket on a foot of cable on the floor, with the router connected away from noise sources. No change to the router stats, so the noise is not being coupled into the router by the original cabling. This cabling runs along inside an exterior wall with a garden and then a lane in front (no other occupants with interfering radiative equipment close by, nor other cabling or equipment inside by the wire run).

Still no sign of the square wave source, so I'm wondering if it's somewhere off down the valley interfering with the line. Ferrites on the noisiest SMPS culprits found by the radio method not making a difference. The only things I haven't tried are running the router from a stabilised bench PSU, or turning off the desktop and checking routerstats on a laptop.

After that palaver, I've reinstated the router and telephone back at their original locations at the end of the long cable. The plot is as follows.

As there's not much more I can think of doing to improve matters, is there any likelihood that resetting the DLM with the line in its current state will make a lasting difference? Perhaps if the banding has come in from extra noise that may now have been dealt with, a reset would return it to its previous performance. Or the problem is on the cable back to the cabinet (damp joints on poles have plagued us in the past), and it's engineer time...

[#8]

Hi,

I’m looking at this on my phone so not so easy to review, however it looks as though the on / off difference is less (good) and the on / off ratio has changed. Could that point to a heating pump (warmer weather)? It might be my imagination - is the cycle period now longer?

The few minutes lead in to the above graph looks very clean. Was it the same on the previous graph? If yes, what happens from the time of the change?

The router stats (speed / initial SNRM) are kit going to change until the DLM has been kicked.

If that does not get actioned by a staff member here, then use to broadband fails bot (link below) to report a speed fault. Note that BT Wholesale has all ISP test facilities out of service this weekend. So act quickly … though using the text service will still queue the problem / line test.

[#9]

Thank you - much appreciated.

The square wave is not linked to anything in the house I can discern. There's a Rayburn that does all cooking, hot water and heating needs. It's audible on the radio when it clicks on and off, but does not correlate to graph spikes. It's also either on for several hours for cooking, or off (and not on and off through the night, for example). The radio has no response to the possible pump connected to the septic tank, and it's not audibly on when the interference spikes occur, which makes me think it's something further off down the valley as we're such a way from the cabinet. It does seem to be approximately 15 minutes between pulses, and it's been exercising me a lot this past week!

In general there seem to be more flat sections on the graph since the re-route, but I can't correlate that with any activity in the house or not. We're not heavily gadgety, perhaps a laptop was in use, but the only loads I can think of are one desktop, router, two telephone base stations and a few standard lamps, apart from white goods (dishwasher and washing machine not running) and the aforementioned Rayburn. I experimented with the thermostat but the graph didn't show any link when it was turned up and down to manually click the heating on and off (and indirectly firing up the Rayburn).

Are you suggesting I should I use the 'broadband fault' button as that will initiate a reset without having to open a particular type of ticket with a human?

[#10]

Yes - it gets the issue on the fault team’s radar.

The narrative needs to be that there has been a history of line instability which has brought about chronic banding. You’ve eliminated some potential causes of disconnections … so the next step (assuming no other fault is found) should be a DLM reset.

That should bring about a 6dB SNRM with an increase in line speed. The current square wave ought not to front about a disconnection. What ever happens, please keep the router stats running. If you later get disconnects and an increase in SNRM you will have better data to profile the issue.

I have seen similar before on a FTTC service - elevated SNRM for no apparent reason … also with an intermittent source of noise. I do wonder if that was dLan technology interference!

[#11]

Thank again. I've just clicked through that button, which takes me to the 'text this number' help. No mobile signal here so no can do. Should I do the fault ticket option as you recommended earlier in the thread instead?