[Olej 0]

- это идиотизм (прошу прощения за прямоту).

 

Это уже та прямота, которая .... "... хуже воровства".

Долго объяснять в деталях, но вы в корне не правы: нехватка RAM ресурсов выявляется на этапах самого раннего тестирования, а вот непредсказуемость временных реакций - не выявляется никогда, сколь угодно методичным тестированием.

 

С какой стати? Если ограничения - это не Виндовоз, а Ethernet и "моторольный" конец (может еще и с OS-9)??? если есть у Вас 10Мбод, и минимальный пакет по 4Кб, тут уж никуда не деться ... да, не сказал, что послылка занимает примерно миллисекунду, а прием около пяти мс. Тоже информация к размышлению.

 

А здесь просто ... - не делайте мне смешно... ;)

 

1. если это Ethernet, то минимальный пакет: 46 байт данных + 18 байт заголовок = 64;

2. а вот максимальный пакет Ethernet, что интересно, MTU = 1500 + те же 18 байт заголовок MAC уровня;

3. а при пользовательском "минимальный пакет по 4Кб" (а у вас ещё там и максимальные были? ;)) - это сегментация на 3 как минимум IP пакета, а для сегментов IP свои правила задержек передачи, да ещё для каждого сегмента может потребоваться и ARP обмен для разрешения адреса...

4. а при TCP протоколе (у вас же Modbus over TCP?) сегментация может быть и ещё мельче: определяется соотношениями размеров окон приёма и передачи...

5. а обратную посылку подтверждающего сегмента ACK вы учитывали? ("вы обращались к проктологу - правильно ли вы вкладываете свой ваучер?")

6. а алгоритм Нэйгла у вас был включен или выключен? ... он влияет на применение в протоколе отсроченных подтверждений;

 

Тестовые замеры. По витой паре Ethernet. Связь по Modbus over TCP|IP с выносным модулем цифровых

входов/выходов. Т10 или 100 не скажу. Цикл приема-передачи занимает 6-7 мс. Методика измерений - заряжаем в цикле 1000 пакетов и засекаем секундомером. В конце делим секунды на тысячу...

 

Может вы бы лучше "засекали" загибая пальцы? ;)

Тоже ведь - методика ...

[Владимир Е. Зюбин 0]

'Владимир Е. Зюбин': "А я со своей стороны скажу, что если Вы уж утверждаете, что ваш оппонент не владеет предметом, так уж будьте добры указать в чем. Не в такие уж дебри QNX я забираюсь, а рассуждаю об общей стратегии."

 

Как раз затрагиваемые детали на поверхности - "не дебри", но для их объективного понимания нужно лезть достаточно глубоко в дебри.

А указать? да пожалуйста:

 

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

 

1.

'Владимир Е. Зюбин': "Тестовые замеры. По витой паре Ethernet. Связь по Modbus over TCP|IP с выносным модулем цифровых

входов/выходов. Т10 или 100 не скажу. Цикл приема-передачи занимает 6-7 мс. Методика измерений - заряжаем в цикле 1000 пакетов и засекаем секундомером. В конце делим секунды на тысячу...

Приложение LabView(Win2000). Уверен, что на другой ОС никаких улучшений не будет. Т.к. дело тут не в ОС."

 

- эта иллюзия определяется только ОС с использованием timeslice=10мс. (шкала разрешения времени), если вы при 2-х измерениях получили 10мс. (1 слайс), а в 3-м - 0 (вообще слайс не истёк), то среднее вы и оцениваете в 6-7мс. Только вопрос при этом: а что же это вы такое меряли?

В QNX с возможностью уменьшения timeslice до 10мкс. (на 3 порядочка, чуть-чуть) я видел совсем другие цифры и вам могу показать.

Измерял время. Если Вы не понимаете, как можно измерить интервал в 7 мс при таймслайсе в 10 мс (а я этого тоже не понимаю), так может быть Ваши сведения о 10 мс - не соответствуют действительности?

Не приходило в голову? А то, что Вы с другим прибором связывались? Думаете, не имеет значения?

 

Уточняю еще раз: цикл в 6-7 мс складывается из двух составляющих - 1 мс на запись, и 5-6 мс на чтение... определялось это установкой таймаутов.

 

2 и 3.'Владимир Е. Зюбин':"В 6-ой QNX версии это граничение снято, но все равно, в реальных задачах процессов немного, ну с десяток-другой при всей ейной микроядерности. Да и затраты на обслуживание процесса в QNX на два порядка выше, чем в многопоточных вариантах."

 

В микроядерной архитектуре с лёгкостью "уживаются" тысячи процессов, и тем более потоков (десятки тысяч). И такая много-параллельная структура, закладываемая в проект, часто намного улучшает его ТТД.

Прошу прощения, нельзя ли чуть менее расплывчато и чуть более конкретно?

Зачем этот субъективизм - "с легкостью уживаются"?

 

Дайте уж возможность собеседнику самому сделать вывод о том, легко процессы уживаются, или нет.

на основании четких сведений о конкретном проекте: чем там управляется, что за специфика, какие требования, какие накладные расходы получены...

 

А "затраты на обслуживание процесса в QNX" не "на два порядка выше", чем в многопоточных вариантах, а на несколько процентов, которые и не всегда вы сможете даже специально выделить в тестах. Чтоб не спорить и не давать вам повода затягивать спор "откуда известно" я вам скажу следующее:

- эти результаты и выводы я привожу в своей книге (вместе с Егором Горошко):

http://www.books.ru/shop/books/357604

- а поскольку их пока никто не оспорил и им не возразил - их нельзя считать неверными ;);

