Точность DateTime в ядре .NET

Question

После того, как пост Эрика Липперта года назад о точности DateTime, я провел его тест на ядре .NET и .NET Framework 4.5.2 на одном компьютере с Windows 10.

        var n = 1000;
        int i = 0;
        long[] diffs = new long[n];
        while (i++ < n-1)
        {
            if (ticks != DateTime.Now.Ticks)
            {
                var newTicks = DateTime.UtcNow.Ticks;
                var diff = newTicks - ticks;
                diffs[i] = diff;
                ticks = newTicks;
            }
        }
        foreach (var d in diffs)
        {
            if (d == 0)
                Console.WriteLine("same");
            else
                Console.WriteLine(d);

        }

Результат в .NET Framework 4.5.2 был таким, как ожидалось: некоторые случайные «одинаковые» в выводе, что означает, что DateTime не является точным для некоторых подуровней.

Однако результат наЯдро .NET было совершенно другим: в выходе не было «одинаковых».Не два Ticks имели одинаковое значение.

Какое объяснение?

Answer 1

Объяснение таково: точка-сеть запрашивает текущую операционную систему.Операционная система запрашивает базовое оборудование.В древние времена аппаратные часы (RTC) на материнской плате обновлялись один раз за 15 миллисекунд.Это число было получено из частоты линии переменного тока 60 Гц в США, которую энергосистема поддерживала достаточно точно.Вспомните, что это были времена «медленных» компьютеров, и дизайнеры старались использовать каждую возможную производительность.Таким образом, ОС не обращалась к RTC каждый раз, когда кто-то запрашивал время и передавал кешированную копию значения - которое очень часто обновляется.

Где-то вниз по течению материнская плата развивалась, и RTC становились более точными.Но ОС и все остальное на ней не ощущалось.Помните, что программное обеспечение развивается намного быстрее, чем программное обеспечение, и даже до сегодняшнего дня, программное обеспечение потребительского уровня тратит большую часть необработанного программного обеспечения.Таким образом, когда платформа dot net запрашивала у ОС время, она получала неточные данные даже тогда, когда это было возможно.Точность возросла с 15 мс до менее 1 мс, но это было все.

В Windows 8 (сервер 2012) было окончательно установлено, что (1) приложения могут работать лучше с более точным временем (2) компьютерыбыстро, так что консультирование с RTC больше не является проблемой (3) большое количество программистов и программ привыкли и фактически полагаются на неточное временное поведение.Таким образом, они (победа 8) продолжили вводить новый немного более медленный механизм для получения наиболее точных данных о времени, но оставили первоначальную реализацию без изменений.

Dot net всегда использовала старую и неточную функцию ОС GetSystemTimeAsFileTimeи когда новый двоюродный брат GetSystemTimePreciseAsFileTime появился в win 8, dot net chise, чтобы пойти обратно совместимым путем, и ничего не сделал.

Dot net core - это новое переписывание многих основных функций и теперь использует данные высокой точностиsource.

Edit

Если текущее время равно 13: 14: 15: 123456 , все еще нет гарантии, что реальное истинное время, как его видят физикии астрономы это.Ваш компьютер не атомные часы.И, конечно, не очень хорошо синхронизированные часы.Единственное, что это означает, это то, что если два события произошли в разные временные метки, то одно событие обязательно произошло раньше другого.На старых компьютерах скорость генерации событий (ex logs, files, txns базы данных и т. Д.) Была ниже, и поэтому была низкая вероятность того, что последовательным событиям будут назначены одинаковые временные метки.Эта новая система времени обслуживает современные высокоскоростные действия, так что вы можете пометить последовательные события как разные.Тем не менее для двух очень близких событий всегда будет возможность одной и той же отметки времени.Это в конечном итоге неизбежно.Если вам нужно измерение наносекундного уровня (почему), вам нужны различные инструменты, такие как Stopwatch, а не System.DateTime