I have seen and read posts on why System.nanoTime() is slower on some OSes than others, however I have never seen anything to explain the difference I am seeing now. Using JMH, I am running this benchmark. (Note: it uses System.nanoTime() as well)
@Benchmark
public long systemNanoTime() {
return System.nanoTime();
}
On Windows 10, this takes ~25 ns.
On Centos 7, Linux 3.10 it is measured as taking ~10293 ns.
This is on the same machine, Intel(R) Core(TM) i7-7820X CPU @ 3.60GHz
Is there an option to change the way the JDK gets the system clock?
EDIT: Based on the link provided by Todd, it appear that tsc is not available
# more /sys/devices/system/clocksource/clocksource0/*
::::::::::::::
/sys/devices/system/clocksource/clocksource0/available_clocksource
::::::::::::::
hpet acpi_pm
::::::::::::::
/sys/devices/system/clocksource/clocksource0/current_clocksource
::::::::::::::
hpet
after performing
echo acpi_pm > /sys/devices/system/clocksource/clocksource0/current_clocksource
The latency improved, but is still poor with a latency of 1,816 ns.
I have tried to find out if the TSC clock source can be added to Centos, but not luck yet.
EDIT: Digging a little further
# dmesg | grep -i tsc
[ 0.000000] tsc: Detected 3600.000 MHz processor
[ 0.058602] TSC deadline timer enabled
[ 0.065868] TSC synchronization [CPU#0 -> CPU#1]:
[ 0.065870] Measured 679995254538 cycles TSC warp between CPUs, turning off TSC clock.
[ 0.065874] tsc: Marking TSC unstable due to check_tsc_sync_source failed
[ 125.451480] Override clocksource tsc is not HRT compatible. Cannot switch while in HRT/NOHZ mode