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

клево...
боюсь думать даже какая там железяка была.

Мне бы так зарабатывать - $100 млн. за миллисекунду.

> Мне бы так зарабатывать - $100 млн. за миллисекунду.

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

про $100 млн - очень похоже на грязный пеар.

Там, где время реакции измеряется в десятках микросекунд, ускорение на тысячные доли секунды (миллисекунды то есть) просто невозможно.

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

SUSE и не тормозит! Ура товарищи! :-)

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

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

А где тут написано "время исполнения транзакции"? Речь идет именно о времени реакции на сервере, с указанной нагрузкой.

Unreal time.

Объясните мне что такое Real Time OS. Не станут же программы более шустрыми только от того что мы обзовём операционную систему "рилтаймовой"? Что такое время транзакции и время реакции? И кому всё это надо.

Наконец-то, где скачать-то можно?

Транзакция - экономический процессс, например, перечисление денег с одного счета на другой. СЛЕРТ справился с 28 млн транзакций за 11 мкс. По-моему все ясно.

> SUSE и не тормозит! Ура товарищи! :-)

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

Обычно RT системы использовались для управления или сбором данных в реальном времени.

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

Посмотреть бы в глаза главного маздайщега Билла, на то как он смотрит на такие системы, и мечтает создать подобное.. Прикрутить еще десяток "патчей" на Ви$ту и в бой )

> Транзакция - экономический процессс, например, перечисление денег с одного счета на другой. СЛЕРТ справился с 28 млн транзакций за 11 мкс. По-моему все ясно.

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

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

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

> СЛЕРТ справился с 28 млн транзакций за 11 мкс. По-моему все ясно.

8)

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

> Обычно RT системы использовались для управления или сбором данных в реальном времени

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

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

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

> Транзакция - экономический процессс, например, перечисление денег с одного счета на другой. СЛЕРТ справился с 28 млн транзакций за 11 мкс. По-моему все ясно.

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

// wbr

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

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

>быть где-то в районе 2.545.454.545.454Hz ~ 25.454.545MHz > некисло, правда?

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

2Phoenix49: Никто против примера ничего и не говорит. Перечитай свой пост: из него следует, что SLERT сделает 28 млн. переводов за 11 мкс. Это ложь. Ну и определение "транзакция - экономический процесс". Всё это даёт основание предполагать, что у тебя хороший поставщик травы.

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

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

>...рассчитывает получать дополнительный доход в $100 млн.

В ГОД

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

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

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

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

2Phoenix49: Никто против примера ничего и не говорит. Перечитай свой пост: из него следует, что SLERT сделает 28 млн. переводов за 11 мкс. Это ложь. Ну и определение "транзакция - экономический процесс". Всё это даёт основание предполагать, что у тебя хороший поставщик травы.

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

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

> Посмотреть бы в глаза главного маздайщега Билла, на то как он смотрит на такие системы, и мечтает создать подобное.

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

> RTOSгарантирует максимальное время реакции системы на событие и как правило реалтайм ОС медленнее, чем не реалтайм системы.

и, что не маловажно, она так-же должна гарантировать минимальное время, заданное пользователем, i.e. [min,max].

// wbr

> Объясните мне что такое Real Time OS. Не станут же программы более шустрыми только от того что мы обзовём операционную систему "рилтаймовой"? Что такое время транзакции и время реакции? И кому всё это надо.

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

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

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

Толик, какой ты умный! Тюбетейка голову не жмет?

Зюзероутер и RT..... ущепните меня кто-нибудь.....

народ, ZDNet всегда славилась своими переводами, на самом деле все гораздо прозаичнее

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 добиться можно.

У "музыкального пидагога" завсегда кульная информация... ;-) :-)

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

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

> Посмотреть бы в глаза главного маздайщега Билла, на то как он смотрит на такие системы, и мечтает создать подобное.. Прикрутить еще десяток "патчей" на Ви$ту и в бой )

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

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

МИША ПРЕВЕД!

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

З.Ы.Надо было Ingres заменить на MySQL :)

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

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

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

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

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

да, кстати, и та функциональность, которая была 10 лет назад, тоже никого не устраивает. Аппетиты растут вместе с повышением частоты ЦП :-)

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

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

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

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

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

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

Все зависит от железа и драйверов

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

>Толик, какой ты умный! Тюбетейка голову не жмет?

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

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

> кстати, и та функциональность, которая была 10 лет назад, тоже никого не устраивает.

Отучаемся говорить за всех :-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 это наподобие "немножко беременная", как известно ;-), к реактивности прерываний отношения не имеет.

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

> cтрого!!! не более Хмкс (т.е. предсказуемым) при любой загрузке системы ... Это для linux'a нормально плюс минус лапоть (11-27мкс)...

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

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

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

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

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

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

>> угу, а то что обработчик не один это ничего?

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

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

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

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

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

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

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

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

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

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