| 1.1, Анон (?), 11:48, 15/06/2009 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
значит ли это, в частности, что дешевые soho линукс-роутеры будут держать большую нагрузку и скорость?
| | |
| |
| 2.3, vadiml (?), 11:52, 15/06/2009 [^] [^^] [^^^] [ответить]
| +/– |
Скорость и время реакции -- разные вещи.
RT ядро чуть медленнее обычного из-за разных приоритетов.
| | |
| |
| 3.7, Анон (?), 12:05, 15/06/2009 [^] [^^] [^^^] [ответить]
| +/– | |
да, это разные вещи.
переформулирую вопрос: значит ли это, что линукс машины с RT ядром смогут более качественно обслуживать VoIP? как частный случай.
| | |
| |
| 4.10, Greg (??), 12:44, 15/06/2009 [^] [^^] [^^^] [ответить]
| +/– |
 Не факт, тут важнее пока что программное обоспечение которое стоит на рутере, и обслуживает траффик. Хочу сказать что мы используем линукс в рутерах собственной загoтовки с ядром 2.4 Проблем с Voip не замечено.
| | |
| 4.37, User294 (ok), 23:05, 15/06/2009 [^] [^^] [^^^] [ответить]
| +/– |
>переформулирую вопрос: значит ли это, что линукс машины с RT ядром смогут
>более качественно обслуживать VoIP? как частный случай.
ИМХО для VoIP надо просто грамотно настроенный QoS и при том хрень типа реалтайма на уровне ядра врядли сильно влияет на что-то.Зато настройки QoS какие пакеты пихать с бОльшим приоритетом - очень даже влияют, особенно если канал в интернет узкий и какие-то скотины вечно норовят его забить трафом.В этом случае правильный шедулинг пакетов может здорово улучшить дело.А вот микросекунды от реалтаймности ядра мало кто разглядит даже с микроскопом имхо.
| | |
|
|
| 2.6, Sarge (??), 11:58, 15/06/2009 [^] [^^] [^^^] [ответить]
| +/– |
Конечно нет. RealTime оси гарантируют высокую отзывчивость за счёт понижения общей производительности.
| | |
| |
| 3.8, 74025 (?), 12:17, 15/06/2009 [^] [^^] [^^^] [ответить]
| +2 +/– |
Ну и хорошо. Главное - отзывчивость. Неприятно, когда система неотзывчива.
| | |
|
| |
| 3.38, User294 (ok), 23:16, 15/06/2009 [^] [^^] [^^^] [ответить]
| –2 +/– | |
>Наверно в лучшем случае вешаться меньше станут.
А они вешаются? Сами по себе роутеры с пингвином могут работать месяцами без проблем.Там обычно софта минимум, ядро древнее 2.4 - глючить в плане софта как бы особо нечему (ядро, базовые демоны и прочая существуют не год и не два и их уже давно более-менее обезглючили в сетевых делах).
Если взвисает то обычно или из-за аппаратных грабель (железо дешевое, а как известно - как заплачено, так и зафигачено) или из-за откровенной лажи вендорья в том что они туда прикручивали своими кривыми руками: у всяких асусов и длинков полтора програмера на всю контору и линукс они знают как-то по своему, устраняя элементарные проблемы месяцами, хотя любой Вася Пупкин слегка понимающий как работает линукс пристрелит такую проблему за пару часов. Еще бывают всякие совсем дешевые роутеры, которые виснут в силу общей дерьмовости конструкции и потому что сэкономили на всем. Но там обычно внутрях вообще какое-нибудь самопальное говно в качестве софта(влезает в меньший объем RAM и flash чем пингвин - экономия еще пары центов обеспечена!). Обычно оно грамотно дополняет общедерьмовую картину - самопальные реализации протоколов в отличие от того что в пингвинах обычно убогие и глюкавые (в пингвинах лажу за годы все-таки более-менее выловили орды тех кто это пользовал, все более-менее популярные протоколы более-менее допинали до кондиции и они работают, в разных позах, чего про "самопальные" стэки протоколов в самопальных операционках - не скажешь).
| | |
|
| 2.16, alexr (??), 15:10, 15/06/2009 [^] [^^] [^^^] [ответить]
| +1 +/– | |
Большая нагрузка и скорость реакции метрики которые влияют друг на друга негативно.
В случае сферического коня в вакууме:
1.Наибольшая пропускная способность достигается при максимально возможной буферизаци.
2.Наименьший RTT или время реакции с нулевой буферизацией.
В мире реальных систем для предельных значений в (1) и (2) можно посчитать оптимальный размер буфера.
| | |
| 2.36, User294 (ok), 23:00, 15/06/2009 [^] [^^] [^^^] [ответить]
| +/– |
> значит ли это, в частности, что дешевые soho линукс-роутеры
> будут держать большую нагрузку и скорость?
У них проблема вовсе не в реалтаймности.А в обычном horsepower'е проца и прочая (проблема в том что мощный проц - дорогой и охлаждения требует).С ростом технологий (уменьшение технологических норм и рост частот, etc) само получится.Реалтаймовость тут не при чем.
А для большой нагрузки в дешевых роутерах у того же Ubicom есть например ряд "коммуникационных" процов где параллельно живет несколько тредов сразу. И к оному недавно прикрутили таки линух (была на этот счет новость).Да и однопоточным процам все конкуренты сделали face lift подняв частоты и прочая.Так что видимо роутеры все-таки будут.А куда они денутся то?Роутить, файрволить и т.п. гигабит и сотни мбит в .n draft все-таки нелегко и проц придется ставить мощнее.
| | |
| 2.42, XoRe (ok), 12:11, 16/06/2009 [^] [^^] [^^^] [ответить]
| +/– |
>значит ли это, в частности, что дешевые soho линукс-роутеры будут держать большую
>нагрузку и скорость?
Вы сначала загрузите линукс-роутер так, чтобы он не справлялся с нагрузкой)
При грамотной настройке и тюнинге хороший комп спокойно обрабатывает сотни мегабит трафика.
А часто ли у soho каналы в интернет на сотни мегабит?
Если выхотите именно "дешевый линукс-роутер", то даже p-300 сможет обработать (разрулить, зашейпить и т.д.) ADSL канал.
С другой стороны, никакой realtime не позволит выжать из железа больше того, что оно дает.
Гигагерц операций из p-300 не получится.
Поэтому нужно исходить из потребностей.
| | |
|
| 1.2, yantux (??), 11:51, 15/06/2009 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
"серия стресс-тестов продемонстрировала уменьшение средней задержки с 7 до 2 микросекунд" - а где описание и исходники тестов?
| | |
| 1.5, Мо (?), 11:57, 15/06/2009 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
>Разработчики стремительно приближаются к моменту полной интеграции "-rt" ветки с основным Linux ядром.
Это значит, что RT можно будет включить передав параметр дистрибутивному ядру?
| | |
| |
| 2.9, uZver (??), 12:20, 15/06/2009 [^] [^^] [^^^] [ответить]
| +/– |
>>Разработчики стремительно приближаются к моменту полной интеграции "-rt" ветки с основным Linux ядром.
>Это значит, что RT можно будет включить передав параметр дистрибутивному ядру?
скорее уж пересобрав ядро и модули с опцией RT.
| | |
| 2.13, rimidal (?), 13:58, 15/06/2009 [^] [^^] [^^^] [ответить]
| –1 +/– |
В Ubuntu в репозитории уже давным давно есть готовые сборки -rt ядра. А UbuntuStudio так вобще по умолчании с -rt ядром ставиться.
| | |
| |
| 3.14, fidaj (ok), 14:05, 15/06/2009 [^] [^^] [^^^] [ответить]
| +/– | |
Ну не во всех ветках ядер.... В 27, 28 - наблюдались проблемы с SMP в rt ядрах... Пока что боевое RT ядро это 2.6.24-24-rt (hardy) что там в поновее дистрах - не знаю, но положа руку на сердце в конфиге 2.6.24-24-rt нет для полноценного rt - CONFIG_PREEMPT_RT - там только CONFIG_PREEMPT_DESKTOP (low latency)
Начал собирать 2.6.29.4-rt18 по ссылке и сразу неточность - реально дает загрузить только патчи для 2.6.29.4-rt19 (http://www.osadl.org/Latest-Stable-Quick-RT-Preempt-kerne.realtime-kernel-ins) поэтому собираю 2.6.29.4-rt19
Путаница какая-то: в новости 2.6.29.4-rt18 - по ссылке в статье 2.6.29.4-rt17 а дает скачать только к 2.6.29.4-rt19...
Да и толку с этого ядра в hardy если все равно нету в репозиториях ubuntustudio под него модулей (restricted/ubuntu) - если кто/что знает на счет этого - подскажите, пожалуйста...
| | |
| |
| |
| 5.18, fidaj (ok), 15:34, 15/06/2009 [^] [^^] [^^^] [ответить]
| +/– | |
Да точно - про old я забыл и патчи к 2.6.29.4-rt18 именно там...Спасибо...
А по поводу сборок restricted/ubuntu modules для Ubuntustudio под ядро 2.6.29.4-rt18 кто-то что-то знает?
| | |
| |
| 6.23, fidaj (ok), 16:24, 15/06/2009 [^] [^^] [^^^] [ответить]
| +/– |
Вот досада... Хоть бери и подменяй версию на 2.6.24-24-rt что бы модули собрать, а то под то ядро, что в новости, нету исходников restricted/ubuntu modules в репозиториях...
| | |
| |
| 7.24, vitek (??), 16:48, 15/06/2009 [^] [^^] [^^^] [ответить] | +1 +/– | вообще-то стабильная бубунта jaunty идет с 28 ведром aptitude show linux-res... большой текст свёрнут, показать | | |
| |
| 8.26, fidaj (ok), 16:52, 15/06/2009 [^] [^^] [^^^] [ответить] | –1 +/– | под 2 6 28 я знаю мне оно не нужно И как я уже писал ранее - в 2 6 28 нет п... текст свёрнут, показать | | |
| |
| 9.29, vitek (??), 17:12, 15/06/2009 [^] [^^] [^^^] [ответить] | +/– | так зачем Вам restricted-modules я ж вроде там много выше накатал, весь список ... текст свёрнут, показать | | |
| |
| 10.30, fidaj (ok), 17:17, 15/06/2009 [^] [^^] [^^^] [ответить] | +/– | Помоему Вы правы - скорее мне нужны ubuntu-modules - без них web-cam не стартова... текст свёрнут, показать | | |
|
|
|
|
|
|
| 4.51, fidaj (ok), 23:11, 14/07/2009 [^] [^^] [^^^] [ответить] | +/– | Сам спросил - сам отвечаю Ничего толкового не нашел по этому поводу, поэтом... большой текст свёрнут, показать | | |
| |
| 5.52, fidaj (ok), 00:52, 15/07/2009 [^] [^^] [^^^] [ответить]
| +/– |
Забыл добавить - при конфигурировании нужно включить опции CONFIG_HZ_1000=y CONFIG_HZ=1000
| | |
|
|
|
|
| 1.12, anonim (?), 13:54, 15/06/2009 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Как я понял эти патчи к ядру не дают жёсткий реалтайм. Они просто делают ядро full preemptive и всё.
| | |
| |
| 2.21, Ariel (??), 16:11, 15/06/2009 [^] [^^] [^^^] [ответить]
| +/– |
Для жесткого реалтайма есть специализированные ОС: QNX, Windows CE, некоторые свободные даже. Что касается soft-realtime - его давно обеспечивает Darwin.
| | |
| |
| |
| 4.34, FHunter (?), 21:17, 15/06/2009 [^] [^^] [^^^] [ответить]
| +3 +/– |
Реалтайм в первую очередь набор механизмов ОС, позволяющее гарантировать время реакции в заданный промежуток времени. Пока лучшего определения я не встречал. Как следствие имеем предсказуемость системы для заранее известного набора задач на заданном оборудовании.
Т.е. в самой структуре ОС должны быть эти самые механизмы. Ушла ОС писать в свап и этот системный вызов не вытесняется - тогда РТ становится величиной вероятностной, или иногда называют софтРТ ("мягкое реальное время"). Понятно, что софтРТ и не РТ вовсе. Но кто-то считает иначе и условно выделяет такой класс ОС.
Таким образом, если вы гарантируете что реакция системы на событие будет не больше года, то ваша система уже реалтайм... Никаких цифр в определении РТ и в помине нет и не будет.
К чему я все это. ВинСЕ имеет механизмы, гарантирующие время реакции. Большее сказать про эту систему трудно. Как мне сказал "специалист" (с вашего позволения назову его так) на выставке презентовав диск с ВинСЕ: "Она настолько РТ, насколько Вы ее настроите". Вот и получается, что вроде время реакции гарантированно не более 50 мс, но с QNX 10 мкс ни в какое сравнение не идет. Да РТ, но такое РТ вроде и нахрен не нужен.
По теме. Попадался мне как-то отчет dedicated systems... разработчикам 2.6 еще много пилить до показателей коммерческих РТОС :(
| | |
|
| 3.33, аноним (?), 21:10, 15/06/2009 [^] [^^] [^^^] [ответить]
| +/– |
Жсткий реалтайм на писюке вообще не осуществим многозадачный, 1 жёсткий, а остальные софт возможно
| | |
|
| 2.39, User294 (ok), 23:39, 15/06/2009 [^] [^^] [^^^] [ответить]
| –2 +/– | |
>Как я понял эти патчи к ядру не дают жёсткий реалтайм.
А что есть жесткий реалтайм в ВАШЕМ понимании?А то например с такими конвеерами и кешами которые у х86 отрощены какие-то определенные времена реакции загарантировать довольно трудно если интересуют времена сравнимые с частотой такта проца а время на педалинг одних и тех же команд может быть "немного" разным - если cache hit, время одно, а если miss - более другое - пока там системная оператива раздуплится, ага... ;).И контроллеры прерываний у х86 та еще хрень.Если нужно быстро и гарантировано дергаться на событие - мелкий "таракан" с фирмваре вылизанным до тактов (которые для простых процессорных ядер даже реально посчитать для worst case) всяко сделает по времени реакции (и его неопределенности) любой qnx и что там еще на х86 уродце...
| | |
|
| 1.19, Muapvois (?), 16:06, 15/06/2009 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Довольно давно сижу на rt ветке из-за аудио приложений. Проблемы со стабильностью были несколько лет назад, сейчас без нареканий работает, даже драйвер nvidia под него собирается. Nvidia + firewire-звук (ffado) у меня вообще только на rt-ядре нормально заработал, иначе ffado вылетает при использовании opengl.
| | |
| |
| |
| 3.22, Muapvois (?), 16:12, 15/06/2009 [^] [^^] [^^^] [ответить]
| +/– |
Fedora (сейчас 10) + репозиторий Planet CCRMA, rt-ядро сейчас оттуда, раньше сам собирал.
| | |
|
| |
| 3.28, Muapvois (?), 17:03, 15/06/2009 [^] [^^] [^^^] [ответить]
| +1 +/– | |
> Как вы думаете, почему так?
В смысле, откуда проблемы с firewire и nvidia? Подозреваю, что драйвер nvidia где-то слишком задерживает обработку прерываний и ffado не успевает вовремя передать данные. В rt ядре обработчики прерываний "threaded", поэтому проблемы нет. Но это только догадки.
| | |
|
|
| 1.31, Аноним (-), 18:17, 15/06/2009 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
>удалось значительно уменьшить максимальное гарантированное время реакции: серия стресс-тестов продемонстрировала уменьшение средней задержки с 7 до 2 микросекунд, а максимальной задержки с 290 до 17 микросекунд.
Не плохо было бы еще и оборудование писать, на котором стресс-тесты проводились...
| | |
| 1.41, belkin (ok), 11:49, 16/06/2009 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
Детский сад продолжается ...
Во-первых, "мягкий RT" это "в большинстве случаев успевает" т.е. выдаём желаемое за действительное, маркетинговая лапша на уши.
Во-вторых, они ядро сильно перебрали, убрав блокировки и добавив инверсию приоритетов т.е. улучшили, но сломали совместимость с модулями. Это параллельная разработка, которую они сами будут пилить до тех пор, пока и если это "мягкое" просто не сделают основным.
Приложения для RT OS должны уметь пользоваться ею т.е. их тоже надо переписывать.
Итоговый вопрос: что здесь есть в этом кроме фанатизма и торговой марки Linux?
| | |
| |
| 2.43, Muapvois (?), 13:40, 16/06/2009 [^] [^^] [^^^] [ответить]
| +1 +/– |
Дело в том, что этими патчами люди пользуются и находят их полезными (не стал бы называть форком, т.к. оно все время синхронизируется с основной веткой ядра, а не идет своей дорогой). Я не знаю, насколько оно применимо там, где требуется жесткий RT, но для звукодельни это абсолютно то, что нужно, и во всех дистрибутивах, ориентированных на работу со звуком, именно такое ядро.
| | |
| 2.44, Anany (?), 14:19, 16/06/2009 [^] [^^] [^^^] [ответить]
| +1 +/– |
Ну например легкий перевод на реалтайм встроенных устройств, до этого успешно работающих (уже) под никсами.
Плюс увеличение отзывчивости ОС как таковой.
Фанатизма нету и в помине, разве что вот в вашем посте немного.
| | |
| |
| 3.45, belkin (ok), 16:17, 16/06/2009 [^] [^^] [^^^] [ответить]
| +/– |
>Ну например легкий перевод на реалтайм встроенных устройств, до этого успешно работающих
>(уже) под никсами.
>Плюс увеличение отзывчивости ОС как таковой.
>Фанатизма нету и в помине, разве что вот в вашем посте немного.
>
Не будет там Real-Time, я написал выше почему. Что касается "никсов", то в POSIX есть расширения для Real-Time. И оно уже кое-где реализовано, в QNX, например. А притягивать за уши Linux туда это по-детски или по-хитропопокоммерсантски. Либо вы ядро и приложения переделываете, как нужно для этого, или тогда не надо называть Real-Time, да ещё с этой адвокатской приставкой-оправдалкой "Soft". Обман в деталях.
Вон уже в прессе во всю глотку орут "теперь Linux ещё и Real-Time". А копнуть кто эту рекламную компанию запустил, так сразу видно - коммерсанты. Они теперь будут это "чудо" впаривать за дёшево, вытесняя настоящие RT-системы. В результате опять всё движется к полной победе копроэкономики. Задумаешь что-нибудь надёжное сделать, а везде RT Linux, потому что дёшево.
| | |
| |
| 4.46, pavlinux (ok), 02:24, 17/06/2009 [^] [^^] [^^^] [ответить]
| –1 +/– |
> Либо вы ядро и приложения переделываете, как нужно для этого
>, или тогда не надо называть Real-Time, да ещё с этой
Чё тормозишь.
Разговор идет про Linux, Linux - это то что валяется в http://www.kernel.org/pub/linux/kernel/ остальное довесок.
В отличии от Вас, тут собрались не дятлы, и все знают, что для реализации RT нужно всё - и ядро и драйвера и приложения....
И вообще, кроме Вас тут никто не орёт...
| | |
| 4.47, Сергей (??), 19:21, 17/06/2009 [^] [^^] [^^^] [ответить]
| +/– |
 >Не будет там Real-Time, я написал выше почему. Что касается "никсов", то
>в POSIX есть расширения для Real-Time. И оно уже кое-где реализовано,
>в QNX, например. А притягивать за уши Linux туда это по-детски
>или по-хитропопокоммерсантски. Либо вы ядро и приложения переделываете, как нужно для
>этого, или тогда не надо называть Real-Time, да ещё с этой
>адвокатской приставкой-оправдалкой "Soft". Обман в деталях.
Глупости говорите. Soft Real-Time - это система, которая гаранирует выполнение заданной задачи в ЗАДАННЫЙ ИНТЕРВАЛ ВРЕМЕНИ с ЗАДАННОЙ ВЕРОЯТНОСТЬЮ. В hard Real-Time это вероятность должна быть равна 1.0
При этом при исследовании этой системы строится зависимость вероятности от временного интервала. Именно таким образом решается насколька эта система реального времени хороша или плоха по сравнению с другими...
Свестульками и перделками это кажется только вам.
| | |
| |
| 5.48, anonimous (?), 03:01, 19/06/2009 [^] [^^] [^^^] [ответить]
| +/– | |
> В hard Real-Time это вероятность должна быть равна 1.0
Но в военное время и до 2 доходит.
| | |
| 5.49, pavlinux (ok), 03:41, 19/06/2009 [^] [^^] [^^^] [ответить]
| +/– |
>[оверквотинг удален]
>>этого, или тогда не надо называть Real-Time, да ещё с этой
>>адвокатской приставкой-оправдалкой "Soft". Обман в деталях.
>
>Глупости говорите. Soft Real-Time - это система, которая гарнирует выполнение заданной
>задачи в ЗАДАННЫЙ ИНТЕРВАЛ ВРЕМЕНИ с ЗАДАННОЙ ВЕРОЯТНОСТЬЮ. В hard Real-Time
>это вероятность должна быть равна 1.0
>
>При этом при исследовании этой системы строится зависимость вероятности от временного интервала.
>Именно таким образом решается насколько эта система реального времени хороша или
>плоха по сравнению с другими...
По-вашему получается, что любая ОС, имеющая, в заданном временном интервале,
вероятность гарантированного выполнение заданной задачи равную единицы - есть RTOS ? :)
Например ОS объявили HRTOS, реакция 30 мс +/- 3мс,
в течении 1 дня, она выполняла задачи за 30мс +/- 2.8, после её начало плющить,
и срабатывала через 30 +/- 3.1мс, потом опять за -/+ 3 мс, на 4-й день за +/-4 мс
Так что, насчёт единицы это вы зря, я б ограничился вероятность 0.999-0.997%
| | |
| |
| 6.50, Tav (?), 17:17, 20/06/2009 [^] [^^] [^^^] [ответить]
| +/– |
Ну так получим реакцию в интервале 30±4 мс с вероятностью 1.0, так и надо было объявлять.
| | |
|
|
|
|
|
|