- а книга по рейтингам www.books.ru - 3-я позиция "книга 2005г." (из пару тысяч), т.е. её читают и, значит, с ней соглашаются.

 

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

Вы написали хорошую книгу, искренне поздравляю. Но нельзя ли привести конкретные данные?

С моей стороны для альтернативных решений числа приведены - это сотни наносекунд на Гигагерцовой частоте на процесс.

 

Нет данных? Информация об этом тоже важна.

 

4.

'Владимир Е. Зюбин':"Что же касается своппинга и "требуемой классики", то могу открыть Вам секрет, что, вообще говоря, даже не своппинг крайне нежелателен, а вообще динамические операции с ОЗУ, даже если они к своппингу не приводят."

 

Именно свопинг, и не свопинг даже, а виртуализация страниц памяти на дисковое пространство через механизм MMU (а свопинга, в первородном его смысле - давно уже нет во всех ОС).

 

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

А Вы почитайте специализированную литературу по вопросу. Например, вот эту:

 

On Software Languages for use in Nuclear Power Plant Safety Systems/

Decker D., Dinsmore G., Graff S., Green W., Hecht H., Justice M., Koch S., Lin D.,

Ossia K., Pollard J., Shokri E., Sorkin A., Tai A., Tso K.S., Wendelboe D. - NRC, 1997.

 

И еще раз: не стоит голословно обвинять оппонента в некомпетентности, или голословности.

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

 

5.

'Владимир Е. Зюбин':"Пояснили бы лучше, почему это в 6-ой версии QNX есть диск-своп, и какой смысл в его отключении, чем по моим наблюдениям QNX-сообщество необычайно гордится и при этом погружается в состояние самодовольного успокоения."

 

Нет его.

Был в ранних версиях линии 6, но на сегодня - вообще нет.

А в чем причина-то? Большая политика? Сделали, а потом поняли, что выбивают сами себе почву из-под ног? 8-) В общем не вижу смысла, да и Вы, я вижу, не желаете приоткрывать завесу над этой тайной.

 

P.S. Я это (и многое ещё мог бы) написал вовсе не для того, чтобы вас, или кого-то ещё, в чём то уличать ... но вы просили? ;).

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

 

Я за. Жду конкретики. И не стесняйтесь показывать мои ошибки. У меня по этому поводу комплексов нет. Только спасибо скажу.

 

'Владимир Е. Зюбин':"А я вообще из лидеров продаж не знаю SCADA-пакетов для QNX, все сплошняком Windows. Ничего не имею против Linux, или QNX, но что поделать? Не знаю. Кстати, дороговизна QNX и Ко и в общем-то и говорит за то, что объем продаж у них невысокий..."

 

"Не знаю" это вовсе не аргумент того, что так оно и есть...

RealFlex, например - система, на базе которой >20 лет.(!) строились и строятся сотни крупных распределённых проектов в крупнейших индустриальных странах... можно и другие упомнить.

Но состояние дел то в том, что большое множество СУ отраслевых - делаются на a'la SCADA инструментальных средствах, "затачиваемых" под отрасль ... и почти все такие tools - под QNX: вся нефте-газоперекачка России, железнодорожный транспорт, авиационное двигателестроение...

А "я не знаю" - так это потому, что такие инструментальные tools - они не позиционируются на горизонтальных рынках, и не афишируются... но стоимостно они покрывают отрасли, финансово-ёмкие на порядки более, чем вся прочая конвейерная АСУТП...

 

Я знаю про RealFlex... под нее я и отдал 10% в своей оценке... с лихвой... за глаза... сколько раз не встречал обзоры скада-пакетов, даже не упомню ее.

 

А про "скада-на коленке", не стоило упоминать... под Виндовозом их тоже немеряно клепается.

Есть и хорошие, не сомневаюсь, но мы же об общих тенденциях говорим, о мэйнстриме, а не о приятных исключениях.

 

Только, чур, не надо уточнять, что кроме RealFlex есть еще пара-тройка скада-пакетов под QNX. Это мне известно.

Изменено 2 июня, 2006 пользователем Владимир Е. Зюбин

[Владимир Е. Зюбин 0]

- это идиотизм (прошу прощения за прямоту).

 

Это уже та прямота, которая .... "... хуже воровства".

Долго объяснять в деталях, но вы в корне не правы: нехватка RAM ресурсов выявляется на этапах самого раннего тестирования, а вот непредсказуемость временных реакций - не выявляется никогда, сколь угодно методичным тестированием.

 

То есть дело настолько сложное, что Вы предлагаете поверить Вам на слово?

 

И, пожалуйста, не надо критиковать утверждения, которые я не делал... В этом нет никакого смысла...

(это я намекаю на то, что ни про раннее тестирование нехватки ОЗУ, ни про непредсказуемость я ничего не говорил).

 

С какой стати? Если ограничения - это не Виндовоз, а Ethernet и "моторольный" конец (может еще и с OS-9)??? если есть у Вас 10Мбод, и минимальный пакет по 4Кб, тут уж никуда не деться ... да, не сказал, что послылка занимает примерно миллисекунду, а прием около пяти мс. Тоже информация к размышлению.

 

А здесь просто ... - не делайте мне смешно... ;)

 

1. если это Ethernet, то минимальный пакет: 46 байт данных + 18 байт заголовок = 64;

2. а вот максимальный пакет Ethernet, что интересно, MTU = 1500 + те же 18 байт заголовок MAC уровня;

3. а при пользовательском "минимальный пакет по 4Кб" (а у вас ещё там и максимальные были? ;)) - это сегментация на 3 как минимум IP пакета, а для сегментов IP свои правила задержек передачи, да ещё для каждого сегмента может потребоваться и ARP обмен для разрешения адреса...

4. а при TCP протоколе (у вас же Modbus over TCP?) сегментация может быть и ещё мельче: определяется соотношениями размеров окон приёма и передачи...

5. а обратную посылку подтверждающего сегмента ACK вы учитывали? ("вы обращались к проктологу - правильно ли вы вкладываете свой ваучер?")

6. а алгоритм Нэйгла у вас был включен или выключен? ... он влияет на применение в протоколе отсроченных подтверждений;

 

Вы увлекаетесь желанием показать свою эрудицию и продемонстрировать некомпетентность оппонента. Я Вам отвечаю честно о результатах своих замеров (возможно, в чем-то ошибаясь, например, в оценке минимального размера пакета). Т.к. передо мной не стоит задача пиарить Виндовоз или КуНаХэ... мне на обе эти ОС и их производителей чихать.

 

Так вот. По моим замерам посылка пакета от Wintel к модулю УСО занимает 1 мс. Прием - 5 мс. И мне не особенно важно, предусмотрен ли там ACK, или алгоритм Нэйгла. Могу сообщить, что при посылке устанавливается таймаут, который при значении 2-3 мс начинает изредка срабатывать, так что можно предположить, что подтверждение передачи приходит.

 

Тестовые замеры. По витой паре Ethernet. Связь по Modbus over TCP|IP с выносным модулем цифровых

входов/выходов. Т10 или 100 не скажу. Цикл приема-передачи занимает 6-7 мс. Методика измерений - заряжаем в цикле 1000 пакетов и засекаем секундомером. В конце делим секунды на тысячу...

 

Может вы бы лучше "засекали" загибая пальцы? ;)

Тоже ведь - методика ...

 

Увы, но в Вашей критике очень мало конструктива... Методика вполне рабочая и позволяет оценить среднее время прохождения пакета... единственно, пакетов посылалось не тысячу, а десять тысяч...

 

И что Вы имеете против оценки на глаз? Вполне рабочий вариант для грубой оценки. Или я Вас настолько сильно рассмешил, что Вы уже не можете остановиться? :-)

Изменено 2 июня, 2006 пользователем Владимир Е. Зюбин

[Olej 0]

- эта иллюзия определяется только ОС с использованием timeslice=10мс. (шкала разрешения времени), если вы при 2-х измерениях получили 10мс. (1 слайс), а в 3-м - 0 (вообще слайс не истёк), то среднее вы и оцениваете в 6-7мс. Только вопрос при этом: а что же это вы такое меряли?

В QNX с возможностью уменьшения timeslice до 10мкс. (на 3 порядочка, чуть-чуть) я видел совсем другие цифры и вам могу показать.

Измерял время. Если Вы не понимаете, как можно измерить интервал в 7 мс при таймслайсе в 10 мс (а я этого тоже не понимаю), так может быть Ваши сведения о 10 мс - не соответствуют действительности?

Не приходило в голову? А то, что Вы с другим прибором связывались? Думаете, не имеет значения?

 

Уточняю еще раз: цикл в 6-7 мс складывается из двух составляющих - 1 мс на запись, и 5-6 мс на чтение... определялось это установкой таймаутов.

 

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

 

Уточняю ещё раз ;) ... нельзя мерять милиметры линейкой с ценой деления в сантиметр:

- если это был Windows, как вы сказали, то дискретная шкала времени - 10мс. (15мс. для SMP ядра NT/2000), ... 2 события в ОС, разделённые интервалом меньше этой единицы - не различаются как разные события, они "одновременны"; какие бы вы не записывали в таймауты (или задержки в функциях типа delay()) если они меньше шкалы времени, то это всё равно что 0, и срабатывание произойдёт ... в "хороших" ОС - через 1 timeslise, а в "плохих" - на следующем.

Так что предполагать вы можите всё что угодно, но различать события в Windows более "плотные", чем 10мс. вы не можете.

 

Прошу прощения, нельзя ли чуть менее расплывчато и чуть более конкретно?

Зачем этот субъективизм - "с легкостью уживаются"?

 

Дайте уж возможность собеседнику самому сделать вывод о том, легко процессы уживаются, или нет.

на основании четких сведений о конкретном проекте: чем там управляется, что за специфика, какие требования, какие накладные расходы получены...

 

Затем, что эффективность, производительность, устойчивость ... всё что хотите - приложения в 1 поток и приложения в 100 потоков - практически не различаются (по крайней мере для ОС с эффективно выполняемыми алгоритмами диспетчеризации, а таковых - большинство).

И от того, "чем там управляется, что за специфика, какие требования" и т.д. - показатели диспетчеризации не зависят.

 

У нас беспредметный разговор.

Но нельзя ли привести конкретные данные?

С моей стороны для альтернативных решений числа приведены - это сотни наносекунд на Гигагерцовой частоте на процесс.

У нас предметный разговор ;).

Вы сказали: "эффективность переключения процессов хуже потоков на пару порядков"... я сказал: "это чушь, которая объясняется тем, что это пишут (умозрительно) и в плохих учебниках... эффективность реализации в N процессов практически не хуже, чем N потоков, и более того, и чем простейшей линейной последовательной программы от main() - до exit()".

 

А Вы почитайте специализированную литературу по вопросу. Например, вот эту:

 

On Software Languages for use in Nuclear Power Plant Safety Systems/

Decker D., Dinsmore G., Graff S., Green W., Hecht H., Justice M., Koch S., Lin D.,

