Программа для настройки rate

В этом руководстве мы покажем вам, как изменить частоту обновления на вашем устройстве Android с помощью команд ADB. Изначально только флагманы позволяли своему дисплею обновляться 120 раз в секунду, однако сейчас мы наблюдаем даже бюджетные устройства с такой частотой обновления 120 Гц. Что касается минимального значения, то большинство устройств ограничивают его частотой 60 Гц. Кроме того, некоторые устройства также предлагают среднюю частоту 90/96 Гц. И это только это.

У вас нет возможности выбрать любое другое значение по вашему выбору. Но зачем кому-то это делать? Ну и причин может быть масса. Например, вместо того, чтобы принимать 60 Гц в качестве минимального значения, вы можете уменьшить его до 10-20 Гц, что, в свою очередь, приведет к значительной экономии заряда батареи.

Кроме того, есть некоторые пользователи, которые хотят вручную ограничить лимит значением по своему выбору. Некоторые пользователи даже предпочитают постоянно поддерживать частоту обновления экрана 120 Гц, даже если это будет стоить батареи.

Видео настройка rate, кратко

Но, как уже обсуждалось, OEM-производители не предоставляют пользователям такой детализированный контроль и обычно ограничиваются стандартными настройками. [60Hz fixed at all time] или адаптивный [oscillate between 60-120Hz depending on the current usage scenario]. Однако с помощью команд ADB вы можете установить любую частоту обновления по вашему выбору на вашем Android-устройстве, от 1 Гц до 120 Гц. Давайте проверим, как это можно осуществить.

Как изменить частоту обновления в Android с помощью команд ADB

Программы для Windows, мобильные приложения, игры — ВСЁ БЕСПЛАТНО, в нашем закрытом телеграмм канале — Подписывайтесь:)

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

ШАГ 1. Установите Android SDK

Прежде всего, вам нужно будет установить Android SDK Platform Tools на свой компьютер. Это официальный бинарный файл ADB и Fastboot, предоставленный Google, и единственный рекомендуемый. Поэтому загрузите его, а затем распакуйте в любое удобное место на вашем ПК. Это даст вам папку platform-tools, которая будет использоваться в этом руководстве.

ШАГ 2. Включите отладку по USB

Затем вам нужно будет включить отладку по USB на вашем устройстве, чтобы оно распознавалось ПК в режиме ADB. Итак, перейдите в «Настройки»> «О телефоне»> «Семь раз нажмите на номер сборки»> «Вернитесь в «Настройки»> «Система»> «Дополнительно»> «Параметры разработчика»> «Включить отладку по USB».

RATE В CS:GO или настройка плавности игры

ШАГ 3: Установите соединение с оболочкой ADB

1. Для начала подключите ваше устройство к ПК через USB-кабель. Убедитесь, что отладка по USB включена.
2. Затем перейдите в папку инструментов платформы, введите CMD в адресной строке и нажмите Enter. Это запустит командную строку.
   
3. Теперь в следующей команде в окне CMD проверьте подключение ADB: устройства adb
4. Если вы получили идентификатор устройства, значит, соединение установлено успешно. Теперь введите приведенную ниже команду, чтобы открыть среду оболочки: оболочка adb.
5. Теперь в нем будет указано кодовое имя / имя вашего устройства, что означает, что соединение с оболочкой было успешно установлено, и вы можете двигаться дальше.

ШАГ 4: Измените частоту обновления на Android с помощью команд ADB

1. Используйте приведенную ниже команду, чтобы установить желаемый уровень минимальной частоты обновления. Здесь x может принимать следующие значения = 1, 10, 24, 48, 60, 96 и 120. Установка системного параметра min_refresh_rate x.0
2. Например, если вы хотите установить минимальную частоту обновления на 10, то команда преобразуется в: settings put system min_refresh_rate 10.0
3. Затем используйте следующую команду, чтобы установить желаемый уровень максимальной частоты обновления. Как и раньше, x может принимать следующие значения = 1, 10, 24, 48, 60, 96 и 120.
4. Например, если вы хотите установить максимальную частоту обновления 96 Гц, приведенная выше команда преобразуется в: settings put systempeak_refresh_rate 96.0
5. Таким образом, объединив два примера, которые мы привели выше, частота обновления устройства будет колебаться от 10 Гц до 96 Гц. Вы можете соответствующим образом настроить значения и получить результаты, соответствующие вашим требованиям.

