1. Ликбез по прерываниям.

2. Ссылки.

3. Борьба с прерываниями.


Позднее дополню каждый раздел.
Все проблемы у нас связаны с тем, что windows относится к операционным системам с вытесняющей многозадачностью.
Вытесняющая многозадачность требует обработки системного прерывания от аппаратного таймера. По истечении кванта времени, отведённого процессу, происходит прерывание и вызывается планировщик процессов. Частота вызова планировщика критична: слишком частый его вызов будет расходовать процессорное время впустую.
Единственное, что мы можем изменить - это увеличить время кванта и поменять соотношение квантов времени на активную задачу и задачи в фоне, за это отвечает параметр в реестре
Win32PrioritySeparation
По умолчанию
0х26 кванты 18:6 = Оптимальный вариант.
https://github.com/keoy7am/Win32PrioritySeparationTool
При этом само время кванта зависит от системного таймера.
При системном таймера 15.625 мс оно будет больше, чем при 1.0 мс.
Высчитывается время системного таймера * тики.
1 тик= 3 кванта
Для системного таймера 0.5 мс фону тогда буде даваться 0.5мс*6/3 = 1мс из каждых 4 мс.
При 1 мс - 2мс из каждых 8мс.
При 2 мс - 4мс из каждых 16мс.
Для борьбы с фризами оптимально выставить системный таймер 0.5мс.

SMI-прерывания зависят от BIOS/UEFI и оборудования.
Отключаем все лишнее, отключаем энергосохранение, скорость вентиляторов фиксируем, это все, что мы можем сделать.
В нашем плане энергосохранения выбрать оценка для поднятия частоты вместо 15 мс максимум 5000 мс.
Есть программа Intel SMI Latency Checker
Для гипервизора - отключаем поддержку виртуальных машин в биосе.

Про прерывания на уровне ядра и пользователя в windows.


Наш пользовательский процесс может иметь следующие приоритеты:
Idle - 4
Below Normal - 6
Normal -8
Above Normal -10
High -13
Real-Time -24
Внутри процесса мы можем задать приоритет для его потоков:
Idle дает итоговый приоритет процесса с потоком 1, кроме real-time, там он его просто снизит до фиксированной 16
Lowest -2
Below Normal -1
Normal 0
Above Normal +1
Highest +2
Time Critical +7

Итоговый приоритет потока - это сумма приоритетов процесса и потока.
31 - максимум
Real-Time - от 16 до 31.
При этом даже максимальный 31 приоритет не лает нам возможности подняться выше уровня Passive/Low(0), поэтому любое прерывание на нашем ядре прервет нашу программу.


Программы для оценки прерываний:


Настройка прерываний


Борьба с прерываниями.
Бороться надо двумя путями.
Первый путь - уменьшить само количество прерываний=их частоту.
Частота прерываний за 1 секунду до 10000 считается еще неплохой.
Второй путь - уменьшить длительность прерываний.
Есть еще третий путь - освободить от прерываний нужные нам ядра.

Отключить VSYNC.
Включить тройную буферизацию если процессор успевает рендерить, то компенсирует воемя двух кадров: 2*1000 мс / частоту кадров в Гц
Краткий список исследований по психофизиологии:
Watson (1986): Задержки <5 мс незаметны.
Kelly (1979): Порог фликера <2 мс.
Burr & Ross (1982): 10% кадра = 100мс/частоту кадров (при движении).
Clayton (2018): 1–2% кадров= 1000мс*процент пропуска кадров (10–20 мс/с) незаметно.
Carrasco (2011): <5–10 мс при внимании.
Hoffman et al. (2017): <3 мс с размытием.
Swafford et al. (2016): <4 мс, 2% (20 мс) при редких фризах (реже 1 раза в секунду).
Digital Foundry (2025): 0.125 фриза/с=0.125*1000мс/частоту кадров Гц) заметно при частых повторениях.

