클럭 드리프트를 측정하고 방지하려면 어떻게해야합니까?

15

여러 프로덕션 플랫폼에서 시간 시계가 주기적으로 앞뒤로 점프하는 것으로 보이는 증상이 관찰되었습니다. 점프는 일반적으로 약 1 초이며, 일반적으로 취소되고 (이후 매우 짧은 후 뒤로 점프) 하루에 약 50 번 발생합니다. 이 드리프트는 최대 애플리케이션 사용 시간과 일일 백업과 같은 디스크 I / O 작업이 많은 시간 동안 가장 두드러집니다. 이러한 드리프트는 소프트 실시간 민감 애플리케이션에 영향을 미칩니다.

시스템은 3.0.58-0.6.6 기본 커널을 사용하여 SLES 11SP2를 실행하는 Oracle Netra X4250 및 Netra X4270 서버입니다.

$ cat /sys/devices/system/clocksource/clocksource0/available_clocksource
tsc hpet acpi_pm

$ cat /sys/devices/system/clocksource/clocksource0/current_clocksource
tsc

NTP 를 비활성화 했지만 드리프트에는 영향을 미치지 않습니다. 시각 시계 드리프트 시간을 측정하는 도구가 있습니까? 우리는 이것을 어떻게 피할 수 있습니까?

이들은 생산 플랫폼이므로 실험실에서 문제를 재현 할 수 없으므로 실험 능력이 제한됩니다. 내 장치에 남겨두면 드리프트를 측정하는 도구를 작성하고 HPET 클럭 소스를 실험 해 볼 수 있습니다.

linux sles clock

— 브렛
소스

5

NTP를 비활성화하면 시계가 훨씬 불안정 해 집니다 .NTP 가 시계를 줄을 유지하지 않는 유일한 이유는 시계가 고장 나고 NTP가이를 업데이트하지 않기 때문입니다 ( ntpdate(8)또는 참조 ntpd(8)).

— vonbrand

1

NTPD는 클럭 드리프트를 추적하고 수정하지만 드리프트는 아닙니다. 드리프트는 시간이 지남에 따라 거의 같은 양으로 같은 방향으로 일관되게 유지됩니다. 무작위로 앞뒤로 점프하면 예측할 수 없으며 수용 할 수 없습니다.

— Patrick

1

@ 패트릭이 말한 것은 옳습니다. 문제는 하루에 여러 번 앞뒤로 불 연속적으로 점프하는 것입니다. NTP는 드리프트에서 잘 작동하지만 이것으로 많은 도움이되지 않습니다. 시스템 날짜가 1 초 해상도의 외부 시간 원본으로 재설정되었을 수 있습니다. 서버가 x86 * 인 경우 하드웨어 RTC가 소스 일 수 있으며 일부 크론 작업이 범인 일 수 있습니다. 클럭 오프셋을 측정하는 한 Bratchley의 ntpdate 응답은 좋은 계층 1 클럭 참조가 사용되는 경우 합리적인 접근 방식입니다. 1 분에 한 번 실행하고 그림의 결과를 gnuplot하십시오.

— duanev

1

새로운 서버 ( drdobbs.com/embedded-systems/… ) 에서 시작하는 NTP 평가에 대해 살펴 보았습니다 . 새로운 결정을 배우려면 NTP 시간이 걸립니다. 정말 나쁜 결정의 경우, NTP는 훈련하는 동안 시계를 여러 번 '단계적으로'단계적으로 조정해야합니다 (이 기사의 그림 4 및 5 참조). ntp.drift의 118ppm의 최종 값은 하루 10 초 또는 30 분마다 208ms입니다. 이것은 OP가보고있는 것이 아니지만 NTP는 처음에 눈에 띄게 점프 할 수 있습니다.

— duanev

8

시각 시계 드리프트 시간을 측정하는 도구가 있습니까?

내가 아는 유일한 도구는 NTP 도구로 충분합니다. 주어진 클럭 소스와 동기화하도록 ntpd를 실제로 구성 할 필요는 없습니다. -d옵션을 사용 ntpdate하여 계산 된 오프셋을 가져올 수 있습니다 .

예:

[davisja5@xxxadmvlm08 ~]$ ntpdate -d clock.redhat.com 2>/dev/null | egrep "^offset"
offset -0.004545
[davisja5@xxxadmvlm08 ~]$

-d NTP가 실제로 시스템 시계를 건드리지 않고 작동하는 디버그 옵션입니다.

이를 피할 수있는 방법에 대한 조언이 있습니까?

하드웨어 시계 때문일 수 있기 때문에 개발자 / 테스트 환경에서이 기능을 재현 할 수 없다고해도 놀라지 않습니다. 다른 사람과 하드웨어를 지원한다면 기계 수리를 받으려고합니다. 한 가지 가능성은이 생산 기계에 대한 개발 기계 중 하나를 교환하여 이전 PROD 시스템을 수정하고이를 현재 PROD에있는 기계를 대체하기 위해 개발 기계로 다시 도입하는 것입니다.

