Where an increase in latency affects the yellow area, but not the blue area, then it is an indication of a relatively minor amount of congestion.
Each pixel width represents about 100 pings over 100 seconds; the blue columns tell you what has happened to the pings on average.
- If there is no blue column, then the average latency is equal to the minimum latency.
- If there is a tall yellow column, but no blue column, then there has been a delay to one or two pings. If more pings were affected, then the average would increase, and a blue column would exist
Working through the maths, you can see that each extra blue pixel requires (from 100 pings) a total of an extra 100ms of latency.
This can be achieved with
- 1 ping taking 112ms instead of 12ms
- 5 pings taking 32ms instead of 12ms
- 10 pings taking 22ms instead of 12ms
- 20 pings taking 17ms instead of 12ms
In the final pingplot attached, at around 9pm, it looks like you are seeing 1 blue pixel over a fair period (2 hours), and 2 blue pixels over short periods (5-10 mins). The average is going up slightly, while the maximum tends to be around the 22ms level or less.
That suggests that, over a 2 hour period, you are getting additional latency of 5-10ms to around 10-20% of your packets. And, in some small 5 minute bursts, the same kind of delay to around 20-40% of your packets.
That plot is quite normal for a line that was in use at the time - such as watching Netflix - or for showing low level congestion over a wide area, that is common in the evening peak. I've attached 2 examples from my line - 1st, a day when only the SamKnows tester was working, and 2nd, notably where Amazon Prime was streaming HD to the TV.
Your plot is not what I'd consider to be an indicator of anything wrong with the line. It looks unlikely to be something caused by the engineer.
Your previous attachment with large outbound pings might, instead, suggest one of Sky's routes was heavily congested, but not the one that the BQM transits over.
Edit: Added the lost attachment.