I'm using HP DL360p Gen8. I've installed dual-boot Windows Server 2008 R2 and RHEL7. In both systems I configured LACP and VLANs. So this is same server, same hardware, same network, same route tables etc.I worry about latency, including network latency, because I'm using this server for HFT trading.Now I was expecting that if I ping the same host from Windows and Linux, then Linux must be slighty better. Surprisingly it is not better at all. Actually it even ~5-10 microseconds worse, then Windows, when I ping same host.i'm using hrping in Windows and ping in Linuxin Windows i've used HP utility for teaming, in RHEL 7 i've used built-in teaming (not bonding)I was expecting Linux to be better, because:i suppose RHEL 7 network implementation is faster than Windows Server 2008 R2i suppose RHEL 7 teaming/LACP/VLANs implementation is faster then Windows Server 2008 R2/HP oneMy questions:if such number exist: how much microseconds faster ping from RHEL 7 than Windows Server 2008 R2?if it indicates potential problem that Linux ping is 5-10 microseconds slower or I should just ignore this fact?what can I do/diagnose/troubleshoot to make Linux ping faster than WindowsOf course in real life i more care about latency of real traffic, such as TCP/UDP, but i'm using ping as a first step. Probably ping show same numbers because it simple but on real TCP/UDP traffic Linux will be much faster?
In general should Linux ping be faster than Windows hrping?
networking
There are a number of factors. First is the machine you are running on. If windows and linux were on different hardware, the measurement is meaningless.Of course you have to measure the average ping after many tries, the first few pings may include other delays.The packets have to go through the kernel (ip stack and network device driver) out, and then in again when the response is received. At this stage, there could be many factors that influence the difference:what is actually timed: two different implementations of ping could do more or less boilerplate work between starting the timer and actually sending the thing (and the same on receiving path).existence o filters: firewalls and such, can introduce extra stepsclock granularity: how finely are processes multiplexed by the kernel? Even among diferent linux levels, the tick length can vary greatly, or the kernel could be more or less tickless (running without interruptions if there is only one process running).process management: how quickly and in what way is the process woken up when the packet comes back? Windows and Linux do this in completely different ways.What is the rest of the system doing? Is there heavy IO happening at the same time that would make the kernel busy? Is there a change if you nice the ping to a higher priority?Frequency scaling: management of CPU frequency can vary greatly: Linux has many governors that do things differently. So, it is possible that linux is running at lower clock speed when idle - also, a moment of frequency switch has extra latency.The implementation and compilation of ping utility could also have some minor effects (although the in-kernel latency is probably the main contribution).Linux kernel is known to hit the limit in network throughput at 10 gigabit level. So... it shouldn't make much of a difference at microsecond speeds. It's likely a matter of scheduling, OS latencies and so on. And the ping latency does not represent the actual performance under load. You shouldn't take this measurement as a factor when you decide anything. You need many other benchmarks, particularly under realistic loads.And finally, linux kernel settings can greatly influence the performance - real-time projects need a dedicated kernel to perform at an optimal level. You will find more variations between different configurations (on both platforms) than you found in these two tries.