/me представил Саныча, подрабатывающего сервером баз данных :-O

Или они встроили в SLERT телепатический модуль, реагирующий на прерывание за миллисекунду до того, как оно произошло?

Лор, @#$! Учитесь читать то, что написано! Время исполнения транзакции != времени реакции.

Unreal time.

А че, взяли сусю, убрали КДЕ, Гном и яст - сразу реалтаймовой стала ;)

Хватит курить :-)

Под транзакцией понимается цикл: запрос - обработка - ответ. Время реакции - время между окончанием подачи запроса и началом процесса обработки.

В экономическом смысле transaction means a deal.

8)

Я тоже хочу такой травы

Аха. И главнная их черта - не скорость, а предсказуемость.

> реальное время тут нужно, например, что бы гарантировано иметь полную оценку рисков по инвестиционному портфелю и инициировать начало сделки

Для этого лучше программу оценки рисков оптимизировать. Например, переписать с Java на C++. Или cache coloring реализовать. Или поддержку NUMA подрихтовать. А real-time OS здесь скорее помешает.

Это уже не ко мне :). Как ктото успел выразиться "запрос-обработка-ответ" и есть перевод бабла с однога счета на другой, но в более практичном виде, скажем: Посылаешь запрос о действиях (запрос), комп обрабатывает (обработка), ты плучаешь ответ о том что и как (ответ), неужели так трудно было понять? Хватит курить! :)

2.5THz - машина для SuSe! ;)

> сэр сам то понял, что за банапню написал :-? 
> посчитаем: 
> 28.000.000 транзакций за 11мкс == 0.000011/28000000 секунды на транзакцию -> 
> если одна транзакция проходит за один тик CPU, то прикидочная частота этого 
> мегадевайса должна быть где-то в районе 2.545.454.545.454Hz ~ 25.454.545MHz 
> некисло, правда? 

Он конечно ""ню написал, но и твой пост не лучше, в нем тоже неверные предположения сделаны, так что извинись перед публикой.

В ГОД

читаем оригинал

http://news.com.com/Novell+to+launch+quick-response+Linux/2100-7344_3-6117479...

плюемся на испорченый телефон зднет + саныч

а все уже размечтались ;)

В данном примере транзакция - и есть экономический процесс, так как речь идет об экономической структуре. То что значит транзакция вообще даже под дурью ясно)

Вообще-то существует отдельный класс RTOS, в которых реализовывается WinAPI. Но распространения они не получили.

ОСРВ -- система, которая _гарантированно_ будет обрабатывать данные с той скоростью, с которой они поступают и не привышет заданной временной задержки при выдаче обработанной принятой информации.

Мляяяяя... Имеется ввиду, что при загрузке системы 28-ю млн. транзакциями (обмен данными), система таки ещё может откликаться на левый запрос 11<t<27 mcS, что даволно круто...

While some real-time operating systems are found in small computing devices, SLERT is geared for larger systems such as multiprocessor servers. On one test on that type of system running the Ingres database over 28.8 million transactions, SLERT responded as fast as 11 millionths of a second and no slower than 27 millionths of a second, Novell said.

а ZDNet перевела последнюю фразу

"В одном из тестов на такой системе с базой данных Ingres, исполняющей 28,8 млн транзакций, SLERT достигала реакции в 11 мкс и не превышала 27 мкс."

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

а реакции в 11 мкс даже на прерывание не у каждой коммерческой RTOS добиться можно.

IIRC, у QNX 10 лет назад заявлялось 40мкс, а это время уменьшается почти линейно при повышении частоты ЦП. Причем тогда 40мкс - был отнюдь не рекорд, у OS-9/Atomic заявлялось 3мкс.

Всё верно, тока Б.Г. не мечтает ничего создавать. Если б не конкуренты, Виндузятников бы и в помине не было, а были бы ДОСятники.

Или по-прежнему есть люди, считающие, что Интернет придумал Б.Г.?

Вот и развеен миф о тормозящий зюзи. Интересно, а слака за сколько бы управилась ?

>IIRC, у QNX 10 лет назад заявлялось 40мкс, а это время уменьшается почти линейно при повышении частоты ЦП. Причем тогда 40мкс - был отнюдь не рекорд, у OS-9/Atomic заявлялось 3мкс.

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

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

OS-9 вообще не RTOS кстати ;-)

