https://www.opennet.ru/openforum/vsluhforumID3/96508.html Опубликованы (http://retis.sssup.it/rts-like/program.html) видеоматериалы и слайды семинара "Real-Time Scheduling in the Linux Kernel", посвященного проблемам и задачам "Реального Времени" ядра Linux. Так же доступен для загрузки (http://retis.sssup.it/rts-like/download.html) дистрибутив Xubuntu Live, модифицированный для использования планировщика SCHED_DEADLINE. Семинар организован Университетом Тренто и Университетом Пизы и ReTiS Laboratory - основными разработчиками планировщика задач SCHED_DEADLINE. Видеозаписи выступлений можно посмотреть на YouTube (http://www.youtube.com/channel/UC9s6mcKszFdIRU7ZpsknfKA).<br><br><br>Темы первого дня: <br><br><br>- Планирование реального времени и треды: Основы. (http://retis.sssup.it/rts-like/program.html#rt-basics) <br>- SCHED_DEADLINE: Презентация, "Как использовать?!" (http://retis.sssup.it/rts-like/program.html#sd-intro)<br>- Введение в Jack (Jack Audio Connection Kit) (http://retis.sssup.it/rts-like/program.html#music-fons)<br>- Жесткое Реальное время в Цифровой Музыкальной Ин https://www.opennet.ru/openforum/vsluhforumID3/96508.html#19 Sun, 29 Jun 2014 12:58:49 GMT Скорее всего это видеокартопроблемы и/или дохлоцпу<br>10^6 &#181;s / 120 fps = 16667 &#181;s - именно столько времени нужно на обработку 1 кадра<br>16667 &#181;s / 2 = 8333 &#181;s. Довольно-таки большое окно, в которое нужно уложиться, чтобы заполнить буферы виднокарты в случаи Page flipping, и вряд ли планировщик "выедает" его неудачно распределяя процессорное время между приложениями<br>Всего скорей, это стандартные проблемы tearing'а. Вопрос, на самом-то деле, довольно не простой, и волшебный vsync тут не всегда помощник (вопрос становится ещё болезней, если fps видео некратно частоте развёртке монитора). Тут конечно выходит вперёд вопрос к дровам видеокарты и алгоритм работы плеера (например vo=opengl-hq в форке форка mplayer под названием mpv. Тут более или менее всё в порядке с множественной буферизацией и качеством upscale до разрешения экрана. Как там дела обстоят с xv или vaapi - пёс его знает)<br> https://www.opennet.ru/openforum/vsluhforumID3/96508.html#18 Sun, 29 Jun 2014 11:41:29 GMT &gt; Просмотр фильмов с высокой частотой кадров на обычном ПК не решена. Не <br>&gt; всегда время смены кадра стабильно, и порой заметность смены кадров обусловлена <br>&gt; не постоянством времени отображения кадра. Первый кадр может быть показан 20 <br>&gt; мс, второй 5 мс, а третий 50 мс. Таким образом, второй <br>&gt; кадр в этом примере не заметен, и выпадет из общей динамики <br>&gt; движения сцены, и таким образом станет заметна смена кадров, движение в <br>&gt; сцене потеряет плавность. Хочется верить, что RT-ядра позволяют решить эту проблему. <br><br>Что-то время показа кадра в 5 мс навевает некоторые сомнения...<br>И многое зависит от разного :-) Алгоритм работы плеера... Установлен ли realtime scheduling (который довольно давно в наличии в ядрах) для плеера, для прочих важных задач (X). Само собой это не делается. И может быть даже невозможно. И важность realtime sched имеет когда система загружена и другими задачами (что-то активно вычисляющими). Если она занята только фильмом (как в общем-то и рекомендуется для такого случая), то... R https://www.opennet.ru/openforum/vsluhforumID3/96508.html#17 Sun, 29 Jun 2014 09:28:55 GMT 27.06.2014 03:35 Материалы семинара по планировщикам режима реального времени в ядре Linux<br>9 сообщений за 2 дня (треть которых павлина)<br>29.06.2014 00:23 В рамках проекта Runtime.JS развивается ядро ОС на базе JavaScript-движка V8 <br>55 сообщений за полдня<br>ВЫВОД: Павел узколобый спец, а весь остальной опеннет - талант талантище талантом погоняет.<br>По-моему всё понятно, кто мастер, а кто так, накакано<br> https://www.opennet.ru/openforum/vsluhforumID3/96508.html#16 Sun, 29 Jun 2014 01:37:14 GMT &gt; Просмотр фильмов с высокой частотой кадров на обычном ПК не решена. <br><br>Nvidia Geforce надеюсь?! <br><br>&gt; Хочется верить, что RT-ядра позволяют решить эту проблему.<br><br>https://raw.githubusercontent.com/balsini/sched-deadline-dynamic-manager/master/doc/presentation.pdf<br> https://www.opennet.ru/openforum/vsluhforumID3/96508.html#15 Sat, 28 Jun 2014 20:09:05 GMT Просмотр фильмов с высокой частотой кадров на обычном ПК не решена. Не всегда время смены кадра стабильно, и порой заметность смены кадров обусловлена не постоянством времени отображения кадра. Первый кадр может быть показан 20 мс, второй 5 мс, а третий 50 мс. Таким образом, второй кадр в этом примере не заметен, и выпадет из общей динамики движения сцены, и таким образом станет заметна смена кадров, движение в сцене потеряет плавность. Хочется верить, что RT-ядра позволяют решить эту проблему.<br> https://www.opennet.ru/openforum/vsluhforumID3/96508.html#14 Sat, 28 Jun 2014 00:04:38 GMT В RT системе уже на стадии проектирования должны быть объявлены границы и погрешности.<br><br> Впрочем в жизни очень мало областей, где нужна микросекундная точность. Более интересует <br>гарантированный диапазон, хотя бы те же 50 миллисекунд, но без накопления. Скажем первый<br>тик был в 30 мс, второй должен произойти между 50 и 100 мс, а это можно гарантировать <br>только имея максимум 20 мс погрешность, иначе следующий тик мжет произойти в 130 мс.<br> Посему, если ты заказываешь 50 мс дедлайн, с 2% отклонением, то есть &#177;1 мс., то это <br>возможно гарантировать только если RTOS гарантирует макс. задержу строго меньше 1 мс.<br> <br> <br> https://www.opennet.ru/openforum/vsluhforumID3/96508.html#13 Fri, 27 Jun 2014 18:22:51 GMT [code]<br>Interlocking System<br>&#9679; Obtains trains positions<br>&#9679; Controls switches<br>&#9679; Controls signals<br>&#9679; Generates control command to trains<br>&#9679; Performs service tasks<br>[/code]<br>А я так смотрю, некоторые программисты решили не ограничиваться "если бы программисты строили дома" и решили проверить это на более интересных вещах :)<br> https://www.opennet.ru/openforum/vsluhforumID3/96508.html#12 Fri, 27 Jun 2014 17:31:02 GMT &gt; На обычном ядре пики могу доходить до 10000 &#181;s, на RT до 300 &#181;s, <br><br>Не говорит о worst case: формально 10000&#181;s пролезает под хотелку 50ms. А если оно раз в год на 100ms заклинит? Ты ж не будешь целый год во всех позах мерять бенчмарком задержки?<br> https://www.opennet.ru/openforum/vsluhforumID3/96508.html#10 Fri, 27 Jun 2014 12:34:57 GMT &gt; Я вот пилю вопрос, можно ли все-таки остаться на обычном ядре, если допустимая разбежка 50ms между событиями I/O. <br><br>Запусти бенчмарк cyclictest из этой репы http://git.kernel.org/cgit/linux/kernel/git/clrkwllms/rt-tests.git/tree/<br>Там есть последние три столбца: мин. задержка, средняя и пиковая.<br>На обычном ядре пики могу доходить до 10000 &#181;s, на RT до 300 &#181;s,<br>среднее на -RT около 10 &#181;s, на обычном 30 &#181;s. <br>