I think there is effectively a rate limit on the pings (maybe just 1 a second) - so it is possible if there is significant jitter and the ping times vary slightly either side of 1s that a significant number of them will drop even though there is only 1 ping monitor running (because the previous ping will have arrived just within the 1s).

It's a pretty dumb decision on AVM's part to have such a low limit on this, they could have allowed 10s of pings per second and there would have been no ill effect from them.

In order to be safe on a Fritzbox you'd probably need to ping it no more often than every 1.5s or so.

The best course of action would be to split the issues; test the connection via wired ethernet and see how that behaves (ping out, and up/down throughput). If that is good, try same tests over wifi close to the router and further away.

In reply to a post by jimbof:

I think there is effectively a rate limit on the pings (maybe just 1 a second) - so it is possible if there is significant jitter and the ping times vary slightly either side of 1s that a significant number of them will drop even though there is only 1 ping monitor running (because the previous ping will have arrived just within the 1s).

It's a pretty dumb decision on AVM's part to have such a low limit on this, they could have allowed 10s of pings per second and there would have been no ill effect from them.

In order to be safe on a Fritzbox you'd probably need to ping it no more often than every 1.5s or so.

The best course of action would be to split the issues; test the connection via wired ethernet and see how that behaves (ping out, and up/down throughput). If that is good, try same tests over wifi close to the router and further away.

Thanks jimbof - will try what you suggested next time I’m at the property - Saturday I’m hoping

Just noticed a thread on this sub forum, describing a very similar issue:

https://forums.thinkbroadband.com/zen/t/4678618-re-h...

In reply to a post by prlzx:

Standard User prlzx
(experienced)
Wed 17-Mar-21 15:08:05

Re: Horrendous packet loss
[re: ukwiz] [link to this post]

As a blanket statement "broken" is pretty meaningless.
AVM have made a design choice around how to treat unsolicited WAN ICMP, and that happens not to envisage the TBB ping interval.

As noted this has no bearing on LAN and Internet connectivity of devices on the LAN, and a trivially longer ping interval is not impacted either.

The only other design limitation I have to deal with is the domain suffix being .fritz.box and not configurable.
I reported it to AVM as a way of finding out if a non-GUI way to change it, and they have no immediate plans to offer a configurable setting.
I have something else running internal DNS anyway for other reasons including remote office links.

On the other hand there are far worse routers still out there in terms of IPv6, firewall, NAT configuration or interaction with VPN connections so you take your pick.
This router was included with the subs but I could just as easily put back my previous router if this were really that "broken".

TBB have made their own design choice around the 1 ping per second and not user-configurable. I asked them about that, as I thought they could collect enough mass data at 1 ping per 6 seconds or 3 seconds
(which is still 100 per 5 mins aggregated as min/max/avg/loss to nearest 1%) but they have their reasons and it's their freely offered service, so that's ok too.

I work in ICT and you simply note the characteristics, choose your poison, deploy any targeted workarounds and move on.

In reply to a post by prlzx:

As I recall previous postings here suggest Fritzbox routers categorise the pattern of the pings as some kind of attack so drop lots of them, and that it still happens even when devices behind the router see the Internet connection as being not otherwise impacted.

I haven't checked recently but I expect at some lower rate of pings (if using a different monitoring system) it would not trigger that behaviour.

Obviously, hoping this is my issue and therefore of no real consequence - and merely an academic conundrum.

Edited by kam67 (Thu 15-Dec-22 15:50:48)

If you were actually seeing the level of loss your graph suggests your connection would be excruciatingly slow and you could forget about video calls. Voice would probably be unusable too.

Agree. Though really you'd think Zen should have a troubleshooting flow chart entry that caters for BQM users with Fritzboxes and can explain how they aren't giving accurate results, and then being an AVM partner they could try and influence the software development.

In reply to a post by XGS_Is_On:

If you were actually seeing the level of loss your graph suggests your connection would be excruciatingly slow and you could forget about video calls. Voice would probably be unusable too.

Thanks for adding your voice to those who (I think probably quite rightly) are arguing that it’s relatively benign, XGS_Is_On.

I will know for certain by Saturday evening: As long my connection is where it was at on Tuesday, then I can safely put in a drawer and classify it as an inconsequential incidental finding.

In reply to a post by jpm:

Agree. Though really you'd think Zen should have a troubleshooting flow chart entry that caters for BQM users with Fritzboxes and can explain how they aren't giving accurate results, and then being an AVM partner they could try and influence the software development.

Yes it is odd that they haven’t picked up on it - or if they have, have decided to ignore it.

I don't know much about these kind of issues but it might be interesting to run a MTR traceroute to bbc.co.uk from a Linux OS terminal and that might indicate where any packet loss is occurring?

Sorry if this post is irrelevant or impractical.

If you download the config backup from a Fritz box, it actually looks like the rate limit is a configurable item in there. However if you modify, re-checksum the backup, and re-upload it, it just gets overwritten with the default values again.

In reply to a post by jpm:

Agree. Though really you'd think Zen should have a troubleshooting flow chart entry that caters for BQM users with Fritzboxes and can explain how they aren't giving accurate results, and then being an AVM partner they could try and influence the software development.

Presumably they're monitoring the line now via LCP which would avoid the limitation.

At least I hope that's what they're doing.