Ossia K., Pollard J., Shokri E., Sorkin A., Tai A., Tso K.S., Wendelboe D. - NRC, 1997.

 

Читал я всё это, и ещё много другого ... это - мнения, но есть и другие, полностью противоположные мнения...

Это предмет обсуждений.

Тогда посоветуйте всем здесь использующим С++ категорически не использовать STL (который уже стандарт C++), который бессмысленен без неявного динамического управления памятью.

А древний strdup() ? вы никогда не задавались вопросом откуда он берёт память для создания копии?

 

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

 

Многократно описаны и реализованы стратегии динамического управления памятью, вообще не приводящие к фрагментации. Та же библиотека LOKI.

А как быть с системами с ссылочным созданием объектов и со сборкой мусора, той же Java?

 

А про "скада-на коленке", не стоило упоминать... под Виндовозом их тоже немеряно клепается.

Есть и хорошие, не сомневаюсь, но мы же об общих тенденциях говорим, о мэйнстриме, а не о приятных исключениях.

 

Почему не стоило? :

1. в большинстве - они совершеннее коммерческих пакетов для "всех-и-вся"...

2. ... а Windows системы распределённого управления данными - они всё равно "не жильцы" при длительной эксплуатации - это хорошо только на "презентациях с промоушн" показывать...

[Goroshko 0]

А в чем причина-то? Большая политика? Сделали, а потом поняли, что выбивают сами себе почву из-под ног? 8-) В общем не вижу смысла, да и Вы, я вижу, не желаете приоткрывать завесу над этой тайной.

 

Могу немного приоткрыть завесу. Свопирование данных (не кода) очень важная вешь для работы компиляторов. При переходе на компилятор gcc в 6 QSSL добавили эту функциональность именно для средст разработки и тестированя, кторый требуют обработки больших объемов данных и при этом не обрабатывают ошибки распределения памяти (а кто их обрабатывает? ;-) )

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

В системах ОСРВ нет не свопирования данных и кода приложений, они также не используют механизмов Copy On Write (COW) предназначенных для постепенной подгрузки кода приложения при его запуске, повсеместно применяющегося в ОСОН (и совершенно правильно и обоснованно применяющегося в ОС этого типа), как раз потому, что подгрузка кода после начала его исполнения может приводить к не предсказуемым задержкам его исполнения.

 

По поводу определений ОСРВ. В свое время работая над статьей для книги "Практика работы в QNX" я перерыл очень большое количество определений ОСРВ. Часть этих определений я приводил и в статье, и все они в целом сводятся к определению задач реального времени как задач коректность выполнения которых связана как с самим результатом выполнения так и с временем этого выполнения. Это краеугольный камень понятия "реальное время" и это весьма очевидно. Ведь согласистесь, когда (очень грубый пример, но все же) поступает команда опустить стержни в реактор, и выполняется она после взрыва реактора - то ее выполнение в принципе уже никому не нужно :-).

Более простой пример. Если по требованиям к системе от момента нажатия кнопки оператором на перевод стрелки до факта перевода стрелки должно пройти не более... ну скажем 10 сек, а система по каким то причинам переводит ее через 100 сек когда поезд уже едет по стрелке - то выполнение этой команды уже явно не имеет смыла - задача не выполнена. Думаю в задачах тех же кристалов вы сами можете привести массу примеров.

 

Еще один момент

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

Вы написали хорошую книгу, искренне поздравляю. Но нельзя ли привести конкретные данные?

С моей стороны для альтернативных решений числа приведены - это сотни наносекунд на Гигагерцовой частоте на процесс.

Ссылка на книгу не случайна - там приводятся не только конкретные цифры но и исходные коды тестовых приложений, с помощью которых эти цифры получены. Также эти результаты и архивы тестовых проектов можно найти в разделе публикации сайта qnxclub.net

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

 

Уточняю ещё раз ... нельзя мерять милиметры линейкой с ценой деления в сантиметр:

- если это был Windows, как вы сказали, то дискретная шкала времени - 10мс. (15мс. для SMP ядра NT/2000), ... 2 события в ОС, разделённые интервалом меньше этой единицы - не различаются как разные события, они "одновременны"; какие бы вы не записывали в таймауты (или задержки в функциях типа delay()) если они меньше шкалы времени, то это всё равно что 0, и срабатывание произойдёт ... в "хороших" ОС - через 1 timeslise, а в "плохих" - на следующем.

Так что предполагать вы можите всё что угодно, но различать события в Windows более "плотные", чем 10мс. вы не можете.

Тут нужно еще кое что уточнить - все это верно, если мы меряем события, разделенные блокированным состоянием потока. (delay(0)) Несомнено используя счетчик циклов процессора можно измерять интервал времени с гораздо большей точностью - но если не было вытеснения потока.

[Andrew2000 0]

Так что предполагать вы можите всё что угодно, но различать события в Windows более "плотные", чем 10мс. вы не можете.

Это не совсем так (правда я так и не понял как мерил Зюбин). Но, в виндах есть т.н. Мультимедийный таймер - см. "mmsystem.h"

 

The timeGetTime function retrieves the system time, in milliseconds. The system time is the time elapsed since Windows was started.

DWORD timeGetTime(VOID);

Windows NT: The default precision of the timeGetTime function can be five milliseconds or more, depending on the machine.

Windows 95: The default precision of the timeGetTime function is 1 millisecond.

 

Может пригодиться кому....

Я при пом. этого таймера генерил 5ms импульсы ногами LPT-порта - Win98 / PentumMMX 166 MHz.

Довольно стабильно, пока к винту обращений нет, но не дай бог мышой по экрану возить ... :)

[Olej 0]