부족한 점은 하드웨어 클럭 소스를 전환하는 것만으로도 가능합니다. 스왑 작업을 수행 할 수 없거나 수행 할 수없는 경우 hpet 경로로 이동하는 것이 좋습니다 . 클럭 소스 변경이 시스템 서비스와 엉망인지 테스트 한 다음 프로덕션에 우박으로 배포 할 수 있습니다.

— 브래 클리
소스

"클럭 드리프트 측정"이란 NTP가 제공하는 기준 시간 소스에서의 드리프트를 의미하지 않았습니다. 나는 연속 시간 범위에서 하루 중 시간에 "점프"를 감지 할 수있는 도구를 의미했습니다. 예를 들어, 50ms마다 하루 중 시간 샘플링을 수행하고 마지막 샘플링과의 차이가 50ms에서 너무 멀리 떨어져 있는지보고하십시오. 이러한 도구는 어떤 이유로 든 시간 시계가 기본 하드웨어 시계에서 표류하는지 여부를 보여줍니다.

— brett

1

그러한 개입이있을 경우 해결하고자하는 것보다 더 많은 성능 저하가 발생하지 않습니까? 그럼에도 하드웨어 문제이므로 하드웨어를 수리하거나이 문제없이 클럭 소스를 사용해야합니다. tscCPU에 기반하므로 CPU 활동이 많을수록 하드웨어 시계에 문제가 발생할 수 있습니다. hpet이 충분히 빠르면 시도해 보거나 서비스를 받거나 교체 작업을 수행해야 할 수도 있습니다. 이것들은 내가 당신을 위해 볼 수있는 유일한 옵션입니다.

— Bratchley

3

한 가지 해결책은 HPET

참고 고성능 이벤트 타이머

부팅 파라미터로 설정하려면

clocksource=hpet

구형 하드웨어에서는 TSC종종 불안정하고 커널에 의해 비활성화되었습니다.

멀티 코어 / 하이퍼 스레드 CPU, 여러 CPU가있는 시스템 및 최대 절전 운영 체제가 등장하면서 TSC는 정확한 결과를 제공 할 수 없습니다.

Wikipedia : 타임 스탬프 카운터

클럭 지터 증상이 나타나는 프로덕션 시스템에서 클럭 소스를 hpet으로 전환했습니다. 이는 관찰 된 클럭 지터 증상에는 영향을 미치지 않았습니다.

— brett

HPET은 외부 하드웨어 타이머이며 지터 할 수 없습니다. 따라서이 솔루션은 잘못된 경로 인 것 같습니다. 구형 하드웨어에는 특히 가상화를 사용할 때 많은 타이밍 문제가있었습니다. 다른 소프트웨어로도 확인 했습니까?

1

나는 우리의 응용 프로그램에서 나타나는 대기 시간 증상과 클록 측정을 연관시키는 더 자세한 도구를 작성했습니다. 이 도구는 이전에 Linux 시간 시계에서 지터로 의심되는 것을 배제하는 것으로 보입니다.

짧은 이야기로, 초기 가설은 유효하지 않습니다. 그러나 답변과 링크에서 Linux 시계에 대해 많은 것을 배웠으므로 모든 응답자에게 감사드립니다!

— 브렛
소스

3

(...) 나의 초기 가설이 잘못되었습니다. 그렇다면 실제 원인이 무엇인지 말씀해 주시겠습니까?

— Piotr Dobrogost

0

누군가가 시계를 바꾸지 않는 한 시계는 단조로운가요? 뒤로 점프 할 수 없습니다. cron 작업 또는 다른 데몬 (예 :에 대한 호출 hwclock --adjust)과 같이 시계를 설정하는 것이 있어야합니다 . 나는 ntp 자체가 드리프트에 대한 통계를 업데이트하고 정기적으로 그것을 보상한다는 것을 기억하며, 오랫동안 ntp를 실행하지 못하고 큰 오프셋을 얻지 않으면 재설정하지 않으면 며칠 동안 시간이 엉망이됩니다 /etc/adjtime. 시간 드리프트를 주기적으로 재조정하고 점프하는 것과 같은 설정이있을 수 있습니다.

ntp 실제로이 문제에 대응하기위한 것입니다.

— 오리온
소스

저도 그렇게 생각했습니다. 하드웨어 클럭 소스를 읽으면 카운터가 단조 증가해야 함을 알 수 있습니다. 그것이 사실이라면, 최악의 경우 우리는 틱틱 틱 속도를 관찰해야하지만 절대로 되돌아 가지 않습니다. 다중 프로세서 시스템에서 프로세서간에 tsc를 동기화해야한다는 것을 알고 있습니다. 아마도 이것이 뒤로 점프하는 원인일까요?

— brett