Страниц: 1 ... 11 12 [13] 14
  Печать  
Автор Тема: Объясните ламеру, что такое ОС реального времени ?  (Прочитано 93275 раз)
olej
QOR.Team
****
Offline Offline

Сообщений: 42



Просмотр профиля
« Ответ #180 : Апреля 13, 2004, 01:08:30 pm »

Всё это становится неконструктивно...:

А эти раздолбаи пусть сначала научатся мобильники делать, чтоб не висли

Господин Калинский тот ещё чудак, но вторая статья не менее нелепа.

А чем же она "нелепа" - человек с большим опытом в АСУТП, и после многих обсуждений с коллегами, совсем людьми небезызвестными, разъехавшимися ныне по всем странам мира... так вот, в конце концов, приходит к подозрению, что нет такой сермяжной правды, как realtime OS... просто те, кто таковые производят, предполагая область использования и собственную степень ответственности - стараются делать тщательно сделанную OS, в отличии от производителей GPOS, которые таковой тщательностью не обременены.
Это - мнение (верное, неверное, спорное - не важно).

Я так же прекрасно понимаю, почему большинство "дискусий" ( так как-то это назвали где-то выше? ... но по моему это - "перебранки" ) не только в этой теме, а вообще в форуме - носят характер "от противного"

- при "негативном" изложении (и ты не прав, и ты ошибаешься и т.д.), когда нет нужды формулировать свою позицию, а только "раздолбать предыдущего оратора" - всё просто и эффективно: "... слоны - в говне, зрители - в говне, и тут выхожу я - в белом фраке..."(с).

- а вот с "позитивным" изложением - здесь практически у всех - туго... только признаваться в этом не хочется.

А вот мне, тоже с немалым опытом и разных realtime OS, всё таки ещё не понятно:

- так существуют такие вот принципиально отличные от GPOS - realtime OS ("найдите 5 отличий"(с) ... только не надо мне про "гарантированное время реакции" долдонить!)?

- а как относительно realtime целевых систем (проектов)? они "realtime" - имеют право квалифицироваться? и когда? а для них - наличие realtime платформы: актуально или не очень?

P.S. Наш форум даёт какой-то "удивительный" эффект, когда текст в " помещается в ()... - "... а вы не пробовали слабительное со снотворным? удивительный эффект получается!"(с) М.Жванецкий.
Записан
klalafuda
QOR.Team
****
Offline Offline

Сообщений: 1


Просмотр профиля
« Ответ #181 : Апреля 13, 2004, 02:03:21 pm »

---cut---
- так существуют такие вот принципиально отличные от GPOS - realtime OS ("найдите 5 отличий"(с) ... только не надо мне про "гарантированное время реакции" долдонить!)?
---cut---

не знаю как насчет подкрепленного списка фундаментальных различий, но какое-то время назад я делал небольшие тесты на механизм Send/Receive/Reply для QNX4.25.

основной процесс форкает пачку дочерних и обменивается с каждым из них заданным количеством сообщений. ну допустим 10^6. все крутится ессно в параллель. измеряется время прохождения теста и считается средяя пропускная способность системы навроде "количество сообщений в секунду".

на сей тест под 4-ку меня сподвигла буча, поднятая Игорем Коваленко из разряда "что криво в 6-ке" и все такое [было дело, тихо загнулось]. цель была сравнить результаты практически одинаковых тестов на QNX4 и QNX6. конечно, были какие-то расхождения и 4-ка на тот момент afair оказалать несколько быстрее, чем 6-ка [не знаю как сейчас]

но суть не в этом. какое-то время спустя, мне потребовалось нарисовать на базе BSD некую систему состоящую из ряда серверов, взаимодействующих друг с другом. с точки зрения QNX, нет ничего проще SRR в руки и вперед и с песней. тут-же дело несколько сложнее бо выбор с одной стороны больше (sockets, System V msg queue || shmem/semaphores etc), а с другой стороны, несколько тяжеловесен для простого SRR. ладно, в конце-концов остановился на UDS (Unix Domain Sockets).