Как исправить конкретную частоту обновления на Android

Есть несколько пользователей, которым не нужна эта адаптивная частота обновления, а они предпочитают придерживаться определенной частоты. В связи с этим наиболее часто задаваемый вопрос заключается в том, как добиться максимально плавного использования, ограничив частоту обновления максимальным значением 120 Гц. Что ж, вам нужно будет установить как минимальную, так и максимальную частоту обновления на 120 Гц. Для этого вы можете использовать следующие две команды:

настройки поставить систему min_refresh_rate 120.0 настройки поставить систему Peak_refresh_rate 120.0

Хотя вы получите лучший пользовательский опыт от своего устройства, это также приведет к чрезмерному разряду аккумулятора. Итак, если вы хотите использовать менее агрессивный подход, вы также можете выбрать 96 Гц. Для этого просто замените 120.0 на 96.0 в двух приведенных выше командах, а именно:

в настройках поставить system min_refresh_rate 96.0 в настройках поставить systempeak_refresh_rate 96.0

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

Источник: vgev.ru

Снижение пинга, настройка рейтов

Что нам потребуется, так это подобрать значение rate под нашу ширину канала и выставить значения cl_cmdrate и cl_updaterate.

Диагностика сетевых проблем в CS

net_grath 2 — красный цвет это очень плохо, жёлтый не очень хорошо, зелёный всё отлично. Входящие пакеты отражаются в виде небольших линий, движущихся справа налево. Высота каждой линии отражает размер пакета. Если между линиями возникает разрыв, это значит что пакеты пришли в некорректном порядке или были потеряны. Цвет линий отражает содержащуюся в пакете информацию.
Пинг (Latency) — Время задержки сервера. Время отправки-получения пакета данных за секунду. Чем выше пинг, тем задержка больше и наоборот. Причина резкого роста пинга — увеличение объема принимаемой клиентом от сервера информации сверх возможностей существующего канала, проблемы со связью, перегруженная сеть и прочее. Сервер передает больше, чем может пройти по сети, сетевые пакеты становятся в очередь и ждут отправки.
Loss — показывает сколько пакетов было потеряно во время передачи от сервера к вам. Если есть Loss, то уменьшаем значение cl_updaterate(min 10, max 101)

Choke — показывает сколько пакетов ваш компьютер не может передать серверу. Если есть Choke, то уменьшаем значение cl_cmdrate(min 10, max 101)

Основные команды: Первым делом смотрим значения sys_ticrate и sv_maxupdaterate на сервере CS sys_ticrate — количество кадров в секунду, которые сервер может вычислить
sv_maxupdaterate — максимальное количество пакетов/секунду, которое сервер может послать

Далее смотрим и правим следующие команды у нас:

rate — ограничение входящего трафика от сервера в байтах в секунду (По умолчанию: 3500; min=2500 ;max=20000) Объем входящего трафика зависит от количества игроков, объектов, стрельбы и т.п. вокруг Оптимальное значение 20000. При больших значениях может привести к снижению производительности.
10 Мбит/сек=10000бит/сек. Далее отнимаем 10% занятых под заголовки пакетов и пр., получаем 9000 бит/сек. Делим на 8 и получаем значение rate в байтах 1125.
100 Мбит/сек=100000бит/сек. Далее отнимаем 10% занятых под заголовки пакетов и пр., получаем 90000 бит/сек. Делим на 8 и получаем значение rate в байтах 11250. Для модема 56К: 3500-5000
DSL: 7500
LAN: 9999

cl_rate — ограничивает исходящий трафик к серверу в байтах в секунду (По умолчанию: — ; min= ;max=) Оптимальное значение 20000.
cl_updaterate — количество обновлений информации от сервера к клиенту, в секунду (По умолчанию: 20; min=10 ;max=100) Ставим равным серверному fps (значение sys_ticrate сервера) и не выше значения sv_maxupdaterate сервера cl_cmdrate — количество обновлений информации от клиента к серверу, в секунду (По умолчанию: 30; min=10 ;max=100) Ставим равным серверному fps (значение sys_ticrate сервера) или выше
cl_resend — вpемя, чеpез котоpое бyдет снова послан пакет, если пpедыдyщий не дошел. Чем меньше, тем лучше. Ставим 1, если постоянно возникает ошибка Connection Problem, то увеличиваем значение. (По умолчанию: 6) Ни в коем случае не ставим в 0. На плохих соединениях получится эффект стрельбы холостыми патронами. cl_cmdbackup — сколько дублей пакетов посылать. На хорошем соединении ставим в 0 (меньше трафика, выше пинг), на плохом повышаем 1,2,3 и т.д.

Дополнительные команды:

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

cl_allowdownload 1 — скачивание карт, моделей и декалей с сервера при подключении (1-Разрешить, 0-Запретить)
cl_allowupload 1 — загрузка карт, моделей и декалей на сервер при подключении (1-Разрешить, 0-Запретить)
cl_download_ingame 0 — скачивание карт, моделей и декалей с сервера прямо в игре ((1-Разрешить, 0-Запретить)
cl_lc 1 — компенсация лагов на стороне сервера
cl_lb 1 — все последствия перестрелки т.е. пятна крови, дыры на стенах и т.д. просчитываются на стороне клиента
cl_lw 1 — все эффекты и действия связанные с оружием просчитываются на стороне клиента. Если 0, то будем слышать звуки выстрелов с задержкой.
ex_interp 0 — количество времени (в секундах) для интерполяции между каждым удачным обновлением с сервера Интерполяция — это восстановление значения функции в промежуточной точке по известным ее значениям в соседних точках Ставим в ноль, при этом CS будет вычислять ex_interp по следующей формуле

ex_interp=1/cl_updaterate
cl_smoothtime — время в мсек сглаживания действий клиента. Менее дерганно бегаем. (По умолчанию 0.1). Ставим cl_smoothtime=Пинг/1000

Вот оптимальные значения для некоторых значений ping, если у вас non-steam counter-strike :

Источник: cs-russerver.ru

Программа для настройки rate

Авторизация

Укажите, пожалуйста, свой e-mail.

Зарегистрироваться
Настройка рейтов для Counter-strike 1.6., Рейты под старые и новые билды и ReHLDS

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

Автор статьи: gudaus

Рейты — общее название для параметров, определяющих частоту и объём обмена информации сервера с клиентом. Существует ряд причин, по которым игра на сервере может быть некомфортной для клиента, то есть с лагами. Это:

1. Ддос. Тут он нас ничего не зависит, с таким справляется хостинг/Датацентр.
2. Неправильно настроенные рейты. А вот это можно поправить.
3. Плохая связь у конкретного клиента с сервером. Виновен провайдер клиента, опять же мы помочь не можем ничем.
4. Плохие маршруты у хостинга/VDS. Надо разговаривать с ТП. Если ничего не решается за неделю, то выход один — переезжать на другую локацию, так как подобные проблемы приводят к лагам у всех игроков и нежеланию играть на таком сервере. Зачем нам терять онлайн из-за подобных вещей?

Вначале пройдёмся по терминологии.

1. sv_maxrate и sv_minrate — максимальное / минимальное количество байт за одну секунду времени которые сервер посылает клиенту, включая потери пакетов (loss).
2. sv_minupdaterate и sv_maxupdaterate — минимальная / максимальная частота отсылки обновлений от сервера к клиенту. Влияет на фпс. Если сервер отошлёт клиенту, к примеру, 40 обновлений за 1 секунду, у клиента фпс будет 40 либо ниже.
3. loss — количество потерянных пакетов из последних 100. Пакеты могут теряться из-за перегрузки канала либо плохой связи между сервером и клиентом. Проблема в 90% случаев неустранимая.
4. choke — количество пакетов, отправка которых была задержана сервером, чтобы не превысить лимит полосы, устанавливаемый sv_minrate, sv_maxrate. Также зависит от sv_minupdaterate и sv_maxupdaterate. Причина — сервер генерирует либо слишком много трафика. Это проблему можно решить настройками.

Как настраивать рейты?

Настройка рейтов — дело для каждого сервера индивидуальное, зависящие от железа, канала, билда, нагруженности, так что искать некие «оптимальные» в интернете — занятие интересное, но, увы, малополезное. Лучше это сделать самому по следующим принципам:

• sv_maxrate 20 000 на билдах 5***. sv_maxrate 50 000-100 000 на билде 6***. На билдах 5*** выше, чем 20 000 устанавливать было нельзя. Вы можете прописать любое число в конфиге, хоть миллион, но реально максимум будет 20 000. На билдах 6*** появилась возможность повысить до 100 000, но если канал связи не очень хороший, то имеет смысл поискать оптимальное значение в диапазоне 50 000 — 100 000.
• sv_minrate 50 000 — 100 000 на билдах 5***. sv_minrate 25 000 на билдах 6***. Да, на билдах 5*** нельзя было выставить sv_maxrate больше, чем 20 000, но это обходилось условием sv_minrate. Никакой магии, дело в принципе отбора рейтов HLDS. Работает это так:

Код:

if rate>sv_maxrate then rate=sv_maxrate;
if ratesv_minrate then rate=rate;
if rate

Под rate имеется в виду клиентский rate. То есть что происходит? В начале HLDS смотрит на maxrate. Если клиентский выше, то понижаем до серверного, если ниже — оставляем как есть. Затем HLDS смотрит на minrate. Если клиентский выше серверного, то оставляем всё как есть, а если клиентский ниже серверного, то приравниваем клиентский к серверному.

Вот и получалось на билдах 5***, что клиентский rate всегда ниже, чем серверный(100 000), и принудительно выставлялось значение 100 000. На билдах 6*** максимальное значение sv_maxrate повысили до 100 000, и эта хитрость стала бессмысленной.

• sv_minupdaterate 20-30. 20 — значение по умолчанию, 30 — разумный минимум для человеческого глаза.
• sv_maxupdaterate 60 — 101 для билдов 5*** и sv_maxupdaterate 60 — 102 для билдов 6***

Теперь можно начать выставлять значения.

Заходим в server.cfg, сперва выставляем всё по максимуму.

Для билдов 5*** это

Код:

sv_maxrate 20000
sv_minrate 100000
sv_minupdaterate 30
sv_maxupdaterate 101

Для билдов 6*** это

Код:

sv_maxrate 100000
sv_minrate 25000
sv_minupdaterate 30
sv_maxupdaterate 102

Далее анализируем поведение сервера. Заходим в игру, включаем в консоли график нагрузки (net_graph 0/1/2/3), играем и параллельно смотрим на выданные в нём значения.

1. Если сервер фризит, то понизьте sv_minrate на билде 5*** / sv_maxrate на билде 6***. Понизьте sv_minupdaterate до 20.
2. Если у клиента choke, то имеет смысл повышать sv_minrate. По сути на билде 5*** вы должны жёстко задать rate клиенту путём sv_minrate>sv_maxrate, а на билде 6*** можно поэкспериментировать с sv_maxrate 100 000 sv_minrate [20 000; 100 000]. Значения выше 100 000 ставить крайне не рекомендуется. Также можно понизить значение sv_maxupdaterate. Зачем слать обновления клиенту, если они всё равно не доходят? Но лучше всего будет, если вы сумеете убрать choke и фризы, не уменьшая sv_maxupdaterate.
3. Если избавились от фризов и choke, то можно попробовать потихоньку снижать рейты, дабы лишний раз не нагружать канал. Понизьте sv_minupdaterate до 20, к примеру. Потихоньку снижайте sv_minrate.

Вопросы и ответы​

Я видел, что на билдах 6*** ставят sv_minrate 100 000, sv_maxrate 25 000, как на старых. А в статье сказано ставить наоборот. Где правда?
Ответ: никакой путаницы нет. Вспомним правило расчёта рейтов

Код:

if rate>sv_maxrate then rate=sv_maxrate;
if ratesv_minrate then rate=rate;
if rate

Оно одинаково для всех билдов.
В случае с sv_minrate 100 000, sv_maxrate 25 000 клиентский rate жёстко задаётся в 100 000. На старых билдах делали именно так, потому что не было возможности превысить ограничение в 20 000 иначе.
В случае с sv_minrate 20 000, sv_maxrate 100 000 клиентский rate колеблется между значениями 20 000 и 100 000. На стиме и клиентах нового билда это оптимально, на клиентах старого билда (с бустов) rate клиента станет скорее всего 25 000, так как именно такое значение чаще всего прописывают владельцы бустов. Его можно увеличивать, повышая sv_minrate.

Поясню на примерах

В случае с билдом 6***
sv_minrate 100 000, sv_maxrate 25 000 => rate 100 000
sv_minrate 70 000, sv_maxrate 40 000 => rate 70 000
sv_minrate 30 000, sv_maxrate 100 000 => rate между 30 000 и 100 000 на стимах, 30 000 на бустах.
sv_minrate 10 000, ssv_maxrate 50 000 => rate между 10 000 и 50 000 на стимах, 25 000 на бустах.
Откуда 25 000? Это значение чаще всего выставляют владельцы бустов в клиенте.

В случае с билдом 5***
sv_minrate 100 000, sv_maxrate 25 000 => rate 100 000
sv_minrate 70 000, sv_maxrate 40 000 => rate 70 000
sv_minrate 30 000,sv_maxrate 100 000 => rate 30 000
sv_minrate 10 000, sv_maxrate 50 000 => rate между 10 000 и 20 000, скорее всего 20 000.
Откуда 20 000? Владельцы бустов в клиенте обычно ставят 25 000, но сервер с билдом 5*** поддерживает только sv_maxrate

Что такое фриз и как понять, есть ли он?
Ответ: Фриз — остановка игры. От английского Freeze. Представляет собой кратковременную остановку. Игровой мир замирает, после чего игра продолжается. Обычно бывают 2 ситуации — или небольших фризов много, каждый — доли секунды, или фризов мало, на каждый — по 1-2 секунды.

На графике net_graph 1/2 выглядит как резкое подскакивание фиолетовой полоски вверх.

Надеюсь вам пригодится! хотелось бы еще добавить вот такой мануал . автор: berq!

Некий мануал по net_graph

Итак, чтобы избавиться от лагов, надо знать их причину. А причину нам поможет узнать очень хорошее встроенное в хл средство под названием net_graph, которе отображает в реальном времени информацию, связанную с передачей данных. Имеется 3 режима отображения, мы будем пользоваться первым (net_graph 1).
Для начала дадим описание того, что там вообще отображается:

1 строчка — фпс, интервал десинхронизации (грубо говоря — пинг), значение cl_updaterate
2 строчка — информация о данных от сервера: текущий размер пакета и средняя скорость приема
3 строчка — информация о данных к серверу: текущий размер пакета и средняя скорость отдачи
4 строчка — график данных от сервера. Каждая точка — входящий пакет, высота точек показывает задержку (пинг), чем выше точка, чем больше задержка. Сами точки могут быть 3-х цветов: зеленые — нормальный пакет, пришел вовремя, нигде не задержался 🙂 желтый — пакет с маркером choke, значит сервер не смог отправить все данные из-за политики рейтов; красный — пакет потерялся на просторах интернета ;). Количество loss (потерянных паетов) и choke пакетов можно так же увидеть в цифрах режиме net_graph 3. Значение, отображаемые там нужно понимать так — сколько пакетов из последних 100 было потеряно(loss) или переполнено(choke).
5 строчка — текущее значение cl_cmdratre
6 строчка — два графика (хотя трудно их там разглядеть)Обновляются они синхронно, каждый столбец соответствует одному кадру, который отрисовывает клиент.
Первый график- высотой в один пиксель в самой нижней части. Содержит красные точки. Ими помечаются кадры, в которые не были отправлены cmd пакеты к серверу (можно сказать, аналог choke для клиента, то есть у клиента есть данные для отправки, но отправить он их не может, так как время отправки еще не подошло). В случае, если пакеты отправляются на сервер после отрисовки каждого кадра, графика вообще не видно.
Второй график — фиолтеовый в нижней части и красный в верхней — показывает уровень десинхронизации состояния клиента и сервера. Если присмотреться внимательно, то он представляет собой гребенку (типа вот так — //////). Степень десинхронизации зависит от того, когда был получен последний пакет от сервера. Следствия — при только что полученном пакете десинхронизация минимальна, а при большой задержке входящих пакетов — максимальна ( график в таком случае превращается в красную полосу в верхней части)

Ниже набор из 6-ти скриншотов + описание к ним

1. Симптомы — слайд-шоу, низкий фпс. Причины: железу на клиенте пора на помойку, либо что-то еще нехило кушает процессорное время (может антивирус, или наоборот какая-то вирусня).
Решение: Найти и истребить объект, использующий ЦП, либо бежать в магазин за новым компутером.

2. Видим красные точечки на зеленом графике — потеря пакетов. Это не лучший скрин для демонстрации, но ничего другого нет к сожалению. Симптомы — рывки игроков во время игры, задержка стрельбы или других действий. Особенно хорошо проявляется, когда теряется несколько пакетов подряд.
Решение: Единого способа нет, т к причина может быть независящей от вас (может пьяный одмин за кабель запнулся). Что можно сделать — вырубить все, что использует сеть, особенно торренты и закачки. Можно попробовать собрать диагностику ping/traceroute и отправить в саппорт провайдера

3. А тут у нас фриз на компьютере клиента. Симптомы — внезапомное «замирание» игры на 200-300мсек, после чего нормальное продолжение. На нетграфе сопровождается подскоком зеленого графика «под потолок» (на скрине видно два фриза с небольшим интервалом), при этом на нижнем графике нет никаких отклонений. Причины — в основном связаны с драйверами или железом. Фриз, который можно лицезреть на скрине был вызван «умным» поведением винчестера — после 5-6 секнуд неактивности он паркует блок головок, а при при попытке чтения чего-либо распарковывает их, при этом вся система ненадолго зависает.
Решения — попробовать поставить «рядом» чистую ОС и посмотреть, будут ли фризы на ней. Если будут — проблема с железом, ищем виновника последовательной заменой комплектующих. Если же полет нормальный — дело было в каком-то шибко умном драйвере. Так же может иметь конфликт железо-железо, либо железо-драйвер. В общем, единый путь решения найти трудно.

4. Самая часто встречающаяся сейчас проблема — choke, желтизна на графике, который должен быть зеленым 😉 Симптомы — рост пинга при большом количестве игроков, либо на картах, где видно одновременно много объектов, задержка стрельбы, может быть видно передвижение других игроков и объектов рывками.
Причина: Сервер генерирует больше данных, чем может передать.
Решение: Нужно увеличивать скорость, выделяемую клиенту. Ставим rate побольше (например 300000) и смотрим, что произойдет. Если желтизна исчезла — можете поздравить себя с решением проблемы 🙂 Если нет — пытаемся достучаться админу сервера. Если админом являйтесь вы, то тогда ставим в хлдсе sv_maxrate побольше (100000 например). Можно так же поднять и sv_minrate — это поможет игрокам с дефолтным конфигом (там вроде стоит rate 6000) избежать choke-ов и лагов.

5. Тут бы наблюдаем явную гребенку на нижнем графике — это означает что клинет получает данные через слишком большие интервалы времени. В игре может выражаться небольшим ростом пинга, небольшим подергиванием объектов, игроков.
Причины: низкий cl_updaterate или очень маленький sv_maxupdaterate на серверное стороне. Лечится увеличением значений этих переменных. Так же такое поведение может вызываться очень низким серверным ФПС (< 50). Решается разгрузкой процессора на сервере, либо поднятием значения sys_ticrate (если он имеет малое значение, т е < 100). Можно еще поставить плагины для увеличения серверного фпс, только при перегруженном ЦП они не спасут.

6. Здесь можно лицезреть фриз на серверной стороне — был очень большой перерыв между обработками кадров на сервере. На нетграфе выражается подскоком на нижнего графике десинхронизации, при этом с доставкой пакетов проблем не было (верхний график в норме).
Причин несколько:
1) обычно связана с высокой загрузкой диска на сервере, когда хлдс пытается что-либо прочитать — происходит задержка.
2) может происходить из-за блокирующих запросов в перегруженную субд. Решение — переходим на неблокирующие (threaded) запросы, правда тут без переписывания кода плагинов не обойтись
3) низкий приоритет, данный хлдсу. Если на сервере нашелся процесс с намного более высоким приоритетом, чем хлдс, при этом он загрузил весь (все) ЦП, то хлдс отправляется курить на это время.

Источник: mskvienna.ru