Little peak time latency humps

[#1]

Quote from: purleigh

I wouldn't have expected ANY peak time 'titanium' latency 'hump' as my connection bandwidth was barely being used, so latency shouldn't have increased as prioritization wouldn't have kicked in.

The traffic is always being marked and is always going through the shapers and queues, while your line (and thus your shaper) isn't congested when you're not doing anything else it isn't necessarily down to the fact there's no congestion but the CPU and queue dequeuing time across the whole device rather than just you.

[#2]

mtr -o JMI NLABWS -c 100 bbc.co.uk --report

Or
mtr bbc.co.uk
then press o hold shift  and type the following  JMI NLABWS then press enter
RPi to install it.

sudo apt-get install mtr

[#3]

Yes, it's crucial to specify the field order in order(!) to unlock the secret TCP ping functionality of mtr. It also makes it run smoother so you don't get so much pinking at high revs, which can damage the internal traceroute engine. 
Sorry for the excess jollity - it is Friday, and in response to a cryptic post!    If you mean mtr might be a useful tool for finding the source of jitter, it doesn't tend to be, as it turns out, because PlusNet's routers are set up to give a low priority to responding to ICMP echo requests (as opposed to routing them).
This output from WinMTR just now (since it was to hand) illustrates that quite well:
[tt]|------------------------------------------------------------------------------------------|
|                                      WinMTR statistics                                  |
|                      Host              -  %  | Sent | Recv | Best | Avrg | Wrst | Last |
|------------------------------------------------|------|------|------|------|------|------|
|        lo0-central10.ptn-ag01.plus.net -    0 |  20 |  20 |    0 |  20 |  191 |  10 |
|      link-a-central10.ptn-gw01.plus.net -    0 |  20 |  20 |    0 |    8 |  10 |  10 |
|                104.core.access.plus.net -    0 |  20 |  20 |  10 |  12 |  40 |  40 |
|              kingston-gw.thdo.bbc.co.uk -    0 |  20 |  20 |    0 |    9 |  10 |  10 |
|                  No response from host -  100 |  20 |    0 |    0 |    0 |    0 |    0 |
|                  No response from host -  100 |  20 |    0 |    0 |    0 |    0 |    0 |
|                ae0.er01.telhc.bbc.co.uk -    0 |  20 |  20 |    0 |    9 |  10 |  10 |
|                        132.185.255.149 -    0 |  20 |  20 |    0 |    9 |  10 |  10 |
|              bbc-vip111.telhc.bbc.co.uk -    0 |  20 |  20 |    0 |    9 |  10 |  10 |
|________________________________________________|______|______|______|______|______|______|
  WinMTR - 0.8. Copyleft @2000-2002 Vasile Laurentiu Stanimir  ( stanimir@cr.nivis.com )[/tt]

It also illustrates the value of using the same utility for any comparative tests, since the Windows command line ping is returning 4ms to the BBC, not 9 or 10 as above. This morning it was 3ms, though, so something has changed. DNS latency has gone up massively too in the last few hours, actually - this morning it was really low.
Anyway, in my little test at lunchtime, the periodic high figures could equally well have been caused by something on that machine, in fact - I didn't do enough testing to rule anything out.

As a side note, for anyone as puzzled as wot i woz, the available fields in the Linux version of mtr are:
L=Loss ratio, D=Dropped packets, R=Received packets, S=Sent Packets, N=Newest RTT(ms), B=Min/Best RTT(ms), A=Average RTT(ms), W=Max/Worst RTT(ms), V=Standard Deviation, G=Geometric Mean, J=Current Jitter, M=Jitter Mean/Avg., X=Worst Jitter, I=Interarrival Jitter

[#4]

Quote from: dave

Quote from: mikehiow Are the gateways where a users session is handed over from BTW to yourselves? I assume this happens in London somewhere? If I ping BT's management gateway from the BTOR modem, I get latencies of around 6-7ms. Yeah, although there is a front end router in between BTW and PCL-AG01 (I can't ping from that as the routing isn't configured to allow that). This is all down in London across our data centres down there. We have a private peering link with the BBC across to their data centre. There's no interleaving on your line: Sync Status In Sync Downstream Speed 80.0 Mbps Upstream Speed 20.0 Mbps Appointment Required N Fault Target Fix Time Fault Report Advised N Profile Name 40M-80M Downstream, Interleaving Off - 10M-20M Upstream, Interleaving Off Do you know if there's any difference in the latency if you are connected to a PTN/PTW gateway or PCL? The BBC peering is in PTW so in theory the PTW gateways are slightly nearer (but that shouldn't make 3ms difference) but worth seeing. Also might be worth taking the router out of the equation and setting up a PPPoE connection on the PC and see if that makes any difference (make sure you have a firewall!) in the latency.

Yeah, I'm aware there's no Interleaving.
I'm currently connected to PTW-AG01 and I'm seeing 10.8-11.6ms to bbc.
Removing the router makes almost no different to latency and since I've had FTTC, I've used the Technicolour, N66U and now pfSense.

[#5]

Quote from: AndyH

@ Amos91 Do you notice it impacting your performance?

I didn't get a chance to play any games but from previous experience with virgin media it contributed to noticeable rubber banding in sensitive games like Iracing.
Either way there shouldn't be any ping differences at any time.

[#6]

Interestingly since I put the new router in my lumps have disappeared.
The Red is where I forgot to enable bb ping 
Then the next day
etc

So def an improvement for me, not that I actually noticed anything 

[#7]

It's just quiet.  Check tonight as we get to peak and see if they come back

[#8]

The graph isn't looking great during the Sunday evening peak session.
Doing the 1000 pings to bbc.co.uk right now.

[#9]

Yeah.  We'll we can definitely say that the changes Dave applied and backed out remove the peak time affect.
We'll see the next step tomorrow!

[#10]

Ping statistics for 212.58.251.195:
    Packets: Sent = 1000, Received = 1000, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 4ms, Maximum = 120ms, Average = 5ms
It's strange. Performance is fine - but there are one or two pings every few mins that are a lot higher than normal. In a way, the graph is a bit misleading because more than 99% of the pings are absolutely normal. I did a couple of 100 ping sets and they came back with a max ping of 9 and 7.

[#11]

It isn't misleading, because the blue trace shows your 99% of average 'normal' pings, and the yellow trace is showing the 1% slow pings.

My graph has random slow pings all the time that I'm online, and big blue spikes when the SamKnows box does a speedtest.

[#12]

Quote from: purleigh

It isn't misleading, because the blue trace shows your 99% of average 'normal' pings, and the yellow trace is showing the 1% slow pings.

But the average when doing pings from cmd prompt is coming back 5ms - yet it is showing higher on TBB.
TBB sends pings every sec and each line represents 100 secs of monitoring. I think it took around 10 mins to do 1,000 pings from cmd prompt, but only a few pings were higher than my normal 5-6 ms (they were consecutive pings too). I just don't think the TBB graph shows what I was getting from the cmd prompt.

[#13]

A view of the 17th 18th
pcl-ag04

[#14]

Quote from: Kelly

That's the theory and how we've designed it, but we've spotted this:   http://forums.thinkbroadband.com/plusnet/t/4240634-re-bqm-i-think-not-relevant-to-gaming-performance-on-pn.html which is what we've been working to correct with some weighting changes.

The thing is, I observed the same odd TCP

Quote from: Kelly

packet taking 20ms or so longer than average (representing the maximum latency increase) This occasional delay is enough to push the average by a couple of ms at peak.

So if the TCP packets to port 80 are in the gold queue, does the titanium-gold queue switching theory still stand up, or is something else happening (as well)?
Andy seems to have confirmed that the effect wasn't an artefact caused by my PC, LAN or router, and, as he says, it's one or two packets in a hundred, -- but both TCP (gold) and  ICMP (titanium).
Also, my brief test wasn't in the evening peak. So maybe it's something more fundamental. Or maybe we're both observing something entirely different from the "hump" phenomenon (and possibly completely insignificant, although it does appear to be consistent and repeatable at any rate).

[#15]

Dave did a test where we forced all traffic into the gold queue and set up a graph.  We saw a much more stable graph as long as there was only the ping graph traffic through it.  This lead us to this avenue of testing.