дык вот что меня не совсем приятно удивило, это то, что аналогичный тест на пропускную способность обмена сообщениями через UDS на том-же железе показал разительно другие результаты.

если для QNX4 я получал где-то порядка 150..200 тысяч обменов в секунду, то для UDS на NetBSD я не смог получить больше 50..60. аналогичные тесты на FreeBSD принципиальных отличий не показали.

да, в случае с BSD scalability в принципе была выше и, если считать по переданному трафику, BSD afair была как минимум не хуже 4-ки, может и лучше, уже не помню. но количество обменов все равно было значительно ниже, чем для QNX.

в конечном итоге, я все равно остановился на UDS, бо особой пропускной способности мне не требовалось, но разницу я почувствовал что называется на яву.

ничего не скажу за realtime, но различие в архитектурах систем иногда очень даже чувствуется.

// wbr
Записан
olej
QOR.Team
****
Offline Offline

Сообщений: 42



Просмотр профиля
« Ответ #182 : Апреля 13, 2004, 04:13:53 pm »

... ничего не скажу за realtime, но различие в архитектурах систем иногда очень даже чувствуется.

Вот это - уже какие-то конкретные намётки "в тему", по крайней мере - повод присмотреться что оно к чему... таких вот наблюдений - побольше бы, спасибо...

Только вот это место я не понял:

да, в случае с BSD scalability в принципе была выше и, если считать по переданному трафику, BSD afair была как минимум не хуже 4-ки, может и лучше, уже не помню. но количество обменов все равно было значительно ниже, чем для QNX.

- подробнее можно растолковать, что оно было? "по трафику" - это как? трафик - это ведь производная, скорость... Как при меньшем числе сообщений получался выше трафик? - за счёт разной длины объёма сообщений?
Записан
klalafuda
QOR.Team
****
Offline Offline

Сообщений: 1


Просмотр профиля
« Ответ #183 : Апреля 13, 2004, 04:42:24 pm »

---cut---
- подробнее можно растолковать, что оно было? "по трафику" - это как? трафик - это ведь производная, скорость... Как при меньшем числе сообщений получался выше трафик? - за счёт разной длины объёма сообщений?
---cut---

ну обе измеряемых величины были производными

процесс A шлет процессу B сообщение длиной x байт (Send). процесс B ожидает сообщения (Receive) и по получению отсылает его обратно (Reply) с той же длиной x. далее, все повторяется по циклу до наступления какого-то заданного количества таких обменов. по желанию, количество процессов может увеличиваться для схемы типа "шлют много - один слушает/отвечает".

оба процесса запускаются со стандартными для данной системы пользовательскими приоритетами so никакой черной магии.

соотв. измеряются:

1) количество транзакций в секунду, которые мы может передать между процессом A и процессом B. транзакция являет собой закноченный цикл "послал-принял-ответил".

2) трафик - полный объем данных, который мы может передать в процессе обмена между обоими процессами. очевидно, равен количеству транзакций * x * 2.

для QNX4/6 на SRR я наблюдал ситуацию, когда количество транзакций в секунду было порядка 150..200 тысяч. при увеличении объема данных в сообщении количество транзакций падало где-то почти линейно. оптимаьный размер блока данных был где-то в районе 4Kb. пиковый трафик уже не помню.

для NetBSD/FreeBSD на UDS количество транзакций было значительно меньше, где-то порядка ~40..50 тысяч. зато к обьему данных, передаваемых в сообщении, эти системы относились заметно спокойнее - чем больше передаваемых данных тем лучше. причем, объем передаваемых данных слабо влиял на кол-во транзации (почти не влиял). оптимальный размер блока данных был где-то в районе 24..32kb. при этом размере блока я имел порядка 200Mb/s трафика.

// wbr
Записан
dip
Участник
*
Offline Offline

Сообщений: 49


eh?


Просмотр профиля
« Ответ #184 : Апреля 14, 2004, 06:10:44 am »

Olej
Всё это становится неконструктивно...:


Не вижу неконстуктивности в моём предложении рассмотреть требования к разным сегментам рынка и как архитектура меняется в зависимости от этих самых требований. Сравнить например скедулинг какой-нибудь серверной платформы и qnx.

