| 1.4, сцбкун (?), 10:30, 27/06/2014 [ответить] [﹢﹢﹢] [ · · · ]
| +2 +/– | |
О. Ого. Кто-то покусился на мск метрополитен. И сразу на конференцию! =))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))
А вообще, да, тема с RT интересная. Я вот пилю вопрос, можно ли все-таки остаться на обычном ядре, если допустимая разбежка 50ms между событиями I/O.
| | |
| |
| |
| 3.12, Аноним (-), 21:31, 27/06/2014 [^] [^^] [^^^] [ответить]
| +/– | |
> На обычном ядре пики могу доходить до 10000 µs, на RT до 300 µs,
Не говорит о worst case: формально 10000µs пролезает под хотелку 50ms. А если оно раз в год на 100ms заклинит? Ты ж не будешь целый год во всех позах мерять бенчмарком задержки?
| | |
| |
| 4.14, pavlinux (ok), 04:04, 28/06/2014 [^] [^^] [^^^] [ответить]
| +/– |
 В RT системе уже на стадии проектирования должны быть объявлены границы и погрешности.
Впрочем в жизни очень мало областей, где нужна микросекундная точность. Более интересует
гарантированный диапазон, хотя бы те же 50 миллисекунд, но без накопления. Скажем первый
тик был в 30 мс, второй должен произойти между 50 и 100 мс, а это можно гарантировать
только имея максимум 20 мс погрешность, иначе следующий тик мжет произойти в 130 мс.
Посему, если ты заказываешь 50 мс дедлайн, с 2% отклонением, то есть ±1 мс., то это
возможно гарантировать только если RTOS гарантирует макс. задержу строго меньше 1 мс.
| | |
|
|
|
| 1.13, Аноним (-), 22:22, 27/06/2014 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Interlocking System
● Obtains trains positions
● Controls switches
● Controls signals
● Generates control command to trains
● Performs service tasks
А я так смотрю, некоторые программисты решили не ограничиваться "если бы программисты строили дома" и решили проверить это на более интересных вещах :)
| | |
| 1.15, Главные Редакторы (ok), 00:09, 29/06/2014 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
 Просмотр фильмов с высокой частотой кадров на обычном ПК не решена. Не всегда время смены кадра стабильно, и порой заметность смены кадров обусловлена не постоянством времени отображения кадра. Первый кадр может быть показан 20 мс, второй 5 мс, а третий 50 мс. Таким образом, второй кадр в этом примере не заметен, и выпадет из общей динамики движения сцены, и таким образом станет заметна смена кадров, движение в сцене потеряет плавность. Хочется верить, что RT-ядра позволяют решить эту проблему.
| | |
| |
| 2.18, Anonym2 (?), 15:41, 29/06/2014 [^] [^^] [^^^] [ответить]
| +/– |
> Просмотр фильмов с высокой частотой кадров на обычном ПК не решена. Не
> всегда время смены кадра стабильно, и порой заметность смены кадров обусловлена
> не постоянством времени отображения кадра. Первый кадр может быть показан 20
> мс, второй 5 мс, а третий 50 мс. Таким образом, второй
> кадр в этом примере не заметен, и выпадет из общей динамики
> движения сцены, и таким образом станет заметна смена кадров, движение в
> сцене потеряет плавность. Хочется верить, что RT-ядра позволяют решить эту проблему.
Что-то время показа кадра в 5 мс навевает некоторые сомнения...
И многое зависит от разного :-) Алгоритм работы плеера... Установлен ли realtime scheduling (который довольно давно в наличии в ядрах) для плеера, для прочих важных задач (X). Само собой это не делается. И может быть даже невозможно. И важность realtime sched имеет когда система загружена и другими задачами (что-то активно вычисляющими). Если она занята только фильмом (как в общем-то и рекомендуется для такого случая), то... Realtime большого значения иметь не должен...
Заметные рывки в изображении могут быть обусловлены тривиально всё же нехваткой данному плееру вычислительных ресурсов на декодирование и показ (слишком большого числа кадров в секунду)...
| | |
| 2.19, Аноним (-), 16:58, 29/06/2014 [^] [^^] [^^^] [ответить]
| +/– |
Скорее всего это видеокартопроблемы и/или дохлоцпу
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 - пёс его знает)
| | |
|
| 1.17, Аноним (-), 13:28, 29/06/2014 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
27.06.2014 03:35 Материалы семинара по планировщикам режима реального времени в ядре Linux
9 сообщений за 2 дня (треть которых павлина)
29.06.2014 00:23 В рамках проекта Runtime.JS развивается ядро ОС на базе JavaScript-движка V8
55 сообщений за полдня
ВЫВОД: Павел узколобый спец, а весь остальной опеннет - талант талантище талантом погоняет.
По-моему всё понятно, кто мастер, а кто так, накакано
| | |
|
