Packet Loss and High Latency under load

[#1]

One of my referrals recently had a fault call out involving a lot of old wiring (NOT TWISTED PAIR) to a not current standard master socket.

The BT OR engineer said lead-in needed to be replaced.  Nice packet of biscuits and "would it be easier if you just put a hole through the wall and put it over there..." got the fault fixed with a new master socket in a much more convenient place.

[#2]

Thanks all for the suggestions.

The OR engineer who turned up was very helpful, and open to swapping the lines over for me.  He didn't even want a hot drink or the biscuit selection I'd prepared. 

All seemed well on the new line yesterday, and tested out fine initially, but as of last night pfsense is back to showing Packet Loss and High Latency.  With a new line connected, and now the PN router connected directly into a master socket, it must be something outside the property.  The Packet loss and latency log errors seems not as regular though, but the only thing I can think it's an issue in the cabinet or the telecoms pole?

Any other suggestions?

Many thanks all

Jack

[#3]

Another engineer visit.

Unfortunately when there is something as glaringly bad as the wiring you showed, it is understandable to consider that is the sole location of issues.  This is a helpful step in the right direction.  In the case I noted above, it took two engineer visits ... since when I have heard nothing from the referral!

[#4]

I just tried booking another OR Engineer visit, but PN Technical Support advised me that when a new line is connected, the line can take 3 days to stabilise in what they call a “monitoring window”.

I'll give it a few more days and see if the issue resolve itself, if not, I'll try to book another visit in then.  I'd be interested to know if the line's still showing the Bridge Tap and a Loop (Rectified) fault that @Gandalf advised me of, or if that was indeed the old wiring causing that particular issue.

I'll keep you all posted, and thanks again for everyone's help so far.

[#5]

Another quick suggestion as you're using pfSense ...
Are you using traffic shaping / CoDel? If so have you remembered to modify the up/down queue bandwidth since moving?

If you're not using traffic shaping ... definitely advise taking a look once you get any physical connection issues sorted ... makes a big difference to latency under load.

[#6]

Good thought @rovingclimber, I haven't updated the up/down queue bandwidth since moving, but I will now.  It's an invaluable tool to help managed the load effectively. 

I can't see this causing the packet loss and latency alarms in the gateway logs though, unless I'm missing something?

[#7]

Hmmm .... you're probably right. I'm not sure if the gateway check goes through the queue or not. I've seen a bad effect on latency under load if the pipes are sized over the available bandwidth but I guess you probably wouldn't see the packet loss with it.

[#8]

---

@jackjohnsonuk wrote:

I'd be interested to know if the line's still showing the Bridge Tap and a Loop (Rectified) fault that @Gandalf advised me of, or if that was indeed the old wiring causing that particular issue.

---

I come bearing good news on this front. Line tests are now passing and there's no bridge tap detected. Speeds look good too. Your modem's in sync at a downstream speed of 77.5mbps and upstream of 20mbps.

It may be worth using the Plusnet hub as a router and see if you get packet loss, just to rule out your own router.

[#9]

---

@jackjohnsonuk wrote:

I just tried booking another OR Engineer visit, but PN Technical Support advised me that when a new line is connected, the line can take 3 days to stabilise in what they call a “monitoring window”.

I'll give it a few more days and see if the issue resolve itself, if not, I'll try to book another visit in then.  I'd be interested to know if the line's still showing the Bridge Tap and a Loop (Rectified) fault that @Gandalf advised me of, or if that was indeed the old wiring causing that particular issue.

I'll keep you all posted, and thanks again for everyone's help so far.

---

Ah that old chestnut?  Unless things have changed for the worse in the past 10 years, there is no training period with FTTC which will lead to improvements.  See FTTC - DLM 10 day training period (kitz.co.uk)

"At provision, the line is put on wide open profiles, allowing downstream line speeds
of up to 40Mbit/s, and upstream line speeds of up to 2Mbit/s or 10Mbit/s depending
on the upstream product option selected.

On the first day of operation, DLM will intervene if severe instability is detected.
Otherwise, DLM will wait until the day after provision before intervening, provided
that the line has been trained up for at least 15 minutes during the preceding day.

If DLM intervenes it will set a capped profile with a maximum rate and a minimum
rate, where the minimum rate is set at approximately half of the maximum rate. The
purpose of the minimum rate is to ensure that the line does not train at a rate which is
significantly below the level the line should be able to achieve. If this happened, then
the line is likely to remain at a very low rate till a re-train is forced by the user
powering off the Active NTE.

I do not know why support agents still refer to the ADSL 10 day line training (assessment) process when looking at FTTC / VDSL services.  If this line is performing below spec now, then it will still be doing so at some point in the future until BTOR resolve the residual issues.

Do not bother with data speed tests until the sync speed is sorted.

EDIT: Posts crossing with @Gandalf the Grey bearer of good tiding from a land far off in the East - line sync at 77mbps is great news (dark magic!).

[#10]

Unless I’m mistaken, I think the main issue was packet loss and high latency rather than slow speeds. With a high sync speed and line tests now passing, things are definitely moving in the right direction though.

There’s no training period per se for FTTC however there are DLM (Dynamic Line Management) induced settings, for example interleaving could have been added as a result of the faults, which would mean higher latency. If so then we would need to allow time for DLM to make adjustments following the faults being resolved. 

[#11]

Thanks for the continued assistance all.

@Gandalf - good news on the line test, but it appears specifically in the evenings, and around midday, the line is still dropping packets badly on and off.  It seems since 9pm it's gone back to a similar quantity of dropped packets as prior to the line change. 

I can try turning the PN modem back into router mode, but I then lose all graphing, logging, and monitoring capacity.  I'm ot sure how much you know about PFSense, and I don't wish to teach you to suck eggs, but I would be extremely surprised if it was the route of any issue. 

Does the PN router have similar abilities so I can continue to monitor the issue further?

[#12]

I know very little about PFSense, but I find the ThinkBroadband Quality Monitor is useful and can be set up to work with the Hub 2. I’m not sure though how it compares with PFSense. 

[#13]

Thanks @Gandalf , I've set it up, as per the below link, hopefully it provides some useful data, which in turn may lead to some other things to try.

https://www.thinkbroadband.com/broadband/monitoring/quality/share/5daa664837ec39cf519cba0ec9c93f7758...

It'll be interesting to see how it correlates to pfsense' graphing of the same duration, come tomorrow evening.  This has been the last 24hr's monitoring though 

I'll keep you all posted with any additional revelations!  Thanks again all for your time spent trying to help

[#14]

The TBBQM looks fairly OK - what is happening between 08.30am and 9am?  A bit of morning news streaming ... or cloud syncing?

On a link which is busy, ping packets (used to measure latency) will be the first to be ignored.  Such on its own is not something to be too concerned about.

[#15]

@Townman Do you mean PM in the post above?😉