Olej
А чем же она "нелепа" - человек с большим опытом в АСУТП, и после многих обсуждений с коллегами, совсем людьми небезызвестными, разъехавшимися ныне по всем странам мира...


Я не согласен с _мнением_ а не с кокретным человеком. И его заслуженность - простите, не аргумент.

Если я на минуточку залезу на мою асутпешную колокольню, то если бы сейчас писал SCADA не имея денег, то выбрал бы линух или BSD. По той простой причине что работать будет на писюке и особого реал-тайма не надо. Оставаясь на той же асутепешной колокольне, если бы делал PLC то это был бы QNX и не на писюке: не успели водород например вовремя перекрыть - получите взрыв, смешние водорода с кислородом в определённой пропорции взрывается сам по себе, без спичек... Есть асутп как мониторинг расхода тепла в городских котельных (тоже работа кстати важная) где секундой раньше секундой позже - не важно, а есть асутп управления установкой каталитического крекинга (нефтепереработка, стоимостью 100-200 млн долларов) не забалуешь, потому как рванёт влюбой момент (про пример с водородом смотреть выше). Вот вам разница в требованиях.

Если про телеком говорить, то есть такая штука например как protection switch. Это когда траффик перенаправляется с одного канала на другой (IP routing - это другой зверь). Преключение должно произойти _полностью_ за 50 ms. Я видел системы где это сделано частично на софте: оптичекий трансивер (девайс такой) потеряв сигнал (обрыв кабеля) дёргает прерывание. Если у вас interrupt latency высокое и не гарантированное (потому как ваша OS не была задезайнена для этого) то шансы что вы успеете переключиться за эти 50 ms не велики.

Возвращаясь к статье "...заметки на полях одной статьи": по-прежнему считаю что нелепо писать про RTOS исключив из рассмотрения VxWorks/Integrity/ThreadX etc. Если статья писалась "про то что знаем" то надо было честно сравнивать QNX и Linux/Windows/BSD. Чарльз Дарвин таскался на Галапогосские острова что бы написать Теорию Эволюции Видов, а тут Критику Теории Эволюции OS написали не выходя на балкон.
Записан
olej
QOR.Team
****
Offline Offline

Сообщений: 42



Просмотр профиля
« Ответ #185 : Апреля 14, 2004, 11:16:25 am »

Не вижу неконстуктивности в моём предложении рассмотреть требования к разным сегментам рынка и как архитектура меняется в зависимости от этих самых требований.

Ну, в первую очередь, давайте, если у нас глубоко техническое сравнение (если его хотелось бы иметь таким) - забудем всё, что связано с "рынком": стоимости, целесообразности, рекламные трюки...

Не станем нарушать одну из важнейших заповедей: "Не пускайте торговцев в Храм"(с), или (если так больше нравится): "Не нужно примешивать чувства к хорошему вину - вкус портится"(с) - О.Уайльд.

Сравнить например скедулинг какой-нибудь серверной платформы и qnx.

Давйте сравним , например.
Но у нас нет критерия, термина: realtime - что ему соответствует! Применительно к чему сравнивать будем?

Я не согласен с _мнением_ а не с кокретным человеком. И его заслуженность - простите, не аргумент.

А звслуженность здесь - и вовсе не при чём, оставим каждому его заслуженность... Я не об том писал, а об опыте: когда некто чем-то долго занимается - у него мысли приходят, бывает... И чем долбше - тем больше. И тогда (неприятности ) вещи, которые были абсолютно простыми и понятными, перестают быть такими вот совсем простыми...

Есть асутп как мониторинг расхода тепла в городских котельных (тоже работа кстати важная) где секундой раньше секундой позже - не важно, а есть асутп управления установкой каталитического крекинга (нефтепереработка, стоимостью 100-200 млн долларов) не забалуешь, потому как рванёт влюбой момент (про пример с водородом смотреть выше). Вот вам разница в требованиях.

Есть разница, безусловно... Но не в требованиях, а в масштабе времени, в первую очередь: там - секунды, здесь - десятки милисекунд... Ну, в стоимостях нефтепереработки тоже, вижу, есть разница...

Это и есть главный критерий realtime? Тогда - берём процессор (ну, ещё что там из оборудования?) в N-раз быстрее (все ведь пропорции, детерминированность - сохраняется на том же уровне?) - и всё? Проблема решена?

Преключение должно произойти _полностью_ за 50 ms. Я видел системы где это сделано частично на софте: оптичекий трансивер (девайс такой) потеряв сигнал (обрыв кабеля) дёргает прерывание. Если у вас interrupt latency высокое и не гарантированное (потому как ваша OS не была задезайнена для этого) то шансы что вы успеете переключиться за эти 50 ms не велики.

А если бы это было 5ms? А - 500ms?
И "шансы, что вы успеете переключиться" стали бы получше - так всё, состоялось - realtime?

И ещё раз: RT OS и RT целевая система - два совершенно разных понятия: "жениться и обещать жениться - 2 большие разницы", как говорят в Одессе. Ваш protection switch - с гораздо большей простотой и меньшей головной болью можно было бы решить на однозадачной OS ("с позволения сказать" OS), например RT-11 или даже MS-DOS...

Вот когда многопроцессность (многопоточность) начинаются в OS, тогда только и начинаются realtime проблеммы. Нельзя изучать паталогии беременности у мужчин... То есть, можно, конечно, если за это платят - но недолго.
Записан
lestat
QOR.Moderator
*****
Offline Offline

Сообщений: 985


I don't trust anything


Просмотр профиля WWW
« Ответ #186 : Апреля 14, 2004, 03:59:35 pm »

Olej
Ваш protection switch - с гораздо большей простотой и меньшей головной болью можно было бы решить на однозадачной OS ("с позволения сказать" OS), например RT-11 или даже MS-DOS...

Угу и откинуть себя лет на 10 назад. Самому писать стеки IP, или юзать кривой Waterloo, Trumpet, MSClient, просто зашибись.
Olej
Это и есть главный критерий realtime? Тогда - берём процессор (ну, ещё что там из оборудования?) в N-раз быстрее (все ведь пропорции, детерминированность - сохраняется на том же уровне?) - и всё? Проблема решена?

Аппаратное решение это круто, конечно, только что будет завтра, когда уже сейчас жизненный цикл дэвайса - 6 месяцев, завтра его не будет в продаже, разводить заново плату, искать новый процессор...
Записан

olej
QOR.Team
****
Offline Offline

Сообщений: 42



Просмотр профиля
« Ответ #187 : Апреля 14, 2004, 04:05:23 pm »

Угу и откинуть себя лет на 10 назад. Самому писать стеки IP, или юзать кривой Waterloo, Trumpet, MSClient, просто зашибись.

Ничего подобного! Я ведь не об конкретной RT-11, для которой и оборудования не найдёте - а об однопотоковых оболочках, поддерживающих целевую terget задачу, от OneTarget, например...
О том, что нет у них "realtime"-проблем.

А с теми же самыми стеками IP - это особая песня: как только появился стек IP - появляется параллелизм, и вырастают realtime-проблемы, независимо от того, всё пишется на коленке, или RTOS используете...

Да и не всем нужен IP - очень многим, особенно в АСУТП, realtime + embedded видится так: на входе - контакт реле, на выходе лампочка... задача: будет ли лампочка загораться "в заранее прогнозируемое время"? ну, не 1-на лампочка, а 1000...
Записан
lestat
QOR.Moderator
*****
Offline Offline

Сообщений: 985


I don't trust anything


Просмотр профиля WWW
« Ответ #188 : Апреля 14, 2004, 04:27:16 pm »

Olej
Да и не всем нужен IP - очень многим, особенно в АСУТП, realtime + embedded видится так: на входе - контакт реле, на выходе лампочка...

А удаленная диагностика, как с ней быть ?
Записан

Evgeniy
Jr. Member
**
Offline Offline

Сообщений: 73


Просмотр профиля
« Ответ #189 : Апреля 14, 2004, 05:04:23 pm »

