| 1.1, Аноним (1), 22:50, 22/03/2008 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
 не совсем понятно, зачем это надо?
Linux уже научился показывать лучшее реальное время нежели традиционные продукты этого сегмента?
или это надо исключительно для разработки ?
| | |
| 1.2, guest (??), 23:33, 22/03/2008 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Совсем не понятно что такое "лучшее реальное время" - гимп рисует лучший красный цвет чем фотожоп?
| | |
| |
| 2.3, pavlinux (ok), 02:16, 23/03/2008 [^] [^^] [^^^] [ответить]
| +/– |
 Лучшее - это когда ГИМП всегда будет зарисовывать, скажем квадрат 500х500 pix,
на CPU в 2GHz за 0.0012153 сек. и затратив на это 2.4306*10^6 тактов.
ЗАМЕЧУ - ВСЕГДА за 0.0012153 сек, а не как Фотошоп - по настроению Windows.
| | |
| |
| 3.4, pavlinux (ok), 02:23, 23/03/2008 [^] [^^] [^^^] [ответить]
| +/– |
Для того, чтоб прочувствовали - скажите 100 раз - "ОПЕРАЦИОННАЯ СИСТЕМА РЕАЛЬНОГО ВРЕМЕНИ",
за столько же времени, за сколько сказали в первый раз.
Что!?! В мозгах кэшируется, а язык-то заплетается?! :)
| | |
| 3.6, Сергей (??), 02:39, 23/03/2008 [^] [^^] [^^^] [ответить]
| +/– |
Пример не тот, у RTOS немного другие задачи :) Как пример, это когда на производстве одновременно приходит 100 сигналов от датчиков и все они должны быть обработаны в строго ограниченные временные рамки (рамики все таки есть), но не более порогового значения.
| | |
| |
| 4.7, pavlinux (ok), 02:50, 23/03/2008 [^] [^^] [^^^] [ответить]
| +/– |
>Пример не тот, у RTOS немного другие задачи :) Как пример, это
>когда на производстве одновременно приходит 100 сигналов от датчиков и все
>они должны быть обработаны в строго ограниченные временные рамки (рамики все
>таки есть), но не более порогового значения.
Но все создатели RTOS только об этом и мечтают...
| | |
| 4.13, Logo (ok), 16:26, 23/03/2008 [^] [^^] [^^^] [ответить]
| +/– |
Немного не так.
В ОС реального времени каждая обработка должна выполняться в строго заданое время. В Linux хоть и меньше латентность, но нет никакой гарантии, что требуемая операция будет выполнена в строго заданое время. В реальных задачах в системах не реального времени (Linux и т.д.), приходится расчитывать так опрос, например датчика, чтобы он начинался гарантировано раньше поступления с него данных, при этом процесс ожидает прихода данных. После получения данных идет уже обработка. Вот и получается, что более короткую латентность и процессорное время тратят на ожидание и переключение между процесами. В РТОС все заранее просчитывается и для получения адекватного результата нужно меньшую частоту процессора и все вытекающие из этого последствия.
Офисные приложения, фотошопы и т.п. не требуют реально времени выполнения, это не те цели.
| | |
|
|
| 2.5, Аноним (1), 02:33, 23/03/2008 [^] [^^] [^^^] [ответить]
| +/– |
лучшее в данном контексте - меньшее.
то есть при прочих равных Linux должен показывать большую скорость реакции и меньшую латентность по сравнению с VxWorks или QNX
а сравнивать RT с цветом по-моему не вполне профессионально, или это у вас стеб такой?
| | |
| |
| 3.8, Konwin (ok), 11:25, 23/03/2008 [^] [^^] [^^^] [ответить]
| +/– |
 До QNX ему как пешком до африки... Я думаю это всё всё-таки для разработки делается.
| | |
| 3.15, guest (??), 01:05, 24/03/2008 [^] [^^] [^^^] [ответить]
| +/– | |
> ... или это у вас стеб такой?
Дошло?! А то я уж боялся что у тебя как у павлина чувство юмора в нокауте...
"Реальное время" оно либо есть (будь то жёсткое или мягкое), либо нет. И со "скоростью реакции", "латентностью" и прочим оно соотноситься как с цветом - это перпендикулярные понятия. Так же как и красный цвет в графическом редакторе - нельзя нарисовать "лучший" просто потому, что его либо можно нарисовать, либо нет: оно не бывает лучше\хуже.
| | |
| |
| 4.19, Аноним (1), 01:29, 25/03/2008 [^] [^^] [^^^] [ответить]
| +/– | |
>"Реальное время" оно либо есть (будь то жёсткое или мягкое), либо нет.
Не вполне согласен - "мягкое" РВ - это фактически отсутсвие РВ.
РВ вполне измеряемо, и если гарантированное время реакции в VxWorks допустим 10 мс, а в Linux 30, то очевидно, что VxWorks по этому параметру лучше.
Собственно именно это я и имел ввиду, когда говорил о лучшем РВ.
| | |
|
|
|
| 1.10, ZANSWER (??), 12:26, 23/03/2008 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
 Зато быдло-менеджеры из Novell уже дистр продают, SLES RT, хотя там лишь жалкий soft real time, но зато, как звучит, Real Time Linux, ура мелкомяхким половым связям, они зделали своё дело с Novell!!!*MRAK*
| | |
| |
| 2.11, Konwin (ok), 14:07, 23/03/2008 [^] [^^] [^^^] [ответить]
| +/– |
>Зато быдло-менеджеры из Novell уже дистр продают, SLES RT, хотя там лишь
>жалкий soft real time, но зато, как звучит, Real Time Linux,
>ура мелкомяхким половым связям, они зделали своё дело с Novell!!!*MRAK*
А что вас так злит? Люди зарабатывают деньги, видимо кого-то это решение устраивает по своим возможностям.
| | |
|
| 1.12, ZANSWER (??), 14:37, 23/03/2008 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
> А что вас так злит? Люди зарабатывают деньги, видимо кого-то это решение устраивает по своим возможностям.
Меня это не злит вовсе, мне то что от этого, пусть зарабатывают, естественно это кого-то устраивает, лижбы это в целом GNU движению не мешало, я имею ввиду их половые связи с мелкомяхкими...:)
| | |
| |
| 2.14, linked (?), 00:14, 24/03/2008 [^] [^^] [^^^] [ответить]
| +/– |
А что, были замечены негативные последствия этих связей? Все только на пользу.
| | |
|
| 1.16, Alex (??), 10:07, 24/03/2008 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Вряд ли тот кто десятилетиями разрабатывал систему под VxWorks реально захочет все переписывать с нуля телько для того, чтобы перенести свой продукт на Linux. Для масштабных проектов всегда требуется время. Одним из примеров является Nortel - большинство их PABX (включая IP тел. станции) работаеют по VxWorks.
| | |
| |
| 2.17, Logo (ok), 15:21, 24/03/2008 [^] [^^] [^^^] [ответить]
| +/– |
А смысл то в чем переносить? Это нужно, как среда разработки для новых проектов, хотя сомнительно, что удастся создать полную эмуляцию (личное мнение).
| | |
|
| 1.18, alex (??), 22:12, 24/03/2008 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Ну мож хоть видео можно будет 99.9% заставить без рывков и артефактов всяких показывать. А то софтверные проигрыватели сливают в этом плане всяким dvd пепельницам
| | |
| |
| 2.20, Konwin (ok), 10:00, 25/03/2008 [^] [^^] [^^^] [ответить]
| +/– |
>Ну мож хоть видео можно будет 99.9% заставить без рывков и артефактов
>всяких показывать. А то софтверные проигрыватели сливают в этом плане всяким
>dvd пепельницам
Софт против аппаратно реализованного кодека всё равно не канает.... Купите видюху поприличнее - не будет ничего логать - у меня в VLC на х800 HDTV почти не лагает.
| | |
|
| 1.21, Алекс (??), 23:28, 25/03/2008 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
А вот как раз и интересует полный реал тайм, когда ЦПУ только и занят потоком видео. В общем то грамотно написанный и использующий SSE3 алгоритм может с точностью до герца расчитать требуемую частоту процессара, учитывая конечно же и архитектуру системы в целом...
Другое дело, что HDTV проприетарщина :(
| | |
|