Тут нужно еще кое что уточнить - все это верно, если мы меряем события, разделенные блокированным состоянием потока. (delay(0)) Несомнено используя счетчик циклов процессора можно измерять интервал времени с гораздо большей точностью - но если не было вытеснения потока.

 

Всё это так, как и то, что дальше добавил Andrew2000, но и это, и другое, и третье ... на других архитектурах отличных от х86 могут быть другие источники и механизмы задатчиков частот ... но:

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

- и "шаг" этих часов является краеугольным понятием и характеристикой ОС...

- кроме того, неприятность любых других часов в системе, которые можно использовать для измерений, ещё состоит и в том, что они могут "идти" быстрее или медленнее относительно системного времени, потому что используют физически другой задатчик (кварц), и достаточно значительно (я видел в экспериментах порядка 10**-4 для разных экземпляров компьютеров).

 

P.S. для иллюстрации и разрядки, подумалось:

- все знают, что "движущееся" кино вполне реализуемо при смене кадров порядка 20гц (любительские кино камеры использовали 16кадр./сек., кажется)...

- а теперь представьте, что мы "гоним кино" с дискретностью событий медленнее ... во столько раз, во сколько тик Windows длиннее QNX: 10000/10 = 1000 раз, т.е. период смены кадров стал ... 5 сек.

- вот чисто количественное изменение, но что у нас получилось? вместо кино ... ну, в лучшем случае серия сменяющихся "художественных снимков" для журнала комиксов.

Вот что такое чисто количественное изменение параметра!

 

Но и помимо разрешающей способности системного времени,есть ещё одно обстоятельство, которое часто забывается, на которое косвенно обратил внимание Егор: "если он не будет вытеснен" - когда вы записываете timeout( 1 ), то это вовсе не означает, что вы отсчитаете интервал времени в 1сек. - это может быть 1, 2, 10, 100 ... вообще бесконечность.

POSIX в этом смысле чётко определяет: любой интервал не может быть меньше заказанного, но сколь угодно больше - пожалуйста... Но не все ОС строятся на POSIX совместимости.

Так что к измерению временных интервалов нужно подходить ох как осторожно!

[yuri_t 0]

Насчет реального времени как регламентированного время отклика, проблемы

своппинга и т.д. - все это вещи, хорошо известные тем, кто занимается Real Time...

А вот что действительно интересно было бы услышать от поклонников ONX - почему

Microkernel Systems (QNX,Mach, Unix SVR 4, Minix, etc) так и не получили широкого распостранения?

Все-таки уступают по быстродействию системам с монолитным ядром ?

[Olej 0]

Тестовые замеры. По витой паре Ethernet. Связь по Modbus over TCP|IP с выносным модулем цифровых

входов/выходов. Т10 или 100 не скажу. Цикл приема-передачи занимает 6-7 мс. Методика измерений - заряжаем в цикле 1000 пакетов и засекаем секундомером. В конце делим секунды на тысячу...

Приложение LabView(Win2000). Уверен, что на другой ОС никаких улучшений не будет. Т.к. дело тут не в ОС.

 

Вот по этому поводу вспомнил и нашёл - я вот здесь:

http://qnxclub.net/modules.php?name=Forums...er=asc&start=15

- как-то совсем по другому случаю и поводу - замерял время распространения, но с гораздо более точной "линейкой", что и как можете посмотреть по указанному URL, а конечные цифры я сцитирую:

В итого, для компьютеров ~500-600мгц и сети Ethernet 10 мбит/сек:

- время задержки ответа (распространения в 2 стороны) порядка 1.15-1.19 мсек.;

- это на 10mbit/sec : ~600мкс. - это ведь не совсем то, что 6-7мс. ;) - я не претендую на точность, но вот что происходит в зависимости от методики.

[Olej 0]

А вот что действительно интересно было бы услышать от поклонников ONX - почему

Microkernel Systems (QNX,Mach, Unix SVR 4, Minix, etc) так и не получили широкого распостранения?

Все-таки уступают по быстродействию системам с монолитным ядром ?

 

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

Кстати, QNX со своей GUI подсистемой Photon - субъективно весьма "шустрая" ОС, по крайней мере, сравнительно с Windows на том же экземпляре оборудования - гораздо "подвижнее".

 

А "не получили широкого распостранения?"... На то есть достаточно много причин, но это только IMHO:

- ОС на основе микроядра реально появились в 80-х годах (развитые - даже к середине), а уже развитые монолитные ОС - с 1960 и ранее (IBM 360 - классика): 20-25 лет и 45 есть разница? ... ещё не вечер, просто... ;)

- над уже развивающимися проектами (и фирмами) довлеет совместимость: любой проект ОС, который к ~90г. из себя хоть что-то представлял (а представлять он мог только монолитное решение) - обречён был развиваться только в рамках изначально заложенной идеологии;

- монолитные ОС легче в развитии эволюционным путём: MS DOS v.1 - уже была какая-то ОС ... в некотором смысле ;), а потом могла себе позволить эволюционировать в v.3.30 (которая хоть на что-то уже годилась) и далее ... для микроядерных проектов нужна достаточно начальная высокая "ступенька" наработки, когда это можно показать хотя бы как draft-версию ОС.

- микроядерная архитектура - это в значительной мере университетское творение (MTI & ...), монолитное же ядро можно начинать "с коленки", "на хлопский розум" - лучше пример чем Linux здесь и не придумаешь (в этом смысле стоит призадуматься, что ни один проект микроядерной реализации не развивался без поддержки на начальных этапах бюджетной поддержки или госзаказа).

