온라인 상태에서 NTP와 시계를 동기화하고 오프라인 상태에서 RTC와 시계를 동기화 하시겠습니까?

온라인 상태에서 Linux 시스템을 NTP와 동기화하고 오프라인 상태에서 예측 가능한 RTC와 동기화하는 기존 메커니즘이 있습니까?

센서 데이터를 수집하고 타임 스탬프하는 임베디드 Linux 시스템 인 원격 "수집기"를 운영합니다. 우리는 5 초 미만으로 합리적으로 작게 유지하기 위해 시계 오류가 필요합니다. 일반적으로 NTP를 사용하여 시계를 동기화하며 시스템이 온라인 상태 인 한 정상적으로 작동합니다.

문제는 일부 수집기에는 매우 나쁜 업 링크가있어 몇 시간, 며칠 또는 몇 주 동안 다운 될 수 있다는 것입니다. 로컬 데이터 수집을 멈추지는 않지만 NTP가 없으면 Linux 시스템 시계가 심하게 예측할 수 없습니다.

하드웨어의 RTC도 많은 속도를 유지하지만 일정한 속도로 유지됩니다. RTC 드리프트 속도는 보드마다 다르지만 보드마다 일정하며 측정 할 수 있습니다.

우리에게 필요한 것은 다음을 수행하는 메커니즘이라고 생각합니다.

• 배포 전에 보드의 RTC 드리프트 속도 측정
• 가능하면 NTP를 통해 지속적으로 / 정기적으로 시스템 시간 조정
• NTP를 사용할 수없는 경우 RTC에서 정기적으로 시스템 시간을 조정하십시오. 알려진 RTC 드리프트 속도를 고려하십시오.
• 선택 사항 : 온라인 상태에서 진행중인 RTC 드리프트 속도 측정 및 기록 (1)

'메커니즘'이란 두 가지 상태 "온라인"과 "오프라인"을 모두 처리 할 수있는 잘 관리되고 문서화 된 소프트웨어 및 / 또는 구성 요소를 의미하며, 시스템 클록이 올바른 시간 소스 (ntp vs. rtc), 상태 변화 감지 및 RTC 드리프트 수정. 특별한 ntpd 구성 / 플러그인, 별도의 데몬, 크론 작업 또는 기타로 구현되는지 여부는 중요하지 않습니다.

나는 Chrony 를 보았지만 , 문서 에 따르면 시스템 클럭 의 드리프트를 예측하려고 시도 하는데, 우리의 경우 RTC보다 훨씬 더 예측할 수 없다. Chrony는 재부팅 동안 시간을 ​​유지하기 위해서만 RTC를 사용하는 것 같습니다.

(1) 참고 ntpd는 커널의 '11 분 모드 '를 활성화합니다 (11 분마다 시스템 시계에서 rtc 업데이트). 현재 커널과 ntpd에는 11 분 모드를 방지 할 방법이없는 것 같습니다. 따라서 ntpd가 실행되는 동안 rtc 드리프트 정보가 손실됩니다 (thx @billthor).

업데이트 / 편집 :

• USB 또는 직렬을 통해 MSF 또는 DCF77 신호 (유럽 기반)에 외부 라디오 시계를 추가하는 것을 고려하고 있습니다. 그러나 우리는 오히려 하드웨어를 간결하게 유지합니다.
• 우리의 수집가는 종종 지하에 실내에 위치하고 있습니다. 따라서 GPS 시계를 추가해도 도움이되지 않습니다.
• 데비안 7을 사용합니다. util-linux-2.20.1의 hwclock, ntpdate-4.2.6p5, ntpd의 ntp-4.2.6.p5, chrony-1.24 (잠재적으로 1.30)를 의미합니다.
• 주 우리의 문제는 우리가 사용하는 방법을 알고하지 않는 것이 아님을 ntpdate(8), hwclock(8), date(1), 등의 추가 섹션을 참조하십시오 이탤릭체 내가 '메커니즘'으로 무엇을 의미하는지에 대한합니다.
• '11 분 모드 '에 대한 각주 추가
• 다음 은 오프라인 동기화 및 RTC 드리프트에 대한 매우 흥미로운 토론입니다.

당신의 상황은 드문 일이며, 누군가가 ntpd당신이 원하는 것을하기 위해 표준 기반 구성을 생각해 내면 놀랄 것 입니다. 즉, 나는 놀란 것을 좋아하며,이 부분들에서 자주 발생합니다.