dip
<i>
Olej
Всё это становится неконструктивно...:

Не вижу неконстуктивности в моём предложении рассмотреть требования к разным сегментам рынка и как архитектура меняется в зависимости от этих самых требований. Сравнить например скедулинг какой-нибудь серверной платформы и qnx.
</i>


С удовольствием увидел бы ваше конструктивное мнение, но как я уже обращал внимание на ваше заявление, к сожалению у вас на него нет времени... или может быть чего-то другого...

dip
Если я на минуточку залезу на мою асутпешную колокольню, то если бы сейчас писал SCADA не имея денег, то выбрал бы линух или BSD. ...............
..............................
..............................

А вот это все практически полностью совпадает с выводом статьи: нет "элитарных" RTOS и "плебейских" GPOS, а есть инструменты (ОС) в большей или меньшей степени пригодные для построения конкретной прикладной системы реального времени и выбор конкретного инструмента делается отдельно в каждом конкретном случае...
Записан
ee
Участник
*
Offline Offline

Сообщений: 0


Просмотр профиля
« Ответ #190 : Апреля 15, 2004, 11:13:37 pm »

Olej
Всё это становится неконструктивно...:

А эти раздолбаи пусть сначала научатся мобильники делать, чтоб не висли

Поясняю - купил мабилу имени этой моторолы. И был шокирован тем, что оно зависает. Так что и вотч-дог не помогает. Т.е. изредка видно что оно само перезагружается, а один раз зависло так, что пришлось аккум. вытаскивать. А после прочтения инструкции оказалось, что это у них вообще фича такая. Заметьте - и система встроенная и самый что ни наесть риалтайм, что бы тут некоторые не говорили.
Записан
lestat
QOR.Moderator
*****
Offline Offline

Сообщений: 985


I don't trust anything


Просмотр профиля WWW
« Ответ #191 : Апреля 16, 2004, 07:32:51 am »

ee
имени этой моторолы

Вообще-то это совершенно разные подразделения Это тоже самое, что говорить, что CD-R Philips отстой, зато какие они классные чайники делают.

Philips CD-R до 24x - это CMC Magnetics - просто делают на заказ брэнда.

Бытовая техника филипса - это выкупленные предприятия и включенные под крылышко концерна, которые тем не менее все равно выпускают свою продукцию, но под другим брэндом.

Аналогия ясна ? Motorolla моторолле рознь.
Записан

ZZZ
Участник
*
Offline Offline

Сообщений: 12


Просмотр профиля
« Ответ #192 : Апреля 20, 2004, 09:25:07 am »

klalafuda писал 2 апреля:

ну а с точки зрения меня, пользователя, совершенно все равно, почему именно я не могу получить желаемые 30Mb/s на запись при доступе к жесткому диску. не работает и все тут. so в проектах допустим со stream video QNX свободен. общение народа в QUICS на протяжении последних трех лет это только подтверждает. далкео не один человек желал поиметь high speed data storage sollution на QNX4/6. ответом было молчание..

Прошу прощения за тормознутость ответа. Только сегодня руки дошли до этой бурной темы....

Если 30Mb/s - это 30 мегабит, а не мегабайт, то, клянусь, в наших тестах 20MB/c (20 Мегабайт) на UDMA-5 мы получали и имеем. Это, так сказать, наше всё, без этого у нас бы и задача не выполнялась. Готов предоставить технологию испытаний. Коротко говоря, использовалась clock(). Процессор был загружен примерно на 50-60%. Когда мы моделировали RAID, записывая поблочно на два диска, подцепленные к IDE-3 и IDE-4 (то есть управляемые контроллером рэйд-массива), скорость достигала 25МБ/с, но при этом процессор (P4 1600Мг) загружался практически под завязку (то бишь становился слабым звеном).

 Если же требуется-таки 30MB/с - то на каком винчестере? Его родные характеристики каковы?

Да, естественно, регистрация идёт на винчестер "регистрирующего" узла, оператор радуется графике и "рулит" на другом узле.
Записан

С уважением, ZZZ
klalafuda
QOR.Team
****
Offline Offline

Сообщений: 1


Просмотр профиля
« Ответ #193 : Апреля 20, 2004, 10:23:58 am »

---cut---
Если 30Mb/s - это 30 мегабит, а не мегабайт, то, клянусь, в наших тестах 20MB/c (20 Мегабайт) на UDMA-5 мы получали и имеем. Это, так сказать, наше всё, без этого у нас бы и задача не выполнялась. Готов предоставить технологию испытаний. Коротко говоря, использовалась clock(). Процессор был загружен примерно на 50-60%. Когда мы моделировали RAID, записывая поблочно на два диска, подцепленные к IDE-3 и IDE-4 (то есть управляемые контроллером рэйд-массива), скорость достигала 25МБ/с, но при этом процессор (P4 1600Мг) загружался практически под завязку (то бишь становился слабым звеном).

Если же требуется-таки 30MB/с - то на каком винчестере? Его родные характеристики каковы?
---cut---

в данном случае, 30Mb/s - это именно мегабайт в секунду на файловую систему цифра была взята в свое время из пожеланий народа с QUICS. afair что-то или с видео или с суровой акустикой делали.

самый банальный тест сразу после установки системы без подстройки и пр.:

bash-2.05b# dd if=/dev/zero of=dat bs=1m count=1024
1024+0 records in
1024+0 records out
1073741824 bytes transferred in 64.892 secs (16546597 bytes/sec)
bash-2.05b# ls -l dat
-rw-r--r--  1 root  wheel  1073741824 Apr 20 14:28 dat

т.е. запись большого нагенеренного файла данных на файловую систему без всяких ухищрений. винт - обычный фуджи afair 5000 или 7200 rpm что-то там. никаких рейдов нет. параметры машины есть на http://ianzag.megasignal.com

минимум ~16Mb/s уже неплохо. если немного потрудиться и подобрать железку, можно поиметь и 30Mb/s.

пока что аналогичного результата у меня не получалось на QNX4/6. вот выйдет в нормальном виде 6.3 опять попробую.

---cut---
Да, естественно, регистрация идёт на винчестер "регистрирующего" узла, оператор радуется графике и "рулит" на другом узле.
---cut---

конечно, лучше разделить data storage и все остальное. машинка все-таки грузится дай бог каждому.

ps: собственно к ОСРВ эти тесты не имеют никакого отношения скорее, сравнение подсистемы ввода/вывода.

// wbr
Записан
ZZZ
Участник
*
Offline Offline

Сообщений: 12


Просмотр профиля
« Ответ #194 : Апреля 22, 2004, 07:23:12 am »

klalafuda
ps: собственно к ОСРВ эти тесты не имеют никакого отношения  скорее, сравнение подсистемы ввода/вывода.

Да понятно... Просто тема для меня волнительная, так что у кого что болит...
И возвращаясь к цифре 30МВ: беру журнал "Компьютерное обозрение" (наш такой, национальный хохляндский) за лето 2003г., тесты современных (на тот момент, естественно, но вполне годится) IDE-винчестеров, числом 18 штук. Конфигурация стенда: ASUS с чипсетом i850E, Pentium 4 2,4GHz, 512MB PC1066 RDRAM, JC Win2000 Prof SP3. То есть весьма пристойно. Смотрю среднюю скорость записи: от 34,1МВps до до 19,9МВps, причём выше 30 -только 2 шт. (WD Caviar WD2500JB да Seagate Barr 7200.7). Вот. А ведь это профессиональный тест, заточенный именно что под проверку возможностей диска, то бишь без учёта "шумов", вызванных особенностями платформы. Это я к тому всё, что вот так просто 30МВ - это задача не банальная.

Ах да, кстати, мы ещё так "тестировали": сгенерировали файл в 10Гб, а потом копировали его. QNX показала себя не хуже ни Win2000, ни Solaris'а.

Так что Ваше
klalafuda
so в проектах допустим со stream video QNX свободен.
мне кажутся уж слишком категоричными.

С уважением, ZZZ
Записан

С уважением, ZZZ
Страниц: 1 ... 11 12 [13] 14
  Печать  
 
Перейти в: