2017-08-21 53 views
9

System.nanoTime() 'ın neden bazı işletim sistemlerinde diğerlerinden daha yavaş olduğunu açıklayan mesajları okudum ve okudum, ancak şu anda gördüğüm farkı açıklamak için hiçbir şey görmedim. JMH kullanarak, bu benchmark çalışıyorum. (Not: System.nanoTime (kullanır) yanı), Windows 10 günüCentos 7, System.nanoTime için 400x daha yavaş Windows için

@Benchmark 
public long systemNanoTime() { 
    return System.nanoTime(); 
} 

, bu sürer ~ 25 ns.

Centos 7'de, Linux 3.10 ~ 10293 ns alarak ölçülür.

Bu aynı makinede ise Intel (R) Core (TM) i7-7820X işlemci @ 3.60GHz

JDK sistem saatini alır şeklini değiştirmek için bir seçenek var mı?


DÜZENLEME: Todd tarafından sağlanan bağlantıyı dayanarak, bu tsc görünür

echo acpi_pm > /sys/devices/system/clocksource/clocksource0/current_clocksource 

geliştirilmiş gecikme gerçekleştirdikten sonra

# more /sys/devices/system/clocksource/clocksource0/* 
:::::::::::::: 
/sys/devices/system/clocksource/clocksource0/available_clocksource 
:::::::::::::: 
hpet acpi_pm 
:::::::::::::: 
/sys/devices/system/clocksource/clocksource0/current_clocksource 
:::::::::::::: 
hpet 

mevcut değil, ama bir hala zayıftır 1.816 ns gecikme.

TSC saat kaynağının Centos'a eklenip eklenemeyeceğini, ancak henüz şansın olmadığını öğrenmek için çalıştım.


DÜZENLEME: son sürümü ile centos için alternatif depo ekleyerek bu sayfayı takip @ apangin önerisine dayanarak

# 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 
+0

Bu blog yayına baktınız mı? Gördüğünüz şeyleri anlatıyor ve iyi araştırılmış gibi görünüyor. http://pzemtsov.github.io/2017/07/23/the-slow-currenttimemillis.html – Todd

+2

Bir ürün yazılımı hatası gibi görünüyor. Yeni çekirdeklerde (4.10 gibi) tsc senkronizasyon yamalarını gördüm. – apangin

cevap

6

biraz daha Kazı

http://elrepo.org/tiki/tiki-index.php

ve daha sonra buradaki diğer talimatları izleyin:

https://www.tecmint.com/install-upgrade-kernel-version-in-centos-7/ yükleme ve çekirdek düşündüren

# $ dmesg | grep -i tsc 
[ 0.001000] tsc: Detected 3600.000 MHz processor 
[ 0.001000] [Firmware Bug]: TSC ADJUST: CPU0: -2100392876408 force to 0 
[ 0.046075] TSC deadline timer enabled 
[ 0.001000] [Firmware Bug]: TSC ADJUST differs: Reference CPU0: -2100392876408 CPU1: 0 
[ 0.001000] [Firmware Bug]: TSC ADJUST differs: Reference CPU0: -2100392876408 CPU2: 0 
[ 0.001000] [Firmware Bug]: TSC ADJUST differs: Reference CPU0: -2100392876408 CPU3: 0 
[ 0.001000] [Firmware Bug]: TSC ADJUST differs: Reference CPU0: -2100392876408 CPU4: 0 
[ 0.001000] [Firmware Bug]: TSC ADJUST differs: Reference CPU0: -2100392876408 CPU5: 0 
[ 0.001000] [Firmware Bug]: TSC ADJUST differs: Reference CPU0: -2100392876408 CPU6: 0 
[ 0.001000] [Firmware Bug]: TSC ADJUST differs: Reference CPU0: -2100392876408 CPU7: 0 
[ 0.001000] [Firmware Bug]: TSC ADJUST differs: Reference CPU0: -2100392876408 CPU8: 0 
[ 0.001000] [Firmware Bug]: TSC ADJUST differs: Reference CPU0: -2100392876408 CPU9: 0 
[ 0.001000] [Firmware Bug]: TSC ADJUST differs: Reference CPU0: -2100392876408 CPU10: 0 
[ 0.001000] [Firmware Bug]: TSC ADJUST differs: Reference CPU0: -2100392876408 CPU11: 0 
[ 0.001000] [Firmware Bug]: TSC ADJUST differs: Reference CPU0: -2100392876408 CPU12: 0 
[ 0.001000] [Firmware Bug]: TSC ADJUST differs: Reference CPU0: -2100392876408 CPU13: 0 
[ 0.001000] [Firmware Bug]: TSC ADJUST differs: Reference CPU0: -2100392876408 CPU14: 0 
[ 0.001000] [Firmware Bug]: TSC ADJUST differs: Reference CPU0: -2100392876408 CPU15: 0 
[ 1.337843] clocksource: tsc: mask: 0xffffffffffffffff max_cycles: 0x6c1bafbc2ab, max_idle_ns: 881591058496 ns 
[ 2.353636] clocksource: Switched to clocksource tsc 

yeniden başlatıldıktan sonra bir firmware hata için etme aşamasındadır.

Testi tekrar çalıştırıyorum, 260 kat geliştirme olan System.nanoTime() kullanarak ortalama 40 ns gecikme elde ediyorum. Aynı zamanda bu ölçütü kullanan kriterler daha anlamlı olduğu anlamına gelir.