그러나 누군가가 더 나은 아이디어를 얻을 때까지 crontab이와 같은 항목 을 고려 했습니까?

*/5 * * * *   ntpdate 0.pool.ntp.org || ( hwclock --adjust; hwclock --hctosys )

IE는 5 분마다를 통해 시계를 동기화하려고 시도 ntpdate하고 실패하는 경우 /etc/adjtime파일 에 따라 드리프트에 대한 하드웨어 시계를 조정 하십시오 (이 형식은 자세한 내용 man hwclock과 지식을 사용하여 첫 번째 줄을 적절하게 채 웠습니다) 그런 다음 특정 RTC 속도로 설정 한 다음 RTC에서 시스템 시계를 설정하십시오.

이와 같은 솔루션을 찾고 많은 수의 시스템을 배포하는 경우 풀과 함께 작동하고 사용량에 비례하여 서버를 다시 제공하는 것이 예의로 간주됩니다. 자세한 정보는 http://www.pool.ntp.org/en/vendors.html 에서 찾을 수 있습니다 .

NTP는 이미 온라인 또는 오프라인인지 알 수있는 메커니즘을 가지고 있으며 필요에 따라 우선 순위가 낮은 소스로 전환합니다. 대체 소스를 트리거하기 위해 도달 값을 확인하는 것은 매우 쉽지만 NTP를 사용합니다. 아래에서 논의 된 바와 같이, RTC 드리프트에 대한 모니터링 및 수정은 어려울 수있다.

인터넷 이전에는 데이터 소스에 전화를 걸어 시계를 동기화하는 프로그램을 사용했습니다. 모뎀을 통해 시간 소스를 제공하는 서비스가 여전히있을 수 있습니다. 전화선에 액세스해야합니다.

로컬 시계에는 RTC에 적용되지 않는 알려진 문제가 있습니다. 일부 문제는 NTP 알려진 OS 문제 목록에 설명되어 있습니다. 이들은 시계 드리프트를 설명 할 수 있습니다. 문제를 해결하면 문제가 해결 될 수 있습니다. 누락 된 틱이 없으면 로컬 (시스템) 시간 소스가 매우 안정적 일 수 있습니다.

/ dev / dumbclockX 장치에 적절한 RTC 시간을 쓰는 프로그램과 함께 Dumb 시계 드라이버 (33)를 사용할 수 있습니다.

라디오 시계를 기반으로하는 여러 가지 다른 드라이버가 있습니다. 이 중 일부는 WWV 및 CHU와 같은 단파 서비스를 사용하며 GPS 신호를 사용할 수없는 환경에서 작동 할 수 있습니다. 유럽의 경우이 목록에는 BBC, TDF, RBU 및 RMW가 포함됩니다.

Pavel Krejci도 RTC 드라이버를 작성했지만 공식 드라이버에는 포함되어 있지 않습니다. PPS 유형 동기화에서 작동 할 수 있습니다.

배포 전에 RTC 드리프트를 측정 할 수 있어야합니다. 그러나 RTC가 자동으로 업데이트되지 않도록해야합니다. 시스템 클럭이 adjtimex 기능으로 업데이트되면 RTC는 11 분마다 업데이트 될 수 있습니다.

NTP가 연결되면 시계를 업데이트합니다. 일반적으로 NTP는 시스템 시계를 크게 조정하지 않습니다. 시계를 얼마나 멀리 조정할 수 있는지 조정하는 옵션이 있습니다.

위의 RTC 사용 옵션을 제안했습니다. 라디오 시계는 GPS 시계보다 더 적합 할 수 있습니다.

신뢰할 수있는 시간 소스가없는 상태에서 드리프트를 측정하여이를 비교하는 것은 쓸데없는 노력 일 것입니다. 현지 시간이 불안정하면이 시간을 사용하여 RTC를 모니터링 할 수 없으며 그 반대도 마찬가지입니다. 커널이 11 분마다 RTC를 업데이트하는 경우 NTP가 연결되어있는 동안 드리프트를 측정 할 수 없습니다. 내가 사용한 RTC는 1 초의 분해능을 가지므로 신뢰성있게 측정 할 수 있도록 크게 표류해야합니다.