Никто не сталкивался с проблемой лагающего на больших битрейтах mplayer’а, если в фоне выполняется жрущий CPU процесс? В моей ситуации таким процессом является boinc. Естественно запущен с низким приоритетом. Но это не спасает, как только битрейт повыше, так начинаются лаги, рассинхронизация звука и видео и вообще всё плохо. Особенно это проявляется на h264. Причём при остановленном boinc mplayer не кушает 100% времени, даже если учитывать ещё и работу Xorg.
Пересобрал ядро сменив его не полностью реентерабельное (CONFIG_PREEMPT=y). Частота системного таймера 1КГц. Толку с того ноль.
На данный момент решил проблему вписав mplayer в список «привилегированных приложений» boinc’а. Теперь boinc ставит все вычисления на паузу, как только стартует mplayer. Но это не очень удачный выход: битрейты проигрываемых файлов не всегда настолько велики, а в аудио-файлах заведомо меньше того порога когда начинаются лаги. То есть это решение приводит к тому, что boinc слишком часто простаивает.
Есть какие-нибудь идеи, как можно проблему решить более удачно?
Последние комментарии
-
OlegL, 17 декабря в 15:00 →
Перекличка
21
-
REDkiy, 8 июня 2023 года в 9:09 →
Как «замокать» файл для юниттеста в Python?
2
-
fhunter, 29 ноября 2022 года в 2:09 →
Проблема с NO_PUBKEY: как получить GPG-ключ и добавить его в базу apt?
6
-
Иванн, 9 апреля 2022 года в 8:31 →
Ассоциация РАСПО провела первое учредительное собрание
1
-
Kiri11.ADV1, 7 марта 2021 года в 12:01 →
Логи catalina.out в TomCat 9 в формате JSON
1
ecobeing.ru
Есть в ядрах старше 2.6.39 (поправьте если я не прав, впадлу по git-у лазить…) такая опция «Automatic process group scheduling». Смысл вот в чем. В обычной ситуации линуховое ядро делит процессорное время равными кусками между процессами (ну ± nice и пр лабуда). Те, если, например, запустить компиляцию в 64 потока и mplayer то ему (для простоты пусть все процессы одно ранговые) выделится всего-навсего 1/65 всего времени процессора(ов). Теперь-же можно заставить шедуллер делить время не между процессами а между ЗАДАЧАМИ. Задача — это один или несколько процессов, которые каким-либо образом логически связаны между друг-другом. Например, все процессы компилятора и все Х-овые процессы. теперь у нас есть 2 группы. и на эти 2 группы будет выделяться по 50% времени. (естественно, если процессам в группе это надо). Automatic process group scheduling автоматически создает такие группы, если я не ошибаюсь, основываясь на control tty используя CGROUPS.
Угу… Пробел в моих знаниях оказывается был. Когда я читал ман про chrt, у меня было смутное подозрение, что я что-то подобное читал, но… Видимо я между делом прочитал когда-то, и тут же забыл об этом.
В общем, действительно, понаблюдав за ситуацией я заметил, что boinc жрёт 50% времени CPU несмотря на приоритеты. Я думал, что просто потому, что mplayer’у больше не надо, но видимо я был не прав. Первой реакцией было вырубить в ядре этот «Automatic process group scheduling,» что я собственно и сделал. Но потом, я ещё до кучи в /etc/conf.d/boinc прописал SCHED_PARAM="--idle 0» (был batch). Насколько это повлияло я не могу сказать, поскольку пока не сталкивался с большими битрейтами, но когда столкнусь, или когда соберусь с духом найти такой битрейт намеренно и поэкспериментировать с конфигом ядра и настройками приоритетов, отпишусь сюда с результатами.
Да особо-то экспериментировать-то чего. Вруби «Automatic process group scheduling» и будет счастье. 64 и 128 потоков компиляции на 8-ми ядерном CPU спокойно уживаются с проигрыванием FullHD в mplayer на 25\′ мониторе.
Я наоборот его вырубил. Чёт меня он смущает своим описанием. Мне не надо процессы группами шедулить. Меня больше прельщает контроль на уровне одиночных процессов. Но… Наверное не зря всё же этот шедулинг групп придумали? Вот и надо поэкспериментировать.
Повлияло судя по всему. Теперь mplayer легко уживается с boinc. Осталось выяснить благодаря чему: благодаря ли отключению автоматических групп или благодаря переводу боинка в idle режим.