LINUX.ORG.RU

Suse Linux Enterprise Real-Time


0

0

Novell планирует анонсировать свой продукт, на конференции Gartner Symposium/ITxpo. Основным разработчиком была компания Concurrent Computer. Novell будет заниматься маркетингом и продажей SLERT. Первым заказчиком SLERT станет фирма Siemens Medical Solutions, которая будет применять эту систему в томографах Magnetom.
Были представлены результаты тестов с базой данных Ingres, исполняющей 28,8 млн. транзакций, реакция SLERT достигала 11 мкс и не превышала 27 мкс.
Один инвестиционный банк сообщил Novell, что на каждую тысячную долю секунды, на которую система сможет опережать конкурентов, компания рассчитывает получать дополнительный доход в $100 млн.

>>> Подробности



Проверено: Shaman007 ()

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

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

isden ★★★★★
()
Ответ на: комментарий от Sun-ch

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

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

ser_bur ★★
()

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

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

anonymous
()

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

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

an
()
Ответ на: комментарий от an

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

Sun-ch
() автор топика

Unreal time.

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

Camel ★★★★★
()
Ответ на: Unreal time. от Camel

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

Phoenix49
()
Ответ на: комментарий от Anoxemian

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

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

ser_bur ★★
()
Ответ на: Unreal time. от Camel

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

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

Sun-ch
() автор топика
Ответ на: комментарий от Sun-ch

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

Phoenix49
()
Ответ на: комментарий от Phoenix49

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

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

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

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

Anoxemian ★★★★★
()
Ответ на: комментарий от Phoenix49

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

8)

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

tailgunner ★★★★★
()
Ответ на: комментарий от Sun-ch

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

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

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

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

tailgunner ★★★★★
()
Ответ на: комментарий от Phoenix49

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

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

// wbr

klalafuda ★☆☆
()
Ответ на: комментарий от klalafuda

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

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

Phoenix49
()
Ответ на: комментарий от klalafuda

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

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

r ★★★★★
()
Ответ на: комментарий от Phoenix49

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

Anoxemian ★★★★★
()
Ответ на: комментарий от klalafuda

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

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

anonymous
()
Ответ на: комментарий от Anoxemian

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

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

Phoenix49
()

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

anonymous
()
Ответ на: комментарий от Phoenix49

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

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

anonymous
()
Ответ на: комментарий от anonymous

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

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

// wbr

klalafuda ★☆☆
()
Ответ на: Unreal time. от Camel

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

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

arsi ★★★★★
()
Ответ на: комментарий от Anoxemian

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

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

eraser
()

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

Metallic
()
Ответ на: комментарий от eraser

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

anonymous
()

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

drSchur ★★★
()
Ответ на: комментарий от anonymous

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

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

tailgunner ★★★★★
()
Ответ на: комментарий от Phoenix49

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

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

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

drSchur ★★★
()
Ответ на: комментарий от tailgunner

МИША ПРЕВЕД!

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

anonymous
()
Ответ на: комментарий от anonymous

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

anonymous
()
Ответ на: комментарий от tailgunner

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

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

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

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

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

anonymous
()
Ответ на: комментарий от anonymous

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

anonymous
()
Ответ на: комментарий от anonymous

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

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

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

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

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

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

tailgunner ★★★★★
()
Ответ на: комментарий от anonymous

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

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

anonymous
()
Ответ на: комментарий от Sun-ch

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

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

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

AcidumIrae ★★★★★
()
Ответ на: комментарий от anonymous

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

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

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

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

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

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

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

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

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

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

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

anonymous
()
Ответ на: комментарий от anonymous

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

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

eraser
()
Ответ на: комментарий от anonymous

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

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

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

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

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

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

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

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

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

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

tailgunner ★★★★★
()
Ответ на: комментарий от eraser

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

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

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

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

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

eraser
()
Ответ на: комментарий от eraser

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

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

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

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

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

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

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

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

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

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

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

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

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

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

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

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.