Отнюдь не всегда. Кроме того, априорно полагается, что "всё нормально" - иначе до обработки прервания дело может просто не дойти.

> от частоты реактивность ЦП зависит отнюдь не линейно, потому как драйвер прерывания обязан лезть в регистры, которые выдадут тебе данные когда захотят

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

> OS-9 вообще не RTOS кстати ;-)

IIRC, OS-9 ниже 3.0 позиционировалась как soft-realtime OS, от 3.0 (с микроядром) - как hard-realtime OS.

ЗЫ ДОС - пример настоящей реалтаймовой ОС 8-)

жмет :( а что делать?

я $100 млн. за миллисекунду не зарабатываю ;)

Отучаемся говорить за всех :-P Для многих задач функциональности на уровне тогдашних RTOS вполне достаточно.

Хотя аппетиты растут, да.

>Ну здрасьте... Время реакции - это время от возникновения прерывания до начала выполнения нужного обработчика, а то, что этот обработчик лезет в регистры - уже не в счет.

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

так что мир гораздо хуже, чем мы думаем :-)

>> OS-9 вообще не RTOS кстати ;-)

>IIRC, OS-9 ниже 3.0 позиционировалась как soft-realtime OS, от 3.0 (с микроядром) - как hard-realtime OS.

не буду спорить, я с OS-9 почти не работал, работал с OS-9000 там уже никаким real-time не пахло. soft-realtime это наподобие "немножко беременная", как известно ;-), к реактивности прерываний отношения не имеет.

Так в том то и дело, что для RTOS реальный отклик должен быть строго!!! не более Хмкс (т.е. предсказуемым) при любой загрузке системы и хоть ты ап стену убейся и не от чего зависеть не должен. Иначе это не RTOS. Это для linux'a нормально плюс минус лапоть (11-27мкс)...

обычно именно так и бывает, но вряд ли показатели interrupt latency меряются в таких условиях

> в том то и проблема что твое прерывание пропустят только когда все высокоприоритетные прерывания завершатся,

Нормальная RTOS тем и отличается, что в ней ты сам назначаешь приоритеты прерываний.

> а еще хуже, если нарвешься на глобальный лок прерываний в каком-нибудь модуле сетевого стека, тогда вообще привет

В нормальных RTOS прерывания запрещаются на короткие, строго определенные промежутки времени, которые в подсчете interrupt latency учитываются.

> OS-9 почти не работал, работал с OS-9000 там уже никаким real-time не пахло

OS-9000 - это версия OS-9 для архитектуры Intel. Я под OS-9 понимал именно ее. Насчет "не пахло" - я излагаю то, что было написано в документации.

> soft-realtime это наподобие "немножко беременная", как известно ;-), к реактивности прерываний отношения не имеет.

Здесь спорить не стану, но сам термин - общепринят и используется широко, и часто сопровождается замерами времени реакции.

Ну так скажи, что для Linux время реакции - 27мкс, и вот тебе Linux == RTOS ;)

А ты уверн, что это для любой задачи так будет ??? При любой загрузке...???

Нет, не уверен. Поэтому у меня там стоял смайлик и отсуствовало слово "hard".

Но вообще-то в статье говорилось о _конкретной_ нагрузке.

>обычно именно так и бывает, но вряд ли показатели interrupt latency меряются в таких условиях

вот и я про то же, в VxWorks заявляется по даташиту 10mks, а по факту постоянно что-то отваливается

>> в том то и проблема что твое прерывание пропустят только когда все высокоприоритетные прерывания завершатся,

>Нормальная RTOS тем и отличается, что в ней ты сам назначаешь приоритеты прерываний.

а ничего, что иногда приоритет прерываний от вообще оборудования зависит?

плюс к тому, что ты будешь делать, когда у тебя на PCI с четырьмя линиями прерываний двадцать устройств сидит?

>> а еще хуже, если нарвешься на глобальный лок прерываний в каком-нибудь модуле сетевого стека, тогда вообще привет

>В нормальных RTOS прерывания запрещаются на короткие, строго определенные промежутки времени, которые в подсчете interrupt latency учитываются.

ну да, 100-200 mks, подумаешь... а TCP-IP добавляешь еще сотню накинут ;-)

в том то и дело, что не учитываются, потому как за BSP отвечает не поставщик RTOS, аналогично и за кучу third-party программных модулей