ZyXEL NBG6617: ping to router and wan higher than on stock firmware

I installed the latest snapshot on my NBG6617 and the ping from LAN to the router and from LAN to WAN got worse:

stock:

lan -> router
--- 192.168.1.1 ping statistics ---
20 packets transmitted, 20 received, 0% packet loss, time 19274ms
rtt min/avg/max/mdev = 0.325/0.521/0.966/0.200 ms

lan -> wan
--- 192.168.0.1 ping statistics ---
20 packets transmitted, 20 received, 0% packet loss, time 19021ms
rtt min/avg/max/mdev = 1.457/1.793/2.847/0.346 ms


openwrt:

lan -> router
--- 192.168.1.1 ping statistics ---
20 packets transmitted, 20 received, 0% packet loss, time 19119ms
rtt min/avg/max/mdev = 0.213/0.994/1.555/0.410 ms
lan -> wan
--- 192.168.0.1 ping statistics ---
20 packets transmitted, 20 received, 0% packet loss, time 19022ms
rtt min/avg/max/mdev = 1.874/2.560/3.616/0.346 ms

I did not change any settings except setting a password for ssh, everything else was untouched.

Any similar experiences with this device or other similar devices (FRITZ!Box 4040 for example which seems to have the same hardware)? My old TP-Link 1043NDv1 does not have such a problem with openwrt (similar values to the zyxel with stock firmware).

I don't see any bad rtt? What rtt did you expect?

I don't know if 2.5ms can be considered bad for going through the router (WAN ist just another router connected via ethernet), it's just that it got worse when flashing openwrt and also worse than my old 1043ND with openwrt (+0.4 to the router and +0.8 to WAN compared to stock).

yea not great, but not not to worry either.

you should evaluate latency under load (ping while down-/uploading or bufferbloat stats on dslreports).

the latency increase might originate from power save stuff (cpu frequency scaling, energy effecient ethernet, ... )

Have you tried to ping the wan router from the zyxel? Do you use sqm or something else?

tried it while running a speedtest on speedtest.net, seems to be the case that it is some kind of power saving or similar:

PING 192.168.0.1 (192.168.0.1) 56(84) bytes of data.
64 bytes from 192.168.0.1: icmp_seq=1 ttl=63 time=3.45 ms
64 bytes from 192.168.0.1: icmp_seq=2 ttl=63 time=2.57 ms
64 bytes from 192.168.0.1: icmp_seq=3 ttl=63 time=2.47 ms
64 bytes from 192.168.0.1: icmp_seq=4 ttl=63 time=2.48 ms
64 bytes from 192.168.0.1: icmp_seq=5 ttl=63 time=4.41 ms
64 bytes from 192.168.0.1: icmp_seq=6 ttl=63 time=2.89 ms
64 bytes from 192.168.0.1: icmp_seq=7 ttl=63 time=2.87 ms
64 bytes from 192.168.0.1: icmp_seq=8 ttl=63 time=2.72 ms
64 bytes from 192.168.0.1: icmp_seq=9 ttl=63 time=2.75 ms
64 bytes from 192.168.0.1: icmp_seq=10 ttl=63 time=2.65 ms
64 bytes from 192.168.0.1: icmp_seq=11 ttl=63 time=3.02 ms
64 bytes from 192.168.0.1: icmp_seq=12 ttl=63 time=2.80 ms
64 bytes from 192.168.0.1: icmp_seq=13 ttl=63 time=2.37 ms
64 bytes from 192.168.0.1: icmp_seq=14 ttl=63 time=3.32 ms
64 bytes from 192.168.0.1: icmp_seq=15 ttl=63 time=1.40 ms <- start of test around here
64 bytes from 192.168.0.1: icmp_seq=16 ttl=63 time=1.30 ms
64 bytes from 192.168.0.1: icmp_seq=17 ttl=63 time=1.28 ms
64 bytes from 192.168.0.1: icmp_seq=18 ttl=63 time=1.51 ms
64 bytes from 192.168.0.1: icmp_seq=19 ttl=63 time=1.66 ms
64 bytes from 192.168.0.1: icmp_seq=20 ttl=63 time=1.41 ms
64 bytes from 192.168.0.1: icmp_seq=21 ttl=63 time=1.41 ms
64 bytes from 192.168.0.1: icmp_seq=22 ttl=63 time=1.38 ms
64 bytes from 192.168.0.1: icmp_seq=23 ttl=63 time=1.54 ms
64 bytes from 192.168.0.1: icmp_seq=24 ttl=63 time=1.23 ms
64 bytes from 192.168.0.1: icmp_seq=25 ttl=63 time=1.35 ms
64 bytes from 192.168.0.1: icmp_seq=26 ttl=63 time=1.57 ms
^C
--- 192.168.0.1 ping statistics ---
26 packets transmitted, 26 received, 0% packet loss, time 25036ms
rtt min/avg/max/mdev = 1.231/2.227/4.417/0.837 ms

that is a ping from zyxel to the wan router, no sqm or anything else, no configuration or additional packages, just the downloaded snapshot

--- 192.168.0.1 ping statistics ---
20 packets transmitted, 20 packets received, 0% packet loss
round-trip min/avg/max = 2.114/2.963/4.328 ms

I see the same effect as mentioned above (adding load via speedtest.net)

64 bytes from 192.168.0.1: seq=2 ttl=64 time=3.004 ms
64 bytes from 192.168.0.1: seq=3 ttl=64 time=2.850 ms
64 bytes from 192.168.0.1: seq=4 ttl=64 time=3.077 ms
64 bytes from 192.168.0.1: seq=5 ttl=64 time=2.884 ms
64 bytes from 192.168.0.1: seq=6 ttl=64 time=2.957 ms
64 bytes from 192.168.0.1: seq=7 ttl=64 time=3.176 ms
64 bytes from 192.168.0.1: seq=8 ttl=64 time=3.550 ms
64 bytes from 192.168.0.1: seq=9 ttl=64 time=2.881 ms
64 bytes from 192.168.0.1: seq=10 ttl=64 time=3.237 ms
64 bytes from 192.168.0.1: seq=11 ttl=64 time=2.914 ms
64 bytes from 192.168.0.1: seq=12 ttl=64 time=3.068 ms
64 bytes from 192.168.0.1: seq=13 ttl=64 time=2.897 ms
64 bytes from 192.168.0.1: seq=14 ttl=64 time=2.882 ms
64 bytes from 192.168.0.1: seq=15 ttl=64 time=2.982 ms
64 bytes from 192.168.0.1: seq=16 ttl=64 time=1.602 ms <- start of speedtest
64 bytes from 192.168.0.1: seq=17 ttl=64 time=1.481 ms
64 bytes from 192.168.0.1: seq=18 ttl=64 time=1.444 ms
64 bytes from 192.168.0.1: seq=19 ttl=64 time=1.539 ms
64 bytes from 192.168.0.1: seq=20 ttl=64 time=1.465 ms
64 bytes from 192.168.0.1: seq=21 ttl=64 time=1.313 ms
64 bytes from 192.168.0.1: seq=22 ttl=64 time=1.756 ms
64 bytes from 192.168.0.1: seq=23 ttl=64 time=1.448 ms
64 bytes from 192.168.0.1: seq=24 ttl=64 time=1.594 ms

definately looks like some kind of power saving then, would be interesting if this could be temporarily turned off via command line to test it.

setting cpu governor to performance seems to help

echo performance > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor

leads to

--- 192.168.0.1 ping statistics ---
20 packets transmitted, 20 received, 0% packet loss, time 19028ms
rtt min/avg/max/mdev = 1.259/1.437/1.745/0.135 ms

thanks for the idea with power saving, that seems to be the cause :slight_smile:

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.