Raspberry Pi Paling Stabil? Akurasi NTP Meningkat 81% Berkat Manajemen Termal

 (austinsnerdythings.com)
1 poin oleh GN⁺ 2025-11-27 | 1 komentar | Bagikan ke WhatsApp
  • Memperkenalkan hasil eksperimen yang menggabungkan penguncian core CPU dan stabilisasi termal untuk mengurangi fluktuasi frekuensi pada server NTP berbasis Raspberry Pi
  • Diamati bahwa perubahan suhu CPU memicu drift frekuensi pada osilator kristal, lalu distabilkan dengan menjaga suhu tetap konstan
  • Dengan proses ‘time burner’ berbasis kontrol PID, CPU dipertahankan pada 54°C, menghasilkan penurunan fluktuasi frekuensi sebesar 81% dan penurunan simpangan baku sebesar 77%
  • Dengan mengunci CPU 0 khusus untuk chronyd dan menjaga beban termal pada core lainnya, offset NTP membaik hingga rata-rata sekitar 38ns
  • Menunjukkan kemungkinan implementasi server timing presisi tinggi berbiaya rendah untuk lingkungan yang membutuhkan akurasi ekstrem seperti sinkronisasi waktu presisi atau peralatan ilmiah

Masalah: ketidakstabilan timing akibat perubahan suhu

  • Fitur dynamic voltage and frequency scaling (DVFS) pada Raspberry Pi menguntungkan untuk efisiensi daya, tetapi merugikan untuk sinkronisasi waktu presisi
    • Jika frekuensi clock berubah sesuai beban CPU, laju tick system clock juga ikut berfluktuasi
  • Frekuensi osilator kristal sensitif terhadap suhu, dan dapat berubah beberapa ppm sesuai panas yang dihasilkan CPU
    • Perubahan suhu siang dan malam menimbulkan drift frekuensi
  • Hasil pemantauan Grafana menunjukkan offset frekuensi sekitar ±1ppm sesuai perubahan suhu CPU
    • Rata-rata RMS offset berada di kisaran 86ns, sehingga masih ada ruang untuk perbaikan

Temuan: efek menjaga suhu tetap konstan

  • Dipastikan bahwa dengan menjaga suhu CPU tetap konstan, stabilitas frekuensi dapat ditingkatkan
  • Solusinya terdiri dari dua bagian
    1. Isolasi core CPU – mengalokasikan chronyd dan interupsi PPS hanya ke CPU 0
    2. Stabilisasi termal – menjaga core lainnya tetap aktif terus-menerus agar suhu tetap konstan
    Iklan
  • Saat sistem stabilisasi termal diaktifkan pada 17 November 2025 pukul 09:10, osilasi frekuensi langsung menurun

Solusi 1: penguncian core CPU dan pengaturan prioritas real-time

  • CPU 0: khusus untuk chronyd dan interupsi PPS
  • CPU 1–3: untuk tugas umum dan mempertahankan beban termal
  • Menyusun skrip optimasi yang berjalan otomatis saat boot
    • Mode pengaturan frekuensi CPU dikunci ke performance
    • PPS IRQ(200) dikunci ke CPU 0
    • chronyd diatur ke prioritas real-time (SCHED_FIFO 50)
    • Prioritas proses ksoftirqd/0 ditingkatkan
  • Skrip dapat didaftarkan melalui /etc/rc.local atau layanan systemd

Solusi 2: stabilisasi termal berbasis kontrol PID

  • Untuk menjaga suhu CPU tetap konstan, digunakan loop kontrol PID
    • Suhu target: 54°C
    • 3 proses worker pada CPU 1–3 menghasilkan beban melalui komputasi hash MD5
    • Waktu komputasi dan waktu tunggu disesuaikan berdasarkan nilai output PID
  • Parameter PID
    • Kp=0.05, Ki=0.02, Kd=0.0
    • Karena perubahan suhu lambat, suku diferensial (Kd) diatur ke 0
  • Hasilnya, suhu CPU tetap stabil dalam rentang ±0.2°C
