IT в России и мире в реалиях мирового кризиса

Цитата: small__virus от 01.01.2017 08:17:13Не обязательно. Есть контроллер прерываний. Есть иерархия прерываний.
Прерывания таймера, например, приоритетнее обработки прерываний клавиатуры.
Последний раз, когда я писал в институте обработчик прерываний (2 или 3-й курс, если мне не изменяет склероз), контроллер прерываний хранил в своем стеке от 16 до 255 прерываний (вот не помню просто). Естественно, во время обработки прерывания таймера еще раз обработка прерывания таймера произойти не может.

Если Вы о 8259a, который скорее всего и программировали, то у него никакого стека для хранения прерываний нет. Он либо теряет запросы, если прерывания инициируются фронтом IRQ (как в PC/AT), либо запросы от устройств просто "ожидают" обслуживания на схемотехническом уровне, если они инициируются уровнем (как на шине PCI).

В реальности процессор/ядро работают  достаточно шустро, чтобы все прерывания можно было успеть обработать, потому что устройства, требующие участия процессора в обработке прерываний, работают медленно. Быстрые устройства, такие, как сетевые карты и контроллеры SATA/SAS на шине PCI Express делают все сами и лишь уведомляют процессор о своих "намерениях" и "результатах", чтобы драйвер мог адекватно отреагировать на получение/отправку данных.

Цитата: Senya от 01.01.2017 08:30:47Нет, он всё правильно написал, пусть немного и непонятно. В доведении до абсурда - если прерывания приходят с частотой большей, чем частота переключения входного каскада, смогут они регистрироваться? Нет. Ну и после приёма сигнала нужно несколько (десятков/сотен) тактов на его регистрацию. Может быть всё вплоть до разнесения по входам аппаратных стеков для ускорения процесса, но это ньюансы.

Прерывание там вообще не причем. Вернее, это отбельная и совсем узкая тема. Ваять контроллер на железе без запаса по производительность – жесть.
Регистрировать событие для реалтайма - пол дела. Важно отработать его вовремя, и не просто «вроде успеваем», а конкретные цифры с расчетами и доказательствами. Это тянет за собой целую кучу особенностей и ограничений на операции с неясным временем выполнения. Диск, сеть, элементарное выделение памяти в куче – уже криминал.

Цитата: Hadan от 01.01.2017 15:44:40Прерывание там вообще не причем. Вернее, это отбельная и совсем узкая тема. Ваять контроллер на железе без запаса по производительность – жесть.
Регистрировать событие для реалтайма - пол дела. Важно отработать его вовремя, и не просто «вроде успеваем», а конкретные цифры с расчетами и доказательствами. Это тянет за собой целую кучу особенностей и ограничений на операции с неясным временем выполнения. Диск, сеть, элементарное выделение памяти в куче – уже криминал.

Да, при управлении реальным процессом (скажем движущимся транспортом) ОС РВ должна гарантировать завершенную реакцию системы за заданное лимитированное время. Практически это означает что следующее прерывание не должно поступить ранее чем полностью завершится отработка предыдущего прерывания, иначе можно не успеть завершить обработку предыдущего. Другими словами ОС РВ способна гарантированно обрабатывать лишь одну последовательность прерываний для одного высшего приоритета, то есть решать лишь одну задачу реального времени. При этом прерывания меньших приоритетов уже не могут быть гарантированно выполнены в реальном времени, а могут обрабатываться лишь с непредсказуемой задержкой в фоновом режиме.
    Так было для однопроцессорных ОС типа RT-11. Но с появлением многоядерных процессоров для ОС РВ возникли более широкие возможности маневра вычислительными ресурсами, чтобы таким образом гарантировать обработку в реальном времени прерываний для нескольких приоритетов ( в пределе - по числу процессорных ядер )

... дискуссии на этом форуме называю срачем. Но если кому нечем развлечься, можно почитать комменты про процессор Байкал )
http://ammo1.livejournal.com/708845.html

Цитата: Поверонов от 01.01.2017 20:01:35Да, при управлении реальным процессом (скажем движущимся транспортом) ОС РВ должна гарантировать завершенную реакцию системы за заданное лимитированное время. Практически это означает что следующее прерывание не должно поступить ранее чем полностью завершится отработка предыдущего прерывания, иначе можно не успеть завершить обработку предыдущего. Другими словами ОС РВ способна гарантированно обрабатывать лишь одну последовательность прерываний для одного высшего приоритета, то есть решать лишь одну задачу реального времени. При этом прерывания меньших приоритетов уже не могут быть гарантированно выполнены в реальном времени, а могут обрабатываться лишь с непредсказуемой задержкой в фоновом режиме.
    Так было для однопроцессорных ОС типа RT-11. Но с появлением многоядерных процессоров для ОС РВ возникли более широкие возможности маневра вычислительными ресурсами, чтобы таким образом гарантировать обработку в реальном времени прерываний для нескольких приоритетов ( в пределе - по числу процессорных ядер )

