Short Answer = about 12-15ms
Longer Answer - I think that what you’re seeing would probably be about the same here. It seems to me that the 3000/300 have higher latency than the 1000/2000 did… but I’m not really sure of how much different, after so many hardware and firmware changes. CLEARLY the ePTP mode on the 1000/2000 series was way way better than the 3000/300 series is, so there’s clearly a difference in how the N vs AC chipset’s work. However, on PtMP AP’s facing customers, we don’t really have any latency complaints from customers though… So - it’s not something we’re seeing too much of an issue with.
But - here’s an example of a 3000L which is at the far end of our network with 18 clients, many of which aren’t really ideal signals. This is a few tower hops away through our network, and this is the AP pinging to Google. If I ping from the 3000L AP to google, I get an average of 44.7ms. If I ping from a connected SM to google, I get an average of 56.8ms. So, looking at it like that, the SM to AP difference is ~12ms. This is kinda my ‘real world test’ and it seems that generally, a client is about 12ms more latency than the ethernet of the AP they are connected to.
This is from the AP to Google:
PING google.com (172.217.1.174) 32(60) bytes of data.
— google.com ping statistics —
10 packets transmitted, 10 received, 0% packet loss, time 9013ms
rtt min/avg/max/mdev = 39.538/ 44.761 /55.114/4.172 ms
This is from a SM on that AP to Google:
PING google.com (172.217.164.238) 32(60) bytes of data.
— google.com ping statistics —
10 packets transmitted, 10 received, 0% packet loss, time 9010ms
rtt min/avg/max/mdev = 43.276/ 56.820 /63.974/7.191 ms
Strangely, if I ping from that SM directly to that AP, it can look more concerning. The jitter and latency seems worse for some reason. However, when I do this test above to figure out more what this client really feels for real latency to an internet site (I think this is a more “real world” test) the latency for him is OK(ish).
Again, before anyone picks on ^^this^^ - this would be our least ideal AP. It is multiple hops, and the 18 clients connected are spread far and wide, and it’s an Omni, and 1/2 of them are from -63 to -72 (which are below our normal install criteria) so only 1/2 of them are ‘good’ or ‘vgood’ range, while 1/2 of them are ‘poor’ or ‘wtf’ signals.
By comparison, this is from my SM on my roof at home to Google.
PING google.com (172.217.165.14) 32(60) bytes of data.
40 bytes from yyz12s06-in-f14.1e100.net (172.217.165.14): icmp_seq=1 ttl=116 time=36.7 ms
40 bytes from yyz12s06-in-f14.1e100.net (172.217.165.14): icmp_seq=2 ttl=116 time=39.6 ms
40 bytes from yyz12s06-in-f14.1e100.net (172.217.165.14): icmp_seq=3 ttl=116 time=40.5 ms
40 bytes from yyz12s06-in-f14.1e100.net (172.217.165.14): icmp_seq=4 ttl=116 time=37.1 ms
40 bytes from yyz12s06-in-f14.1e100.net (172.217.165.14): icmp_seq=5 ttl=116 time=40.0 ms
40 bytes from yyz12s06-in-f14.1e100.net (172.217.165.14): icmp_seq=6 ttl=116 time=38.1 ms
40 bytes from yyz12s06-in-f14.1e100.net (172.217.165.14): icmp_seq=7 ttl=116 time=36.9 ms
40 bytes from yyz12s06-in-f14.1e100.net (172.217.165.14): icmp_seq=8 ttl=116 time=36.8 ms
40 bytes from yyz12s06-in-f14.1e100.net (172.217.165.14): icmp_seq=9 ttl=116 time=36.4 ms
40 bytes from yyz12s06-in-f14.1e100.net (172.217.165.14): icmp_seq=10 ttl=116 time=38.6 ms
— google.com ping statistics —
10 packets transmitted, 10 received, 0% packet loss, time 9012ms
rtt min/avg/max/mdev = 36.487/ 38.124 /40.542/1.465 ms
So, that’s more typical on our network, But our house is closer to town, with only two tower hops from our fiber. And that is also an ePMP2000 AP with Force200 SM at our house.
But, the short answer is that if I compare what any of our APs pings to google or to any other site - and then compare what a client SM connected pings to the same site, the difference seems to be about 12-15ms extra for the client.