- ... наверное, микроядерная архитектура и не есть наилучшая на все случаи жизни (это только у MS - Windows OS наилучшая для любых применений), в других областях применений могут быть оптимальны и другие архитектуры.

[=AK= 12]

желание "всё написать с нуля" - оно проще, за него проще отвечать, но происходит оно ... от страха (именно и только от страха) использования чужих механизмов.

А страх, прочно базируется на незнании :-( и нежелании/неспособности постигать новое после

некоторого освоения и изобретения первого "лома".

Безапелляционность при отсутствии аргументов, то есть голые понты. Кроме пресловутого "страха" (который вообще можно было и не упоминать, т.к. случаев наверняка мало, мне, например, они вообще неизвестны), есть много других, гораздо более веских причин. Например, ограниченность кругозора, когда человек просто не знает о существовании подходящего продукта, или, если и знает, то (ошибочно) думает, что продукт неприменим для его задачи.

 

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

 

Не говоря уж о том, что "универсальные" продукты просто гарантированно избыточны для каждой отдельно взятой задачи, а расплатой за оную универсальность будет не только размер кода, но и объем информации, который надо перелопатить. Хорошо еще если этот универсальный продукт можно будет применять снова и снова, причем не "механическим повтором", т.к. такой повтор сводит потенциальные преимущества универсального продукта к нулю - проще написать свое и повторять в каждом проекте.

 

Я отнюдь не пытаюсь умалить роль "чужих" решений, они нужны, но они не являются панацеей. В сущности я еще раз другими словами сказал то, что здесь много раз говорили разные ораторы, так что довольно странно видеть здесь процитированные реплики. Если уж такие простые вещи и с пятого раза не доходят, то что же можно ожидать от описаний на относительно сложные продукты, сколько раз их придется перечитать, пока информация усвоится?

[=AK= 12]

Зюбин - единственный, кто утверждает, что IL произошел от STEP5.

Ясно, спасибо за информацию.

На сайте Фиорда в презенташке нашел: "IL - Подобен SIEMENS (Step 5)"

т.е. наверное Step 5 подобен IL :)

На всякий случай я задал вопрос о том, действительно ли IL произошел от Step5 г-ну von Ingo Rolle, члену IEC от Германии, автору книги "IEC 61131, Wozu?". К сожалению, книга написана на немецком, которым я не владею, однако уважаемый автор не поленился мне ответить. Он пишет: "the book says in chapter 4.2 that German contributions to IEC 61131-3 were DIN 19239 and VDI Richtlinie 2880 which already contained precursors of IL, FBD and LD." Как видим, о сименсовском Step5 речи не идет, т.е., как и ожидалось, Зюбин бредит.

[Владимир Е. Зюбин 0]

'Владимир Е. Зюбин':"Измерял время. Если Вы не понимаете, как можно измерить интервал в 7 мс при таймслайсе в 10 мс (а я этого тоже не понимаю), так может быть Ваши сведения о 10 мс - не соответствуют действительности?

Не приходило в голову? А то, что Вы с другим прибором связывались? Думаете, не имеет значения?

 

Уточняю еще раз: цикл в 6-7 мс складывается из двух составляющих - 1 мс на запись, и 5-6 мс на чтение... определялось это установкой таймаутов.

 

Могу сообщить, что при посылке устанавливается таймаут, который при значении 2-3 мс начинает изредка срабатывать, так что можно предположить, что подтверждение передачи приходит."

 

Уточняю ещё раз ;) ... нельзя мерять милиметры линейкой с ценой деления в сантиметр:

- если это был Windows, как вы сказали, то дискретная шкала времени - 10мс. (15мс. для SMP ядра NT/2000), ... 2 события в ОС, разделённые интервалом меньше этой единицы - не различаются как разные события, они "одновременны"; какие бы вы не записывали в таймауты (или задержки в функциях типа delay()) если они меньше шкалы времени, то это всё равно что 0, и срабатывание произойдёт ... в "хороших" ОС - через 1 timeslise, а в "плохих" - на следующем.

Так что предполагать вы можите всё что угодно, но различать события в Windows более "плотные", чем 10мс. вы не можете.

Почему Вы не можете предположить, что в Винде можно получать разрешение в 1 мс?

Мои опыты прямо приводят к этому выводу. Почему, когда я устанавливаю таймаут в 4 мс, таймаутов не наблюдается, а когда устанавливаю 2-3 они начинают появляться?

 

То же самое и про измерение линейками... Вы просто не владеете простыми методиками.

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

просто измерять надо не единичный процесс, а серию... тысячу, или десять тысяч, или сто тысяч...

задачка-то простая:

Дано: длительность N операций равна T.
Найти: длительность одной операции.

ПОНЯТНО, что измеряется СРЕДНЕЕ время, но если длительность процессов более-менее постоянная, то методика вполне рабочая и для оценки времен вполне годится.

 

'Владимир Е. Зюбин':"Прошу прощения, нельзя ли чуть менее расплывчато и чуть более конкретно?

Зачем этот субъективизм - "с легкостью уживаются"?

 

Дайте уж возможность собеседнику самому сделать вывод о том, легко процессы уживаются, или нет.

на основании четких сведений о конкретном проекте: чем там управляется, что за специфика, какие требования, какие накладные расходы получены... "

 

Затем, что эффективность, производительность, устойчивость ... всё что хотите - приложения в 1 поток и приложения в 100 потоков - практически не различаются (по крайней мере для ОС с эффективно выполняемыми алгоритмами диспетчеризации, а таковых - большинство).

И от того, "чем там управляется, что за специфика, какие требования" и т.д. - показатели диспетчеризации не зависят.