Да бросьте Вы, как раз хватало ОС-РВ и "Электроники-60", чтобы отрабатывать прерывания от контроля обработки детали в той же электрохимии и не только....
Я сейчас не помню скорость обработки прерываний, но суть в том, что во время обработки текущего включался механизм отложенных прерываний и они сохранялись или в регистрах или в стеке памяти (где точно забыл блин, тридцать лет прошло всё-же), и извлекались по мере высвобождения системы от оперативной обработки текущего, которое понижалось а приоритете и порождало процесс второго(?) уровня, а основной ресурс на извлечённое.... 
Тут главное просчитать максимально допустимое время просчёта принятия решения по текущему, и иметь механизм принудительного завершения затянувшейся обработки если выходит за лимит времени. Главным в этом случае становится не оптимальное решение, а просто принятие решения.
При этом система работала как по прерываниям от событий, так и по временным прерываниям...
В работе одновременно могло быть несколько десятков прерываний, и несколько запущенных параллельных процессов с разделением времени.

Цитата: AndreyK-AV от 02.01.2017 00:25:42Я сейчас не помню скорость обработки прерываний, но суть в том, что во время обработки текущего включался механизм отложенных прерываний и они сохранялись или в регистрах или в стеке памяти (где точно забыл блин, тридцать лет прошло всё-же), и извлекались по мере высвобождения системы от оперативной обработки текущего, которое понижалось а приоритете и порождало процесс второго(?) уровня, а основной ресурс на извлечённое....

Все было совершенно по-другому. Прерывания инициировались по 4-м линиям уровнем по ИЛИ, что позволяло "хранить" запросы на схемотехническом уровне. Аналогичный метод реализован на шине PCI и тоже всего 4 линии. Никаких стеков и регистров для складирования запросов не было. Да и нет их нигде. Запросы от устройства физически не могут поступать быстрее, чем они будут обработаны.

Цитата: adolfus от 02.01.2017 02:52:10Все было совершенно по-другому. Прерывания инициировались по 4-м линиям уровнем по ИЛИ, что позволяло "хранить" запросы на схемотехническом уровне. Аналогичный метод реализован на шине PCI и тоже всего 4 линии. Никаких стеков и регистров для складирования запросов не было. Да и нет их нигде. Запросы от устройства физически не могут поступать быстрее, чем они будут обработаны.

Я не говорю как было у вас, я говорю как решили это мы. 
Естественно плата ввода вывода "своя", и на ней схемотехническое решение доработано.
Если Вы под понятием запрос понимаете очередной битовый электрический сигнал от датчика (после ЦАП-АЦП), то извиняйте, но это уже совсем об ином и решается на плате схемотехнически.
А вот дальше дело операционных систем и драйверов, которые и совершают работу, 
и опять же, я сейчас говорю только про работу с "Электроникой 60" с интерфейсом "общая шина". 
Вы не путайте понятие прерывание и порождёный ими запрос на обработку. 
Прерывание вполне себе хранятся в стеке или регистрах, 
если скорость обработки процессора позволяет, 
а порождённый запрос вполне себе обрабатывается, 
совместно с предыдущими, конкурируя за ресурсы процессора....

Цитата: AndreyK-AV от 02.01.2017 10:23:39Прерывание вполне себе хранятся в стеке или регистрах, 
если скорость обработки процессора позволяет, 
а порождённый запрос вполне себе обрабатывается, 
совместно с предыдущими, конкурируя за ресурсы процессора....

Назовите хоть одну систему, где "прерывания хранятся в стеке или регистрах"?

Цитата: Hadan от 02.01.2017 16:06:59

Логично. Хотя я так и не понял, как внешние события узнают «можно им произойти физически и или еще рано».  

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

Не на векторе, а на линии. Все однофункциональные устройства на шине PCI могут сидеть на одной физической линии INTA и бесконфликтно обслуживаться.
Вектор -- это всего лишь число, которое устройство или контроллер прерываний выставляет на шину в специальном цикле шины обработки IRQ. Как это число интерпертируется и обрабатывается, зависит от конкретной системы. В DEC и IBM PC/AT вектор интерпретируется, как индекс в таблице прерываний.

Насчет того, "как внешние события узнают «можно им произойти физически и или еще рано»". Событиям ничего не нужно узнавать -- они просто происходят в случайные моменты времени с некоторой частотой. Представьте очень простое устройство, которое принимает данные, символ за символом приходящие по некоторой линии в случайные моменты времени, накапливает их в буфере, и по заполнению передает содержимое буфера в ОС. Как только буфер приема заполняется, устройство перестает принимать данные с линии и инициирует прерывание. Обработчик прерывания забирает данные из буфера и разрешает прием данных с линии. Пока буфер не будет готов принимать символы, они будут игнорироваться, если поступят, поэтому следующий запрос на прерывание может возникнуть только после того, как предыдщий будет обработан.
Что происходит в процессе обработки запроса с поступающими с линии символами, решается отдельно. RS-232 "умеет", например, RTS/CTS. Сетевые карты и видеоадаптеры имеют два буфера, один из которых пишется в те моменты, когда читается другой.
 

Цитата: adolfus от 02.01.2017 16:45:11Назовите хоть одну систему, где "прерывания хранятся в стеке или регистрах"?

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

Цитата: adolfus от 02.01.2017 16:45:11Назовите хоть одну систему, где "прерывания хранятся в стеке или регистрах"?

Давайте определимся о чем говорим. 
Мне конечно сложно вспоминать "дела давно минувших дней", к которым пришлось возвращаться крайний раз в конце 1999, когда эксплуатанты интересовались повлияет ли на наши разработки 15-летней давности проблема 2000.
В RSX-11 ну и в ОСРВ СМ существуют механизмы обработки прерываний, он кратко но неплохо расписан у Р. Экхауз, Л. Морррис МИНИ-ЭВМ:Организация программирование 1983 года. страница 233.
Т.е. обсуждаем тот момент когда информация будет передана на устройство I/O или прочитана с него, а так как цикл продолжительный, то система не ждёт, а за счёт исключения времени ожидания, выполняет другие работы. А чтобы не терять новые прерывания работают ISR (программы обработки прерывания)
Естественно что лучше расписано в документации, но где её сейчас найдёшь.

Цитата: slavae от 02.01.2017 18:33:26Могу предложить. Обработка прерывания должна заключаться всего лишь в помещении данных о нём в собственный стек, который обрабатывается независимым процессом. Тогда по крайней мере данные об аппаратном прерывании не улетят в никуда.

Они и так никуда не улетают без всяких стеков и регистров. Система реального времени всегда строится таким образом, чтобы никуда ничего не пропадало. Для разгребания запросов на обслуживание не стеки используются, а очереди с приоритетами. И занимается всем этим контроллер прерываний. Система же потребляет уже то, что этот контроллер упорядочил и раздал по процессорам/ядрам. Вот тут, тут и  тут в главе 10 описано, как это все работает и почему ничего нигде не протекает. Курим до посинения прежде чем продолжим про прерывания.

Цитата: adolfus от 02.01.2017 22:57:26Они и так никуда не улетают без всяких стеков и регистров. Система реального времени всегда строится таким образом, чтобы никуда ничего не пропадало. Для разгребания запросов на обслуживание не стеки используются, а очереди с приоритетами. И занимается всем этим контроллер прерываний. Система же потребляет уже то, что этот контроллер упорядочил и раздал по процессорам/ядрам. Вот тут, тут и  тут в главе 10 описано, как это все работает и почему ничего нигде не протекает. Курим до посинения прежде чем продолжим про прерывания.

Я знаю про прерывания только на основе 580-й серии, вкорячивал 59-й контроллер в самопаяный Орион-128 из Моделиста-конструктора )
Нужно будет - изучу существующие конкретные решения, но они не запрещают мне думать самому 

Цитата: AndreyK-AV от 03.01.2017 00:12:08Особенности, свойственные операционной системе RSX-11, определяемые ее способностью работать с асинхронными процессами с помощью механизма обработки отложенных прерываний, позволяют задаче-клиенту запускать множество параллельно работающих удаленных подпрограмм-серверов. Каждая подпрограмма-сервер также может порождать множество других удаленных процессов.

