Dns seems high
Quote from: 30FTTC06
Nameserver Response Time (ms)
min/avg/max/stdev/retries
192.168.0.15 0.58/0.59/0.60/0.01/0
212.159.6.9 17.50/264.92/1250.34/492.71/0
212.159.6.10 17.77/310.92/1481.76/585.42/0
I think PlusNet were just trying to outdo you with their numbers yesterday, but they went the wrong way by mistake!
Pretty impressive attempt, though.
You may have converted me to Unbound, 30FTTC06. I installed it on a Linux laptop at lunchtime to have a play with. Did you know it can do something similar to the cache refresh thing npr likes about Acrylic too? Just add this to the conf file:
prefetch: yes
Tested ns_bench a little bit too re. the above-noted extra latency. I think it's actually nothing to do with PlusNet, the exchange or my connection - it seems to be introduced by Cygwin, in fact, when I run it under Windows (as I not infrequently do if that happens to be convenient). No difference in ping between the two platforms, but the ns_bench results are consistently 2 or 3 ms higher when running it via Cygwin than under Linux. Doesn't matter particularly, just so long as we're comparing like with like. If cached name resolution time goes up from 6 to 310 ms, it isn't the 3ms Cygwin latency that anybody's going to be concerned with!
Anyway, this is what PlusNet's servers look like from here with ns_bench on Linux this afternoon:
[tt]Nameserver Response Time (ms)
min avg max stdev retries
212.159.6.9 3.45 3.85 4.32 0.30 0
212.159.6.10 3.44 3.67 4.18 0.26 0
212.159.13.49 3.48 3.68 3.94 0.15 0
212.159.13.50 3.71 3.81 3.97 0.10 0[/tt]
No complaints there!
Oh and, just for reference, I notice they're running PowerDNS.
I've loaded unbound too.
Seems very good.
Seems very good.
Quote from: SuperZoom You may have converted me to Unbound
I can't fault it in all honesty, it does what i need it to do.
verbosity: 0
hide-identity: yes
hide-version: yes
prefetch: yes
do-ip4: yes
do-ip6: no
do-udp: yes
do-tcp: no
num-threads: 1
so-rcvbuf: 4m
so-sndbuf: 4m
cache-min-ttl: 3600
I seem to have the perfetch enabled with an older version though, i'm not 100% that it worked properly with my version, i do recall reading about a bug somewhere, it escapes me atm.
Quote from: SuperZoom ns_bench results are consistently 2 or 3 ms higher when running it via Cygwin than under Linux
What are you doing to that poor O/S? it will be confused for sure
as long as it puts pay to an issue and gives you an advantage over the meek, it's gotta be a + surely.Plusnet seem to have come good in the end, fingers crossed!, tonight will flush out any hole left in the dike now the finger has been pulled out
Quote from: vilefoxdemonofdoom I've loaded unbound too.
Seems very good.
Did you get the stats or ns_bench working on that rusty ole pc you have there yet ?
sudo unbound-control stats_noreset
Quote from: 30FTTC06 as long as it [...] gives you an advantage over the meek
I'm just worried they may inherit the Earth long before my HTTP issue gets fixed!
Well, good luck to them - at least they won't have wasted their days at the mercy of Openreach's questionable grip on reality
I was refering to the 3ms drop i'm assuming you discovered was caused by cygwin, not your http problem, my your angry today
Yes, absolutely, I know you were, and it was. But no, not angry at all - I was amused. Obviously didn't come across. Ooops! 
Does Kelly have no wisdom for you on the issue in question? it does seem to be dragging on-'n'-on so to speak 
I'm seeing peaks of 30 atm to the dns, however, bbc.co.uk seems fabulous as normal
--- bbc.co.uk ping statistics ---
124 packets transmitted, 124 received, 0% packet loss, time 123181ms
rtt min/avg/max/mdev = 16.654/17.204/17.839/0.243 ms
--- 212.159.6.9 ping statistics ---
123 packets transmitted, 123 received, 0% packet loss, time 122189ms
rtt min/avg/max/mdev = 16.197/17.306/32.508/2.093 ms
I'm seeing peaks of 30 atm to the dns, however, bbc.co.uk seems fabulous as normal
--- bbc.co.uk ping statistics ---
124 packets transmitted, 124 received, 0% packet loss, time 123181ms
rtt min/avg/max/mdev = 16.654/17.204/17.839/0.243 ms
--- 212.159.6.9 ping statistics ---
123 packets transmitted, 123 received, 0% packet loss, time 122189ms
rtt min/avg/max/mdev = 16.197/17.306/32.508/2.093 ms
Nameserver Response Time (ms)
min/avg/max/stdev/retries
192.168.0.15 0.81/0.88/0.96/0.06/0
212.159.6.9 28.54/29.93/32.48/1.54/0
212.159.6.10 23.90/25.24/27.10/1.12/0
212.159.13.49 29.25/30.39/31.65/0.79/0
212.159.13.50 25.40/28.07/32.49/2.39/0
208.67.222.123 17.34/17.64/18.18/0.31/0
208.67.220.123 17.20/17.57/17.79/0.22/0
208.67.220.222 17.20/17.42/17.51/0.12/0
208.67.222.222 17.22/17.62/18.16/0.31/0
8.8.8.8 22.89/23.22/23.48/0.22/0
8.8.4.4 22.94/23.19/23.56/0.21/0
4.2.2.1 16.97/17.35/17.65/0.23/0
4.2.2.6 17.05/17.25/17.36/0.11/0
Nameserver Response Time (ms)
min/avg/max/stdev/retries
192.168.0.15 0.82/0.86/0.96/0.05/0
212.159.6.9 25.86/29.39/32.93/2.75/0
212.159.6.10 26.61/27.94/29.99/1.13/0
212.159.13.49 27.70/28.62/29.58/0.70/0
212.159.13.50 26.82/27.70/29.06/0.87/0
208.67.222.123 17.21/17.65/17.98/0.30/0
208.67.220.123 17.46/17.62/18.13/0.26/0
208.67.220.222 17.08/17.29/17.67/0.21/0
208.67.222.222 16.77/17.27/17.54/0.31/0
8.8.8.8 22.53/23.01/23.64/0.37/0
8.8.4.4 22.66/23.15/23.85/0.40/0
4.2.2.1 17.36/17.58/17.77/0.15/0
4.2.2.6 17.01/17.32/17.59/0.19/0
Quote from: 30FTTC06 Does Kelly have no wisdom for you on the issue in question? it does seem to be dragging on-'n'-on so to speak
We're investigating it as a fault. It's not anything we've seen before 😕
Things do look better since the work the other day (ignore the blips last night/this morning, that was due to maintenance).
In other news:
It's been quite rightly pointed out to me that this graph isn't much use to us. It's merely measuring the ICMP response of the load balancers that sit in front of the caching servers, not the DNS servers themselves. The load balancers only have 100Mb interfaces at the moment. We're looking to increase that though. That's what the red packet loss this morning is from (a failed attempt at upgrading the devices). Once this work is complete I strongly suspect we'll see the TBB monitor level out.
In other news:
It's been quite rightly pointed out to me that this graph isn't much use to us. It's merely measuring the ICMP response of the load balancers that sit in front of the caching servers, not the DNS servers themselves. The load balancers only have 100Mb interfaces at the moment. We're looking to increase that though. That's what the red packet loss this morning is from (a failed attempt at upgrading the devices). Once this work is complete I strongly suspect we'll see the TBB monitor level out.
Quote from: Kelly
Quote from: 30FTTC06 Does Kelly have no wisdom for you on the issue in question? it does seem to be dragging on-'n'-on so to speak
We're investigating it as a fault. It's not anything we've seen before 😕
In fairness, Kelly, Dave and other PlusNet staff have been extremely good, and the tech support analyst who is dealing with the issue (who I'm not allowed to name according to forum rules, I think) is particularly excellent. It is just a bit wearing that it drags on, as you say. I would rather like to move on from it myself. But I have been forgetting that FTTP is a trial product, and you can't have a trial without the odd tribulation (which is actually very minor, in reality, if you can have such a thing as a minor tribulation!) - so it should be treated as a learning opportunity. Another engineer visit next week, hopefully.
I did wonder about that BQM for the DNS servers, Bob, but I assumed you'd been able to set it up somehow so that it did ping something meaningful. Good to know what the issues are and what's being done about them. So the servers can presumably cope with the level of query traffic quite happily - it's just a question of feeding it to them efficiently enough and down a big enough set of pipes.
