I use NDI|HX. That's what breaks down over 802.11ac or faster Wi-Fi. Hardwired networking is the only viable approach, even with a completely 100% dedicated Wi-Fi network in a building with no other Wi-Fi networks far away from anything. And wired networks are flawless with the same hardware on both ends.
Pings are a bad way to analyze a network, because they have the lowest priority of any traffic. QoS on the router or switch will drop them on the floor far more often than real traffic.
Either way, NDI|HX latency is about an eighth of a second (even over wired Ethernet, and IIRC slightly higher over Wi-Fi). Any compressor technology would have to be bespoke to operate with low enough latency to be useful for autonomous driving.
for reliable automotive-grade networking, the future (imho) is with AVC (which is the old name; audio video bridging) and the new name is TSN (time sensitive networking).
to play in the TSN game, you need a whole bunch of new networking goodies. ptp for timing (iee1588), high-end gps and special NIC hardware that squirts the NIC-based RTC timestamp into the outgoing packets just in bit-time as it exits. its really cool stuff and its getting there, for cars; but the hardware is still a bit expensive, the switches all have to be tsn-aware, the software and config is kind of new to most vendors and so on. but once it is understood and implemented by the vendors, then we'll have level-5 capable infra that we can really count on.
you can get experimental TSN stacks for host-based linux, and some autosar companies also are starting to offer it.
wireless (wifi) is useless. give it up, guys. wifi is so far behind in all that car networking needs; the only time you use wireless is for end-user stuff or low reliability backwards compat use-cases. lte is for WAN use, and that has nothing in common with wired ethernet, since the reasons for them existing and their speed needs are quite different.
for high speed reliable networking, its not only *wired* but the new kind of wires (including broad-r-reach gig-e and redundant switch ports).
oh, and pings can be useful for testing; but you do have to run qos and assign them prio's so that they dont get dropped.
use udp based tools (netperf2 is still one of my favorites) and you can see the latency, jitter, frame-loss and thruput. its not a Spirent (I love those) but its also not a $100k bit of kit. regular raspi pi4 can fill a gig-e pipe with iperf reliabily.
take it from someone who does this stuff.
