Трансатлантический пинг быстрее, чем отправка пикселя на экран?

Джон Кармак написал в Твиттере ,

Я могу отправить IP-пакет в Европу быстрее, чем отправлю пиксель на экран. Как дела?

И если бы это был не Джон Кармак, я бы подал его под заголовком «глупые переплетения».

Но это Джон Кармак.

Как это может быть правдой?

Чтобы избежать дискуссий о том, что именно подразумевается в твите, я бы хотел получить ответ:

Сколько времени требуется, в лучшем случае, чтобы получить один IP-пакет, отправленный с сервера в США в Европу, начиная с момента, когда программное обеспечение запускает пакет, до того момента, когда оно было получено вышеуказанным программным обеспечением? уровень водителя?

Сколько времени занимает, в лучшем случае, чтобы пиксель отображался на экране, измеряемый с момента, когда программное обеспечение выше уровня драйвера изменяет значение этого пикселя?

Даже если предположить, что трансатлантическое соединение является лучшим оптоволоконным кабелем, который можно купить за деньги, и что Джон сидит рядом со своим провайдером, данные по-прежнему должны быть закодированы в IP-пакет, передаваться из основной памяти через его сетевую карту. оттуда через кабель в стене в другое здание, вероятно, перепрыгнет через несколько серверов (но давайте предположим, что ему просто нужно одно реле), фотонизируется через океан, преобразуется обратно в электрический импульс фотодатчиком, и, наконец, интерпретируется другой сетевой картой. Давай остановимся там.

Что касается пикселя, это простое машинное слово, которое отправляется через слот PCI Express, записывается в буфер, который затем выводится на экран. Даже учитывая тот факт, что «отдельные пиксели», вероятно, приводят к тому, что весь экранный буфер передается на дисплей, я не вижу, как это может быть медленнее: биты передаются «один за другим», а не они являются последовательными электрическими импульсами, которые передаются без задержки между ними (верно?).

Время отправки пакета на удаленный хост составляет половину времени, сообщаемого командой ping, которая измеряет время приема-передачи.

Дисплей, который я измерял, был дисплеем Sony HMZ-T1 с головным креплением, подключенным к ПК.

Чтобы измерить задержку отображения, у меня есть небольшая программа, которая находится в цикле вращения, опрашивая игровой контроллер, делая очистку для другого цвета и меняя буферы при каждом нажатии кнопки. Я записываю видео, показывающее как игровой контроллер, так и экран с камерой с частотой 240 кадров в секунду, а затем подсчитываю количество кадров между нажатой кнопкой и экраном, показывающим изменение.

Игровой контроллер обновляется с частотой 250 Гц, но нет прямого способа измерить задержку на входном пути (хотелось бы, чтобы я все еще связывал вещи с параллельным портом и использовал инструкции Сэма in / out). В качестве контрольного эксперимента я делаю тот же тест на старом ЭЛТ-дисплее с вертикальным обратным ходом 170 Гц. Aero и несколько мониторов могут создавать дополнительную задержку, но при оптимальных условиях вы обычно увидите изменение цвета, начинающееся в некоторой точке экрана (vsync отключено) через два кадра 240 Гц после нажатия кнопки. Кажется, что при обработке USB HID происходит задержка в 8 мс или около того , но я бы хотел улучшить это в будущем.

Весьма часто можно увидеть, что настольные ЖК-мониторы показывают кадры 10+ 240 Гц, чтобы показать изменения на экране. В среднем Sony HMZ составляла около 18 кадров, или более 70 миллисекунд.

Это было в настройке с несколькими мониторами, поэтому пара кадров - ошибка водителя.

Некоторая задержка присуща технологии. ЖК-панели на самом деле меняются в течение 4-20 миллисекунд, в зависимости от технологии. Однокристальные дисплеи LCoS должны буферизовать один видеокадр для преобразования из упакованных пикселей в последовательные цветовые плоскости. Лазерные растровые дисплеи нуждаются в некоторой буферизации для преобразования из растрового возврата в режим сканирования назад и вперед. Стереопередача 3D с последовательным кадром или сверху вниз не может обновлять средний кадр в половине случаев.

OLED- дисплеи должны быть одними из лучших, что продемонстрировал eMagin Z800 , который сравним с задержкой CRT 60 Гц, лучше, чем любой другой тестированный не-CRT I.

Плохая производительность на Sony из-за плохой разработки программного обеспечения. Некоторые функции телевизора, такие как интерполяция движения, требуют буферизации как минимум одного кадра и могут получить выгоду от большего. Другие функции, такие как плавающие меню, преобразования форматов, защита контента и т. Д., Могут быть реализованы потоковым способом, но простой выход - просто создать буфер между каждой подсистемой, что может накапливать до полудюжины кадров в некоторых системах. ,

Это очень прискорбно, но все это поправимо, и я надеюсь, что производители дисплеев будут больше думать о задержке в будущем.

Некоторые мониторы могут иметь значительную задержку ввода

Учет отличного интернет-соединения по сравнению с паршивым монитором и видеокартой, это возможно

Источники:

Консольные игры: фактор отставания • Страница 2

Итак, при 30 кадрах в секунду мы получаем базовую производительность в восемь кадров / 133 мс, но во втором клипе, где игра упала до 24 кадров в секунду, между нажатием на курок и четкой задержкой в ​​12 кадров / 200 мс Нико начинает анимацию стрельбы из дробовика. Это 200 мс плюс дополнительная задержка с вашего экрана. Уч.

Дисплей может добавить еще 5-10 мс

Таким образом, консоль может иметь отставание до 210 мс

И, согласно комментарию Дэвида, лучший случай должен быть около 70 мс для отправки пакета

Это очень просто, чтобы продемонстрировать задержку ввода на мониторах, просто прикрепите ЖК-дисплей рядом с ЭЛТ и покажите часы или анимацию, заполняющую экран, и запишите их. Один может быть вторым или более позади. Это то, к чему ужесточились производители ЖК-дисплеев, поскольку геймеры и т.д. заметили это больше.

Например. Youtube видео: входной тест задержки Vizio VL420M