Raspberry Pi ổn định nhất? Độ chính xác NTP cải thiện 81% nhờ quản lý nhiệt

 (austinsnerdythings.com)
1 điểm bởi GN⁺ 2025-11-27 | 1 bình luận | Chia sẻ qua WhatsApp
  • Giới thiệu kết quả thử nghiệm kết hợp cố định lõi CPU và ổn định nhiệt để giảm biến động tần số của máy chủ NTP dùng Raspberry Pi
  • Quan sát cho thấy thay đổi nhiệt độ CPU gây ra độ trôi tần số của bộ dao động tinh thể, và hệ thống được ổn định bằng cách giữ nhiệt độ ở mức cố định
  • Duy trì CPU ở 54°C bằng tiến trình ‘time burner’ dựa trên điều khiển PID, đạt giảm 81% biến động tần số và giảm 77% độ lệch chuẩn
  • Cố định CPU 0 dành riêng cho chronyd và dùng các lõi còn lại để duy trì tải nhiệt, cải thiện độ lệch NTP xuống mức trung bình 38ns
  • Cho thấy khả năng xây dựng máy chủ thời gian độ chính xác cao chi phí thấp cho các môi trường cần độ chính xác cực hạn như đồng bộ thời gian chính xác hoặc thiết bị khoa học

Vấn đề: bất ổn định thời gian do thay đổi nhiệt độ

  • Tính năng điều chỉnh tần số động (DVFS) của Raspberry Pi có lợi cho hiệu quả điện năng, nhưng bất lợi cho đồng bộ thời gian chính xác
    • Khi tần số xung nhịp thay đổi theo tải CPU, tốc độ tick của đồng hồ hệ thống cũng dao động
  • Tần số của bộ dao động tinh thể nhạy cảm với nhiệt độ, và thay đổi theo mức vài ppm do nhiệt từ CPU
    • Sự thay đổi nhiệt độ giữa ngày và đêm gây ra độ trôi tần số
  • Kết quả giám sát bằng Grafana cho thấy độ lệch tần số khoảng ±1ppm theo biến động nhiệt độ CPU
    • Giá trị RMS offset trung bình ở mức 86ns, vẫn còn dư địa để cải thiện

Phát hiện: hiệu quả của việc duy trì nhiệt độ ổn định

  • Xác nhận rằng việc giữ nhiệt độ CPU ổn định có thể cải thiện độ ổn định tần số
  • Giải pháp gồm hai phần
    1. Cô lập lõi CPU – chỉ gán chronyd và ngắt PPS cho CPU 0
    2. Ổn định nhiệt – giữ các lõi còn lại hoạt động liên tục để duy trì nhiệt độ cố định
  • Khi kích hoạt hệ thống ổn định nhiệt vào 09:10 ngày 17/11/2025, dao động tần số giảm ngay lập tức

Giải pháp 1: cố định lõi CPU và đặt ưu tiên thời gian thực

  • CPU 0: chỉ dành cho chronyd và ngắt PPS
  • CPU 1–3: xử lý tác vụ thông thường và duy trì tải nhiệt
  • Cấu hình script tối ưu hóa tự động chạy khi khởi động
    • Cố định chế độ điều chỉnh tần số CPU thành performance
    • Cố định PPS IRQ(200) vào CPU 0
    • Đặt chronyd ở ưu tiên thời gian thực (SCHED_FIFO 50)
    • Tăng ưu tiên cho tiến trình ksoftirqd/0
  • Script có thể được đăng ký trong /etc/rc.local hoặc dịch vụ systemd

Giải pháp 2: ổn định nhiệt bằng điều khiển PID

  • Sử dụng vòng điều khiển PID để giữ nhiệt độ CPU ổn định
    • Nhiệt độ mục tiêu: 54°C
    • 3 tiến trình worker trên CPU 1–3 tạo tải bằng phép băm MD5
    • Điều chỉnh thời gian tính toán và thời gian chờ theo giá trị đầu ra của PID
  • Tham số PID
    • Kp=0.05, Ki=0.02, Kd=0.0
    • Vì nhiệt độ thay đổi chậm nên thành phần vi phân (Kd) được đặt bằng 0
  • Kết quả là nhiệt độ CPU được giữ ổn định trong phạm vi ±0.2°C

Kết quả: cải thiện độ ổn định tần số

  • Biến động tần số giảm 81%, độ lệch chuẩn giảm 77%, RMS offset giảm 49%
  • RMS offset trung bình: 85.44ns → 43.54ns
  • RMS offset trung vị: 80.13ns → 37.93ns
  • Khi giữ CPU ở 54°C, đạt được độ ổn định tần số trong phạm vi ±0.14ppm
  • Vẫn duy trì ổn định dù nhiệt độ phòng dao động (18.9~22.2°C)

Quy trình thiết lập

  • Chuẩn bị trước: cần xây dựng máy chủ NTP dựa trên GPS PPS
  • Cài đặt các gói bắt buộc
    • linux-cpupower, python3, util-linux
  • Tạo script tối ưu khởi động /usr/local/bin/pps-optimize.sh và đăng ký với systemd
  • Tạo script điều khiển nhiệt /usr/local/bin/time_burner.py và đăng ký dịch vụ
    • ExecStart=/usr/bin/python3 /usr/local/bin/time_burner.py -t 54.0 -n 3
  • Lệnh kiểm tra
    • Xác nhận CPU governor là performance
    • Kiểm tra việc cố định CPU và mức ưu tiên của chronyd
    • Đo RMS offset bằng chronyc tracking (ví dụ: khoảng 35ns)

Giám sát và khắc phục sự cố

  • Giám sát thời gian thực: watch -n 1 "chronyc tracking"
  • Kiểm tra trạng thái dịch vụ: sudo systemctl status time-burner.service
  • Tinh chỉnh PID
    • Nếu nhiệt độ dao động, giảm Kp; nếu ổn định chậm, tăng Ki
    • Có thể điều chỉnh nhiệt độ mục tiêu trong khoảng 50~60°C
  • Mức sử dụng CPU cao (khoảng 90%) là hành vi được chủ đích

Đánh đổi

  • Tăng tiêu thụ điện: tiêu thụ liên tục 3–4W (khoảng 15–25kWh mỗi năm)
  • Tăng nhiệt: duy trì ở 54°C, vẫn trong ngưỡng an toàn
  • Chiếm dụng tài nguyên CPU: dùng 3 trong 4 lõi
    • Phù hợp với thiết bị chuyên dụng cho NTP, không phù hợp trong môi trường đa dịch vụ

Lĩnh vực có thể áp dụng

  • Đồng bộ thời gian chính xác, thiết bị khoa học, nghiên cứu hệ thống phân tán, kiểm thử mạng v.v.
  • Có thể là quá mức cho nhu cầu thông thường, nhưng hữu ích để xây dựng môi trường thử nghiệm chi phí thấp với độ chính xác cao

Hướng cải tiến trong tương lai

  • Tinh chỉnh PID thích ứng để ứng phó với thay đổi nhiệt độ theo mùa
  • Điều khiển làm mát bằng phần cứng (như quạt PWM) để cải thiện hiệu quả điện năng
  • Áp dụng OCXO (bộ dao động tinh thể điều khiển bằng lò nhiệt) có thể loại bỏ độ trôi do nhiệt

Kết luận

  • Kết hợp cố định lõi CPU và quản lý nhiệt bằng PID để hiện thực hóa máy chủ NTP siêu chính xác
  • Cải thiện 81% độ ổn định tần số, đạt RMS offset 38ns
  • Thử nghiệm chứng minh mối tương quan giữa quản lý nhiệt và lập lịch thời gian thực
  • Đây là dự án thiên về khám phá kỹ thuật và giá trị học tập hơn là tính thực dụng

Bài viết liên quan

