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 ()

Re: Suse Linux Enterprise Real-Time

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

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

isden ★★★★★ ()

Re: Suse Linux Enterprise Real-Time

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

Sun-ch ()
Ответ на: Re: Suse Linux Enterprise Real-Time от Sun-ch

Re: Suse Linux Enterprise Real-Time

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

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

ser_bur ★★ ()

Re: Suse Linux Enterprise Real-Time

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

isden ★★★★★ ()

Re: Suse Linux Enterprise Real-Time

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

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

anonymous ()

Re: Suse Linux Enterprise Real-Time

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

Anoxemian ★★★★★ ()

Re: Suse Linux Enterprise Real-Time

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

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

an ()
Ответ на: Re: Suse Linux Enterprise Real-Time от an

Re: Suse Linux Enterprise Real-Time

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

Sun-ch ()

Unreal time.

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

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

Re: Unreal time.

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

Phoenix49 ()
Ответ на: Re: Suse Linux Enterprise Real-Time от Anoxemian

Re: Suse Linux Enterprise Real-Time

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

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

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

Re: Unreal time.

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

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

Sun-ch ()
Ответ на: Re: Unreal time. от Sun-ch

Re: Unreal time.

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

Phoenix49 ()
Ответ на: Re: Unreal time. от Phoenix49

Re: Unreal time.

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

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

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

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

Anoxemian ★★★★★ ()
Ответ на: Re: Unreal time. от Phoenix49

Re: Unreal time.

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

8)

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

tailgunner ★★★★★ ()
Ответ на: Re: Unreal time. от Sun-ch

Re: Unreal time.

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

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

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

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

tailgunner ★★★★★ ()
Ответ на: Re: Unreal time. от Phoenix49

Re: Unreal time.

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

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

// wbr

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

Re: Unreal time.

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

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

Phoenix49 ()
Ответ на: Re: Unreal time. от klalafuda

Re: Unreal time.

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

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

r ★★★★★ ()
Ответ на: Re: Unreal time. от Phoenix49

Re: Unreal time.

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

Anoxemian ★★★★★ ()
Ответ на: Re: Unreal time. от klalafuda

Re: Unreal time.

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

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

anonymous ()
Ответ на: Re: Unreal time. от Anoxemian

Re: Unreal time.

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

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

Phoenix49 ()

Re: Suse Linux Enterprise Real-Time

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

anonymous ()
Ответ на: Re: Unreal time. от Phoenix49

Re: Unreal time.

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

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

anonymous ()
Ответ на: Re: Suse Linux Enterprise Real-Time от anonymous

Re: Suse Linux Enterprise Real-Time

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

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

// wbr

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

Re: Unreal time.

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

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

arsi ★★★★★ ()
Ответ на: Re: Unreal time. от Anoxemian

Re: Unreal time.

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

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

eraser ()

Re: Suse Linux Enterprise Real-Time

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

Metallic ()
Ответ на: Re: Unreal time. от eraser

Re: Unreal time.

народ, 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 ()

Re: Suse Linux Enterprise Real-Time

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

drSchur ★★★ ()
Ответ на: Re: Unreal time. от anonymous

Re: Unreal time.

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

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

tailgunner ★★★★★ ()
Ответ на: Re: Unreal time. от Phoenix49

Re: Unreal time.

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

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

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

drSchur ★★★ ()
Ответ на: Re: Unreal time. от tailgunner

Re: Unreal time.

МИША ПРЕВЕД!

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

anonymous ()
Ответ на: Re: Unreal time. от anonymous

Re: Unreal time.

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

anonymous ()
Ответ на: Re: Unreal time. от tailgunner

Re: Unreal time.

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

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

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

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

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

anonymous ()
Ответ на: Re: Unreal time. от anonymous

Re: Unreal time.

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

anonymous ()
Ответ на: Re: Unreal time. от anonymous

Re: Unreal time.

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

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

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

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

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

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

tailgunner ★★★★★ ()
Ответ на: Re: Unreal time. от anonymous

Re: Unreal time.

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

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

anonymous ()
Ответ на: Re: Suse Linux Enterprise Real-Time от Sun-ch

Re: Suse Linux Enterprise Real-Time

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

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

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

AcidumIrae ★★★★★ ()
Ответ на: Re: Unreal time. от anonymous

Re: Unreal time.

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

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

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

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

Re: Unreal time.

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

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

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

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

>> 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 ()
Ответ на: Re: Unreal time. от anonymous

Re: Unreal time.

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

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

eraser ()
Ответ на: Re: Unreal time. от anonymous

Re: Unreal time.

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

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

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

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

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

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

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

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

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

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

tailgunner ★★★★★ ()
Ответ на: Re: Unreal time. от eraser

Re: Unreal time.

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

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

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

Re: Unreal time.

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

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

eraser ()
Ответ на: Re: Unreal time. от eraser

Re: Unreal time.

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

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

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

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

Re: Unreal time.

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

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

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

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

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

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

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

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

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

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

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

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