The red is loss, as measured by one second LCP echoes over the PPP link, and is often over 5%. Levels of random packet like this are severely impacting his ability to make use of the service.
The loss started at the exact moment BT did work on the circuit due to a major outage, so is clearly related.
This is the line before the outage, and you do not get much clearer than that - no loss. Same as every day before :-
This is the day the line came back after their major outage (which lasted two days) :-
And this is the next day, which looks much like every day since :-
It does not take a rocket scientist to see there is a problem there - periods of around 5% loss, sometimes more, most of the day, every day, since the outage.
And yes, that is start of OCTOBER 2016! BT have failed to fix the fault for that long!
Today we got this, and I am almost at a loss for words! Talk about teaching us to suck eggs!
Is the customer using a VPN? Data is transmitted in discrete units known as packets. When a network server is overloaded, these can get discarded. This is known as packet loss and results in slow loading game dynamics and graphics, or the unsatisfactory performance of a VPN connection. In such circumstances, there isn't much which can be done to improve matters, as the cause is not associated with your PC or broadband service.
I'm really not happy about this, but the "there isn't much which can be done to improve matters" is just shocking. We have asked BT to confirm if they are stating, officially, that 5% loss on an idle line is considered "acceptable" for a GEA/FTTC service - we await the response.
They even go on to say :-
In the meantime can you ask the customer to run some traceroute and provide and this hopefully will aid us in seeing where in the network the packet loss is occurring. SPs engineers can use a "wire shark" which can detect packet loss at points in network.
This is after explaining that we can see the loss at the LCP level on the PPP link and providing access to and copies of graphs showing the loss over and over again! It is like dealing with Dory to find a fault called Nemo. We keep having to repeat ourselves.
There is one other small snag.
We are all used to the notion of "fibre" broadband not actually being "fibre" which is why this is "Fibre to the cabinet". BT sell this to us as "Fibre to the cabinet" and call it FTTC. It turns out this line is in fact "Microwave to the cabinet". A good idea, normally, but not as described, and clearly beyond BT to actually understand and fix.
This just highlights the problem with a clear definition of the service: We need a clear specification of levels of idle/random packet loss, idle latency and jitter, reliability/resyncs, min sync speeds up and down, and even throughout before loss/latency starts. Without these you can literally spend months bashing your head against a brick wall and having engineer after engineer sent (each potentially costing around £200).