Здравствуйте, Sinclair, Вы писали:
OE>>Ты кредиткой пользуешься ? Если банкомат заставит карточку ждать пол часа из-за того, что в Москве или еще где перегружена сеть, тебе понравится ? Или гарантирует через неделю, после инкассации ? OE>>Потому и требуется малое время отклика для системы банкоматов, торговых автоматов и всяких других
S>???? Какое там время отклика? Ты банкоматом пользовался хоть раз? Там речь вообще не идет ни о каких миллисекундах. Термин "реальное время" означает только то, что сказал AVK. То есть значение времени отклика определяется задачей. В бизнес-системах (например, для тех же банкоматов) реальное время означает реакцию в пределах нескольких секунд. Практика это подтверждает. Так что приведенные тобою аргументы свидетельствуют не в твою пользу.
У меня VISA Electron. Пользуюсь постоянно. Так вот.
Система бонкоматов != система в банкомате.
Система управления всеми банкоматами — сетевая система РВ.
И эта система РВ постоена на ОСРВ.
Для одного банкомата — секунды. А для сервера — гораздо меньше.
Здравствуйте, Sinclair, Вы писали:
OE>>>>Видеопоток — нужна производительность и только, частота опроса — 24 раза в секунду — это не реальный режим времени.
AVK>>>А чего это ты кадры считаешь? Ты пиксельную частоту посчитай.
OE>>А попиксельно никогда не грабится. Все грабится блоками 24 раза в секунду. S>Тогда, извини, данные ядерных испытаний грабятся раз в несколько месяцев. Это не реальное время.
Ты с чем не согласен ? AVK сам сказал, что грабится пачками. Только несколько позже
Здравствуйте, old->*Plutonia_Experiment(), Вы писали:
OE>У меня VISA Electron. Пользуюсь постоянно. Так вот. OE>Система бонкоматов != система в банкомате. OE>Система управления всеми банкоматами — сетевая система РВ. OE>И эта система РВ постоена на ОСРВ. OE>Для одного банкомата — секунды. А для сервера — гораздо меньше.
Ну да. В принципе, добавляется еще время на доставку пакета туда-обратно, плюс тормоза локального проца при проворачивании интерфейса.
Так вот, как человек, который занимался интеграцией с системами платежей в реальном времени, я тебе скажу, что типичное время обработки одной транзакции от 200 до 1500 миллисекунд. На сервере. И никто не собирается делать его сильно меньше. Потому, что там критична пропускная способность, а не время одной транзакции. То, что сервак протягивает 10000 транзакций в секунду не означает, что длительность каждой равна 100мкс. И такие большие, с твоей точки зрения, времена не означают, что это "не риал тайм". С точки зрения бизнеса это — самый что ни на есть риалтайм.
Пользуюсь RSDN@Home 1.0 alpha 15, слушая C uibul — Cuibul
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, AndrewVK, Вы писали:
VD>>Т.е. по твоему ДОС на современном железе не в силах обеспечить время реакции измеряемое в милисекундах? Нда...
AVK>Да я вобще непонимаю из какого пальца высосали эти единицы миллисекунд.
Если бы ты просмотрел хотя бы ссылки мои:
Принято различать системы "мягкого" и "жесткого" реального времени (РВ). Система "Жесткого" РВ — система, где неспособность обеспечить реакцию на какие-либо события в заданное время является отказом и ведёт к невозможности выполнения поставленной задачи. В большинстве русскоязычной литературы такие системы называют системами с детерминированным временем. При практическом применении время реакции должно быть минимальным. Системами "мягкого" РВ называются системы, не попадающие под определение "жесткие", т.к. в литературе четкого определения для них пока нет. Системы "мягкого" РВ могут не успевать решать задачу, но в зависимости от функции, выполняемой системой, задержка выполнения может быть различной.
Здравствуйте, old->*Plutonia_Experiment(), Вы писали:
AVK>>Да я вобще непонимаю из какого пальца высосали эти единицы миллисекунд.
OE>Если бы ты просмотрел хотя бы ссылки мои:
Здравствуйте, AndrewVK, Вы писали:
AVK>>>Да я вобще непонимаю из какого пальца высосали эти единицы миллисекунд. OE>>Если бы ты просмотрел хотя бы ссылки мои: AVK>Вот в твоих ссылках тое все из пальца высосано.
Та ссылка, что я тебе дал — это специализированный сайт по системам реального времени и QNX.
Укажи тогда источник, который позволит считать обратное — только не рубикон и не словарь Даля.
Я топик както кинул по реальному времени. Можешь туда глянуть для общего развития.
Здравствуйте, Dmitry A. Sustretov, Вы писали:
DAS>Пара вопросов по архитектуре микроядра.
DAS>1) почему микроядро — это хорошо ? DAS>2) почему микроядро не медленнее традиционных ядер ? DAS>3) каким (эффективным) образом реализуется механизм доставки сообщений серверам ? DAS>4) есть ли реализации микроядра второго поколения (микромикроядра) ?
Друзья, а не переливаете ли вы из пустого в порожнее?
Давайте условимся, что:
1. Система реального времени — эта такая система, для которой предельное время отклика на каждое событие детерминировано. И не статистически, а жестко.
2. Система жесткого реального времени — это система, не нарушающая предельное время отклика ни при каких обстоятельствах. Система мягкого реального времени — может нарушать.
3. Соответственно, ОС жесткого реального времени строятся по совсем другим законам, нежели обычные: статическая архитектура, статическое планирование и т.д. Ни одна из перечисленных вами систем (за исключением QNX, да и то не совсем) системой жесткого реального времени не является.
4. ОС мягкого реального времени — любая ОС. В зависимости от принятой схемы диспетчеризации и планирования, "реальность" может варьироваться от "очень мягкой" до "весьма неплохой". Но в любом случае система, не гарантирующая 100% детерминизм предельного времени отклика не может использоваться для задач жесткого реального времени.
5. Задачи жесткого реального времени — преимущественно задачи управления критическими процессами. Задачи обработки видео и вообще большинство "обычных" задач — задачи мягкого РВ. Соответственно в большей или меньшей степени для этих задач подходят юниксы, линуксы и виндоусы всех мастей.
6. Кстати, NTшные реалтайм потоки — это попытка создать "почти жесткое" реальное время. Вот только спецификация диспетчера все равно не гарантирует детерминизма предельного времени отклика (хотя на практике оно и обеспечивается), а планировщик не рассчитан на статическое планирование.
Здравствуйте, WildCat, Вы писали:
WC>Друзья, а не переливаете ли вы из пустого в порожнее?
Уважаемый, не могли бы Вы не кричать в форуме? Если Вы думаете, что без употребления жирного шрифта Вас никто читать не будет — лучше уделите время качеству постингов. Спасибо.
... << RSDN@Home 1.0 beta 2 | слушаю Limp Bizkit — No sex>>
Вообще в литературе нет четкого определения "мягкого" реального времени. Все в основном относится к жесткому, он же просто реалтайм.
Нашел более менее нормальное определение:
Система реального времени — система массового обслуживания с жестко детерминированным временем ответа.
В случае нарушения этого условия система выходит из строя.
Мягкий — допускаются некоторые задерки, сказывающиеся лишь на качестве выхода и к выходу системы из строя не ведут.
WC>2. Система жесткого реального времени — это система, не нарушающая предельное время отклика ни при каких обстоятельствах. Система мягкого реального времени — может нарушать.
В точку.
WC>3. Соответственно, ОС жесткого реального времени строятся по совсем другим законам, нежели обычные: статическая архитектура, статическое планирование и т.д. Ни одна из перечисленных вами систем (за исключением QNX, да и то не совсем) системой жесткого реального времени не является.
Согласен. ОС реального времени должна соответсвовать куче стандартов и требований.
WC>4. ОС мягкого реального времени — любая ОС. В зависимости от принятой схемы диспетчеризации и планирования, "реальность" может варьироваться от "очень мягкой" до "весьма неплохой". Но в любом случае система, не гарантирующая 100% детерминизм предельного времени отклика не может использоваться для задач жесткого реального времени.
Вот-вот !
WC>5. Задачи жесткого реального времени — преимущественно задачи управления критическими процессами. Задачи обработки видео и вообще большинство "обычных" задач — задачи мягкого РВ. Соответственно в большей или меньшей степени для этих задач подходят юниксы, линуксы и виндоусы всех мастей.
И фризер туда же, и датчик, и трубопровод. Для них и ДОС хватит.
WC>6. Кстати, NTшные реалтайм потоки — это попытка создать "почти жесткое" реальное время. Вот только спецификация диспетчера все равно не гарантирует детерминизма предельного времени отклика (хотя на практике оно и обеспечивается), а планировщик не рассчитан на статическое планирование.
Нужен кроме этого детерминизм всех системных вызовов и совсем другая схема диспетчеризации.
Для NT не указаваются временные параметры, например такие, как задержка обработки прерывания и тд.
А для ОС РВ это крайне важно.
А не указываются потому, что нет способа обеспечить это.
Для мелких задач NT сгодится. Особливо там, где задержка не играет роли.
Здравствуйте, orangy, Вы писали:
WC>>Друзья, а не переливаете ли вы из пустого в порожнее? O>Уважаемый, не могли бы Вы не кричать в форуме? Если Вы думаете, что без употребления жирного шрифта Вас никто читать не будет — лучше уделите время качеству постингов. Спасибо.
Здравствуйте, AndrewVK, Вы писали:
OE>>Что скажет AVK и Рубикон по этому поводу ?
AVK>А то что никто не говорил что ОС РВ это обязательно жесткий реалтайм.
Именно жесткий.
Под "мягкий" подойдет почти любая оса, дося или муха. Стоит ли говорить об этом ?
Здравствуйте, old->*Plutonia_Experiment(), Вы писали:
OE>Именно жесткий. OE>Под "мягкий" подойдет почти любая оса, дося или муха. Стоит ли говорить об этом ?
Когда разговор шел, он шел о просто реальном времени, а значит и о мягком тоже. Не надо стрелки теперь переводить. Под NT и DOS могут решаться задачи реального времени. С остальным никто и не спорил.
Здравствуйте, AndrewVK, Вы писали:
AVK>Когда разговор шел, он шел о просто реальном времени, а значит и о мягком тоже. Не надо стрелки теперь переводить. Под NT и DOS могут решаться задачи реального времени. С остальным никто и не спорил.
Реальное время обычно жесткое. Посмотри мои примеры и ссылки(хотя бы ту одну, что ты цитировал).
А то, что "Под NT и DOS могут решаться задачи реального времени"
1. Есть такие штаны, которые одеваются через голову. Натягиваешь их, застегиваешь и все. Замок просто хитрый — была юбка, стали штанины.
2. ДОС является только загрузчиком программного кода. И реалтайм обеспечивается не благодаря, а вопреки — сам ДОС для РВ ничего не предоставляет.
3. NT в чистом виде может использоваться не многим лучше ДОС.
Здравствуйте, old->*Plutonia_Experiment(), Вы писали:
OE>Реальное время обычно жесткое. Посмотри мои примеры и ссылки(хотя бы ту одну, что ты цитировал).
Обычно не катит. Я тебе гору примеров привел.
OE>1. Есть такие штаны, которые одеваются через голову. Натягиваешь их, застегиваешь и все. Замок просто хитрый — была юбка, стали штанины.
Задачи РВ не сами по себе живут. Написание удобных интерфейсов под wxWorks тоже надевание штанов через голову.
OE>3. NT в чистом виде может использоваться не многим лучше ДОС.
Надоел уже. Тебе говорят что решали задачи реального времени времени. А уж какое оно там — мягкое или жесткое это уже другой вопрос.
Все, надоела мне эта демагогия — не хочешь признавать реальные факты, не признавай. Мне все равно.
Здравствуйте, AndrewVK, Вы писали:
OE>>Реальное время обычно жесткое. Посмотри мои примеры и ссылки(хотя бы ту одну, что ты цитировал). AVK>Обычно не катит. Я тебе гору примеров привел.
Три — фризер + газопровод + видеопоток.
Нет оснований считать это реалтаймом.
Ибо система не выйдет из строя в случае задержки. В случае с реактором — задержка введения графитовых стержней чревата ядерным взрывом — налицо выход системы из строя.
То, что ты привел — это "мягкий". Такие реалтаймы везде есть. Незачем выделять группу систем по какомуто параметру, если этим параметром обладают все системы.
AVK>Надоел уже.
Что поделаешь, я сварливый чел и люблю докапываться до истины.
AVK>Тебе говорят что решали задачи реального времени времени. А уж какое оно там — мягкое или жесткое это уже другой вопрос.
Вот на него я хочу найти ответ. С моей точки зрения реальное время — только жесткое. Это диктует не разработчик, а внешняя среда.
Все остальное — не считается таковым.
AVK>Все, надоела мне эта демагогия — не хочешь признавать реальные факты, не признавай. Мне все равно.