Iklan

Hasil: stabilitas frekuensi meningkat

  • Variabilitas frekuensi turun 81%, simpangan baku turun 77%, dan RMS offset turun 49%
  • Rata-rata RMS offset: 85.44ns → 43.54ns
  • Median RMS offset: 80.13ns → 37.93ns
  • Dalam kondisi suhu CPU dijaga pada 54°C, tercapai stabilitas frekuensi pada rentang ±0.14ppm
  • Stabilitas tetap terjaga meski suhu ruangan berubah (18.9~22.2°C)

Prosedur konfigurasi

  • Persiapan awal: perlu membangun server NTP berbasis GPS PPS
  • Instal paket yang diperlukan
    • linux-cpupower, python3, util-linux
  • Menulis skrip optimasi saat boot /usr/local/bin/pps-optimize.sh dan mendaftarkannya ke systemd
  • Menulis skrip kontrol termal /usr/local/bin/time_burner.py dan mendaftarkan layanannya
    • ExecStart=/usr/bin/python3 /usr/local/bin/time_burner.py -t 54.0 -n 3
  • Perintah verifikasi
    • Pastikan governor CPU adalah performance
    • Periksa penguncian CPU dan prioritas chronyd
    • Ukur RMS offset dengan chronyc tracking (misalnya sekitar 35ns)

Pemantauan dan pemecahan masalah

  • Pemantauan real-time: watch -n 1 "chronyc tracking"
  • Periksa status layanan: sudo systemctl status time-burner.service
  • Tuning PID
    • Jika suhu berosilasi, kurangi Kp; jika stabilisasi lambat, tingkatkan Ki
    • Suhu target bisa disesuaikan dalam rentang 50~60°C
    Iklan
  • Penggunaan CPU yang tinggi (sekitar 90%) adalah perilaku yang memang disengaja

Trade-off

  • Konsumsi daya meningkat: konsumsi berkelanjutan 3–4W (sekitar 15–25kWh per tahun)
  • Panas meningkat: dipertahankan di 54°C, masih dalam batas aman
  • Sumber daya CPU terpakai: 3 dari 4 core digunakan
    • Cocok untuk perangkat khusus NTP, tidak cocok untuk lingkungan multi-layanan

Bidang penerapan

  • Sinkronisasi waktu presisi, peralatan ilmiah, riset sistem terdistribusi, pengujian jaringan, dan sebagainya
  • Berlebihan untuk penggunaan umum, tetapi berguna untuk membangun lingkungan eksperimen presisi tinggi berbiaya rendah

Arah pengembangan selanjutnya

  • Menangani perubahan suhu musiman dengan tuning PID adaptif
  • Meningkatkan efisiensi daya melalui kontrol pendinginan berbasis hardware (seperti kipas PWM)
  • Jika menerapkan OCXO (oven-controlled crystal oscillator), drift termal dapat dihilangkan

Kesimpulan

  • Implementasi server NTP ultra-presisi melalui kombinasi penguncian core CPU dan manajemen termal berbasis PID
  • Stabilitas frekuensi meningkat 81%, RMS offset mencapai 38ns
  • Eksperimen ini membuktikan korelasi antara manajemen termal dan penjadwalan real-time
  • Ini adalah proyek yang lebih berfokus pada eksplorasi teknis dan nilai pembelajaran daripada kepraktisan

Bacaan terkait

1 komentar

 
GN⁺ 2025-11-27
Komentar Hacker News
  • Dengan menghindari CPU0 dan mengatur idle=poll di baris perintah kernel, akurasi yang lebih baik bisa didapat
    Karena interrupt lain menumpuk di CPU0, inti ini tidak cocok untuk pekerjaan yang membutuhkan presisi timing tinggi
    • Saya juga berpikir begitu. Di distribusi OS berbasis Debian kami, kami juga melakukan optimasi serupa seperti menonaktifkan frequency scaling dan melakukan pinning core
      Ada banyak tugas sistem di CPU0 yang tidak bisa dipindahkan, jadi jauh lebih baik menggunakan core lain sebagai pulau terisolasi (isolated core)
      Latensi scheduler pada core terisolasi kami sangat stabil, dengan minimum 1µs, rata-rata 5µs, dan maksimum sekitar 59µs
    • Tips yang bagus. Saya berencana mencobanya sendiri nanti hari ini
  • Di pemancar WWVB, peralatan diisolasi dengan ratusan botol air untuk mencegah perubahan suhu
    Artikel terkait: Spare Time – JILA
    • Halaman itu layak dibagikan tersendiri. Sangat mengesankan bahwa mereka menjalankan 4 jam atom, sementara UPS-nya terdiri dari dua aki mobil dan dua lampu depan
      Thermal mass dari botol air juga menarik
    • Saya juga memakai metode serupa. Saya menyimpan air di bawah meja di gudang berinsulasi agar tidak membeku semalaman
      Efeknya mirip menaruh batu hangat di dalam kantong tidur
  • Saya adalah Austin (austinsnerdythings.com). Saya memposting tulisan itu tadi malam, lalu bangun tidur dan kaget melihatnya jadi nomor 1 di HN
    LEA-M8T saya menghasilkan time pulse pada 16Hz, dan di konfigurasi chrony saya atur dpoll=-4. Dengan interval 16 detik, 256 sampel dikumpulkan sehingga stabilitas meningkat
    Di samping meja saya juga ada BH3SAP GPSDO. Claude memodifikasi firmware-nya dan menambahkan mode flywheel agar tetap menghasilkan pulse bahkan tanpa GPS PPS
    Saya juga memperbaruinya agar mendukung keluaran TSIP (protokol Trimble). Saya akan membahasnya di tulisan berikutnya
    Saya juga akan segera membalas komentar-komentarnya, dan pertanyaan selalu diterima
    • Terima kasih untuk tulisannya. Saya juga punya setup yang mirip, jadi ini sangat membantu sebagai referensi
      Saya penasaran seberapa besar perbedaan yang benar-benar dihasilkan oleh pulse 16Hz. Dan saya juga ingin tahu bagaimana Anda memasukkan data ke influxdb. Saya memakai collectd, tapi informasinya masih kurang
    • Proyek yang keren. Saya penasaran apakah Raspberry Pi dimasukkan ke dalam casing
      Bahkan casing logam pun bisa memberi hasil yang lebih stabil terhadap perubahan suhu periodik dari pemanas atau AC
  • Jika kristal osilator Pi murah diganti dengan TCXO, frekuensinya bisa jauh lebih stabil
    Dokumen terkait: Raspberry Pi StackExchange – mengganti oscillator
    Cara ini saja bisa mengurangi drift 4–5 kali lipat. Jika digabung dengan teknik lain hasilnya akan lebih baik
    • Saya sudah membaca tulisan itu berkali-kali. Ada juga HAT audiofil dengan OCXO untuk Pi4 yang dijual
      Tapi kemampuan menyolder saya kurang, jadi saya tidak percaya diri untuk menggantinya sendiri
    • Harga TCXO ternyata cukup murah. Beberapa produk Abracon harganya di bawah 2 dolar
  • Ini adalah OCXO seukuran SBC. Saya penasaran apakah menambahkan heatsink yang lebih besar atau thermal mass di sekitar osilator akan membantu
    Bahkan dari sekadar menyiapkan server NTP pun banyak hal yang bisa dipelajari
    • Saya merekomendasikan casing logam Flirc. CPU menempel rapat ke badan casing sehingga membentuk thermal mass yang besar
      Pendinginan pasif yang sangat baik bisa didapat tanpa kipas
    • Saya juga berpikir mirip. Menaruh blok logam di atas CPU dan osilator tampaknya bagus untuk meningkatkan inersia termal
      Jika suhu berubah perlahan, drift clock juga berubah lebih lambat sehingga lebih mudah dikoreksi
      Namun heatsink kecil justru bisa membuatnya lebih sensitif terhadap perubahan suhu sekitar
    • Saya juga mempertimbangkan untuk menambahkan insulasi ke casing Pi
      Ini bisa meredam perubahan suhu ruangan yang mendadak (membuka jendela, kelembapan setelah mandi, dll.) dan mengurangi CPU membuang panas secara tidak perlu
      Pada akhirnya, tujuannya adalah menjaga panas tetap konstan
    • Namun pelepasan panas yang terlalu besar justru bisa berdampak sebaliknya
      Core lain sudah bekerja dekat suhu maksimum, dan secara otomatis menyesuaikan kecepatan clock sesuai suhu
      Pendinginan berlebihan dapat mengganggu mekanisme kontrol suhu internal ini
  • Ada juga cara dengan menempelkan resistor dan insulasi foam ke kristal untuk memanaskannya secara langsung
    Dengan menambahkan transistor yang bisa dikendalikan lewat GPIO, suhu juga bisa dijaga memakai kontrol PID
    • Ini adalah metode yang sudah dipakai hampir 100 tahun. Oven kristal pada 1950-an dipertahankan pada sekitar 75°C di dalam kotak logam kecil
      Karena menggunakan kristal yang dipotong agar koefisien suhunya mendekati 0, hasilnya stabil
      Peralatan modern pun masih memakai struktur seperti ini, dan butuh sekitar 5 menit hingga benar-benar stabil
    • Saya dulu juga pernah melakukan eksperimen menaruh Pi di atas foam kemasan
      Perubahan suhu sekitar memang berkurang, tapi pada akhirnya solusi yang paling pasti adalah memasukkannya ke dalam ruang kendali suhu
  • Daripada sengaja membebani CPU untuk menjaga suhu, saya pikir bukankah lebih baik memakai mikrokontroler dan osilator presisi
    Misalnya, board STM32 yang dihubungkan ke Ethernet tampaknya akan lebih stabil jika dipakai sebagai server NTP
    • Saya juga punya itu. Itu BH3SAP GPSDO yang saya beli di eBay seharga 70 dolar, dan dengan firmware yang dimodifikasi mendukung mode flywheel
      Itu bisa memasok sinyal NTP ke Pi, dan STM32 juga memungkinkan, tetapi pada dasarnya tidak punya fungsi Ethernet bawaan
    • Secara umum, NTP adalah proses yang sensitif terhadap waktu, jadi MCU jauh lebih stabil daripada SoC
      Di RTLinux juga ada fitur untuk menyinkronkan scheduler dengan status pin eksternal
      Namun jika prosesor bertambah banyak, masalah metastability akan muncul
      Pi tidak memberikan jaminan real-time seperti FPGA (Zynq)
  • Saya tidak pernah terpikir soal gagasan memberi beban secara sengaja untuk menjaga suhu SoC tetap konstan
    Tapi karena konsumsi dayanya rendah, menyelesaikannya dengan sedikit pemborosan daya tampaknya masuk akal dibanding membangun sistem pendinginan yang rumit
  • Pada 2022 ada makalah terkait: USENIX NSDI22 – Najafi
    • Makalah yang menarik. Pendekatan pemodelan kurva respons suhu menyelesaikan masalah ini dengan cara yang lebih elegan daripada membakar CPU
    • Tapi makalah itu hanya sebatas mengamati keragaman sensor suhu di dalam server
      Metode mendeteksi jitter dengan dua sinyal PPS adalah teknik lama, dan tempco learning juga sudah ada sejak puluhan tahun lalu
      Tidak ada verifikasi tentang seberapa akurat tempco yang dipelajari itu dalam praktiknya