Страниц: 1 [2] 3
  Печать  
Автор Тема: EAGAIN  (Прочитано 18157 раз)
oder
Гость
« Ответ #15 : Декабря 13, 2010, 06:15:19 pm »

Это не мы решаем. Smiley
А кто решает? Разве не разработчик?
Заказчик. Smiley Ему нужен такой-то мотор и никаких CANов. Smiley И ещё такой-то, такой-то и такой-то. Smiley

Такие штуки так не поектируются! Изначально, перед тем как садиться чтото делать нужно потратить не один день на осмысление затеянного.
И по ходу продвижения разработки "предвидеть" возможные варианты развития событий.
В группе разработчиков должно быть единоначалие, чтобы один человек держал весь проект в голове.  Это важно!  Чтобы потом, такие как вы, не задавали вопросы о пресловутом EAGAIN, и кто в нем виноват.
Ой, уважаемый, конечно же мы осмысляем. Но "тратить не один день" никто не позволит. Разве что задача совсем ещё новая. И то, она обдумывается, в основном, в фоновом режиме, в подсознании.
И варианты я предвидел: я же о них пишу. Smiley Только, вот, проблема в том, что EAGAIN никак не решается, кроме как падать. Smiley
И такой как я, как раз, и держит большую часть проекта в голове - весь нет смысла ибо 20 мегабайт исходников - они и в Африке 20 мегабайт исходников: за некоторые части отвечают другие люди.
И я не ищу совета по EAGAIN, ибо все ответы и решения я знаю, или до того, как написал или начинаю понимать незадолго после того, как написал, пока вы ещё только в тему вникаете.
Я предложил подиспутировать, в надежде услышать что-нибудь новое, оригинальное и нестандартное, что помогло бы решить неразрешимую проблему.

Записан
oder
Гость
« Ответ #16 : Декабря 13, 2010, 06:22:07 pm »

В данном конкретном случае правильный ответ таков, что MsgReply/MsgError не возвращают EAGAIN никогда. Тоесть, они должны быть сделаны так, чтобы не возвращать, или будут полные кронты всей концепции обмена сообщениями. Возвращать EAGAIN могут только инициаторы сообщений типа MsgSend или send для сокета. И это надо знать и в правильных местах правильно выбирать сторону-инициатора сообщения, чтоб в нужном направлении сигнал гарантированно доходил.
Но тема, всё-равно, скользкая ибо ядро меняется и люди, которые над ним работают меняются. И никто никогда не гарантирует, что кто-нибудь из QSS по неосторожности не всунет какую-нибудь функцию, которая вернёт EAGAIN. Поэтому бояться, всё-равно, надо.

И, даже, если в случае возвращения ответа на сообщение тривога была ложной, в общем случае проблема остаётся и о ней постоянно надо помнить.
« Последнее редактирование: Декабря 13, 2010, 06:24:49 pm от oder » Записан
lesav
Sr. Member
****
Offline Offline

Сообщений: 262



Просмотр профиля
« Ответ #17 : Декабря 13, 2010, 07:27:57 pm »

Возвращать EAGAIN могут только инициаторы сообщений типа MsgSend или send для сокета.
Однозначно! Исполнителю команд "до фени" что ему может прислать главный процесс.

Кто висит на MsgReceive, тот и отвечает на команды.
Но перед тем, как отсылать "трудные" команды, дабы не попасть в блокировку лучше прощупать подчиненный процесс Пульсом. Если в ответе на пульс придет пульс "Незанят", смело отсылать "трудную" команду.
Один из вариантов решения проблемы блокировки.


Записан

oder
Гость
« Ответ #18 : Декабря 13, 2010, 07:50:39 pm »

Ну, пардон, два пульса это "по сети туда" и "по сети обратно" (не считая возможных коллизий в обе стороны). Я бы таким не баловался. Пропускная способность сильно падает.
Кроме того, "трудная команда" - почему она трудная? Потому, что у неё объем данных большой? - Если её придерживать и обрабатывать другое - рискуем память переполнить. Потому, что обрабатывается долго? - Ну так тут нам свободный сервер тоже не слишком поможет: свободен сервер или нет - всё-равно, долго обрабатываться будет.
Так какая польза от пульсов?
Записан
oder
Гость
« Ответ #19 : Декабря 13, 2010, 08:04:24 pm »

Ну, тоесть, я, конечно, понимаю, что при определённом распределении легких/тяжёлых комманд пользу можно найти. Но, это только при условии, что отсылающий поток имеет ещё какую-нибудь левую работу, кроме отсылки комманд. А это уже черевато.
И, кроме того, проблема занятости однопоточного менеджера ресурсов к EAGAIN не имеет никакого отношения.
Записан
lesav
Sr. Member
****
Offline Offline

Сообщений: 262



Просмотр профиля
« Ответ #20 : Декабря 13, 2010, 09:01:19 pm »

У вас как выглядит система? Обрисуйте ?
Один компьютер главный. Все остальное микроконтроллеры как подчиненые ?
Или както подругому ?
Не держите карты в рукаве.
А то получается мы говорим о разных вещах.
Записан

oder
Гость
« Ответ #21 : Декабря 13, 2010, 09:28:44 pm »

Там всё сложнее и все - коммерческая тайна. Smiley
Может быть много главных и может быть много подчинённых.
Ну, понятно, что два командира на одного исполнителя - это уже слишком. Но один со всеми тоже может не управиться.
Записан
lesav
Sr. Member
****
Offline Offline

Сообщений: 262



Просмотр профиля
« Ответ #22 : Декабря 14, 2010, 08:21:00 am »

Я работаю в атомной энергетики.
Открыл для себя мир где нет ТСР, только UDP.

Представьте себе:
Стоят промкомпьютеры, соединенные оптоволокном в три подсети.
1 Инженерная сеть
2 Сеть данных (UDP)
3 Резервная
Компьютеры общаются между собой по спецпротоколу, в котором встречается широковещание.
На каждом хосте запущен агент, который знает кому(а может и всем) и на какой порт отсылать необходимые данные.
Так как система распределенная, конфигурационные файлы сложны в понимании человеком. Их генерит спецпрограмма, для каждого хоста индивидуальный кфг.
В сети данных передаются и принимаются тысячи параметров в реальном времени.  Каждый хост в сети может иметь зеркальную копию себя.
Одновременно происходят обмен и архивация. И никаких задержек в обмене данных.

Можно пойти по похожему пути. В продаже есть недорогие процессоры (истинный реалтайм) с eth  ~300р. Ядро ARM7 60-80MHz (производитель NXP)
Если есть навык проектирования печатных плат можно соорудить отличную систему. Соеденить все в свитчем и в путь. Слабое место в системе - свитч (если только он не HIRSCHMANN с отказоустойчивым кольцом).


Можно пойти менее дорогим путем - интерфейс CAN. Идеальное решение в отказоустойчивых сетях (CAN не даром выбрали автопроизводители).  Его никоем образом не может заменить RS485-422, так как любое подчиненное устройство, при неисправности, может погубить обмен данными в сети.


Если на начальном этапе не обсудить все возможные проблемы с Заказщиком, можно заиметь большой гемморой в будущем.
Записан

oder
Гость
« Ответ #23 : Декабря 14, 2010, 11:57:52 am »

У нас, периодически ходят идеи отдельного кольца для приоритетных данных, чтоб не мешать их в общую кашу, но на изначальном этапе проектирования этого заложено не было, а сейчас нет ресурсов (времени и разработчиков) чтоб "делать врезку". Кроме того, заказчики (в смысле, мы делаем софт для иностранной фирмы, которая уже и производит инсталляцию системы и монтаж оборудования конечным заказчикам) - так вот - заказчики, банально жмутся на лишний эзернет-кабель. Оно, с одной стороны выглядит немного смешно, ибо проекты там на миллионы, а с другой стороны мы - лишь малая часть этих проектов и лишний кабель требует лишнего проектирования, шахт/коробов, свичей, стоек для техники и т.д. и т.п. Ну и метраж там бывает нехилый.
Короче, пока что, без этого обходятся. А в будущем - кто знает!
Записан
oder
Гость
« Ответ #24 : Декабря 14, 2010, 05:26:51 pm »

Я работаю в атомной энергетики.
Открыл для себя мир где нет ТСР, только UDP.
начальном этапе не обсудить все возможные проблемы с Заказщиком, можно заиметь большой гемморой в будущем.

С UDP, просто, та проблема, что пакет может пропасть и, поэтому практически для всего надо делать перепосылку. А это - свои сложности: потоки, очереди пакетов, таймера, выбор таймаутов, очистка/игнорирование застаревших. Общая структура программы/хода исполнения может стать слишком запутанной.
« Последнее редактирование: Декабря 14, 2010, 05:28:46 pm от oder » Записан
lesav
Sr. Member
****
Offline Offline

Сообщений: 262



Просмотр профиля
« Ответ #25 : Декабря 15, 2010, 04:28:41 pm »

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

Допустим есть устройство Мастер и два Слэйва. Они соеденены по ТСР, идет двух сторонний обмен данными между главным и подчиненными.
Алгоритм работы Главного основан на одном потоке, в котором идет последовательное обращение ко всем подчиненным.
Тут один из Слейвов перестает отвечать на запросы.  Главный висит на таймауте ТСР, и пока он ожидает ответ от "молчаливого" устройства,
он не может вести обмен данным с остальными участниками обмена.  И даже в том случае, если таймаут выставить минимальным,
каждый раз, при обращении к несуществующему Слэйву он будет впадать в томительное ожидание. 
Вся система будет "скособочена" одним устройством.

Другое дело UDP. В одном потоке идет отправка и прием сообщений, без таймаутов. 
Всегда знаешь, какое устройство отказало, и можно перейти на резервное. Можно организовать опрос неисправного, без потери обмена с резервным. При восттановлении связи перейти в штатный режим.

