Hacker News 의견
  • CPU0을 피하고 커널 명령줄에 idle=poll을 설정하면 더 나은 정밀도를 얻을 수 있음
    CPU0에는 다른 인터럽트들이 몰리기 때문에, 높은 타이밍 정밀도가 필요한 작업에는 적합하지 않음
    • 나도 같은 생각임. 우리 Debian 기반 OS 배포판에서도 주파수 스케일링 비활성화, 코어 고정 등 비슷한 최적화를 함
      CPU0에는 옮길 수 없는 시스템 작업이 많아서, 다른 코어를 격리된 섬(isolated core) 으로 쓰는 게 훨씬 나음
      우리 격리 코어의 스케줄러 지연(latency)은 최소 1µs, 평균 5µs, 최대 59µs 정도로 매우 안정적임
    • 좋은 팁임. 오늘 나중에 직접 시도해볼 생각임
  • WWVB 송신소에서는 온도 변화를 막기 위해 수백 개의 물병으로 장비를 단열함
    관련 기사: Spare Time – JILA
    • 그 페이지는 따로 공유할 가치가 있음. 원자시계 4개를 운영하면서 UPS가 자동차 배터리 두 개와 헤드라이트 두 개로 구성된다는 점이 정말 인상적임
      물병으로 만든 열 질량(thermal mass)도 흥미로움
    • 나도 비슷한 방법을 씀. 단열된 창고 안 책상 밑에 물을 저장해서 밤새 얼지 않게 함
      마치 침낭 속에 따뜻한 돌을 넣는 효과와 비슷함
  • 나는 Austin (austinsnerdythings.com) 임. 어젯밤에 글을 올리고 자고 일어났더니 HN 1위라 놀랐음
    LEA-M8T는 16Hz로 타임 펄스를 생성하고, chrony 설정에서 dpoll=-4로 설정했음. 16초 간격으로 256 샘플을 모아 안정성이 향상됨
    책상 옆에는 BH3SAP GPSDO도 있음. Claude가 펌웨어를 수정해 GPS PPS가 없어도 펄스를 계속 생성하는 flywheel 모드를 추가했음
    또 TSIP(Trimble 프로토콜) 출력을 지원하도록 업데이트했음. 관련 내용은 다음 글에서 다룰 예정임
    댓글들에 대한 답변도 곧 달 예정이며, 질문은 언제든 환영임
    • 좋은 글 고마움. 나도 비슷한 세팅을 하고 있어서 참고가 많이 됨
      16Hz 펄스가 실제로 얼마나 차이를 만드는지 궁금함. 그리고 데이터를 influxdb로 어떻게 넣는지도 알고 싶음. 나는 collectd를 쓰는데 정보가 부족함
    • 프로젝트 멋짐. 혹시 Raspberry Pi를 케이스에 넣었는지 궁금함
      금속 케이스라도 있으면 난방기나 에어컨의 주기적 온도 변화로부터 더 안정적인 결과를 얻을 수 있음
  • 저가형 Pi 오실레이터 크리스털을 TCXO로 교체하면 훨씬 안정적인 주파수를 얻을 수 있음
    관련 문서: Raspberry Pi StackExchange – oscillator 교체
    이 방법만으로도 드리프트가 4~5배 줄어듦. 다른 기법과 병행하면 더 좋음
    • 그 글 여러 번 읽었음. Pi4용 OCXO가 달린 오디오파일용 HAT도 팔고 있음
      하지만 납땜 실력이 부족해서 직접 교체하기는 자신이 없음
    • TCXO 가격이 의외로 저렴함. Abracon 제품 중 일부는 2달러 이하였음
  • 이건 SBC 규모의 OCXO임. 더 큰 히트싱크를 달거나 오실레이터 주변에 열 질량(thermal mass) 을 추가하면 도움이 될지 궁금함
    단순히 NTP 서버를 세팅하는 일에서도 배울 게 많음
    • Flirc 금속 케이스를 추천함. CPU가 케이스 본체에 밀착되어 큰 열 질량을 형성함
      팬 없이도 훌륭한 수동 냉각이 가능함
    • 나도 비슷하게 생각함. CPU와 오실레이터 위에 금속 블록을 얹어 열 관성을 높이면 좋을 듯함
      온도가 천천히 변하면 클록 드리프트도 느리게 변하므로 보정이 쉬움
      다만 작은 히트싱크는 오히려 주변 온도 변화에 민감해질 수 있음
    • Pi의 케이스에 단열재를 추가하는 것도 고려 중임
      방 온도 급변(창문 열기, 샤워 후 습기 등)을 완화하고, CPU가 불필요하게 열을 태우는 걸 줄일 수 있음
      결국 목표는 열을 일정하게 유지하는 것임
    • 하지만 너무 많은 열 방출은 오히려 역효과일 수 있음
      다른 코어들이 이미 최대 온도 근처에서 동작하며, 온도에 따라 클록 속도를 자동 조절함
      과도한 냉각은 이 자체 온도 제어 메커니즘을 방해할 수 있음
  • 크리스털에 저항과 폼 단열재를 붙여 직접 가열하는 방법도 있음
    GPIO로 제어 가능한 트랜지스터를 추가해 PID 제어로 온도를 유지할 수도 있음
    • 이건 거의 100년 전부터 쓰이던 방식임. 1950년대의 크리스털 오븐은 작은 금속 상자 안에서 약 75°C로 유지되었음
      온도 계수(temperature coefficient)가 0에 가깝도록 절단된 크리스털을 사용했기 때문에 안정적이었음
      최근 장비들도 여전히 이런 구조를 사용하며, 완전히 안정화되기까지 약 5분 정도 걸림
    • 나도 예전에 Pi를 포장용 폼 위에 올려놓는 실험을 했음
      주변 온도 변화는 줄었지만, 결국엔 온도 제어 챔버 안에 넣는 게 가장 확실한 해결책임
  • 굳이 CPU를 태워 온도를 유지하기보다는, 마이크로컨트롤러와 정밀 오실레이터를 쓰는 게 더 낫지 않을까 생각함
    예를 들어 STM32 보드에 이더넷을 연결해 NTP 서버로 쓰면 더 안정적일 듯함
    • 나도 그걸 가지고 있음. eBay에서 70달러에 산 BH3SAP GPSDO인데, 수정된 펌웨어로 flywheel 모드를 지원함
      Pi에 NTP 신호를 공급할 수 있고, STM32도 가능하지만 기본적으로 이더넷 기능은 없음
    • 일반적으로 NTP는 시간 민감 프로세스라서, SoC보다 MCU가 훨씬 안정적임
      RTLinux에는 외부 핀 상태에 맞춰 스케줄러를 동기화하는 기능도 있음
      하지만 프로세서가 많아지면 메타안정성(metastability) 문제가 생김
      Pi는 FPGA(Zynq)처럼 실시간 보장을 제공하지 않음
  • SoC의 온도를 일정하게 유지하기 위해 의도적으로 부하를 주는 발상은 생각 못 했음
    하지만 소비 전력이 낮으니, 복잡한 냉각 시스템 대신 약간의 전력 낭비로 해결하는 게 합리적임
  • 2022년에 관련된 논문이 있었음: USENIX NSDI22 – Najafi
    • 흥미로운 논문이었음. 온도 반응 곡선 모델링으로 CPU를 태우는 대신 더 우아하게 문제를 해결함
    • 하지만 그 논문은 서버 내 온도 센서의 다양성을 관찰한 정도임
      PPS 신호 두 개로 지터를 감지하는 방법은 오래된 기술이고, 온도 계수 학습(tempco learning) 도 수십 년 전부터 존재함
      실제로 그 학습된 tempco가 얼마나 정확한지에 대한 검증은 빠져 있음