Для 120 Гц:
1982-0.833мс
2025-1.042мс


Снизить частоту опроса мыши до 125Гц.

Главные правила для таймеров:
Таймеры используются для времени (QPC) и для системных прерываний=тиков.

При этом возможны разные комбинации таймеров.


bcdedit /set useplatformtick no (отключаем RTC и включаем TSC для тиков)
bcdedit /set useplatformclock no (отключаем HPET и включаем TSC для времени QPC)
bcdedit /set disabledynamictick yes (отключаем динамическое изменение частоты системного таймера - влияет только на тики)
bcdedit /set tscsyncpolicy Enhanced (включаем улучшенную синхронизацию TSC-таймера)
HPET не следует отключать в биосе и в диспетчере устройств.
Посмотреть текущую конфигурацию можно с помощью команды
bcdedit /enum


Обсуждение проблем ОС и оборудования: задержка реакции системы (latency), микроcтаттер, инпутлаг, фризы.

Перед тем как задавать вопросы, просьба прочитать FAQ

Осуществлять мониторинг программой Latency Monitor нужно в течение 1 минуты, в состоянии простоя системы т.е. без дисковой, сетевой активности, и любой другой, с выключенным ав и приложениями в трее и автозагрузке,
не раньше чем через 2 минуты после загрузки системы.
Не двигаем мышку и не используем клавиатуру в момент измерений. Потом остановка и скриншот.

Презентация NVIDIA (на англ.) о проблемах статтеров, фризов и лагов (терминология, описание и причины возникновения)

Agiliter ну и? Я тоже могу такое показать с играми и udp пакетами в них это никакой связи не имеет практически и полезной нагрузки не несет.
Вообще эта тема не очень подходит для обсуждения данной проблемы)

Я к тому что крутить рабочее оборудование не надо. Если ваш сегмент сети сбоит из за железа, то это будет видно на любых пакетах.

kiberman, а здесь у тебя какие цифры? - http://www.dslreports.com/speedtest

насчет питания - влияние плохого качества электрической сети на задержку, в отношении роутера вполне допускаю, влияние же на комп представляется маловероятным. дело в том что напряжение сети после входа в блок питания (БП) претерпевает несколько преобразований.
сначала входное напряжение фильтруется специальным фильтром
стоит либо на плате БП, либо отдельный блоком прямо на входном разъеме.
Этот фильтр фильтрует импульсные помехи. Далее напряжение выпрямляется и опять фильтруется сглаживающим конденсатором после выпрямителя, далее это постоянное напряжение преобразуется в переменное с высокой частотой порядка 15-50кГц т.е. это в 500-1000 раз больше чем частота в сети 220В
Далее это напряжение идет на понижающий трансформатор, где понижается в 15-50раз, после этого выпрямляется и снова фильтруется сглаживающими конденсаторами, причем тут они уже достаточно большой емкости. Ну и еще как правило есть конденсаторы на матери и на платах расширения...

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

Ну и конечно нужно знать про большое количество буферов сетевого трафика и конкретно о том как работает шейпинг у провайдеров.
ну и вот еще для общей информации -
https://www.raisecom.su/articles/45890/
http://iptcp.net/buferizatsiya-paketov.html

Речь была о потерях пакетов в оптическом терминале, из-за проблем конкретно с его питанием- его бп- с розеткой которая подключена к щитку. А такие вещи имеют место быть- на pda форуме - инженера ростелекома сталкивались с такими случаями. Отсюда и копание в эту степь.

И как сказал OLD Hunter сегодня это не актуально, и ничего не показывает, может быть идеальное прохождение, нет потери пакетов- на всём маршруте, минимальный пинг и малое количество прыжков до сервера, сам сервер мощный с высоким тикрейтом, а в итоге- хитрег никакой- хуже да-же чем на мобильном интернете.

На мобилке с пингом 150- хитрег и то лучше,почти такой как надо.

