I get 60ms RTT for the largest bin of packets with WebUDP many requests goes as high as 140ms (positive skew of the distribution), while ICMP never goes above 29ms RTT. I know UDP can be badly prioritized in some networks but I don't think it can only be that...
This needs more investigations imho, I wonder where this fails so badly; is WebRTC aiming at ~100ms latency?
Definitely a bit weird. Where are you located? The echo demo server is hosted in the Netherlands. That's how the round trip histogram looks for me in Estonia: https://i.imgur.com/iBoqwe4.png I'll take a look later if there's any noticeable delays caused by the server.
Chrome use ~100% cpu transceiving ~83 packets per second, and I think it sends packets at a slower rate later on, that's why we get so many 30ms responses when we wait some hours.
This is a tcpdump after loading the page:
\time sudo tcpdump -c 1000 -ni eth0 udp and port 9777
1000 packets captured
1000 packets received by filter
0 packets dropped by kernel
0.02user 0.05system 0:12.45elapsed 0%CPU (0avgtext+0avgdata 5472maxresident)k
0inputs+8outputs (0major+1508minor)pagefaults 0swaps
This is just a flood ping, interesting that the UDP version shoots more packets.
This needs more investigations imho, I wonder where this fails so badly; is WebRTC aiming at ~100ms latency?