DNS Resolution Slow

[#1]

Have you answered what your normal latency was on the Be network?
Your line speed profile is higher that your BT profile atm.  I'll change that is it could be causing retransmissions and slowing you down,  I'll check and change that tomorrow.

[#2]

Thanks for following this up on a Sunday, Kelly.
I'm not quite sure I follow you, but I think the line is still in the training period after the upstream cap was removed, and certainly resync'd at a higher speed when I rebooted the router for the test.
I don't have thorough and systematic latency records, but the average of 20 pings to www.bbc.co.uk on 21st May at 09:56 on the Be* network was 11ms.
The same average just now on the PlusNet network was 24ms.
Different IP address, but 9 hops in both cases.
Couple of screenshots attached of comparative DNS performance (showing OpenDNS to be even faster via the Be* connection than their own servers!) The figures are calculated from 10 A record queries for the name www.google.com
I sent tech support a Wireshark capture of something similar from Saturday, which showed some improvement, as noted above.
I'll be able to compare FTTP in a couple of weeks.

[#3]

Ok.  We've set your profile to match your current BT speed profile.  This means the QoS should be performing right.  You may find your line performs a bit more predictably.  Try those curl requests again to see if they are better?
Re: your latency differences, Chris Purvey has just told me that you have some interleaving on.  This will increase your latency a bit.  We can remove it if you want but you may risk some line instability.  Worth a shot though.  Let us know if you want us to try that.
After that there may still be some difference in minimum latency based on differences between BE's and BTW's backhaul from the exchange.  20ms is still an ok latency though!

[#4]

Thanks for continuing to look at this, Kelly.
Here are some current DNS stats:

[tt]Nameserver              Response Time (ms) Over 10 Lookups of www.google.com
                        min avg max stdev retries
192.168.0.1(212.159.6.9) 27.19 28.84 30.54 1.11 0
212.159.6.9              25.04 25.96 26.61 0.57 0
212.159.6.10            25.39 26.18 27.23 0.59 0
212.159.13.49            26.27 26.68 27.19 0.30 0
212.159.13.50            25.30 26.06 27.06 0.80 0
208.67.222.222          33.26 33.87 34.57 0.54 0
208.67.220.220          33.15 33.62 34.49 0.46 0
8.8.8.8                  35.26 35.82 36.60 0.46 0
8.8.4.4                  34.56 35.31 36.64 0.70 0
4.2.2.1                  25.87 26.26 26.86 0.38 0
4.2.2.6                  25.56 26.06 27.10 0.55 0[/tt]

I don't think it's a good idea to turn the interleaving off on the downstream, but it was off on the upstream with Be* and that didn't cause any problems, so if you think the fact that the upstream is interleaved is really causing that much extra latency compared to the same line on Be* then we can certainly experiment with turning it off on that portion of the signal. Please leave it on downstream, though (unless the depth is set unusually high, in which case it could perhaps usefully be reduced - again, if extra interleaving depth does cause extra latency).
Of course, differences due to the way the core network is structured, as opposed to those caused by QoS equipment functioning or DNS service configuration, will not be able to be eliminated.
There has, however, been an improvement of approximately 20% since I raised the issue and I remain unclear as to where this has come from.

[#5]

Something that may or may not be relevant: I tried pinging my current gateway:

C:\Users\John>ping -t 195.166.128.182
Pinging 195.166.128.182 with 32 bytes of data:
Reply from 195.166.128.182: bytes=32 time=60ms TTL=126
Reply from 195.166.128.182: bytes=32 time=84ms TTL=126
Reply from 195.166.128.182: bytes=32 time=38ms TTL=126
Reply from 195.166.128.182: bytes=32 time=294ms TTL=126
Reply from 195.166.128.182: bytes=32 time=64ms TTL=126
Reply from 195.166.128.182: bytes=32 time=28ms TTL=126
Reply from 195.166.128.182: bytes=32 time=106ms TTL=126
Reply from 195.166.128.182: bytes=32 time=67ms TTL=126
Reply from 195.166.128.182: bytes=32 time=42ms TTL=126
Reply from 195.166.128.182: bytes=32 time=17ms TTL=126
Reply from 195.166.128.182: bytes=32 time=103ms TTL=126
Reply from 195.166.128.182: bytes=32 time=197ms TTL=126
Reply from 195.166.128.182: bytes=32 time=35ms TTL=126
Reply from 195.166.128.182: bytes=32 time=16ms TTL=126
Reply from 195.166.128.182: bytes=32 time=100ms TTL=126
Reply from 195.166.128.182: bytes=32 time=184ms TTL=126
Reply from 195.166.128.182: bytes=32 time=83ms TTL=126
Reply from 195.166.128.182: bytes=32 time=33ms TTL=126
Reply from 195.166.128.182: bytes=32 time=180ms TTL=126
Reply from 195.166.128.182: bytes=32 time=409ms TTL=126
Reply from 195.166.128.182: bytes=32 time=416ms TTL=126
Reply from 195.166.128.182: bytes=32 time=233ms TTL=126
Reply from 195.166.128.182: bytes=32 time=302ms TTL=126
Reply from 195.166.128.182: bytes=32 time=17ms TTL=126
Reply from 195.166.128.182: bytes=32 time=272ms TTL=126
Reply from 195.166.128.182: bytes=32 time=74ms TTL=126
Reply from 195.166.128.182: bytes=32 time=264ms TTL=126
Reply from 195.166.128.182: bytes=32 time=172ms TTL=126
Reply from 195.166.128.182: bytes=32 time=15ms TTL=126
Reply from 195.166.128.182: bytes=32 time=25ms TTL=126
Reply from 195.166.128.182: bytes=32 time=111ms TTL=126
Reply from 195.166.128.182: bytes=32 time=171ms TTL=126
Reply from 195.166.128.182: bytes=32 time=175ms TTL=126
Reply from 195.166.128.182: bytes=32 time=114ms TTL=126
Reply from 195.166.128.182: bytes=32 time=308ms TTL=126
Reply from 195.166.128.182: bytes=32 time=443ms TTL=126
Reply from 195.166.128.182: bytes=32 time=305ms TTL=126
Reply from 195.166.128.182: bytes=32 time=60ms TTL=126
Reply from 195.166.128.182: bytes=32 time=275ms TTL=126
Reply from 195.166.128.182: bytes=32 time=131ms TTL=126
Reply from 195.166.128.182: bytes=32 time=235ms TTL=126
Reply from 195.166.128.182: bytes=32 time=269ms TTL=126
Reply from 195.166.128.182: bytes=32 time=50ms TTL=126
Reply from 195.166.128.182: bytes=32 time=431ms TTL=126
Ping statistics for 195.166.128.182:
    Packets: Sent = 44, Received = 44, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 15ms, Maximum = 443ms, Average = 159ms

[#6]

Thanks for pointing that out, jelv. Well noticed. I'm getting something not dissimilar from pcl-ag02.
Web browsing is like wading through treacle here today. Might as well not bother.
Definitely regretting the move from Be* to PlusNet. If it's not one thing, it's another, it seems. If it doesn't get better with a move to fibre it will all have been for nothing. Just a complete waste of time.
[tt]Pinging 195.166.128.183 with 32 bytes of data:
Reply from 195.166.128.183: bytes=32 time=200ms TTL=126
Reply from 195.166.128.183: bytes=32 time=243ms TTL=126
Reply from 195.166.128.183: bytes=32 time=333ms TTL=126
Reply from 195.166.128.183: bytes=32 time=175ms TTL=126
Reply from 195.166.128.183: bytes=32 time=295ms TTL=126
Reply from 195.166.128.183: bytes=32 time=201ms TTL=126
Reply from 195.166.128.183: bytes=32 time=693ms TTL=126
Request timed out.
Request timed out.
Request timed out.
Reply from 195.166.128.183: bytes=32 time=796ms TTL=126
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Reply from 195.166.128.183: bytes=32 time=399ms TTL=126
Reply from 195.166.128.183: bytes=32 time=222ms TTL=126
Reply from 195.166.128.183: bytes=32 time=816ms TTL=126
Reply from 195.166.128.183: bytes=32 time=557ms TTL=126
Reply from 195.166.128.183: bytes=32 time=582ms TTL=126
Reply from 195.166.128.183: bytes=32 time=29ms TTL=126
Reply from 195.166.128.183: bytes=32 time=98ms TTL=126
Reply from 195.166.128.183: bytes=32 time=155ms TTL=126
Reply from 195.166.128.183: bytes=32 time=215ms TTL=126
Reply from 195.166.128.183: bytes=32 time=62ms TTL=126
Reply from 195.166.128.183: bytes=32 time=207ms TTL=126
Reply from 195.166.128.183: bytes=32 time=23ms TTL=126
Reply from 195.166.128.183: bytes=32 time=57ms TTL=126
Reply from 195.166.128.183: bytes=32 time=32ms TTL=126
Reply from 195.166.128.183: bytes=32 time=23ms TTL=126
Reply from 195.166.128.183: bytes=32 time=23ms TTL=126
Reply from 195.166.128.183: bytes=32 time=34ms TTL=126
Reply from 195.166.128.183: bytes=32 time=25ms TTL=126
Reply from 195.166.128.183: bytes=32 time=26ms TTL=126
Reply from 195.166.128.183: bytes=32 time=29ms TTL=126
Reply from 195.166.128.183: bytes=32 time=23ms TTL=126
Reply from 195.166.128.183: bytes=32 time=24ms TTL=126
Reply from 195.166.128.183: bytes=32 time=46ms TTL=126
Reply from 195.166.128.183: bytes=32 time=23ms TTL=126
Reply from 195.166.128.183: bytes=32 time=35ms TTL=126
Reply from 195.166.128.183: bytes=32 time=25ms TTL=126
Reply from 195.166.128.183: bytes=32 time=24ms TTL=126
Reply from 195.166.128.183: bytes=32 time=24ms TTL=126
Reply from 195.166.128.183: bytes=32 time=23ms TTL=126
Reply from 195.166.128.183: bytes=32 time=24ms TTL=126
Reply from 195.166.128.183: bytes=32 time=27ms TTL=126
Ping statistics for 195.166.128.183:
    Packets: Sent = 53, Received = 39, Lost = 14 (26% loss),
Approximate round trip times in milli-seconds:
    Minimum = 23ms, Maximum =  816ms, Average =  129ms[/tt]

[#7]

edit: I totally didn't read your post right.
Chris P is going to try and give you a call.  You've got loads of errors on your line atm.  Something isn't right.

[#8]

Missing replies? I don't understand...
As I replied to jelv, pretty much like treacle here. Worse than before, despite the apparent slight improvement in DNS resolution times.
I'm getting to the point where I don't really care what the cause is any more. I don't want to spend any more time on it. I just want browsing to work at least as quickly as it did on Be* and if it takes a move to 160Mbps fibre to achieve that, then fine. If even that doesn't improve things, I want out.

[#9]

I suspect you saw my original reply before I edited it.  I missed the bit about browsing performance.  I think Chris is on the phone to you now.

[#10]

Thanks for your time on the phone, as discussed I have rasied a fault with our suppliers as we're seeing errors on your line and I've also placed a modify order to move you over to ADSL2+ which will complete tomorrow.
I've created a ticket(#70307891) on your account which you can view here.

[#11]

Kelly,
Any idea why I'm seeing such a wild variation in response from the gateway? I'd expect a significant variation, but given the time of day nothing like as much as I am seeing. To me that says it's a box that is significantly loaded.

[#12]

Hi SuperZoom,
I've updated your ticket with the latest information regarding your line and the fault that was raised.

[#13]

OK. Where to start?
Yes, you're right Kelly, I did post before you edited your reply, and then almost immediately Chris called me. Unfortunately, he caught me just as I was off to do more pressing things, by which time I had also become really quite fed up with the hassle, as you and he would have been able to tell. Sorry for the delay in coming back to you.
And thank you for taking the time and trouble to call me, Chris. As I said to you on the phone, I am extremely impressed with PlusNet's attitude to customers and general approach, so I wouldn't want to lose sight of that.
That said, I wonder whether the company maybe knows a bit more about this problem than it is letting on. I think jelv's point above may be highly pertinent (and I'll post some gateway pings from today below to compare with yesterday's). I think the problem is precisely that things are overloaded somewhere (or possibly in several areas). I wonder whether the issue is that most of the traffic is gold traffic, and there is a lot of it. The traffic prioritisation, therefore, isn't doing much on that front, and every now and then also has to delay some titanium traffic to let gold get through. The sheer volume of traffic with the same 2nd-level priority is causing a sluggish browsing experience compared to Be*. That's not to say traffic prioritisation is bad, but it isn't succeeding in having the intended effect. Or, if this is intended, it's not an effect I appreciate, having had something to compare it with!
So, let's deal with line 'issues' first. There are none of any significance as far as I can tell. I'm not sure what errors you were seeing yesterday, but if they were corrected by interleaving then that's what it's there for, of course. I didn't see any indication that any such correction was the cause specifically of sluggish browsing. Today the line has synced on ADSL2 (not 2+, which is pretty much as expected given the base quality of the line, so no issue there) but at the same sync speed as before in any case: 6672 Kbps down and 883 Kbps up. It looks as if interleaving is also off on the upstream, which is all well and good. Thank you for sorting all that out and experimenting with it - certainly worth doing. There has, however, been no change in ping times or DNS resolution times from that (still 24ms to BBC, 40ms to Germany, and DNS largely the same as posted yesterday.) So all of that's fine, but the line is the line, it's the same line as with Be*, if anything the line speed is higher with PlusNet, but the browsing experience is still worse.
It is a little better today, I must say. (I think I've seen an improvement, at least: who knows what reality really is any more?!!) But maybe that is explained by the fact that I am connected to a different gateway (ptn-ag02) and pinging it produces less horrendous results. Whether or not that is significant, I don't know. I certainly have better things to be doing than responding to ping requests, so no doubt the gateway does as well!    This is what it looks like, anyway:
[tt]Pinging 195.166.128.191 with 32 bytes of data:
Reply from 195.166.128.191: bytes=32 time=33ms TTL=126
Reply from 195.166.128.191: bytes=32 time=24ms TTL=126
Reply from 195.166.128.191: bytes=32 time=33ms TTL=126
Reply from 195.166.128.191: bytes=32 time=25ms TTL=126
Reply from 195.166.128.191: bytes=32 time=28ms TTL=126
Reply from 195.166.128.191: bytes=32 time=26ms TTL=126
Reply from 195.166.128.191: bytes=32 time=26ms TTL=126
Reply from 195.166.128.191: bytes=32 time=25ms TTL=126
Reply from 195.166.128.191: bytes=32 time=28ms TTL=126
Reply from 195.166.128.191: bytes=32 time=77ms TTL=126
Reply from 195.166.128.191: bytes=32 time=27ms TTL=126
Reply from 195.166.128.191: bytes=32 time=113ms TTL=126
Reply from 195.166.128.191: bytes=32 time=49ms TTL=126
Reply from 195.166.128.191: bytes=32 time=24ms TTL=126
Reply from 195.166.128.191: bytes=32 time=27ms TTL=126
Reply from 195.166.128.191: bytes=32 time=28ms TTL=126
Reply from 195.166.128.191: bytes=32 time=34ms TTL=126
Reply from 195.166.128.191: bytes=32 time=30ms TTL=126
Reply from 195.166.128.191: bytes=32 time=26ms TTL=126
Reply from 195.166.128.191: bytes=32 time=33ms TTL=126
Reply from 195.166.128.191: bytes=32 time=30ms TTL=126
Reply from 195.166.128.191: bytes=32 time=24ms TTL=126
Reply from 195.166.128.191: bytes=32 time=34ms TTL=126
Reply from 195.166.128.191: bytes=32 time=23ms TTL=126
Reply from 195.166.128.191: bytes=32 time=28ms TTL=126
Reply from 195.166.128.191: bytes=32 time=26ms TTL=126
Reply from 195.166.128.191: bytes=32 time=26ms TTL=126
Reply from 195.166.128.191: bytes=32 time=27ms TTL=126
Reply from 195.166.128.191: bytes=32 time=24ms TTL=126
Reply from 195.166.128.191: bytes=32 time=23ms TTL=126
Reply from 195.166.128.191: bytes=32 time=48ms TTL=126
Reply from 195.166.128.191: bytes=32 time=23ms TTL=126
Reply from 195.166.128.191: bytes=32 time=229ms TTL=126
Reply from 195.166.128.191: bytes=32 time=26ms TTL=126
Reply from 195.166.128.191: bytes=32 time=63ms TTL=126
Reply from 195.166.128.191: bytes=32 time=28ms TTL=126
Reply from 195.166.128.191: bytes=32 time=43ms TTL=126
Reply from 195.166.128.191: bytes=32 time=27ms TTL=126
Reply from 195.166.128.191: bytes=32 time=24ms TTL=126
Reply from 195.166.128.191: bytes=32 time=25ms TTL=126
Reply from 195.166.128.191: bytes=32 time=24ms TTL=126[/tt]

So where next? Well, as far as general latency goes, I had a good chat to the man from Openreach today when he blew the fibre through to the CSP and he said other people on FTTP in nearby streets were getting pings of about 5ms (all of them on BT Infinity, according to him). So it looks as if the fibre should shed some valuable light on the issue.
In the meantime, I'd just like to post a couple of illuminating cURL results in order to eliminate some red herrings raised previously
You can't get an accurate indication of maximum throughput speed with small file sizes, so I created a really big (153MB) HTML file from some long documents and stuck a copy on a server in Germany and one on a Windows Apache server I very quickly set up on my LAN (no optimization or anything like that).
This is the result, using the same ancient machine as before as the client, on the LAN:
[tt]Name resolved after:    0.000 Secs
Connected after:        0.010 Secs
Transfer started after: 0.030 Secs
Total transfer size:    160577341 Bytes
Total time taken:      13.359 Secs
Perceived Speed:        12020161.000 Bytes/Sec[/tt]
So that's 91Mbps. So there is no issue with the machine or the network locally. Hardware constraints mean that this machine is not going to be able to pull in data at full gigabit speeds, but there is definitely nothing wrong with it.
I emphasise again that browsing speeds were quite acceptable and noticeably faster when connected via Be*. Same machine. Same setup. Different ISP.
So what about the same file from a remote server, pulled down via the router (at a sync speed of 6672Kbps)?
[tt]Name resolved after:    0.160 Secs
Connected after:        0.200 Secs
Transfer started after: 0.280 Secs
Total transfer size:    160569861 Bytes
Total time taken:      263.809 Secs
Perceived Speed:        608659.000 Bytes/Sec[/tt]
That's 4755Kbps. But it was at 13:15. Not bad. Not sure why the transfer size is very slightly different (can't be bothered finding out) but the long name resolution time is because the domain wasn't cached.
So the slow browsing experience isn't about the ability to actually transfer the data at a sensible speed per se.
Oh, I've just seen your reply, Chris (this was open but not posted) - I'll head over to the ticket now.

[#14]

Quote from: SuperZoom

That said, I wonder whether the company maybe knows a bit more about this problem than it is letting on. I think jelv's point above may be highly pertinent (and I'll post some gateway pings from today below to compare with yesterday's). I think the problem is precisely that things are overloaded somewhere (or possibly in several areas). I wonder whether the issue is that most of the traffic is gold traffic, and there is a lot of it. The traffic prioritisation, therefore, isn't doing much on that front, and every now and then also has to delay some titanium traffic to let gold get through. The sheer volume of traffic with the same 2nd-level priority is causing a sluggish browsing experience compared to Be*. That's not to say traffic prioritisation is bad, but it isn't succeeding in having the intended effect. Or, if this is intended, it's not an effect I appreciate, having had something to compare it with!

We're always looking just in case, but the whole time you appear to have errors on your line, it's hard to differentiate local/exchange side issues with our network.  Chris will keep on that fault ticket to see it through to help clear anything up.

[#15]

Fair enough. I know these things aren't straightforward. Chris has offered to send an engineer out and (although, as you can tell, I'm sceptical) I'll certainly do what I can to facilitate that if it is going to provide helpful information. I do appreciate you looking into all this. And I hope it is helpful feedback too.