Suse linux enterprise real time

Suse Linux Enterprise Real-Time

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

Re: Suse Linux Enterprise Real-Time

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

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

Re: Suse Linux Enterprise Real-Time

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

Re: Suse Linux Enterprise Real-Time

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

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

Re: Suse Linux Enterprise Real-Time

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

Re: Suse Linux Enterprise Real-Time

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

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

Re: Suse Linux Enterprise Real-Time

SUSE и не тормозит! Ура товарищи! 🙂

Re: Suse Linux Enterprise Real-Time

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

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

Re: Suse Linux Enterprise Real-Time

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

Unreal time.

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

Re: Suse Linux Enterprise Real-Time

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

Re: Unreal time.

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

Re: Suse Linux Enterprise Real-Time

> SUSE и не тормозит! Ура товарищи! 🙂

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

Re: Unreal time.

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

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

Re: Unreal time.

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

Re: Unreal time.

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

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

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

Re: Unreal time.

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

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

Re: Unreal time.

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

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

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

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

Re: Unreal time.

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

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

25.454.545MHz
некисло, правда?

Re: Unreal time.

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

25.454.545MHz некисло, правда?

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

Re: Unreal time.

>быть где-то в районе 2.545.454.545.454Hz

25.454.545MHz > некисло, правда?

2.5THz — машина для SuSe! 😉

Re: Unreal time.

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

Re: Unreal time.

Re: Suse Linux Enterprise Real-Time

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

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

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

Re: Unreal time.

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

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

Re: Suse Linux Enterprise Real-Time

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

Re: Unreal time.

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

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

Re: Suse Linux Enterprise Real-Time

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

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

Re: Unreal time.

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

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

Re: Unreal time.

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

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

Re: Suse Linux Enterprise Real-Time

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

Re: Suse Linux Enterprise Real-Time

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

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

Re: Suse Linux Enterprise Real-Time

У «музыкального пидагога» завсегда кульная информация. 😉 🙂

Re: Unreal time.

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

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

Re: Unreal time.

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

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

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

Re: Unreal time.

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

Re: Unreal time.

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

Re: Unreal time.

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

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

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

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

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

Re: Unreal time.

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

Re: Unreal time.

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

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

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

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

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

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

Re: Unreal time.

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

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

Re: Suse Linux Enterprise Real-Time

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

жмет 🙁 а что делать?

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

Re: Unreal time.

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

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

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

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 это наподобие «немножко беременная», как известно ;-), к реактивности прерываний отношения не имеет.

Re: Unreal time.

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

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

Re: Unreal time.

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

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

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

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

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

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

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

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

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

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

Re: Unreal time.

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

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

Re: Unreal time.

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

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

Re: Unreal time.

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

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

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

Re: Unreal time.

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

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

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

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

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

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

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

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

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

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

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

Источник