| 1.2, User294 (ok), 23:50, 11/03/2010 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– | |
Павлин в роли Капитана Очевидности :). А что, разве не логично что или число потоков команд равно числу ядер, или всяко придется отнимать у кого-то процессорное время в пользу кого-то иного?! Ну или как вариант - если этого не делать, получится что-то типа DOS :).А под реальным временем обычно имеют в виду предсказуемое время реакции системы. Дергание от 17 до 37 микросекунд - не больно то предсказуемо, а?
ЗЫЖ а настоящий реалтайм - что-то типа http://habrahabr.ru/blogs/DIY/87034/ - вот это да, реальное время во всех смыслах этого слова :)
| | |
| |
| 2.4, zhus (ok), 00:29, 12/03/2010 [^] [^^] [^^^] [ответить]
| +1 +/– |
> А под реальным временем обычно имеют в виду предсказуемое время реакции системы.
> Дергание от 17 до 37 микросекунд - не больно то предсказуемо, а?
Я, может, ошибаюсь, но rt это не предсказуемое, а гарантированое время отклика. Если мне гарантируют <=37us, я капризничать не буду :)
ps. Вы знаете, в мире так мало _действительно_ очевидных вещей...
pps. Если они вообще есть...
| | |
| |
| |
| 4.8, pavlinux (ok), 01:14, 12/03/2010 [^] [^^] [^^^] [ответить]
| +1 +/– |
Разброс зависит от интенсивности аппаратных прерываний работающих на каком-либо ядре.
Тут, наверно, на ядре №2 работала видюшка или диск, а может сеть.
У меня, например, вот такой хит-парад прерываний.
21: 9727673 eth0
22: 2374504 sata_nv
23: 2519178 sata_nv
58: 742751 nvidia
eth0 висит как раз на 3-ем ядре.
Так что, думается, до Труъ реалтайма надо 16 ядер только на устройства,
а вот на остальные можно и процессы разбрасывать.
---
Интересно, если на IBM Roadrunner, запустить 264000 процессов,
задача которых принимать сообщение и передавать соседу...
Раскидать эти процессы, каждый на отдельные ядро, и устроить "перекличку"
"- Первый - передал, Второй - принял, второй - передал, Третий - принял, третий - передал, ..... "
За сколько время write(fd, 'Hello world!', 12); дойдёт до 264000 проца? %-)
| | |
| |
| 5.12, User294 (ok), 04:43, 12/03/2010 [^] [^^] [^^^] [ответить]
| +/– | |
>Так что, думается, до Труъ реалтайма надо 16 ядер только на устройства,
Эээ а что, несколько прерываний на 1 ядро загнать - не копенгаген? А то одноядерники их все обслуживают, и ничего, живые. Благо у большей части железок есть буфера и им не надо обслуживание сей момент на каждый пшик. Собссно персональное ядро прерыванию надо только если оно грузит проц на 100% (что как-то не частое явление природы).
| | |
| |
| 6.15, Аноним (-), 09:28, 12/03/2010 [^] [^^] [^^^] [ответить]
| –1 +/– |
IMHO, с прерываниями на РС история вообще прикольная.
Сначала было все нормально - в системе есть 7 (15) прерываний, каждому устройству по одному (хотя бы из первых 7).
Потом оказалось, что для некоей широко распространенной ОС слишком сложно выбирать РАЗЛИЧНЫЕ прерывания - и почти все устройства, кроме контроллеров PATA и иногда видеоадаптера, повисли на одном прерывании...
Понятно, что правильный обработчик прерывания состоит более чем из одной части и как-то оптимизирован под быстрое исполнение своей первой части, но это с точки зрения гарантированного времени отклика ухудшение ситуации...
| | |
|
|
|
| 3.13, User294 (ok), 04:48, 12/03/2010 [^] [^^] [^^^] [ответить]
| +/– | |
>Я, может, ошибаюсь, но rt это не предсказуемое, а гарантированое время отклика.
Само по себе реальное время - это реальное время, оно не ждет и оно непрерывно. Чем точнее с ним оперируют, тем лучше. А точность - это минимальное время реакции и предсказуемость этого времени (при том если оно колеблется, уповать можно только на максимум, а закладываться на то что будет меньше - не выйдет, т.к. иначе будет иногда не успеваться что-то, а это фэйл уже...). В самом суровом случае реалтайм - это считанные такты процессора до реакции на событие, зачастую всегда одинаковое их количество. А то я могу гарантировать что даже в обычном ядре время отклика будет не хуже минуты и скорее всего - не совру. Вот только реалтаймом это назвать... кхм... "и пусть весь мир подождет"? А что, время гарантированное. А хотя-бы и довольно большое :)
| | |
| |
| 4.23, anonymous (??), 16:50, 12/03/2010 [^] [^^] [^^^] [ответить]
| +/– |
>А то я могу гарантировать что даже в обычном ядре время отклика будет не хуже минуты и скорее всего - не совру
>скорее всего - не совру
Соображаешь, оговорку то оставил :)
В обычном ядре полно мест с алгоритмами типа того "ну это событие редкое, и скорее всего данные будут в кэше, а если не будут - ну это почти невозможно". Зато текста меньше и в быдлобенчмарках впереди всех.
Но курс линукс на интеграцию RT патчей в основную ветку, так что нас ждет светлое будущее.
| | |
| 4.28, anonymous vulgaris (?), 06:45, 13/03/2010 [^] [^^] [^^^] [ответить]
| +/– |
>Вот только реалтаймом это назвать... кхм... "и пусть весь мир подождет"?
Вообще в абсолютных числах РВ системы обычно медленнее, чем не РВ. А быстрая ОС это ДОС.
Я вот другого не понимаю
>при условии, что количество задач не превышает количество ядер процессора
Как вот это сделать если в пустой системе ее собственных потоков уже до фига. Обычно ядро выделяют РВ процессу, это понятно. Ну а остальным остальные ядра. Но чтоб количество задач не превышало количество ядер процессора это в нынешних ос пока не бывает.
| | |
|
|
|
| 1.3, scrat (?), 00:25, 12/03/2010 [ответить] [﹢﹢﹢] [ · · · ]
| –8 +/– |
далеко не только linux. Mac OS вполне себе параллелит вычисления, да ещё и на два процессора с помощью IPI.
| | |
| |
| 2.7, pavlinux (ok), 01:04, 12/03/2010 [^] [^^] [^^^] [ответить]
| +2 +/– | |
Ага, щаз... и все с гарантированным временем отклика.
IPI/MPI/OpenMP это не то... это (a + b) * (с + d), (a + b) - на одно ядро, (с + d) на второе,
умножать на последнем освободившемся.
Вот как раз в этих MPI-фреймворках ядро выбирается почти хаотически, а реалтайм любит определённость.
| | |
|
| 1.9, Дмитрий Ю. Карпов (?), 02:06, 12/03/2010 [ответить] [﹢﹢﹢] [ · · · ]
| –4 +/– | |
> На однопроцессорной сиcтеме, в режиме реального времени может выполняться только одна задача. Остальные, хоть и имеют приоритет реального времени, всё равно ожидают своей очереди к процессору.
Начнём с того, что понятие "приоритет реального времени" существует только в больном мозгу людей, не различающих реалтаймовую и кооперативную многозадачность. У реалтаймовых задач нет приоритета - у них есть квоты на процессорное время.
| | |
| |
| 2.10, pavlinux (ok), 02:21, 12/03/2010 [^] [^^] [^^^] [ответить]
| +3 +/– |
Читай ещё 20 раз, затем повтори вслух. Если не въехал, я не виноват.
Теперь ткни пальцем в то место, где написано, что у задач с приоритетом реального времени есть приоритет?! :)
Про Очередь написано, а как она реализована я не написал. В оригинале есть.
Ах да, в системе, кроме Вашей реалтайм приблуды работает ещё туева хуча процессов,
которые отличаются от вашего, и это отличие называется приоритет.
Ну и в догонку, система не обязана быть вся реалтайм, для того чтобы процесс
работал в детерминированном режиме задержек. Наглядный пример в начале. :)
Всё дедули, кончилось ваше время, RT-Linux наступает.
Выкидывайте Ваши тома документации, методики программирования
под QNX /VXWorks/RSX-11/OS-9 и прочую макулатуру....
| | |
| |
| 3.26, linux_must_die (ok), 00:43, 13/03/2010 [^] [^^] [^^^] [ответить]
| +/– |
>>Выкидывайте Ваши тома документации, методики программирования
>>под QNX /VXWorks/RSX-11/OS-9 и прочую макулатуру...
те только линукс может развиваться а вся эта хрень не может?
| | |
| |
| 4.27, pavlinux (ok), 00:56, 13/03/2010 [^] [^^] [^^^] [ответить]
| +/– |
>>>Выкидывайте Ваши тома документации, методики программирования
>>>под QNX /VXWorks/RSX-11/OS-9 и прочую макулатуру...
>
>те только линукс может развиваться а вся эта хрень не может?
Битва - кучка разработчиков против всего мира?! :)
| | |
|
| 3.29, anonymous vulgaris (?), 07:47, 13/03/2010 [^] [^^] [^^^] [ответить]
| +/– | |
>Всё дедули, кончилось ваше время, RT-Linux наступает.
Так сертификатов нет, всяких там DO-178B, Common Criteria ISO/IEC 15408 Evaluation Assurance Level 4+ (EAL 4+). Т.е. никуда где бабки есть не поставишь.
>Ну и в догонку, система не обязана быть вся реалтайм, для того чтобы процесс
работал в детерминированном режиме задержек.
Ну вы и отожгли.
| | |
| |
| 4.30, pavlinux (ok), 12:32, 13/03/2010 [^] [^^] [^^^] [ответить]
| +/– |
>>Всё дедули, кончилось ваше время, RT-Linux наступает.
>
>Так сертификатов нет, всяких там DO-178B, Common Criteria ISO/IEC 15408 Evaluation
> Assurance Level 4+ (EAL 4+). Т.е. никуда где бабки есть не поставишь.
Увы. Но думается это дело времени.
У OSADL деньги есть, подать заявку на сертификацию смогут.
>
>>Ну и в догонку, система не обязана быть вся реалтайм, для того чтобы процесс
>>работал в детерминированном режиме задержек.
>
> Ну вы и отожгли.
Вот-вот, и вам кажется бредом, а вот так! :-P
| | |
| |
| |
| 6.35, pavlinux (ok), 19:32, 14/03/2010 [^] [^^] [^^^] [ответить]
| +/– |
>[оверквотинг удален]
>>
>>Вот-вот, и вам кажется бредом, а вот так! :-P
>
>В RT-Linux главное это РВ микроядро, ядро обычного линуха это просто не
>РВ задача для микроядра. В итоге система в целом РВ.
>
>http://ru.wikipedia.org/wiki/RTLinux
>http://info.krc.karelia.ru/Linux/rt/rtlinux.shtml
>
>Кстати он уже коммерциализован см. Wind River Real-Time Core
RTLinux != Патчи от Инго
Этот гадкий RTLinux, кроме как стабильно кидать байты RS232/RS485 не умеет.
Дистрибутив от "Ветренной Реки" это некий гибри Слаквари как системы
и K2 Linux как системы компиляции, кроме 3 сетевых драйверов, RT COM-портов
и урезанного TCP стека там них...я нет.
| | |
|
|
|
|
| 2.11, User294 (ok), 04:26, 12/03/2010 [^] [^^] [^^^] [ответить]
| +/– |
>времени" существует только в больном мозгу людей, не различающих реалтаймовую и
>кооперативную многозадачность.
Для начала, реальное время, строго говоря, непрерывное и если имеется многозадачность способная хотя-бы теоретически прервать "реалтаймный" процесс - реалтайм вообще становится некоей абстрактной условностью снабженной некими дополнительными оговорками, основательно поднимающими планку в сторону "и пусть весь мир подождет". А еще у x86 время выполнения кода не детерминированно (может быть cache hit, а может и не быть и разница при этом может быть очень велика, всякие там предсказания ветвлений и прочая). А реакция на события довольно тормозная - получить с х86 утюга сносный реалтайм (с минимальным временем реакции порядка нескольких тактов процессора, желательно за известное их число) в общем то не получится. В спиче павлина есть вполне здравый критерий - логично что время отклика реалтаймной задачи сильно портится если ее постоянно переключают. Поэтому реалтаймные процессы хорошо себя чувствуют если им дадено по сути персональное ядро. Тогда и время никто не отбирает, и кэши никто не отравит, etc. Логично что время реакции здорово улучшается. Сие как-то достаточно очевидно, за что я его КО и обозвал :)
>У реалтаймовых задач нет приоритета - у них есть квоты на процессорное время.
Строго говоря, если у задачи отобрали процессор - она отдыхает. По большому счету это уже не совсем реалтайм. Примерно как в 1-процессорной системе где в 1 момент времени выполняется 1 задача, многозадачность по сути некий фэйк (настоящая многозадачность - когда проц или процы молотят несколько параллельных потоков команд за 1 присест).
| | |
| |
| 3.17, const86 (ok), 10:56, 12/03/2010 [^] [^^] [^^^] [ответить]
| +/– | |
> А еще у x86 время выполнения кода не детерминированно (может быть cache hit, а может и не быть и разница при этом может быть очень велика, всякие там предсказания ветвлений и прочая).
Промах кеша может теоретически привести к неограниченному времени выполнения инструкции? Как уже выше сказали, RT - это не скорость, а гарантия. Считайте, что у проца нет кеша (вроде, его даже выключить можно?) и будет вам гарантия.
| | |
| |
| 4.20, User294 (ok), 11:51, 12/03/2010 [^] [^^] [^^^] [ответить]
| +/– | |
> Промах кеша может теоретически привести к неограниченному времени выполнения инструкции?
Без специальных мер - в принципе может.
Cache miss -> сунулись в оперативку -> оказалось что оно выгружено в своп -> полезли в своп. А это уже надолго. С этим можно бороться, ессно.
> и будет вам гарантия.
Дык будет гарантися, но, гм, реалтайм основательно сместится в сторону "пусть весь мир подождет". Скажем у моего асуса есть вачдог. И если система не ответила за (IIRC) 5 минут - происходит ребут без суда и следствия. Гарантия? Да, разумеется. Реалтайм? Ха-ха, с интервалом гарантии в 5 минут - это реалтайм? Ну или где та грань до которой - реалтайм, а после - не реалтайм? :)
| | |
| |
| 5.21, uZver (??), 12:41, 12/03/2010 [^] [^^] [^^^] [ответить]
| +/– |
>
>Без специальных мер - в принципе может.
>Cache miss -> сунулись в оперативку -> оказалось что оно выгружено в своп -> полезли в своп. А это уже надолго. С этим можно бороться, ессно.
>
А что real-time процессы могут вытесняться в своп? мне казалось что для таких процессов своп принудительно отключен =)
| | |
| |
| 6.38, User294 (ok), 23:49, 14/03/2010 [^] [^^] [^^^] [ответить]
| +/– |
>А что real-time процессы могут вытесняться в своп? мне казалось что для
>таких процессов своп принудительно отключен =)
Эээ а как реалтаймность затрагивает управление памятью? Я думал, она затрагивает только шедулинг процессорного времени. А память и то что она виртуальная - по идее отдельная сущность.
А так - как минимум павлин тут приводил пример как этого избежать. Ну и своп можно отключить, если что.
| | |
|
|
|
|
|
| 1.19, pro100master (ok), 11:23, 12/03/2010 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
забавный тест. Им потребовалось 17-34к процессорных тактов. Таким образом ядро линукса у них обогнало само себя :)))
| | |
| 1.22, Alex (??), 16:18, 12/03/2010 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
 17-37 мк - слишком долго. Можно использоать только для /var/log.
Даже управление группой контроллеров должно идти с тактом 5 -10 мк.
Для робота со скоростью 1 м/сек от 5 датчиков может и будет успевать.
| | |
| |
| 2.25, pavlinux (ok), 22:08, 12/03/2010 [^] [^^] [^^^] [ответить]
| +/– |
>17-37 мк - слишком долго. Можно использоать только для /var/log.
>Даже управление группой контроллеров должно идти с тактом 5 -10 мк.
>Для робота со скоростью 1 м/сек
Уверены, что за 17*10-6 сек. контроллер успеет накачать катушку индукцией
и набрать магн. момент, дабы преодолеть нагрузку на робота повешенную?
| | |
| |
| 3.39, User294 (ok), 23:54, 14/03/2010 [^] [^^] [^^^] [ответить]
| +/– |
>Уверены, что за 17*10-6 сек. контроллер успеет накачать катушку индукцией
>и набрать магн. момент, дабы преодолеть нагрузку на робота повешенную?
Павлин, если уж хочется до усрачки релтайма, микроконтроллером можно и 40 наносекунд(!!!) отмерять. Пруфлинка - там где про взлом гипервизора PS3. Чувак реально умудрился отмерять 40 нс микроконтроллером вместо PLDхи. Заметь, не 50 и не 30. Вот это да, реалтайм. Ы?
| | |
| |
| 4.41, pavlinux (ok), 01:52, 15/03/2010 [^] [^^] [^^^] [ответить]
| +/– |
>>Уверены, что за 17*10-6 сек. контроллер успеет накачать катушку индукцией
>>и набрать магн. момент, дабы преодолеть нагрузку на робота повешенную?
>
>Павлин, если уж хочется до усрачки релтайма, микроконтроллером можно и 40 наносекунд(!!!)
>отмерять. Пруфлинка - там где про взлом гипервизора PS3. Чувак реально
>умудрился отмерять 40 нс микроконтроллером вместо PLDхи. Заметь, не 50 и
>не 30. Вот это да, реалтайм. Ы?
Там PowerPC, там легче.
Давай линк!
| | |
| |
| 5.45, User294 (ok), 08:54, 16/03/2010 [^] [^^] [^^^] [ответить]
| +/– | |
>Там PowerPC, там легче.
Ага, проще просто некуда: если не ошибаюсь, там всего-то скоростная рамбусовская шина, работающая с немеряной скоростью. Там летают всего-то какие-то жалкие гигабайты в секунду. А на ней еще и надо данные исказить. Не абы как, а вполне осмысленным образом. Иначе - хрен тебе, а не режим гипервизора. Чувак перетягивает уровень на шине в 1 разряде оной на 40 нс (видимо, 1 период шины), вызывая неверное чтение 1 бита. Этого достаточно для апгрейда прав. Исходно сие было сделано на FPGA-чипе, но повторявший эксперимент фрукт изгальнулся сделать ту же 40-наносекундную просадку и на микроконтроллере.
>Давай линк!
Пожалста - http://rdist.root.org/2010/02/08/ps3-hypervisor-exploit-reproduced/
Чувак слабал 40-наносекундную приблуду на быстром микроконтроллере (Parallax - они достаточно забавные и необычные камни, в общем то).
| | |
|
|
|
|
| 1.24, Аноним (-), 21:33, 12/03/2010 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
реалтиме алгоритмы как правило просты и вписаться в 15 мксек вполне реально даже на древнем железе, чтото непойму оппонентов. Нужна автоматика для истребителя берите инструмент под ТЗ. А для большинства автоматики rt-linux под линухом выше крыши.
| | |
| 1.33, Vasia (??), 10:07, 14/03/2010 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Здарова всем ! :-)
Я че то не пойму - процы до сих пор используют стандартно? То есть 64 бита шины данных, и их грузят одной задачей. Чудно.
А как бы уже создан проект opend называется как бы ! От придуман для того что бы немножко попользовать ГПУ-шные конвеера, если их на видяхе около 1600. Вот и паралельность, вот и многопоточность. Юзайте на здоровье :-)
| | |
| 1.34, Demo (??), 19:25, 14/03/2010 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
User, хватит гнать пургу. Просто смешно читать.
>Строго говоря, если у задачи отобрали процессор - она отдыхает.
>По большому счету это уже не совсем реалтайм.
Почитай, наконец, FAQ. Ладно, так и быть для тебя процитирую:
======
Каноничеcкое:
"Сиcтема pеального вpемени, та, в котоpой пpавильный pезyльтат
вычиcлений завиcит не только от пpавильноcти вычиcлений, а также от
вpемени, за котоpое бyдет полyчен pезyльтат вычиcлений. Еcли вpеменные
огpаничения не выполняютcя, cчитаетcя, что cлyчилcя cбой в cиcтеме."
Отcюда полyчаем, что вpеменные огpаничения в cиcтеме должны
гаpантиpованно выполнятьcя.
======
| | |
| |
| 2.36, pavlinux (ok), 19:56, 14/03/2010 [^] [^^] [^^^] [ответить]
| +/– |
Плахой ФАК, не читай больше..., про правильность вычислений вааааще не должно быть и слова.
Операционке на это как-то насрать (должно быть).
Не, конечно если вам приспичит на РТ-системе считать самое большое простое число, а из-за того,
что проц будет забит одним толстым циклом while ( x != y ) while ( n % x != 0) n++; x++;,
и система охлаждения яд. ректора не успеет добраться даже до планировщика, не то что бы сигнал выдать, то сами виноваты.
| | |
| 2.40, User294 (ok), 23:57, 14/03/2010 [^] [^^] [^^^] [ответить]
| +/– | |
>Почитай, наконец, FAQ. Ладно, так и быть для тебя процитирую:
Отлично. Если мой роутер не справляется за 5 минут с обслуживанием вачдога - это считается ошибкой и он огребает от вачдога ресет. Вот только там ядро не реалтаймное. И вообще - тормозной какой-то реалтайм получается. Но под ваш FAQ - вписывается на все 100%. Отсюда мораль: по такому FAQ вообще любая система - реалтаймная. Просто берем время гарантии в полдня и готово - реалтаймность налицо :)
| | |
| |
| 3.42, Alex__S (?), 03:01, 15/03/2010 [^] [^^] [^^^] [ответить]
| +/– |
>>Почитай, наконец, FAQ. Ладно, так и быть для тебя процитирую:
>
>Отлично. Если мой роутер не справляется за 5 минут с обслуживанием вачдога
>- это считается ошибкой и он огребает от вачдога ресет. Вот
>только там ядро не реалтаймное. И вообще - тормозной какой-то реалтайм
>получается. Но под ваш FAQ - вписывается на все 100%. Отсюда
>мораль: по такому FAQ вообще любая система - реалтаймная. Просто берем
>время гарантии в полдня и готово - реалтаймность налицо :)
если ты гарантируешь реакцию системы за полдня - при любых ситуациях и нагрузках - то да, система RT. Временной интервал тут неважен.
Вопрос применимости такой RT системы - уже другой вопрос.
| | |
| |
| 4.43, User294 (ok), 04:49, 15/03/2010 [^] [^^] [^^^] [ответить]
| +/– | |
> то да, система RT.
Ну если учесть что упомянутый роутер набирает аптайм в полгода, стало быть не превышая задержку вачдога в 5 минут - да, я гарантирую что за полдня его система уж тем более ответит. Стало быть не-реалтаймное ядро линукса - реалтаймная система! :D.
> Вопрос применимости такой RT системы - уже другой вопрос.
Вопросы границ формального маразма - вот это да, вопрос. Чем больше гарантируемое время - тем больше ОС в него впишется. С временем гарантий в полдня впишутся практически все мало-мальски вменяемые системы в мало-мальски вменяемых условиях эксплуатации.
| | |
|
|
|
| 1.37, Аноним (-), 21:14, 14/03/2010 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
На графике 8 "ядер"? HyperThreading и реалтайм - взамоисключающие моменты. Ибо тут привносятся задержки на аппаратном уровне.
| | |
| 1.46, andr.mobi (??), 21:47, 16/03/2010 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
Вот наиболее полный обзор ОСРВ на русском, несколько лет уже там висит
http://www.citforum.ru/operating_systems/rtos/
Вы там видите линукс?!
Вы понимаете, что линукс в принципе не может соответствовать ни одной из перечисленных в обзоре спецификаций ОСРВ в силу своей убогой устаревшей архитектуры и отсутствия специальных возможностей управления приоритетами, например инверсии приоритетов?
Вы понимаете, что искалеченные версии ядра линуса с поддержжкой realtime в десятки раз уступают по своим возможностям ОСРВ специальным, и обязаны своему появлению только крайней некомпетентностью в данном вопросе многочисленного молодого племени идолопоклонников тукса, которому лень тратить время на образование?
Вы вообще понимаете, что надо, не имея специального образования, как минимум прочитать пару-тройку общедоступных статей по теме, чтобы выносить мало-мальски грамотные суждения по теме? Это касается авторов статьи в первую очередь
> истинный параллелизм в режиме реального времени... поддерживает в настоящее
> время ... только Linux
Вы понимаете, что сморозили глупость?
| | |
| |
| 2.49, anonim (?), 14:01, 17/03/2010 [^] [^^] [^^^] [ответить]
| +/– |
сэр вы бы еще на лор сослались тоже ведь форум, пальцы подогните... во первых речь идет не о linux а rt-linux, который может жить без линукса и вполне сам себе posix rtos, а искалеченный линукс делается под специфические хотелки и ртосом является часто условно. рад за вас что прочитали пару-тройку общедоступных статей очень энтерпрайзно изложили. смотрю там даже rtems упомянули :) если будут аппаратные прерывания от железа rt-linux врядли уступит самым продвинутым, только эта область узкая и тут особо правит бабло, а rt-linux развивать некому
| | |
|
|
