(я пока не уверен, в этой ветке стоит обсуждать это или в другой. Но, всё же.)

А вот это уже интересное наблюдение. У кого происходить та же ерунда при стриме?
Случай, когда видеопоток реально является плавным (т.е. более-менее равномерным), что подтверждает нам один из его получателей (при чём, самый медленный) - записывающее стрим ПО, а на экране мы видим некоторое лагалище, может говорить о том, что у стриминга может просто стоять более высокий приоритет. И пока стример не выполнит свой неделимый во времени кусок работы, другие, например обработчик вывода на экран монитора/ТВ может простаивать в его ожидании (идеально запараллелить тут не получится, т.к. источник 1 и обращение к нему за данными в буфер кадра будет всё равно поочерёдное, только если заранее специально не предусмотреть 2(!) одинаковых буфера хранения под такие дела).
А при отключении стриминга дергатня пропадает? Если да, то, скорее всего вышеописанное. Если нет - нужно немного подумать...

НУ без стрима микрофризы без всинк, хотел записать их шадоуплеем но он пишет в 60 фпс видимо фризы он поэтому не записывает.

faq. все софт и часть аппаратных причин описаны -в том числе датчики и оверлеи. Заполняйте профиль подробно на каком пк дергается Интел или Амд. Попробуйте новые 397.31 в связке Ос- 1803 и wddm 2.4 - у меня отличные впечатления от новых драйверов,а человек я привередливый в таких моментах.

В общем, я пока что сдаюсь. Фризы уменьшились и пусть не хотят пропадать, но я тоже не хочу целыми днями воевать с пк, уже работать на нём надо. В принципе, жить можно. Как созрею, начну с техподдержки MSI.

Да. Фокус именно в том, что записывать - не показывать. Запись 60 к/с это ровно 60 к/с, где каждый кадр ровно 1/60 секунды. При этом записывается в файл ровно то, что считалось с буфера кадра, где без всинка мог оказаться рваный кадр, состоящий из двух разных полукадров. Дёргание на видео появится только тогда, когда какой-то кадр слишком надолго (на 2+ фреймов) задержался в буфере, и то, если сжатие видео не использует какое-нибудь выравнивание/интерполяцию. При сильном же сжатии, когда используется мало ключевых полных кадров, видеоэнкодер вообще может брать только каждый третий/пятый/десятый... кадр за основу для ключевого, а несколько последующих будут кодироваться изменениями к нему с такой потерей качества и смазыванием, что ни один Шерлок Холмс не найдёт потом разницу и "виновных".

в буфере нет рваных кадров это проблема моника.

Нет, не монитора, а видеокарты. В тройном буфере - нет рваных. Но он не везде используется. А вот в двойном - могут быть запросто. Опять же - от типа синка ещё зависит.
Классический всинк-офф, насколько мне известно, передаёт кадр на монитор ровно по мониторной синхронизации: подошло время - перехватывает управление буфером и отправляет то, что получилось в буфере. Если ВК не успела дорисовать туда кадр, её обрывают и она продолжит его рисовать во второй (из двух) буфер. Если закончит, снова начнёт рисовать в него же. И так, пока у неё опять не перехватят управление и не отдадут под рисование другой буфер. Отсюда и растут ноги у тиринга.
Вообще, какую конкретно проблемную ситуацию рассматриваем? Чего гадать-то? Какой стоял всинк? Двойной или тройной буфер работал? А то мы в теорию от проблемы уже ушли...

Хуже стало по DPC с новыми дровишками,версия винды 1709 - 16299.15 без Meltdown и т.д.
Скрины кликабельны.


У всех так? в смысле ухудшились показатели?

Ваша правда по DPC показатели пошли вверх с 397.31 винда 1803 - 17133.1
Сорре без скринов т.к. с работы

Enkvar И да, и нет.
Скринов с 390.77, на них сидел все это время, не осталось, но там драйвер нвидии прыгал до 150us, тут же 200, т.е. вроде как и ухудшилось, но не в 2 раза же.

Про pagefault знаю, но у меня своп выключен полностью, да и чаще всего эти значения не являются поводом бить тревогу, только если реальных проблем не наблюдается(зацикливание звука, статтеры и проч.).

Для статистики оставлю: на 378.92 было примерно 10-30us на 397.31 прыгает до 140+us

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

Всё сейчас на 397.31 так-же на мой взгляд, эти значения нельзя же без отрыва от ос и текущей задержки анализировать. При измерениях-должны быть максимально равные условия-одно время измерений и состояние ос.
В 3д приложениях и играх я вижу отличный очень стабильный фреймрейт, а если у кого-то скачок единчный до 300-400,это ниочём не говорит. Перемеряв позже- вы получите другие значения.

Если померяв раз 5-6 в режиме энергосбережения цпу и после загрузки всех служб и отсутствия какой-либо активности во ос- значения такие,да можно говорить -изменилось. Учитывайте что фокус окна,рефреш гуи,или любые быстрые сообщения справа на панели в ос- вы всё это увидите в этих значениях.

у меня со всеми заплатками, dpc в норме

Это инфа прежде всего для всех,что-бы не поднимали панику с 397.31.. вы тут не причём,вы прям так испугались показаться невеждой))

kiberman Прошу помощи у Вас как у специалиста: не могу вернуть значение таймера с 3,11 на 1,73. История такая, на плате ga-b150m, проц i5 6500, был биос F2: из коробки на старте глючили контроллеры юсб и рс2, перешил на F21(под 7серию)- стало хуже, вернул назад, все стало о.к. контроллеры подхватились, но теперь не могу вернуться на старый таймер, на нем задержки были 50-90, на этом 230-290. В биосе матери только одна настройка: hpet доступно или недоступно. При вкл. если bcdedit /set useplatformclock true, то таймер 24, если bcdedit /deletevalue useplatformclock то - 3.11, если выкл. то тоже 3.11, а раньше с недоступным в биосе hpet таймер был 1,73, как его вернуть? По системе больше ничего не крутил, только новые интеловские дрова на чипсет, может в них быть дело? Остальные настройки биоса те же, разгона нет

Многопоточный процессор (i7, Rysen), приличная материнка, и память работающая по jedec параметрам (без всяких XMP и разгонов) вероятнее всего уберут все эти latency.
У Nvidia драйвер многопоточный, и делит время с игровой логикой, от этого могут быть фризы на слабых либо на чрезмерно разогнанных процах и памяти т.к. код более сложный.

Здравствуйте-специалист я "такой себе" честно ,лично я после каждой прошивки делаю clr-cmos перемычкой для очистки таблицы dmi- с этого я бы и начал-

Так вы сейчас вернулись на F2?-там нет опции?.

Мои бы действия были бы такие- отключил в биосе hpet-если вы на f21, прописал bcdedit /set useplatformclock false в ос и перед перезагрузкой после ввода ключа- проверил бы в диспетчере задач драйвер:

"Высокоточный таймер событий" - попробовал бы отключить/удалить. Но учитывайте, что у вас какая-то была не понятка с контроллёрами, Рабочая схема TSC+HPET сейчас на 95% Пк используется и у меня в том числе,без необходимости что-то ковырять- и задержки такие могут быть у вас от неисправного оборудования и проблем с драйверами/ос на этом оборудовании.

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

Добавлено спустя 15 минут 40 секунд:

Золотые слова,если не гнать в шею контроллёр Озу- это очень благотворно сказывается на всём.

После обновления драйверов видеокарта начала "пропадать". Зато заработал оверлей GeForce Experience (до этого работать отказывался; без него тоже пробовал). Походу, все проблемы из-за неё.

kiberman Сделал как Вы написали, 1.прописал bcdedit /set useplatformclock false 2.Отключил и удалил высокоточный таймер через диспетчер, 3. в биосе отключил Hpet: результат вместо 3.11 получил 3,57. Какие мысли у Вас на такое поведение системы?