Если аппаратная проблема есть, то она будет фиксироваться любыми пакетами, а не избирательными. Или вы думаете у вас какие-то особенные фотоны по оптике гонять будет? Вы случайно аудиофилией не страдаете заодно?

это верно было бы в том случае если бы в других районах города на оптике ростелекомовской не было бы все хорошо.



по тестам у меня сейчас так

http://www.dslreports.com/speedtest/56526027



на это я повлиять не могу)))

Я вам дал нормальные инструменты для диагностики. То что вы приводите - погода на марсе.

Нет не страдаю)))), супер бескислородную медь или спец провода не покупаю-выискивая мельчайшие нюансы, но для аудиоаппаратуры тем не менее, качество питания и проводов- качество пайки и экранирование ,хорошая земля, влияет как на качество воспроизведения так и на запись.

Добавлено спустя 38 секунд:

зачем мне ваш инструмент, если это выполняет стандартный tracert и ping ))) - нет у меня ни потерь на всех точках маршрутах ни проблем

kiberman
Да и это можно измерить. От того что вы вместо музыки пустите по проводам другой сигнал ничего не поменятся. Характеристики сети можно измерить в любом случае.
Как и состояние сети. Без разницы какие пакеты там гонять. Если проблема возникает под нагрузкой, то дайте нагрузку и под ней трассировку делайте. Если проблема со стороны сервера или где-то далеко от вас, то бесполезно пытаться что-то делать у себя. Это как пытаться починить звук соседа крутя у себя микшер...

Это понятно, проблема вылезла после увеличения количества абонентов

- на adsl 5 мгбит- был идеальный хитрег, просто 1 в 1, был правда пожар в щитке и шахте на этаже ниже потом)))). После 24-26 числа, проверю в другом доме. Если там так-же будет, то или шейпят торренты, а они насколько я знаю перешли на udp.

Вообще игровой и торрент траффик внутри маршрутов провайдера или магистралов, не является же приоритетным траффиком по сути.

Посмотрим ещё до 2022 года Ростелеком планировали техническую модернизацию оборудования.

Добавлено спустя 2 минуты 11 секунд:


Да очень похоже, не реагирует совсем или реагирует с задержкой..

Попробую после 24-26 числа. Хочу проверить в другом доме-прежде чем создавать что-то.

И собрать какое-то faq, ну хотя бы практическую базу, а то местные "сетевики админы" меня "загрызут"- что это все выдумки- что приведет к срачу и "переливания воды" из "пустого в порожнее".

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

Как и сказал OLD Hunter - Объяснить будет сложно человеку который с таким не сталкивался. А так как для провайдера это не доказуемо - и не существенно, то и решать этот вопрос не будут. Пока не будет массового ухудшения у всех.

а какое отношение к драйверам нвидии имеет сетевое оборудование?

ну вот смотри у тебя buffer bloat на upload какойто нереально огромный (красная скобка на графике)...
про то что это такое
вообще то можешь. например изменить размер пакета, или изменить настройки сетевой карты.
у меня к слову buffer bloat на всех колеблется от 0 до 5мс http://www.dslreports.com/speedtest/56528470
на графике это красные скобки над столбиками.
Поройся вот тут может быть найдешь что полезное - https://www.bufferbloat.net/projects/

ничего тут спорного. в деревне и помех может не быть или перекосов по напряжению, как в многоквартирном доме.
одно делдо когда сигнал передается между двумя заземлеными устройствами и другое дело когда оба не заземлены или одно заземлено. тогда на сигнал могут пролезать помехи с сети 220В ибудет зависеть уже от способности устройств, тех же роутеров избаялться от них.
грубо говоря если есть заземление обоих компов то напряжение между двумя корпусами этих компов будет не больше 1В, а скорее меньше.
а вот если заземления нет то напряжение будет колебаться от десятка до сотни вольт и сигнал будет жить на этой "подставке"