Увы, я опять не увидел, ни чисел, ни данных... "практически не различается" - это малоинтересная лирика. Вам же была дана конкретная цифра "накладные расходы на обслуживание процесса на 1ГГц процессоре составляют приблизительно 200 нс". А Вы в ответ "практически не различается" - это что больше, или меньше, чем 200 нс?

 

'Владимир Е. Зюбин':"У нас беспредметный разговор.

Но нельзя ли привести конкретные данные?

С моей стороны для альтернативных решений числа приведены - это сотни наносекунд на Гигагерцовой частоте на процесс."

 

У нас предметный разговор ;).

Вы сказали: "эффективность переключения процессов хуже потоков на пару порядков"... я сказал: "это чушь, которая объясняется тем, что это пишут (умозрительно) и в плохих учебниках... эффективность реализации в N процессов практически не хуже, чем N потоков, и более того, и чем простейшей линейной последовательной программы от main() - до exit()".

 

У нас БЕСПРЕДМЕТНЫЙ РАЗГОВОР, т.к. Вы до сих пор не привели ни одной цифры.

 

'Владимир Е. Зюбин':"А Вы почитайте специализированную литературу по вопросу. Например, вот эту:

 

On Software Languages for use in Nuclear Power Plant Safety Systems/

Decker D., Dinsmore G., Graff S., Green W., Hecht H., Justice M., Koch S., Lin D.,

Ossia K., Pollard J., Shokri E., Sorkin A., Tai A., Tso K.S., Wendelboe D. - NRC, 1997."

 

Читал я всё это, и ещё много другого ... это - мнения, но есть и другие, полностью противоположные мнения...

Это предмет обсуждений.

Тогда посоветуйте всем здесь использующим С++ категорически не использовать STL (который уже стандарт C++), который бессмысленен без неявного динамического управления памятью.

А древний strdup() ? вы никогда не задавались вопросом откуда он берёт память для создания копии?

Чего тут обсуждать-то? 8-)

Динамические операции с ОЗУ приводят к дефрагментации памяти, а возможно и к утечкам...

В первом случае возникают неконтролируемые задержки, во-втором вообще-крах системы...

Ну, чего тут обсуждать? :-)))

 

То, что программирование на Си++ менее безопасное, чем на Си? Это секрет Полишенеля, про который

уже везде писано-переписано...

 

Просто надо трезво смотреть в глаза фактам. То, что Си++ кто-то использует и потом гнет пальцы о какой-то там надежности и предсказуемости, детерминизме и реальном времени - так это лично его проблемы... ;-) страусы - они ровно те же проблемы имеют. ;-)

 

'Владимир Е. Зюбин':"То, что дефрагментация памяти при динамических операциях ведет к потере производительности, не такая уж и революционная мысль... и непонятно, что тут дискуссионного."

 

Многократно описаны и реализованы стратегии динамического управления памятью, вообще не приводящие к фрагментации. Та же библиотека LOKI.

А как быть с системами с ссылочным созданием объектов и со сборкой мусора, той же Java?

А что такое сборка мусора, по Вашему? 8-) По мне, так это источник непредсказуемых задержек.

 

'Владимир Е. Зюбин':"А про "скада-на коленке", не стоило упоминать... под Виндовозом их тоже немеряно клепается.

Есть и хорошие, не сомневаюсь, но мы же об общих тенденциях говорим, о мэйнстриме, а не о приятных исключениях."

 

Почему не стоило? :

1. в большинстве - они совершеннее коммерческих пакетов для "всех-и-вся"...

2. ... а Windows системы распределённого управления данными - они всё равно "не жильцы" при длительной эксплуатации - это хорошо только на "презентациях с промоушн" показывать...

 

1. ... только очень дороги в эксплуатации...

2. ... это Ваше личное мнение, которое расходится со статистическими данными.

Изменено 3 июня, 2006 пользователем Владимир Е. Зюбин

[Olej 0]

Безапелляционность при отсутствии аргументов, то есть голые понты. Кроме пресловутого "страха" (который вообще можно было и не упоминать, т.к. случаев наверняка мало, мне, например, они вообще неизвестны), есть много других, гораздо более веских причин. Например, ограниченность кругозора, когда человек просто не знает о существовании подходящего продукта, или, если и знает, то (ошибочно) думает, что продукт неприменим для его задачи.

 

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

 

АК, это я по неосторожности употребил первым термин "страх" ... но совсем в другом смысле: именно опасения взвешивающего альтернативные решение специалиста, и стремление его быть ответственным в своих выборах. И это есть в точности то, что вы описываете.

И только в таком смысле я это употребил... а оно потом "пошло поехало", а поправляться лень было.

Прошу почтенную публику воспринимать термин "страх" в контексте данного разговора - только так :cheers:

 

 

Почему Вы не можете предположить, что в Винде можно получать разрешение в 1 мс?

Мои опыты прямо приводят к этому выводу. Почему, когда я устанавливаю таймаут в 4 мс, таймаутов не наблюдается, а когда устанавливаю 2-3 они начинают появляться?

 

Я не "не могу предположить" (предположить - это вообще из области веры) - а я знаю:

- у каждой ОС есть величина разрешения системного времени;

- и получить системные интервалы меньше - нельзя;

- можно измерять сторонним источником, как здесь справедливо дополнили, но получить интервал - нельзя;

- и я знаю, что в Windows величина этого разрешения - 10мс. (для SMP - 15мс.);

- очень многи разработчики ОС стараются не афишировать эту величину ... но предыдущие цифры найдены в глубине техдокументации MS.

 

То же самое и про измерение линейками... Вы просто не владеете простыми методиками.

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

 

