форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка

Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Изначальное сообщение		[ Отслеживать ]

"Материалы семинара по планировщикам режима реального времени..."	+/–
Сообщение от opennews (??) on 27-Июн-14, 09:52
Опубликованы (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). Темы первого дня:   -  Планирование реального времени и треды: Основы. (http://retis.sssup.it/rts-like/program.html#rt-basics) -  SCHED_DEADLINE: Презентация, "Как использовать?!" (http://retis.sssup.it/rts-like/program.html#sd-intro) -  Введение в Jack (Jack Audio Connection Kit) (http://retis.sssup.it/rts-like/program.html#music-fons) -  Жесткое Реальное время в Цифровой Музыкальной Индустрии. (http://retis.sssup.it/rts-like/program.html#music-gabrielli) Отдельного внимания заслуживает тема: Эксперимент с использованием PREEMPT_RT Linux в Московском метро (http://retis.sssup.it/rts-like/program.html#train-andrey). Докладчик: Андрей Федотов из  OAO НИЦВТ (http://www.nicevt.ru). В докладе также рассказано о текущей организации IT-инфраструктуры Московского метро, в которой активно используется Linux. <center><iframe width="640" height="360" src="//www.youtube.com/embed/VL0Iyh9qLbc?rel=0" frameborder="0" allowfullscreen></iframe></center> URL: http://retis.sssup.it/rts-like/program.html Новость: http://www.opennet.me/opennews/art.shtml?num=40094
Ответить | Правка | Cообщить модератору

Сообщения по теме

[Сортировка по времени | RSS]

4. "Материалы семинара по планировщикам режима реального времени..."	+2 +/–
Сообщение от сцбкун on 27-Июн-14, 10:30
О. Ого. Кто-то покусился на мск метрополитен. И сразу на конференцию! =)))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))) А вообще, да, тема с RT интересная. Я вот пилю вопрос, можно ли все-таки остаться на обычном ядре, если допустимая разбежка 50ms между событиями I/O.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	10. "Материалы семинара по планировщикам режима реального времени..."	+3 +/–
	Сообщение от pavlinux (ok) on 27-Июн-14, 16:34
	> Я вот пилю вопрос, можно ли все-таки остаться на обычном ядре, если допустимая разбежка 50ms между событиями I/O. Запусти бенчмарк cyclictest из этой репы  http://git.kernel.org/cgit/linux/kernel/git/clrkwllms/rt-tes.../ Там есть последние три столбца: мин. задержка, средняя и пиковая. На обычном ядре пики могу доходить до 10000 µs, на RT до 300 µs, среднее на -RT около 10 µs, на обычном 30 µs.
	Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

	12. "Материалы семинара по планировщикам режима реального времени..."	+/–
	Сообщение от Аноним (??) on 27-Июн-14, 21:31
	> На обычном ядре пики могу доходить до 10000 µs, на RT до 300 µs, Не говорит о worst case: формально 10000µs пролезает под хотелку 50ms. А если оно раз в год на 100ms заклинит? Ты ж не будешь целый год во всех позах мерять бенчмарком задержки?
	Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

	14. "Материалы семинара по планировщикам режима реального времени..."	+/–
	Сообщение от pavlinux (ok) on 28-Июн-14, 04:04
	В RT системе уже на стадии проектирования должны быть объявлены границы и погрешности.    Впрочем в жизни очень мало областей, где нужна микросекундная точность. Более интересует гарантированный диапазон, хотя бы те же 50 миллисекунд, но без накопления. Скажем первый тик был в 30 мс, второй должен произойти между 50 и 100 мс, а это можно гарантировать только имея максимум 20 мс погрешность, иначе следующий тик мжет произойти в 130 мс.    Посему, если ты заказываешь 50 мс дедлайн, с 2% отклонением, то есть ±1 мс., то это возможно гарантировать только если RTOS гарантирует макс. задержу строго меньше 1 мс.
	Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

13. "Материалы семинара по планировщикам режима реального времени..."	+/–
Сообщение от Аноним (??) on 27-Июн-14, 22:22
Interlocking System ● Obtains trains positions ● Controls switches ● Controls signals ● Generates control command to trains ● Performs service tasks А я так смотрю, некоторые программисты решили не ограничиваться "если бы программисты строили дома" и решили проверить это на более интересных вещах :)
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

15. "Материалы семинара по планировщикам режима реального времени..."	+/–
Сообщение от Главные Редакторы (ok) on 29-Июн-14, 00:09
Просмотр фильмов с высокой частотой кадров на обычном ПК не решена. Не всегда время смены кадра стабильно, и порой заметность смены кадров обусловлена не постоянством времени отображения кадра. Первый кадр может быть показан 20 мс, второй 5 мс, а третий 50 мс. Таким образом, второй кадр в этом примере не заметен, и выпадет из общей динамики движения сцены, и таким образом станет заметна смена кадров, движение в сцене потеряет плавность. Хочется верить, что RT-ядра позволяют решить эту проблему.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	16. "Материалы семинара по планировщикам режима реального времени..."	+/–
	Сообщение от pavlinux (ok) on 29-Июн-14, 05:37
	> Просмотр фильмов с высокой частотой кадров на обычном ПК не решена. Nvidia Geforce надеюсь?! > Хочется верить, что RT-ядра позволяют решить эту проблему. https://raw.githubusercontent.com/balsini/sched-deadline-dyn...
	Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

	18. "Материалы семинара по планировщикам режима реального времени..."	+/–
	Сообщение от Anonym2 on 29-Июн-14, 15:41
	> Просмотр фильмов с высокой частотой кадров на обычном ПК не решена. Не > всегда время смены кадра стабильно, и порой заметность смены кадров обусловлена > не постоянством времени отображения кадра. Первый кадр может быть показан 20 > мс, второй 5 мс, а третий 50 мс. Таким образом, второй > кадр в этом примере не заметен, и выпадет из общей динамики > движения сцены, и таким образом станет заметна смена кадров, движение в > сцене потеряет плавность. Хочется верить, что RT-ядра позволяют решить эту проблему. Что-то время показа кадра в 5 мс навевает некоторые сомнения... И многое зависит от разного :-) Алгоритм работы плеера... Установлен ли realtime scheduling (который довольно давно в наличии в ядрах) для плеера, для прочих важных задач (X). Само собой это не делается. И может быть даже невозможно. И важность realtime sched имеет когда система загружена и другими задачами (что-то активно вычисляющими). Если она занята только фильмом (как в общем-то и рекомендуется для такого случая), то... Realtime большого значения иметь не должен... Заметные рывки в изображении могут быть обусловлены тривиально всё же нехваткой данному плееру вычислительных ресурсов на декодирование и показ (слишком большого числа кадров в секунду)...
	Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

	19. "Материалы семинара по планировщикам режима реального времени..."	+/–
	Сообщение от Аноним (??) on 29-Июн-14, 16:58
	Скорее всего это видеокартопроблемы и/или дохлоцпу 10^6 µs / 120 fps = 16667 µs - именно столько времени нужно на обработку 1 кадра 16667 µs / 2 = 8333 µs. Довольно-таки большое окно, в которое нужно уложиться, чтобы заполнить буферы виднокарты в случаи Page flipping, и вряд ли планировщик "выедает" его неудачно распределяя процессорное время между приложениями Всего скорей, это стандартные проблемы tearing'а. Вопрос, на самом-то деле, довольно не простой, и волшебный vsync тут не всегда помощник (вопрос становится ещё болезней, если fps видео некратно частоте развёртке монитора). Тут конечно выходит вперёд вопрос к дровам видеокарты и алгоритм работы плеера (например vo=opengl-hq в форке форка mplayer под названием mpv. Тут более или менее всё в порядке с множественной буферизацией и качеством upscale до разрешения экрана. Как там дела обстоят с xv или vaapi - пёс его знает)
	Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

17. "Материалы семинара по планировщикам режима реального времени..."	+/–
Сообщение от Аноним (??) on 29-Июн-14, 13:28
27.06.2014 03:35  Материалы семинара по планировщикам режима реального времени в ядре Linux 9 сообщений за 2 дня (треть которых павлина) 29.06.2014 00:23  В рамках проекта Runtime.JS развивается ядро ОС на базе JavaScript-движка V8 55 сообщений за полдня ВЫВОД: Павел узколобый спец, а весь остальной опеннет - талант талантище талантом погоняет. По-моему всё понятно, кто мастер, а кто так, накакано
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема