DateTime.Now (또는 DateTime.UtcNow)은 시스템 타이머 해상도에서만 정확하다는 것을 알고 있습니다. "문서화되지 않은"함수 NtSetTimerResolution이 있지만 doesn't affect the current time입니다. 저는 이미 DateTime.UtcNow의 시작 값과 추가 된 Stopwatch 카운터의 하이브리드 솔루션을 사용하여 최대 정밀도를 마이크로 초로 낮추었습니다. 실제로는 잘 작동하지만 시스템의 여러 프로세스에서 오는 시간 값과 비교하지 않습니다.정확히 언제 DateTime.Now가 업데이트 되었습니까?
이제 기본 시간을 더 보정하고 싶습니다. DateTime.Now의 정확도를 높일 수 없다면 적어도 그 값이 다음 값으로 업데이트 될 때를 알고 싶습니다. 나는 값이 변할 때까지 너무 오랫동안 돌아간 루프를 생각하고있다. 그런 다음 그것을 사용하고 즉시 스톱워치를 시작한다. 이 같은
뭔가 (테스트되지 않은)
DateTime t0 = DateTime.UtcNow;
DateTime baseTime;
Stopwatch stopwatch = new Stopwatch();
while ((baseTime = DateTime.UtcNow) == t0);
stopwatch.Start();
내 가정이 변경되는 값 기다리는 나에게보고 된 값이 정확있는 순간을 제공하는 것이 맞습니까? 예를 들어 공통 로그에보고하는 모든 응용 프로그램에서이 작업을 수행하면 현재보다 훨씬 더 많은 시간 값을 가져야합니다. (나는 동기화 수준의 정확도를 얻고 싶지는 않지만 더 나은 정보를 얻고 싶다.)
NtSetTimerResolution 함수를 사용하여 약간의 테스트를 해본 결과 최대 해상도로 설정하고 루프에서 DateTime.UtcNow 값을 비교했다. . 값이보다 정확하고 정확합니다 (여기서 구별 할 수 없음). 그러나 나는 내가 여기에서 무엇을 보는지 확신하지 못한다. 그리고 프로그램 시작시 현재 해상도가 매번 달라졌습니다. 다른 프로세스와 간섭하는지 확신 할 수 없으므로 프로덕션 코드에서 문제를 일으키지 않는 것이 좋습니다.
주문 하시겠습니까? 어떤 종류의 "정확한"당신이 말하는거야? ("절대적인"정확도는 물론 NTP 서버와 같은 절대 시계에 대한 시스템 클록의 정확도에 따라 달라집니다.) –
엄격한 시간 측정에 관심이 있다면 그 동안의 긴 루프는 많은 CPU 사이클을 소비합니다. 측정중인 작업에 영향을 미칠 수 있습니다. –
로컬 정확도이면 충분합니다. Windows는 기본적으로 며칠마다 NTP 소스를 사용합니다. 물론이 루프는 프로세스를 초기화 할 때 한 번만 수행됩니다. 또한'baseTime.Add (stopwatch.Elapsed)'를 사용합니다. 루프는 16ms를 넘지 않아야합니다. – ygoe