Any clues regarding BQM

Hi,

I have recently got a slow down with this BQM.

Restarted router, changed cabling. Restarted ONT. No improvement. With Zen 900/100.


Clues, advice please.

In reply to a post by Rhynchelma:

I have recently got a slow down with this BQM.
Restarted router, changed cabling. Restarted ONT. No improvement. With Zen 900/100.

My gut instinct is you should check your router's configuration to make sure it's not rate limiting the pings. I've checked the route to you specifically and I don't see anything until the last hop although there isn't a response from the few hops before so I can't bet sure. The sawtooth pattern makes me think your router might be rate limiting it potentially and then removing, then adding, etc..

That is very bad packet-loss. I would probably suggest you measure ping times on the command line and see what the pattern looks like. You're likely to see 10-30% packet-loss based on that graph (except when it goes low again like at 1am and at the end of the graph just before midnight).. do this for the following:

212.23.8.1 - this is one of Zen's name servers
80.249.99.164 - this is the box that does the pinging
8.8.8.8 - this is google's name server
212.58.249.144 - this is a BBC server

On Mac/Linux: ping -i .2 212.23.8.1
On Windows drop the -I but you will only see one ping per second which won't show you the issue as well so run for a few minutes

If you measure it outbound then it's not going to be your router responding but the server on the other end. If you see heavy packet loss then it's probably a router or Zen issue.. if you don't, then your router might just be filtering ICMP traffic heavily. When I ping your IP I get this:

64 bytes from x.x.x.x: icmp_seq=13 ttl=58 time=9.89 ms
64 bytes from x.x.x.x: icmp_seq=18 ttl=58 time=9.86 ms
64 bytes from x.x.x.x: icmp_seq=23 ttl=58 time=9.39 ms
64 bytes from x.x.x.x: icmp_seq=27 ttl=58 time=9.60 ms
64 bytes from x.x.x.x: icmp_seq=32 ttl=58 time=9.30 ms

As you can see from the sequence numbers, it's losing a lot of packets in between.. that's on a one second interval. Windows ping won't show you the sequence numbers but you will see a packet dropped I think.

If this was a link congestion situation, you'd see latency spikes but latency is perfectly ok.. i.e. either a packet is responded to or it's not.. if it is then the performance is fine.. this makes me think the router is doing something - you may have a denial of service protection mode enabled or such. Can you let us know here as it would be a good example to add to our FAQ if so


seb

Thank you very much for your reply. It was most comprehensive.

Currently I am on Zen Backhaul. Awaiting a move to A&A.

For a month or so I have been getting terrible downloads speeds, sometimes in the 3-15 Mbps, but with 100 ish upload.

Zen have moved me onto BTW backhaul which resolved the issue, but promptly moved me back to their backhaul.

The router is a Fritzbox 7530 with the latest firmware. I have tried another of the same model with the "previous" firmware. No better.

I will certainly try what you have suggested, but, as a non techie, I am going to hope that A&A will be better. Certainly they have a reputation for getting Openreach etc to fix their stuff.

Again, I am more than grateful for you reply.

Thanks

I'm not a Fritzbox user nor a Zen customer but I recall other people mentioning that the Fritzbox can't cope with two ping monitors being run and I think Zen ring their own, so your BQM monitor counts as the second and as such may explain the packet loss.

I do stand to be corrected on this though, so if anybody suggests I have got this wrong I would go with what they say!

In reply to a post by Rhynchelma:

Currently I am on Zen Backhaul. Awaiting a move to A&A.
For a month or so I have been getting terrible downloads speeds, sometimes in the 3-15 Mbps, but with 100 ish upload.
Zen have moved me onto BTW backhaul which resolved the issue, but promptly moved me back to their backhaul.
The router is a Fritzbox 7530 with the latest firmware. I have tried another of the same model with the "previous" firmware. No better.
I will certainly try what you have suggested, but, as a non techie, I am going to hope that A&A will be better. Certainly they have a reputation for getting Openreach etc to fix their stuff.

If you're getting unexplainably low speeds which vary a lot then it does suggest an issue. Pings to the router are useful in this context. If the backhaul changes are genuine that gives some idea to the cause although I do wonder if that's exactly what happened as it doesn't make sense they'd switch and then switch you back. Ping graphs that support evidence of other issues I think do corroborate things when you go to an ISP with issues.

A&A run the Firebricks as their broadband termination devices do they will run LCP Echo which is a lower level protocol than ICMP Pings we run so you will certainly get monitoring from them. Do keep us posted on what you find.

seb

Hello Seb,

Thanks for the time touhave put in to this.

I was moved to A&A and only had a little time to do your tests. ping -1 did not work on my Mac. They changed the terminal version a while ago. So, I did simple pings.

PING 212.23.8.1 (212.23.8.1): 56 data bytes
64 bytes from 212.23.8.1: icmp_seq=0 ttl=57 time=10.913 ms
64 bytes from 212.23.8.1: icmp_seq=1 ttl=57 time=10.346 ms
64 bytes from 212.23.8.1: icmp_seq=2 ttl=57 time=11.268 ms
64 bytes from 212.23.8.1: icmp_seq=3 ttl=57 time=9.597 ms
64 bytes from 212.23.8.1: icmp_seq=4 ttl=57 time=10.675 ms
64 bytes from 212.23.8.1: icmp_seq=5 ttl=57 time=10.309 ms
64 bytes from 212.23.8.1: icmp_seq=6 ttl=57 time=10.500 ms
64 bytes from 212.23.8.1: icmp_seq=7 ttl=57 time=10.643 ms
64 bytes from 212.23.8.1: icmp_seq=8 ttl=57 time=10.456 ms
64 bytes from 212.23.8.1: icmp_seq=9 ttl=57 time=9.602 ms
64 bytes from 212.23.8.1: icmp_seq=10 ttl=57 time=10.367 ms
64 bytes from 212.23.8.1: icmp_seq=11 ttl=57 time=10.394 ms
64 bytes from 212.23.8.1: icmp_seq=12 ttl=57 time=10.302 ms
64 bytes from 212.23.8.1: icmp_seq=13 ttl=57 time=10.212 ms
14 packets transmitted, 14 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 9.597/10.399/11.268/0.423 ms

PING 80.249.99.164 (80.249.99.164): 56 data bytes
64 bytes from 80.249.99.164: icmp_seq=0 ttl=55 time=10.391 ms
64 bytes from 80.249.99.164: icmp_seq=1 ttl=55 time=9.734 ms
64 bytes from 80.249.99.164: icmp_seq=2 ttl=55 time=10.070 ms
64 bytes from 80.249.99.164: icmp_seq=3 ttl=55 time=9.861 ms
64 bytes from 80.249.99.164: icmp_seq=4 ttl=55 time=10.057 ms
64 bytes from 80.249.99.164: icmp_seq=5 ttl=55 time=9.976 ms
64 bytes from 80.249.99.164: icmp_seq=6 ttl=55 time=10.171 ms
64 bytes from 80.249.99.164: icmp_seq=7 ttl=55 time=10.012 ms
64 bytes from 80.249.99.164: icmp_seq=8 ttl=55 time=9.825 ms
64 bytes from 80.249.99.164: icmp_seq=9 ttl=55 time=9.992 ms
64 bytes from 80.249.99.164: icmp_seq=10 ttl=55 time=9.680 ms
64 bytes from 80.249.99.164: icmp_seq=11 ttl=55 time=9.843 ms
^C
--- 80.249.99.164 ping statistics ---
12 packets transmitted, 12 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 9.680/9.968/10.391/0.188 ms

PING 8.8.8.8 (8.8.8.8): 56 data bytes
64 bytes from 8.8.8.8: icmp_seq=0 ttl=116 time=9.932 ms
64 bytes from 8.8.8.8: icmp_seq=1 ttl=116 time=9.435 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=116 time=9.472 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=116 time=9.575 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=116 time=9.768 ms
64 bytes from 8.8.8.8: icmp_seq=5 ttl=116 time=9.598 ms
64 bytes from 8.8.8.8: icmp_seq=6 ttl=116 time=9.608 ms
64 bytes from 8.8.8.8: icmp_seq=7 ttl=116 time=9.772 ms
64 bytes from 8.8.8.8: icmp_seq=8 ttl=116 time=9.595 ms
64 bytes from 8.8.8.8: icmp_seq=9 ttl=116 time=9.622 ms
64 bytes from 8.8.8.8: icmp_seq=10 ttl=116 time=9.341 ms
64 bytes from 8.8.8.8: icmp_seq=11 ttl=116 time=9.635 ms
64 bytes from 8.8.8.8: icmp_seq=12 ttl=116 time=9.515 ms
64 bytes from 8.8.8.8: icmp_seq=13 ttl=116 time=9.755 ms
64 bytes from 8.8.8.8: icmp_seq=14 ttl=116 time=9.540 ms
^C
--- 8.8.8.8 ping statistics ---
15 packets transmitted, 15 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 9.341/9.611/9.932/0.145 ms
paul@EllenK ~ %

PING 212.58.249.144 (212.58.249.144): 56 data bytes
64 bytes from 212.58.249.144: icmp_seq=0 ttl=53 time=10.761 ms
64 bytes from 212.58.249.144: icmp_seq=1 ttl=53 time=10.011 ms
64 bytes from 212.58.249.144: icmp_seq=2 ttl=53 time=10.080 ms
64 bytes from 212.58.249.144: icmp_seq=3 ttl=53 time=9.952 ms
64 bytes from 212.58.249.144: icmp_seq=4 ttl=53 time=10.043 ms
64 bytes from 212.58.249.144: icmp_seq=5 ttl=53 time=9.779 ms
64 bytes from 212.58.249.144: icmp_seq=6 ttl=53 time=10.172 ms
64 bytes from 212.58.249.144: icmp_seq=7 ttl=53 time=9.944 ms
64 bytes from 212.58.249.144: icmp_seq=8 ttl=53 time=9.932 ms
64 bytes from 212.58.249.144: icmp_seq=9 ttl=53 time=10.142 ms
64 bytes from 212.58.249.144: icmp_seq=10 ttl=53 time=10.253 ms
64 bytes from 212.58.249.144: icmp_seq=11 ttl=53 time=10.133 ms
64 bytes from 212.58.249.144: icmp_seq=12 ttl=53 time=9.913 ms
64 bytes from 212.58.249.144: icmp_seq=13 ttl=53 time=10.161 ms
^C
--- 212.58.249.144 ping statistics ---
14 packets transmitted, 14 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 9.779/10.091/10.761/0.223 ms

"… doesn't make sense they'd switch and then switch you back;"

Three times. I honestly have no idea why they moved me to their backhaul, price probably. They moved me back because I grumbled.

Not Zen's finest hour.

Still, with A&A now, fingers crossed.

I have not deleted my BQM if you want to snip part for illustrative purposes.

Thanks again.

In reply to a post by Rhynchelma:

I was moved to A&A and only had a little time to do your tests. ping -1 did not work on my Mac. They changed the terminal version a while ago. So, I did simple pings.

It's the letter 'i' for 'internal' then '.2' or '0.2' for two tenths of a second (or whatever I said before.. Works on latest MacOS

Based on your results I don't see any issues, but sometimes these kinds of things will take a lot longer than 10 packets to see.

Good luck with A&A.. You should get a straight answer from them on this as their staff are pretty clued up (you might with Zen but as a larger company it depends a bit more who you speak to)

seb

Can I delete the BQM that I was referring to? Not sure if you wanted a sample.

No problems with A&A. Night and day.

Thank you again.

In reply to a post by Rhynchelma:

Can I delete the BQM that I was referring to? Not sure if you wanted a sample.

No problems with A&A. Night and day.

Thank you again.

You can delete any of your monitors