Little peak time latency humps

[#1]

Any more news regarding this peak time jitter /latency humps? You can see just how much effect that what believe to be  congestion at peak times has when i download or upload anything during this period at all other times or on the a day where there is no jitter  the increase in latency  is small and throughput is at the max ,

[#2]

Quote from: Kelly

We are trying to see if you are seeing impact from the hump on your performance

Understandably, people don't seem to have quite taken up the invitation to follow a protocol in investigating this, so I don't know how useful the following suggestions may be.
It seems logical that there would be a noticeable effect on web browsing because it generally involves setting up a lot of connections to pull in a web page, but the amount of data transferred is comparatively small.
The problem is how to measure that and separate network from web server and client effects.
The jitter is certainly very visible in DNS queries. On Wednesday evening it was extreme (but I, like others, wasn't dedicated enough to record all the details!) A useful tool for automating the sampling of that effect in a consistent way is ns_bench in combination with pings.
Perhaps the W3C Navigation Timing features of the most popular modern browsers can help in pinning down the effects, as suggested here, but it is going to be hard to achieve consistency so that the results can be compared.
Another possibility, stripping out the variables of both browser and DNS, may be to compare cURL requests, something like this:

curl -o "C:\curl_test_download.html" --user-agent "Mozilla/5.0" --write-out "\nURL Fetched:\t\t%{url_effective}\nConnected after:\t%{time_connect} Secs\nTransfer started after:\t%{time_starttransfer} Secs\n" --resolve www.bbc.co.uk:80:212.58.246.92 http://www.bbc.co.uk/news/

I'm not sure to what extent those two numbers can help to build up a picture or would even reveal anything out of the ordinary. Clearly there are serious limitations to the approach. It is only a single HTTP request, for a start. And the BBC news page may not be the best test target for obvious reasons - although, having said that you can see here that around 8-10pm is a quieter time at the BBC than the middle of the day, so it could prove a useful comparator.
Anyone have any other ideas?

[#3]

The SamKnows box includes a measure of website load times. It also has an option to show the hourly averages. Attached is a graph for June to date.
One thing I have found with SamKnows stats is that they make no attempt to exclude anomalous results, so one bad result can seriously distort the results.

[#4]

This is the SamKnows test protocol:

Quote

Web Browsing Measures the time taken to fetch the HTML and referenced resources from a page of a popular website. This test does not test against centralised testing nodes; instead it tests against real websites, ensuring that content distribution networks and other performance enhancing factors may be taken into account. Each Whitebox will test ten common websites on every test run. The time taken to download the resources, the number of bytes transferred and the calculated rate per second will be recorded. The primary measure for this test is the total time taken to download the HTML page and all associated images, Javascript and stylesheet resources. The results include the time taken for DNS resolution. The test uses up to eight concurrent TCP connections to fetch resources from targets. The test pools TCP connections and utilises persistent connections where the remote HTTP server supports them. The test may optionally run with or without HTTP headers advertising cache support (through the inclusion or exclusion of the “Cache-Control: no-cache” request header). The client advertises the user agent of Microsoft Internet Explorer 8.

I don't think it will specifically be able to identify sluggish web browsing performance caused by traffic-management-induced latency, if that is what's going on; but can you see any pattern in your graphs, jelv?
Samknows does actually make the source code available as well. I haven't checked it, but it sounds like they may be using wget for this test.
Nevertheless, maybe PlusNet should consider making the Java-based web browser version of the tests available to all customers, even if they don't have a whitebox?...

[#5]

Browsing /web pages loading time, doesn't seem to slow down,  the only page that i have come across that can sometimes  take an age to completely load is the one on this forum with all the think broadband quality meter graphs on it ,Earley this morning probably at around 2.30am  for no apparent  reason  my base latency increased  the increase although only 3-4ms  for some reason was applied to the gateway that i was on , after GW hopping  i was able to restore the original base latency level, I also tested the throughput, and was able to achieve a slightly higher download rate (highest since my service was activated)  I then checked the network performance  http://www.plus.net/support/service/network_performance/broadband_bandwidth_usage.shtml and the GW that i was connected to at that time have a very small amount of customers connected to it , I have re tested throughput since and the small gain i had earlier  has gone, the usage is currently above it's average , Maybe  the number of people connected to any one gateway  is part of the reason for the jitter,
I would like to ask is , Why is it  that some plusnet Gateways  have a higher base latency/ping , and should they all not be the same (as low as possible) ?

[#6]

We aim to keep the balance perfect and indeed have recently rolled out some automation on that score (at least for 21CN, which we have more control over - unfortunately we haven't been able to implement it for 20CN connections as yet). Unfortunately though with as many connections coming in and out as often as they do maintaining balance is not easy and won't always be perfect.
Ideally yes they should all be the same but as per the above it's not that easy to achieve.

[#7]

Quote from: Matt

Unfortunately though with as many connections coming in and out as often as they do maintaining balance is not easy and won't always be perfect.

[cynic mode]
Perhaps someone very high up should be kicking Openreach very hard to get people's connections repaired properly [/cynic mode]

[#8]

I'm not sure what quantity would be down to faulty disconnects but I suspect it'd be very very small in relation to the number of overall connections/disconnections we have anyway in a given period.

[#9]

Hi all,
We're going to be doing some testing next week to see if we improve this and try and eliminate the peak time latency hump that people are seeing. We have a theory as to what's causing the problem based on some testing we've done in the labs and want to try out two possible fixes.
So next Monday we will be making some changes to PCL-AG01 and PCL-AG02 to see if we can improve this. Each one will have a different fix on it, like I say we've got 2 possible solutions so we want to try them both out. The fixes will be in place from Monday afternoon through to Thursday afternoon when we will back the changes out and revert back to the current config. Based on the results of the tests we will then try out some additional changes Monday to Thursday the week after across the whole network and again back the changes out at the end of the test so we can review and decide on the best permanent change.
The change next week will be make adjustments to how the weighting of each of the different queues of traffic (titanium, gold, silver, bronze etc.) gets on the network. It won't change the order just adjust how the network treats each of those queues when the network gets busy. In the labs we've seen that a busy network can potentially increase the latency a small amount on the titanium queue so we're trying to change that so it doesn't.
We'd therefore like to see as many people as possible connected to PCL-AG01 or PCL-AG02 as possible next week especially if you have Thinkbroadband latency graphs. We'd like to see if the changes we're doing have any impact on your performance or on your graphs. We're running the test for 3 nights to give us a decent amount of time to gather data so any help will be really appreciated, even if you just get on PCL-AG01 and PCL-AG02 and do nothing and just let us have the link to your graph.

[#10]

Change made on PCL-AG01 and PCL-AG02. If you can help and get on to one of those gateways would be really appreciated. Even if you aren't in to do any testing, if your line is on one of them and you have a Thinkbroadband test set up that would be useful for us to see too.

[#11]

After about twenty ADSL disconnect/connect sequences to hop gateways, I'm now ready !  
[quote=Gateway Checker]Which gateway
You are currently connected to gateway pcl-ag01.

This is my live TBB graph -

[#12]

At work currently but I believe from a trace route home I am on PCL-AG02.
1  205ms  RS-Gateway.local [78.129.174.1]
2  0ms    87.117.211.45
3  1ms    593.core1.thn.as20860.net [62.233.127.173]
4  1ms    202.core1.hex.as20860.net [62.233.127.1]
5  1ms    linx-gw2.plus.net [195.66.236.164]
6  1ms    ae1.pcl-cr02.plus.net [195.166.129.3]
7  1ms    vlan128.pih-gw3.plus.net [212.159.0.199]
8  2ms    link-b-central10.pcl-ag02.plus.net [212.159.2.167]
9  10ms   My router
Will update tomorrow morning with an updated graph. I've noticed that there has been the odd ping spike at peak times to both google.co.uk and bbc.co.uk (30ms-100ms). Pretty disappointing start to Plusnet coming from the non-traffic shaped Be*.
Always wondered if you are so far below capacity, would no traffic management actually make it go over? Funny how your testing it as the cause.
My current graph below:

[#13]

On PCL-AG01 now.
The following is my TBB monitor:
http://www.thinkbroadband.com/ping/share/640afe2accf2eb4c958ce2ee4165c98c.html

This is a fairly typical humpy graph for me (in my case, I only see them around 2 out of 3 nights).  I had been on ptn-ag01 since 20th July.
http://www.thinkbroadband.com/ping/share/26258ac49bd62b9d6d1fa2aca8eb14ee-05-08-2013.html

If you want any further historical graphs please just let me know.

[#14]

Not wanting to pre-judge, but the graph looks pretty hairy still.

[#15]

Are you doing anything though?  We expect spikes of yellow when you are doing things, just not the constant pattern we've been seeing at peak when people aren't browsing.