Владимир, я владею методиками ;) ... по крайней мере такими (по-моему с методикой арифметического усреднения впервые знакомятся в 3-м классе церковно-приходской школы).

 

ПОНЯТНО, что измеряется СРЕДНЕЕ время, но если длительность процессов более-менее постоянная, то методика вполне рабочая и для оценки времен вполне годится.

 

При одном маленьком "но": если эти ваши "процессы" следуют непрерывной чередой друг за другом, без промежутков ... чего в многозадачной ОС не бывает (за исключением простейших искусственных циклов for(...)), а тем-более - в области TCP/IP стека, где всё в высшей степени асинхронно, и подчиняется множеству дополнительных алгоритмов (сегментация 2-х уровней: и MAC и IP, ARP разрешение, ... некоторые я называл). И вот тут, когда промежутки между иизмеряемыми "процессами" на порядки превосходят по длительности сами "процессы" - усреднение "не стреляет"!

 

Увы, я опять не увидел, ни чисел, ни данных... "практически не различается" - это малоинтересная лирика. Вам же была дана конкретная цифра "накладные расходы на обслуживание процесса на 1ГГц процессоре составляют приблизительно 200 нс". А Вы в ответ "практически не различается" - это что больше, или меньше, чем 200 нс?

 

Я специально не дал (и не дам ;)) цифр, потому что предмет объёмный, не "с кандачка" - а я вам указал источник, где страниц 150 уделено этим вопросам и цифрам ... хотите - посмотрите, не хотите - значит и не очень надо ;).

Но важно то, что здесь логика совершенно другая, чем вы толкуете с 200 нс-ами ;):

- диспетчирование в многозадачной ОС происходит и над одним единственным процессом/потоком, с той же интенсивностью как и при множестве...

- но самое клавное, что в тех же узлах сетки системного времени, где происходит и диспетчирование, происходит обслуживание службы времени ОС (изменение уставок таймеров, статистики использования времени потоками и мн. другое) и эта работа более трудоёмкая, чем переключение или не переключение контекста...

 

В результате на ваш вопрос: "это что больше, или меньше?" я отвечу, что это примерно не более 10% разницы при переключении процессов по сравнению с работой 1-го процесса. Но уж никак не на "пару порядков" которыми вы пугали, и которые кочуют также из одного плохого учебника в другой. Кроме того, и это "больше, или меньше?" сильно (25%-50%) зависит от величины всё того же системного тика, установленного в системе (там, где его можно менять).

 

Чего тут обсуждать-то? 8-)

Динамические операции с ОЗУ приводят к дефрагментации памяти, а возможно и к утечкам...

В первом случае возникают неконтролируемые задержки, во-втором вообще-крах системы...

Ну, чего тут обсуждать? :-)))

 

Динамические операции могут выполняться разными алгоритмами - это не данность (хотя и есть стандартный по умолчанию), и вы можете использовать свой под класс задач - в этом случае динамические операции могут вообще не приводить к ... фрагментации (а не "дефрагментации", Владимир - этоб счастье было бы если так ;)).

 

P.S. посмотрите, как динамическое управление было сделано в pSOS - и вас возникнет много вопросов к тому, что вы утверждаете.

 

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

 

То, что программирование на Си++ менее безопасное, чем на Си? Это секрет Полишенеля, про который

уже везде писано-переписано...

 

Более безопасно! ... Хотя что вы называете "безопасно"? Я знаю только 1 опасность - скрытые ошибки.

В С++ их будет меньше. Главный фактор: строгая и именная (не структурная!) типизация. Всё остальное - как следствие.

[Goroshko 0]

Насчет реального времени как регламентированного время отклика, проблемы

своппинга и т.д. - все это вещи, хорошо известные тем, кто занимается Real Time...

А вот что действительно интересно было бы услышать от поклонников ONX - почему

Microkernel Systems (QNX,Mach, Unix SVR 4, Minix, etc) так и не получили широкого распостранения?

Все-таки уступают по быстродействию системам с монолитным ядром ?

Естественно уступают. Только надо уточнять в чем и почему. Теоретически микроядерные системы с обменом сообщениями должны работать медленнее чем момнолитные по следующим причинам:

1. При высокой степени модульности возникают IPC взаимодействия там где в монолитной ОС их нет.

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

2. В QNX например, благодаря модульности системы, работа разных подсистем ОС выполняется в разных "кругах" защиты х86 процессора - следовательно получаем дополнительные задержки на переключения контекста.

- Опять же с другой стороны - поскольку только ядро, отвечающее за весьма узкий круг функций находится в 0 кольце защиты благодаря такой распределенности отдельные подсистемы могут быть легко остановлены и перезапущены.

 

В общем если еще раз процитировать старую поговорку - "Что русскому в радость - немцу смерть" :-)

И вообще попробуйте провести другую аналогию по типу Винда - QNX. Почему не рассматривается вопрос написания систем реального времни на Visual Basic ? Почему обсуждается С или С++? Давайте тогда уже и Visual Basic примем! А что, он тоже по сравнению с обычным Basic стал намного лучше :-)

И что? Почему то такие идеи не возникают... (Тьфу, тьфу, тьфу, что бы не сглазить)

 

А насчет получения широкого примения микроядерными системами. Дело в том что почти сразу (лет 10) :-) после их появления началась новая волна, развивающая идеи микроядерных ОС - объектные ОС.

В этом плане очень интерестным примером развития является Singularity от Microsoft Reseach:

http://rsdn.ru/article/singularity/singularity.xml

Хотя это и не имеет отношения к теме этой дискуссии - просто илюстрирует развитие ОС.