Главное в пакете передавать уникальные метки.  Типа:
Отправляем  "Счетчик посылки", "Команда", "Данные"
Принимаем   "Счетчик посылки", "Данные"
Проверка - счетчики совпадают, Отлично команда принята
Записан

oder
Гость
« Ответ #26 : Декабря 15, 2010, 05:49:12 pm »

С UDP, просто, та проблема, что пакет может пропасть ... А это - свои сложности ... Общая структура ... может стать слишком запутанной.

По опыту скажу, UDP пакеты в рамках сложной сети пропадают крайне редко. 
Не очень понимаю, что значит "крайне редко". Раз в год человека покалечить - это допустимая частота? Или раз в десять лет реактор рвонуть? Wink
Протокол по своей сути допускает потерю пакетов. Тоесть, каждое звено имеет право, просто, молча выбросить пакет, если считает, что обрабатывать его будет затруднительно. Кроме того, существуют чисто-железячные опасности: плохой контакт, перебитый кабель, дефектный свич, наводки мощного оборудования рядом с кабелем. Так, вроде, всё нормально, а тут ты отправил пакет, а на той стороне контрольная сумма не сошлась и протокол его выбросил. Не каждый пакет, конечно, - один из ста... один из тысячи...

А в одной сети доходят достоверно. Но от нумерации посылок к каждому подчиненному отказываться не стоит.
Пока-ещё доходят достоверно...

Другое дело UDP. В одном потоке идет отправка и прием сообщений, без таймаутов. 
Всегда знаешь, какое устройство отказало, и можно перейти на резервное. Можно организовать опрос неисправного, без потери обмена с резервным. При восттановлении связи перейти в штатный режим.

Есть извечная проблема относительности события. Ты отправил комманду - ожидаешь ответа. Ответа нет. Отправил команду ещё раз. Ожидаешь - ответа опять нет. Переключаешься на резервный. Отправил команду резервному. Тут тебе приходят два ответа от основного и ответ от резервного. Просто, тормознула сеть где-нибудь или кто-нибудь на высоком приортете io-net/pkt отсвопил.
Хорошо, если основной и резервный исполнитель могут контролировать устройство впараллель и не должны его делить на эксклюзивный доступ. А то, вообще кошмар начнётся с определением, кто получил команду первым, а кто - вторым и кто должен контролировать устройство, а кто уступить. И хорошо, если такой вот конфликт можно разрешить в автоматическом режиме, не показывая никаких неожиданных задержек и "спецэффектов" для внешних компонент. А, ведь, задержка и так уже произошла...
И хорошо, если есть десятикратный запас по производительности ЦП и десятикратный запас по пропускной способности сети и на входе стоит автоматчик и отвечает за то, чтоб никто не подключил к сети свой компьютер и не начал Интернет качать, файлы с диска на флешку сливать или пасьянс раскладывать. Тогда такого можно, почти, не опасаться. А если автоматчика нет?
Записан
lesav
Sr. Member
****
Offline Offline

Сообщений: 262



Просмотр профиля
« Ответ #27 : Декабря 16, 2010, 10:31:33 am »

Просто, тормознула сеть где-нибудь или кто-нибудь на высоком приортете io-net/pkt отсвопил.
О каком io-net/pkt идет речь, если я говорю о низкоуровневом TCP\IP стеке в микроконтроллере? Все задержки в микроконтроллере известны до нанометра
Записан

lesav
Sr. Member
****
Offline Offline

Сообщений: 262



Просмотр профиля
« Ответ #28 : Декабря 16, 2010, 11:00:31 am »

И хорошо, если есть десятикратный запас по производительности ЦП и десятикратный запас по пропускной способности сети и на входе стоит автоматчик ...
Частота 40-80MHZ на микроконтроллере ARM7, этого - "выше крыши" чтобы выполнять достаточно сложные задачи.
Если паранойя взяла вверх над вашим разумом, есть ARM9 400MGz. И упаси вас Бог ставить туда ОСь. И автоматчика тоже стоит предусмотреть. А то какойнить оператор вздумает пасьянс раскладывать на безмониторном устройстве, или блурэй фильмы качать из БД системы.


Реально, в сети вышеупомянутой системы работают несколько десятков хостов, передаются и принимаются тысячи параметров.  И никаких задержек.
Может разработчик этой системы секрет какой знает?  Или у него спецбубен есть для проведения пусконаладочных работ,
типа побренчал пару раз, и все работает в течении пяти лет без сбоев.
Кстати все работает под линуксом, без ЙТЧ.

Вы попросите меня, я попробую выкрасть чертежи спецбубна. Очень нужный девайс.
Записан

lesav
Sr. Member
****
Offline Offline

Сообщений: 262



Просмотр профиля
« Ответ #29 : Декабря 16, 2010, 11:08:31 am »

А вот так выглядит вышеупомянутая система.

Не скрою, что в низком уровне работает QNX4.
Записан

Страниц: 1 [2] 3
  Печать  
 
Перейти в: