이기종 환경의 시간 동기화

Question 1

[편집] 방금 메모리에서 이전 답변을 적어 두면서 참고 자료를 사용하여 크게 다시 작성했습니다.

짧은 대답: 아니요.현재 x86/x64 플랫폼의 평범한 운영 체제에서는 밀리초에 가까운 정확도를 얻는 것이 불가능합니다.

부인 성명 저는 컴퓨터에 대한 일반적인 시스템 관리자의 관점을 가진 일반 시스템 관리자이기 때문에 이것은 평신도의 대답입니다. 일부 커널 개발자와 하드웨어 설계자는 시간 관리에 대한 전문적인 수준의 지식을 갖고 있을 가능성이 높습니다.

긴 답변:

어딘가에서 시작해야합니다. 오실레이터를 향해 아래로 이동하는 애플리케이션부터 시작하여 이 하향식 작업을 수행하겠습니다.

첫 번째 문제는 한 대의 컴퓨터에서 시간을 관리하는 것이 아니라 시간 관리에 대해 전체 환경이 동의하도록 관리하는 것입니다. 무슨 시간을 지키나요? 오늘날의 컴퓨터에서 시간을 유지하는 방법에는 몇 가지가 있습니다. 우리가 가장 많이 보는 것은 시스템 시간입니다(화면 모서리 중 하나에 표시됨). 몇 문단 아래로 간단하고 복잡한 일이 있다고 가정해 보겠습니다.

우리는 시스템 시간이 정확하고 모든 컴퓨터에서 동일하기를 원합니다. 우리의 요구 사항이 무엇이든 충족할 수 있도록 매우 세부적인 수준에서 신뢰할 수 있는 소스로부터 정보를 전달할 수 있는 방법이 필요합니다.

요구 사항을 1ms의 허용 수준으로 설정해 보겠습니다. 즉, 시간이 환경 내에서 1ms를 벗어나거나 중요한 목표를 놓칠 수 있습니다. 구체적으로 알아보고 Microsoft가 우리를 위해 무엇을 할 수 있는지 살펴보겠습니다.

NT와 같은 더 이상 사용되지 않는 제품을 제외하고 Windows 기본은 단순화된 ntp(XP/2003으로 시작하는 도메인에 가입된 컴퓨터) 또는 단순화된 sntp(Win2k로 시작하는 도메인에 가입되지 않은 컴퓨터)를 기반으로 시간 관리를 실행합니다. 이 세부 사항을 자세히 알려준 @Ryan에게 감사드립니다. .마이크로소프트는 두 가지 목표를 세웠다시간 계측 구현을 할 때 어느 쪽도 우리가 원하는 정확도 수준을 포함하지 않습니다.

"우리는 네트워크의 노드 간 W32Time 서비스의 정확성을 보장하거나 지원하지 않습니다. W32Time 서비스는 시간에 민감한 애플리케이션 요구 사항을 충족하는 완전한 기능을 갖춘 NTP 솔루션이 아닙니다. W32Time 서비스는 주로 다음을 수행하도록 설계되었습니다. 수행원:

Kerberos 버전 5 인증 프로토콜이 작동하도록 합니다.
클라이언트 컴퓨터에 느슨한 동기화 시간을 제공합니다.

W32Time 서비스는 동기화 시간을 1~2초 범위로 안정적으로 유지할 수 없습니다. 이러한 허용 오차는 W32Time 서비스의 설계 사양을 벗어납니다."

좋아요. 두 대 이상의 컴퓨터에서 서비스 스택을 실행하고 이벤트 상관 관계에 대한 시간 유지 허용 오차 수준이 1ms에 가깝다고 가정하면 이는 상당히 실망스러운 일입니다. 서비스 스택에 두 대의 컴퓨터가 포함되어 있으면 실제로 Windows 기본 시간 관리를 전혀 사용할 수 없습니다. 하지만 그 과정에서 Windows 기본 시간 관리에 대한 핵심 사항 한두 가지를 강조하고 몇 가지 철저한 문서를 포함해 보겠습니다.

AD가 있는 경우 해당 도메인의 시간은 DC에 상관없이 PDC 에뮬레이터 역할에서 동기화됩니다. 따라서 도메인에 정확한 시간을 가져오는 것은 PDC 에뮬레이터 역할을 실행하는 도메인 컨트롤러를 통해 이루어져야 합니다. 다중 도메인 포리스트에 있는 경우 이는 포리스트 루트 도메인의 PDC 에뮬레이터로 변환됩니다. 거기에서 시간은 주로 하위 도메인의 PDC 에뮬레이터와 팬아웃 방식으로 각 도메인 구성원에게 분산됩니다(몇 가지 주의 사항 있음). 이 과정은여기에 문서화되어 있습니다. 더욱 자세한 정보여기

좋아요. 우리는 무엇을 할 수 있나요?

우선, 우리는하나또는다른환경 전반에 걸쳐 시간을 동기화하는 보다 정확한 방법입니다. Linux ntpd를 실행할 수 없다고 가정하거나윈도우용 ntpd다음과 같은 셰어웨어 클라이언트를 살펴볼 수 있습니다.타디스하지만 시도해 볼 만한 것이 더 많이 있을 것입니다.

우리는 설명할 수 없는 역사적 이유로 전체 네트워크를 동기화할 수밖에 없었던 CMOS 시계가 있는 PDC 에뮬레이터로 실행되는 Win2k3 서버에서 Tardis를 실행했습니다. 이제 외부의 원자 시계에서 시간을 가져오는 전용 Linux ntpd로 큰 기쁨으로 대체되었지만 Tardis는 그때 우리를 훌륭하게 구했습니다.그러나 Windows 기본보다 더 높은 정밀도를 달성하는 데 도움이 될 수 있는지는 모르겠습니다.

하지만 이 시점부터 우리(우리)가 완벽한 대체 네트워크 시간 동기화를 구현하는 방법을 알아냈다고 가정해 보겠습니다. 고유한 교묘함으로 인해 1밀리초 미만의 허용 수준을 허용할 수 있습니다. 우리는 AD가 네트워크를 통해 시간이 확산될 것으로 예상하는 방식을 시행하기 위해 이를 마련했습니다.

이는 1밀리초에 가까운 단위로 운영 체제와 마이크로서비스에서 정확한 진단을 얻을 수 있다는 의미입니까?

x86/x64 아키텍처의 운영 체제가 프로세서 시간을 예약하는 방법을 살펴보겠습니다.

그들은 인터럽트를 사용합니다.고고학적 물질이 풍부한 다방면의 짐승. 그러나 중단을 원하는 것은 운영 체제만이 아닙니다. 하드웨어도 인터럽트를 원하며 이를 수행할 수 있는 수단이 있습니다! (안녕하세요 키보드) 운영체제도 함께 작동합니다.

여기가 복잡해지기 때문에 지나치게 단순화하여 이 문제를 해결하겠습니다. 질문? 나는 몸을 숙이고, 덮고, 당신에게 다음을 가리킵니다.주제에 관한 정말 훌륭한 논문. (Windows 플랫폼에서 밀리초를 찾고 있다면 꼭 읽어보세요.) Win8.1/Win2012r2의 업데이트 버전은 다음과 같습니다.작업 중인 것으로 알려졌다하지만 아직 출시일이 나오지 않았습니다.

알겠습니다. 방해합니다. OS에서 어떤 일이 발생할 때마다 인터럽트는 그에 따른 작업을 트리거합니다. 액션은 커널에서 가져온 일련의 명령어로, 한 번에 실행될 수 있습니다.전부~의다른 매너. 결론은 하드웨어 아키텍처 및 커널 인터럽트 처리에 따라 어느 정도 정확도로 결정될 수 있는 시간에 인터럽트가 발생함에도 불구하고 일반적으로 후속 실행 부분이 발생하는 정확한 시간을 알 수 없다는 것입니다. 특정 명령어 세트는 인터럽트 이후 조기에 실행될 수도 있고 늦게 실행될 수도 있고, 예측 가능한 순서로 실행될 수도 있고 그렇지 않을 수도 있으며, 버그가 있는 하드웨어나 잘못 작성된 드라이버로 인해 인식하기 어려운 대기 시간에 영향을 줄 수도 있습니다. 대부분의 경우 단순히 알지 못합니다. 후속 로그 파일에 표시되는 밀리초 수준의 타임스탬프 -매우 정확합니다. 그런데 사건이 언제 일어났는지는 정확합니까?

계시 중단으로 인해 잠시 중지하겠습니다. 인터럽트에는 우선 순위 수준이 있으며 가장 낮은 수준은 사용자 응용 프로그램(예: 표준 서비스)이 프로세서 시간을 얻는 위치입니다. 다른 (상위) 레벨은 하드웨어 및 커널 작업용으로 예약되어 있습니다. 가장 낮은 수준보다 높은 수준의 인터럽트가 도착하면 시스템은 대기열에 있는 더 낮은 우선 순위의 인터럽트도 존재하지 않는 척합니다(더 높은 우선 순위의 인터럽트가 처리될 때까지). 이러한 방식으로 실행 중인 일반 응용 프로그램과 서비스는 프로세서 시간에 따라 마지막에 배치됩니다. 대조적으로 클록 인터럽트에는 거의 가장 높은 우선순위가 부여됩니다. 시간 업데이트는 거의 항상 시스템에서 수행됩니다. 이것은 모든 작동 방식을 거의 지나치게 단순화한 것이지만 이 답변의 목적을 충족합니다.

업데이트 시간은 실제로 두 가지 작업으로 구성됩니다.

시스템 시간 업데이트 / 일명 벽시계 / 일명 누군가가 나에게 몇시인지 물을 때 내가 말하는 것 / 일명 ntp가 근처 시스템을 기준으로 약간 앞뒤로 조정하는 것입니다.
예를 들어 코드 실행 기간을 측정할 때 사용되는 틱 수 업데이트.

그러나 벽 시간이나 틱 수에 관계없이 시스템은 어디에서 시간을 가져옵니까? 하드웨어 아키텍처에 따라 크게 달라집니다. 하드웨어 어딘가에서 하나 또는 여러 개의 오실레이터가 틱하고 있으며 해당 틱은 다음을 통해 가져옵니다.하나~의여러 개의가능한경로커널과의 접촉을 위한 인터페이스에 더 크거나 더 낮은 정밀도와 정확도로 벽 시간과 틱 수를 업데이트합니다.

멀티코어 시스템에는 오실레이터 배치를 위한 여러 가지 설계 모델이 있으며, 주요 차이점은 동기식 배치와 비동기식 배치인 것으로 보입니다. 정확한 시간 유지에 대한 각각의 과제와 함께 이러한 사항이 설명됩니다.여기예를 들어.

간단히 말해서, 동기식 시간 유지에는 멀티코어당 하나의 참조 클럭이 있으며, 이는 신호를 모든 코어에 분산시킵니다. 비동기식 시간 유지에는 코어당 하나의 발진기가 있습니다. 최신 Intel 멀티코어 프로세서(Haswell)가 "Forwarded Clocking"과 함께 "QuickPath Interconnect"라는 직렬 버스를 사용하는 동기식 설계 형식을 사용한다는 점은 주목할 가치가 있습니다.데이터 시트. 전달된 클럭킹은 일반인(나)이 빠르게 표면적으로 이해할 수 있는 용어로 설명됩니다.여기.

자, 그럼 그 모든 너더리즘을 제쳐두고(시간 측정이 많은 살아있는 역사를 지닌 복잡하고 실용적인 작업이라는 것을 보여주는 데 도움이 됨) 인터럽트 처리에 대해 좀 더 자세히 살펴보겠습니다.

운영 체제는 틱 또는 틱리스라는 두 가지 전략 중 하나를 사용하여 인터럽트를 처리합니다. 귀하의 시스템은 둘 중 하나를 사용합니다. 그러나 용어는 무엇을 의미합니까?

틱킹 커널고정된 간격으로 인터럽트를 보냅니다. OS는 틱 간격보다 더 미세한 해상도로 시간을 측정할 수 없습니다. 그럼에도 불구하고 하나 또는 여러 작업을 수행하는 데 관련된 실제 처리에는 틱 간격보다 더 큰 지연이 포함될 수 있습니다. 서비스 간 호출에 내재된 지연으로 인해 상대적으로 많은 시간이 소요될 수 있는 분산 시스템(예: 마이크로서비스)을 생각해 보세요. 그러나 모든 명령어 세트는 커널 틱 시간보다 더 미세한 해상도로 OS가 측정한 하나 이상의 인터럽트와 연결됩니다. 틱 시간에는 기본 값이 있지만 적어도 Windows에서는 개별 응용 프로그램의 요청에 따라 줄어들 수 있습니다. 관련된 작업입니다.혜택뿐만 아니라 비용도, 그리고 운반꽤 작은 글씨그것으로.

소위틱리스 커널(매우 설명적이지 않은 이름을 가지고 있음)은 비교적 새로운 발명품입니다. 틱리스 커널은 틱 시간을 가변 간격으로 설정합니다(향후 가능한 한 긴 기간). 그 이유는 OS가 전력을 절약한다는 단순한 목적으로 프로세서 코어가 가능한 한 오랫동안 다양한 수준의 절전 모드에 들어갈 수 있도록 동적으로 허용하기 때문입니다. "다양한 수준"에는 최고 속도로 명령을 처리하는 것, 감소된 속도로 처리하는 것(예: 더 느린 프로세서 속도) 또는 전혀 처리하지 않는 것 등이 포함됩니다. 서로 다른 코어는 서로 다른 속도로 작동할 수 있으며 틱 없는 커널은 인터럽트 배치에서 프로세서를 실행하기 위해 명령을 대기열에 추가하는 경우에도 프로세서를 가능한 한 비활성 상태로 유지하려고 합니다. 간단히 말해서, 다중 프로세서 시스템의 서로 다른 코어는 서로에 대해 시간에 따라 표류할 수 있습니다. 물론 이것은 좋은 시간 유지에 큰 혼란을 야기하며, 효율적인 절전을 가능하게 하는 최신 절전 프로세서 아키텍처와 틱리스 커널에서는 지금까지 해결되지 않은 문제입니다. 이를 실제 작업 수신 여부에 관계없이 모든 프로세서 코어를 지속적으로 깨우는 틱 커널(정적 틱 간격)과 비교해 보십시오. 시간 유지는 어느 정도 부정확하지만 틱 없는 커널에 비해 상대적으로 신뢰할 수 있는 수준입니다.

표준Windows 틱 시간(시스템 해상도)은 15.6ms입니다.기본 동작이 틱 없는 Windows 8/2012까지(그러나 틱 커널로 되돌릴 수 있음). 제가 생각하는 Linux 기본 틱 시간은 커널 컴파일에 따라 다르지만이 틈새 시장~이다글쎄, 내 경험을 넘어서(그리고이 하나도) 따라서 의존하는지 다시 확인하는 것이 좋습니다. 내가 생각하는 Linux 커널은 2.6.21부터 틱 없이 컴파일되었으며 틱 없는 동작을 최적화하는 다양한 플래그로 컴파일될 수 있습니다(그 중 no_hz의 몇 가지 변형만 기억합니다).

베어메탈 시스템에는 이 정도입니다. 가상 시스템에서는 VM과 하이퍼바이저가 서로 다른 방식으로 경합하여 정확한 시간을 유지하는 것이 극도로 어려워지기 때문에 상황이 더욱 악화됩니다. 여기는VMware 개요그리고여기 RHEL KVM용이 있습니다.. 분산 시스템에서도 마찬가지입니다. 클라우드 시스템은더욱 어려운실제 하이퍼바이저와 하드웨어를 가까이서 볼 수도 없기 때문입니다.

결론적으로, 시스템에서 정확한 시간을 얻는 것은 다층적인 문제입니다. 이제 높은 수준의 관점에서 상향식으로 진행하여 다음을 해결해야 합니다. 하드웨어와 커널 간의 내부 시간 동기화, 인터럽트 처리 및 원하는 명령 실행 지연(가상 환경에서 부정확한 경우) 두 번째 OS 계층의 캡슐화로 인해 분산 시스템 간의 시간 동기화가 가능해졌습니다.

따라서 컴퓨팅 역사의 현 시점에서 우리는 최소한 평범한 운영 체제를 사용하지 않고 x86/x64 아키텍처에서 밀리초 수준의 정확도를 얻지 못할 것입니다.

하지만 우리는 얼마나 가까이 갈 수 있을까요? 나는 모르고 시스템마다 크게 다를 수 있습니다. 자신의 특정 시스템의 부정확성을 파악하는 것은 어려운 작업입니다. 하나만 보면 된다인텔이 코드 벤치마킹을 수행해야 한다고 제안하는 방법제가 관리하고 있는 시스템과 같은 일반 시스템은 이러한 관점에서 볼 때 통제할 수 없는 수준이 매우 크다는 것을 알게 되었습니다.

나는 성취할 생각조차 하지 않는다"모든 전력 최적화, 인텔 하이퍼스레딩 기술, 주파수 스케일링 및 터보 모드 기능이 꺼졌습니다."중요한 시스템에서는 C의 코드 래퍼를 수정하고 후속 답변을 얻기 위해 장기 테스트를 실행하는 일이 훨씬 적습니다. 나는 단지 그들을 살아있게 하고 그들을 너무 방해하지 않으면서 그들에 대해 최대한 많이 배우려고 노력할 뿐입니다. 타임스탬프 감사합니다. 제가 당신을 완전히 믿을 수 없다는 건 알지만 시간이 얼마 남지 않았다는 건 압니다. 실제 밀리초 정확도가 중요해지면 한 번의 측정만으로는 충분하지 않지만 패턴을 확인하려면 더 많은 수의 측정이 필요합니다. 또 무엇을 할 수 있나요?

마지막으로 보면 재미있습니다.실시간 OS 사용자가 인터럽트 대기 시간을 어떻게 생각하는지. 또 한있다매우 흥미로운 시간 동기화 대안꽤 흥미로운 작품이 있는 곳에서통계,방법론그리고하얀 종이공개됩니다. 여기에 향후 하드웨어 아키텍처와 커널 개발을 추가하면 몇 년 안에 이러한 시간 유지 정확성 문제가 더 이상 문제가 되지 않을 수 있습니다. 희망할 수도 있습니다.

Answer