1 bình luận

 
GN⁺ 2025-11-27
Ý kiến trên Hacker News
  • Có thể đạt độ chính xác tốt hơn nếu tránh CPU0 và đặt idle=poll trong dòng lệnh kernel
    Vì CPU0 thường gánh nhiều interrupt khác, nên không phù hợp cho các tác vụ cần độ chính xác thời gian cao
    • Tôi cũng nghĩ vậy. Trong bản phân phối OS dựa trên Debian của chúng tôi cũng có các tối ưu tương tự như tắt frequency scaling, ghim core, v.v.
      CPU0 có rất nhiều tác vụ hệ thống không thể chuyển đi, nên dùng core khác làm isolated core sẽ tốt hơn nhiều
      Độ trễ scheduler trên core cô lập của chúng tôi rất ổn định, tối thiểu khoảng 1µs, trung bình 5µs và tối đa 59µs
    • Mẹo hay đấy. Hôm nay tôi định sẽ tự thử sau
  • Ở trạm phát WWVB, người ta cách nhiệt thiết bị bằng hàng trăm chai nước để ngăn thay đổi nhiệt độ
    Bài liên quan: Spare Time – JILA
    • Riêng trang đó cũng đáng để chia sẻ. Điều thực sự ấn tượng là họ vận hành 4 đồng hồ nguyên tử, còn UPS thì được cấu thành từ hai ắc quy ô tô và hai đèn pha
      Khối nhiệt (thermal mass) tạo từ các chai nước cũng rất thú vị
    • Tôi cũng dùng cách tương tự. Tôi trữ nước dưới bàn trong kho cách nhiệt để nó không bị đóng băng qua đêm
      Nó giống như hiệu ứng bỏ viên đá ấm vào trong túi ngủ vậy
  • Tôi là Austin (austinsnerdythings.com). Tối qua tôi đăng bài rồi đi ngủ, sáng dậy thấy đứng đầu HN nên khá bất ngờ
    LEA-M8T của tôi tạo xung thời gian ở 16Hz, và tôi đặt dpoll=-4 trong cấu hình chrony. Việc thu 256 mẫu theo khoảng 16 giây đã cải thiện độ ổn định
    Bên cạnh bàn tôi còn có một BH3SAP GPSDO. Claude đã sửa firmware để thêm chế độ flywheel, cho phép tiếp tục tạo xung ngay cả khi không có GPS PPS
    Nó cũng đã được cập nhật để hỗ trợ đầu ra TSIP (giao thức của Trimble). Tôi sẽ nói thêm về chuyện đó trong bài tiếp theo
    Tôi cũng sẽ sớm trả lời các bình luận, và luôn hoan nghênh mọi câu hỏi
    • Cảm ơn vì bài viết hay. Tôi cũng có một thiết lập tương tự nên tham khảo được rất nhiều
      Tôi tò mò 16Hz thực sự tạo ra khác biệt đến mức nào. Và tôi cũng muốn biết bạn đưa dữ liệu vào influxdb như thế nào. Tôi đang dùng collectd nhưng không có nhiều thông tin
    • Dự án hay đấy. Tôi muốn hỏi liệu bạn có đặt Raspberry Pi vào trong vỏ máy không
      Nếu có dù chỉ là vỏ kim loại, bạn có thể nhận được kết quả ổn định hơn trước các biến động nhiệt độ theo chu kỳ từ máy sưởi hay điều hòa
  • Nếu thay crystal oscillator giá rẻ của Pi bằng TCXO, bạn có thể có được tần số ổn định hơn nhiều
    Tài liệu liên quan: Raspberry Pi StackExchange – thay oscillator
    Chỉ riêng cách này cũng giảm drift xuống 4 đến 5 lần. Nếu kết hợp với các kỹ thuật khác thì còn tốt hơn
    • Tôi đã đọc bài đó nhiều lần. Người ta còn bán HAT cho audiophile có gắn OCXO cho Pi4 nữa
      Nhưng tay nghề hàn của tôi không đủ tự tin để tự thay
    • Giá TCXO rẻ đáng ngạc nhiên. Một số mẫu của Abracon còn dưới 2 đô la
  • Đây đúng là OCXO ở quy mô SBC. Tôi tự hỏi liệu gắn thêm heatsink lớn hơn hoặc thêm khối nhiệt (thermal mass) quanh oscillator có giúp ích không
    Ngay cả việc chỉ thiết lập một máy chủ NTP thôi cũng có rất nhiều điều để học
    • Tôi khuyên dùng vỏ kim loại Flirc. CPU áp sát vào thân vỏ, tạo thành một khối nhiệt lớn
      Nó cho khả năng tản nhiệt thụ động rất tốt mà không cần quạt
    • Tôi cũng nghĩ tương tự. Có vẻ sẽ tốt nếu đặt một khối kim loại lên trên CPU và oscillator để tăng quán tính nhiệt
      Nếu nhiệt độ thay đổi chậm thì clock drift cũng thay đổi chậm hơn, nên dễ hiệu chỉnh hơn
      Tuy vậy, heatsink nhỏ có thể lại khiến nó nhạy hơn với thay đổi nhiệt độ môi trường
    • Tôi cũng đang cân nhắc thêm vật liệu cách nhiệt vào vỏ của Pi
      Như vậy có thể giảm các biến động nhiệt độ phòng đột ngột (mở cửa sổ, hơi ẩm sau khi tắm, v.v.) và hạn chế CPU tỏa nhiệt không cần thiết
      Rốt cuộc mục tiêu là giữ nhiệt càng ổn định càng tốt
    • Nhưng tản quá nhiều nhiệt có thể phản tác dụng
      Các core khác vốn đã chạy gần mức nhiệt tối đa và tự động điều chỉnh xung theo nhiệt độ
      Làm mát quá mức có thể cản trở cơ chế tự điều tiết nhiệt độ này
  • Cũng có thể dán điện trở và foam cách nhiệt vào crystal để gia nhiệt trực tiếp
    Thậm chí có thể thêm transistor điều khiển bằng GPIO để giữ nhiệt độ bằng điều khiển PID
    • Cách này đã được dùng từ gần 100 năm trước. Crystal oven của thập niên 1950 được giữ ở khoảng 75°C trong một hộp kim loại nhỏ
      Chúng ổn định vì dùng crystal được cắt sao cho temperature coefficient gần bằng 0
      Thiết bị hiện đại hơn gần đây vẫn dùng cấu trúc này, và thường mất khoảng 5 phút để ổn định hoàn toàn
    • Trước đây tôi cũng từng thử đặt Pi lên foam đóng gói
      Nó có giảm biến động nhiệt độ môi trường, nhưng rốt cuộc giải pháp chắc chắn nhất vẫn là đặt vào buồng điều khiển nhiệt độ
  • Thay vì cố giữ nhiệt bằng cách đốt CPU, tôi nghĩ có lẽ dùng vi điều khiển và oscillator chính xác sẽ tốt hơn
    Ví dụ dùng bo STM32 gắn Ethernet làm máy chủ NTP có lẽ sẽ ổn định hơn
    • Tôi cũng có cái đó. Đó là BH3SAP GPSDO tôi mua trên eBay với giá 70 đô, và firmware đã sửa hỗ trợ chế độ flywheel
      Nó có thể cấp tín hiệu NTP cho Pi, và STM32 cũng được, nhưng về cơ bản không có Ethernet tích hợp sẵn
    • Nhìn chung NTP là một tiến trình nhạy thời gian, nên MCU ổn định hơn SoC rất nhiều
      RTLinux cũng có tính năng đồng bộ scheduler theo trạng thái chân ngoài
      Nhưng khi số lượng processor tăng lên thì sẽ xuất hiện vấn đề metastability
      Pi không cung cấp bảo đảm thời gian thực như FPGA (Zynq)
  • Tôi chưa từng nghĩ đến ý tưởng cố tình tạo tải để giữ nhiệt độ SoC ổn định
    Nhưng vì mức tiêu thụ điện thấp, giải quyết bằng cách lãng phí một ít điện thay vì dùng hệ thống làm mát phức tạp có vẻ hợp lý
  • Năm 2022 có một bài báo liên quan: USENIX NSDI22 – Najafi
    • Bài báo khá thú vị. Nó giải quyết vấn đề một cách thanh nhã hơn bằng mô hình hóa đường cong phản ứng nhiệt độ thay vì đốt CPU
    • Nhưng bài đó chủ yếu chỉ quan sát sự đa dạng của cảm biến nhiệt độ trong máy chủ
      Cách phát hiện jitter bằng hai tín hiệu PPS là kỹ thuật đã có từ lâu, và tempco learning cũng đã tồn tại từ nhiều thập kỷ trước
      Điều còn thiếu là kiểm chứng xem tempco đã học được đó thực sự chính xác đến mức nào