С RSX-11 работал я очень мало... Почти сразу пересел за VAX-VMS (в варианте МОС ВП на ИЗОТ-1700, он же СМ-1700).
А вот с фирменными железяками DEC столкнулся слегка позже... Были очень интересные штуки. Например, принтеры DEC TurboPrint Server 20 и 40. Оба работали под управлением VAX ELN - операционка реального времени (приобретена VX-Works). Кстати, работали бы и до сих пор, (сплошной металл), но оказалось, что дешевле менять принтеры от HP раз в три-четыре месяца, чем их содержать. Сетевые карты, которые стояли в DECNIS и AlphaServer-2100 имели по 16 заводских MAC-адресов (младший байт адреса был задействован для каждой карты, + дополнительно назначаемые для DECNET Phase IV + ...). Таких железок уже не делают (купил Intel).
Ну и даже мой DS-10 тоже может немало, несмотря на его древность. И VMS до сих пор способна работать в режиме, близком к реалтайму. Многое просто оказалось невостребовано.
С другой стороны, под многочисленные микроконтроллеры ARM во всю живет FreeRTOS, и не только...

Цитата: Цитатасистемы реального времени бывают 2х типов: QNX и сотоварищи (их много, в том числе самоправленных разными концернами) и WIndows-style

Цитата:  Цитата: Valery от 03.01.2017 00:22:57С другой стороны, под многочисленные микроконтроллеры ARM во всю живет FreeRTOS, и не только...

Второе мнение значительно ближе к истине.

Помимо QNX, есть много заслуженных вполне себе "жесткого" или "настоящего" (в системах "мягкого" реального времени лишь обеспечивается реализация временных ограничений в заданном проценте случаев, или с заданной вероятностью) реального времени, например:
семейство VxWorks
Lynx
RTOS
Есть отечественные варианты, например - JetOS
И вообще 

Цитата: TAU от 03.01.2017 21:28:57Второе мнение значительно ближе к истине.

Помимо QNX, есть много заслуженных вполне себе "жесткого" или "настоящего" (в системах "мягкого" реального времени лишь обеспечивается реализация временных ограничений в заданном проценте случаев, или с заданной вероятностью) реального времени, например:
семейство VxWorks
Lynx
RTOS
Есть отечественные варианты, например - JetOS
И вообще 

Пытаясь разобраться в костях QNX пришел к выводу что в сущности она не имеет ничего специального для реального времени, а лишь предоставляет микроядро непосредственно поддерживающее pthreads, то есть по сути это такая же система разделения времени но с очень быстрым переключением контекстов потоков управления. Полагаю, что и фриварные RTOS построены аналогично. 
Если они предоставляют интерфейс POSIX, то вероятно несложно слепить linux docker  для фриварной RTOS, тогда станет возможным гонять в ней всевозможные докеры с меньшими затратами на переключения, чем в linux хостах.

Цитата: Поверонов от 03.01.2017 23:05:36Пытаясь разобраться в костях QNX пришел к выводу что в сущности она не имеет ничего специального для реального времени, а лишь предоставляет микроядро непосредственно поддерживающее pthreads ...

1) Какая QNX? 4.x или 6.x?
2) pthreads -- всего лишь интерфейс, а под ним может лежать любая реализация.
3) Переключение потоков это хорошо, но для ОС РВ важнее запросы от внешних устройств обслуживать. В некоторых случаях проще и надежнее использовать полсотни дешевых одноядерных одноплатников, чем один дорогой мультипроцессорный или мультиядерный комп, и работать в невытесняющем режиме, когда задача освобождает процессор либо сама, либо в пользу системного процесса, т.е. по принципу "одно ядро -- одна задача". В этом случае pthreads даже в генерации системы может не участвовать...

Цитата: slavae от 15.12.2016 11:59:24Системная плата на микропроцессоре Эльбрус-8С

Всем привет!
немного эксклюзива: материнка для персоналки Эльбрус 801-РС на новом микропроцессоре Эльбрус-8С!
Это предсерияная партия плат, для внутренней отладки, но на серийной партии микропроцессоров.
Работа идет полным ходом по наладке, для того что бы во второй половине 2017 года можно было отгрузить персоналки, а далее и четырехпроцессорный сервер на Эльбрус-8С для конечных потребителей.
Сразу скажу: в видео засветились только 4 платы: они остались на выходные для окончания монтажа. Они и попали в мои руки. Так же ранее было выпущено еще некоторое количество плат за предыдущие пол года.
От себя добавлю: по производительности — сущий термояд! все летает, но это еще не до конца оптимизировано ПО! так что хочу всех поздравить: Эльбрус-8С уже на уровне производительности с зарубежными аналогами!

Год назад наша контора получала на тестирование сервер на Эльбрус-4С. В этом году получили сервер на Эльбрус-8С.
Если камрадам интересно, можем немного на эту тему пообщаться.
В целом, впечатления неоднозначные

Цитата: ps_ от 05.01.2017 16:18:37Очень интересно

Тогда пишите более-менее конкретно, что интересно.
Из того что помню по прошлому году без записей - с java работа была неудовлетворительной. Говорят (разработчики) что сейчас это дело поправили и java1.8 работает сносно. Мне это частично удалось проверить на SPECjvm®2008. Для сравнения был использован ноут на атоме N2500 и ПК на Э-4С (система свежая, ПК был привезен нам вместе с сервером Э-8С), результаты близки (+/- 15%). Не все тесты прошли, подозреваю что из-за openjdk, но особо не выяснял пока. Год назад ситуация по скорости java была на порядок хуже (как бы не на два).
На мой взгляд вымораживают следующие обстоятельства:
1. Уникальный дистрибутив (частично на Debian базируется). По хорошему такого быть не должно. Нужны полноценные дистрибутивы Debian и CentOS, за вычетом аппаратно-зависимых пакетов (ядро, загрузчик). Т.е., не должны разработчики в МЦСТ вариться в собственном соку, лучше бы те же усилия прикладывали для кооперации с имеющимися командами
2. Средства эмуляции и виртуализации. Сейчас есть два таких средства - исполнение x86 бинарников и полная эмуляция x86 машины. Если бы я эксплуатировал сервера на базе Эльбруса, то мне не хватало бы в первую очередь qemu+KVM, хотя сейчас мощность серверов не так чтоб избыточна для использования в качестве платформы виртуализации. Для стороннего же разработчика важно иметь средства эмуляции на x86 платформе, для того чтобы можно было собирать и отлаживать свое ПО без кросс-сборки и без реальной железки. Последнее - важно, если МЦСТ хочет иметь полноценные порты дистрибутивов и ПО на своей платформе
3. GCC. Есть lcc, но не уверен что им нормально соберется большая часть пакетов. Более того, уверен что большая часть не соберется в силу тех или иных причин. Вместо того чтобы делать свой велосипед на титановых колесах с реактивным приводом - лучше бы запилили поддержку gcc на своей платформе
4. Ванильное ядро ничего не знает про архитектуру Эльбрус. Форк пилится МЦСТ самостоятельно, причем версии ядра довольно древние. Необходимо сливать свои наработки в апстрим, растить сторонних разработчиков. А для этого необходимы дешевые железки по учебным заведениям и по почте на заказ, тогда может быть и будет пул разработчиков лет через 5. Своими силами новую платформу одна фирма не вытянет, как мне кажется. 

Цитата: TydymBydym от 05.01.2017 16:56:452. Средства эмуляции и виртуализации. Сейчас есть два таких средства - исполнение x86 бинарников и полная эмуляция x86 машины. Если бы я эксплуатировал сервера на базе Эльбруса, то мне не хватало бы в первую очередь qemu+KVM, хотя сейчас мощность серверов не так чтоб избыточна для использования в качестве платформы виртуализации. Для стороннего же разработчика важно иметь средства эмуляции на x86 платформе, для того чтобы можно было собирать и отлаживать свое ПО без кросс-сборки и без реальной железки. Последнее - важно, если МЦСТ хочет иметь полноценные порты дистрибутивов и ПО на своей платформе
3. GCC. Есть lcc, но не уверен что им нормально соберется большая часть пакетов. Более того, уверен что большая часть не соберется в силу тех или иных причин. Вместо того чтобы делать свой велосипед на титановых колесах с реактивным приводом - лучше бы запилили поддержку gcc на своей платформе
4. Ванильное ядро ничего не знает про архитектуру Эльбрус. Форк пилится МЦСТ самостоятельно, причем версии ядра довольно древние. Необходимо сливать свои наработки в апстрим, растить сторонних разработчиков. А для этого необходимы дешевые железки по учебным заведениям и по почте на заказ, тогда может быть и будет пул разработчиков лет через 5. Своими силами новую платформу одна фирма не вытянет, как мне кажется.

Я правильно понял, что ядро скомпилировано для "родной" системы команд, а все остальное работает под эмулятором x86?
А Вы пробовали скомпилировать какие-нибудь простые тесты в "родной" системе команд и сравнивнить быстродействие с эмулятором и соседней машиной на x86?

А вообще насколько быстро все работает с точки зрения обычного пользователя? Ну если сидеть в GUI, лазить по интернету и что-нибудь простое писать на OpenOffice?