Вася Богуславский

Во-первых, зачем смотреть числа, которых не понимаешь (с учетом некорректно указанной единицы измерения)? Если бы задержка исчислялась действительно в миллисекундах(10 в -3 степени), то у тебя бы винда лагала при обычном вводе с клавы или движении мышкой. При попытке к, примеру, прочитать/записать текущие координаты курсора в каком-то ПО. Во-вторых, на это число нужно смотреть через призму того, что ПО, которое его вычисляет - делает это обращаясь к памяти, когда другие запущенные в фоне процессы (как виндовых, так и установленных лично) также это делают. Начнем с того, откуда получено число в 61 наносекунду(далее - ns) в посте: с учетом того, что RAM разогнана с 3600 МГц до 3800 - мы можем вычислить, сколько операций способна выполнять память с учетом такой частоты: Поскольку Гц - значение обратно пропорциональное секунде, то RAM делает 3'800'000'000 операций в секунду, т.е. 3'800'000'000/1'000'000'000 ns = 3.8 операции/ns. Учитывая, что память работая на такой частоте имеет тайминг 16 (16 тактов на подзарядку ячеек, которые потеряли часть заряда при чтении данных оттуда) - 3.8 * 16 = 60.8 ns, округляя ~ 61 ns - это и есть та задержка, которую процессор ожидает в случае, если необходимые данные не находились в кэше L1/L2/L3 уровня + перед этим процессор уже запрашивал из RAM данные(из-за которого RAM начала перезарядку ячеек). В связи со всем этим, дополнительные 19 ns - ничто иное как дополнительный набор программ работающий с памятью, который был установлен и постоянно работает в фоне со времен замера задержки на чистой 10 винде.