Кто-нибудь пробовал? Можете описать, какие минимальные требования, как он вообще живет, и с какими проблемами столкнулись?
Re: Erlang на embedded платформе
От:
Аноним
Дата:
18.11.08 23:06
Оценка:
Здравствуйте, Gaperton, Вы писали:
G>Кто-нибудь пробовал? Можете описать, какие минимальные требования, как он вообще живет, и с какими проблемами столкнулись?
нет. но скажи нам просто, зачем???
Здравствуйте, Gaperton, Вы писали:
G>Кто-нибудь пробовал? Можете описать, какие минимальные требования, как он вообще живет, и с какими проблемами столкнулись?
Пробовал. Запускал Erlang на MIPS'овой доске с 233Mhz CPU. Результаты, откровенно, не очень-то обрадовали.
Тормозит весьма сильно. Следующую версии переписали на С++ в Erlang'овом стиле.
Здравствуйте, Gaperton, Вы писали:
G>Кто-нибудь пробовал? Можете описать, какие минимальные требования, как он вообще живет, и с какими проблемами столкнулись?
Ну, не совсем ембеддед — на МикроПС запускали с Линуксом. 64 мега памяти, Целерон. Работает нормально ( Мнезию не использовали ). Каких-то особенных проблем не вылезло — дык, это обычный компутер, только маааленький.
Читал в свое время ( лет 5 назад ), что люди запускали Ерланг на свистках ( это пень 3-ий 32/64 мега РАМы и флеш внутри сетевого разьема ). Жаловались на производительность — но это и понятно.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, Gaperton, Вы писали:
G>>Кто-нибудь пробовал? Можете описать, какие минимальные требования, как он вообще живет, и с какими проблемами столкнулись? C>Пробовал. Запускал Erlang на MIPS'овой доске с 233Mhz CPU. Результаты, откровенно, не очень-то обрадовали.
Скоко памяти было на доске было всего, скоко было доступно VM, включен ли был своп, и если да, то куда? Применяли ли HiPE? Что была за задача?
C>Тормозит весьма сильно. Следующую версии переписали на С++ в Erlang'овом стиле.
Профилировали? Что тормозит? Переписывание кусков на linked-in driver рассматривали?
Хм. В 98 году помнишь какие процы были? Вот мне интересно — как они в AXD301 его на тормозных ультрах поднимали.
Здравствуйте, Аноним, Вы писали:
G>>Кто-нибудь пробовал? Можете описать, какие минимальные требования, как он вообще живет, и с какими проблемами столкнулись? А>нет. но скажи нам просто, зачем???
Здравствуйте, gandalfgrey, Вы писали:
G>Здравствуйте, Gaperton, Вы писали:
G>>Кто-нибудь пробовал? Можете описать, какие минимальные требования, как он вообще живет, и с какими проблемами столкнулись?
G>Ну, не совсем ембеддед — на МикроПС запускали с Линуксом. 64 мега памяти, Целерон. Работает нормально ( Мнезию не использовали ). Каких-то особенных проблем не вылезло — дык, это обычный компутер, только маааленький.
МикроПС — это что? PC104? 64 метра — супер. Какая частота у целерона? Диск или флеш был? Своп включали? Какой дистрибутив применяли? HiPE включали?
G>Читал в свое время ( лет 5 назад ), что люди запускали Ерланг на свистках ( это пень 3-ий 32/64 мега РАМы и флеш внутри сетевого разьема ). Жаловались на производительность — но это и понятно.
Скажем так, на крайняк можно собрать платформу на базе младших версий Intel Atom. Тогда он точно будет не хуже по производительности, чем Эрикссоновское железо десятилетней давности, на котором Эрланг жил, и энергии жрать будет мало.
Кроме того, есть SoC от интела с интегрированными мостами на базе Pentium M. А также, более дешевые и тормозные SoC от AMD (Geode), и совсем неторопливые <100 Мгц писюки от сторонних производителей.
Но я думаю об армах, примерно 400Мгц или около того, и оперативкой около 128 метров. Без свопа. С флешкартой в качестве диска. Пойдет?
Здравствуйте, Gaperton, Вы писали:
G>МикроПС — это что? PC104? 64 метра — супер. Какая частота у целерона? Диск или флеш был? Своп включали? Какой дистрибутив применяли? HiPE включали?
МикроПС — это такая коробочка, размером от электробритвы до толстой книги. Используется для промышленных нужд. Начинка бывает самая разная — от Пня 2 до Пня 4, и по памяти так же. Стоят все равно дохрена — промышленные бренды, итить !
Своп в таких вещах обычно не используюти з-за непредсказуемого влияния на реактивность. Было и с винчестером ( 2.5 дюйма, насколько я помню ), и с флэшем. Версия Ерланга была 9.хх, насколько помню. Хайп точно не использовали, его и не было в опциях сборки из стандартного пакета. ОС — в основном ФриБСД, но ставили и Линух АСП.
G>Скажем так, на крайняк можно собрать платформу на базе младших версий Intel Atom. Тогда он точно будет не хуже по производительности, чем Эрикссоновское железо десятилетней давности, на котором Эрланг жил, и энергии жрать будет мало.
А что это за Атом ? Это что-то вроде 186 процессора ?
G>Но я думаю об армах, примерно 400Мгц или около того, и оперативкой около 128 метров. Без свопа. С флешкартой в качестве диска. Пойдет?
128 мег — это более чем ! своп не нужен. Вот насчет производительности на АРМе сказать сложно, проще попробовать. На ОТП 9.хх самые времякритичные операции ( на тухленьком железе ) :
— выборка и массовое удаление из ETS
— формирование строк через io:fwrite
— паттерн матчинг с термами, где много строк ( это можно обьехать архитектурно, что я и сделал )
Можно состряпать крохотный тестик, который покажет приемлемость ( или наоборот ) данного железа
Здравствуйте, gandalfgrey, Вы писали:
G>Здравствуйте, Gaperton, Вы писали:
G>>МикроПС — это что? PC104? 64 метра — супер. Какая частота у целерона? Диск или флеш был? Своп включали? Какой дистрибутив применяли? HiPE включали? G>МикроПС — это такая коробочка, размером от электробритвы до толстой книги. Используется для промышленных нужд. Начинка бывает самая разная — от Пня 2 до Пня 4, и по памяти так же. Стоят все равно дохрена — промышленные бренды, итить ! G>Своп в таких вещах обычно не используюти з-за непредсказуемого влияния на реактивность. Было и с винчестером ( 2.5 дюйма, насколько я помню ), и с флэшем. Версия Ерланга была 9.хх, насколько помню. Хайп точно не использовали, его и не было в опциях сборки из стандартного пакета. ОС — в основном ФриБСД, но ставили и Линух АСП.
Я думаю свою железку сделать, чтобы утоптать себестоимость железа в сотню долларов. Что без свопа и без Хайпа — это хорошо. Это обнадеживает.
G>>Скажем так, на крайняк можно собрать платформу на базе младших версий Intel Atom. Тогда он точно будет не хуже по производительности, чем Эрикссоновское железо десятилетней давности, на котором Эрланг жил, и энергии жрать будет мало. G>А что это за Атом ? Это что-то вроде 186 процессора ?
Он совместим по системе команд с Core 2 Duo, в ем до двух аппаратных тредов, каждый тред — очень простой — одна инструкция за такт, он жрет очень мало энергии, и он дешевый. Частоты — до 1,6 Ггц. Предназначен для карманных компов, планшетников, и нетбуков. http://www.intel.com/design/intarch/atom500/index.htm?iid=ipp_embed+proc_atomz5xx
Минус — требуется внешний мост, и непонятно, как его поднять без видеоконтроллера, который нахрен не нужен. _Пока_ непонятно.
А можно взять Арм-ы. Которые работают до 600 Мгц, и где выбор однокристальных вариантов просто огромен.
G>>Но я думаю об армах, примерно 400Мгц или около того, и оперативкой около 128 метров. Без свопа. С флешкартой в качестве диска. Пойдет? G>128 мег — это более чем ! своп не нужен.
Отлично. Это я и хотел узнать, спасибо.
G>Вот насчет производительности на АРМе сказать сложно, проще попробовать. На ОТП 9.хх самые времякритичные операции ( на тухленьком железе ) : G>- выборка и массовое удаление из ETS
Это не хорошо. Впрочем, резерв для оптимизации есть, если нужен хэш — можно использовать по месту process dictionary, это раз в 10 быстрее.
G>- формирование строк через io:fwrite
Это понятно. io пользоваться вообще не надо по возможности. Он для диагностики и отладки. Для ввода-вывода надо использовать file — это в десятки раз быстрее.
G>- паттерн матчинг с термами, где много строк ( это можно обьехать архитектурно, что я и сделал )
Можно переехать на представление строк в виде бинарисов — в R12 бинарисы очень быстры.
G>Можно состряпать крохотный тестик, который покажет приемлемость ( или наоборот ) данного железа
Отлично. Думаю, принципиальных проблем не будет. Скажем, такая платформа:
400 Мгц ARM, последней редакции. Надо будет предусмотреть, чтоб можно было 600 Мгц впаять.
Ethernet-разъем.
RS-232/485 разъем. Возможно, два.
Возможно, USB-разъем, может быть два. Кстати, есть какие-нибудь стандартные промышленные USB-разъемы, чтобы завинчивались? А то больно легко зараза он вынимается, подозрительно как-то.
Память — 128 метров, возможность допаивания еще 128 метров.
Flash — скажем, разъем для карты памяти до 4 гиг.
Embedded Linux, с real-time расширениями. Кстати, вопрос — а каким образом сейчас модно делать real time в линуксе?
Ну, формат платы типа PC-104, то есть 9 на 9 см, разъемы там, то, се. Да, еще момент — может быть такая платформа уже есть, и кто-нибудь тупо даст мне ссылку на плату? Плачу баллами
Здравствуйте, Gaperton, Вы писали:
G>Я думаю свою железку сделать, чтобы утоптать себестоимость железа в сотню долларов. Что без свопа и без Хайпа — это хорошо. Это обнадеживает.
А реально ее сделать ? Все равно чипы будут готовые, только плата своя и обвязку выбрать можно подешевле. Но в 100 баксов все равно не влезет
G>Он совместим по системе команд с Core 2 Duo, в ем до двух аппаратных тредов, каждый тред — очень простой — одна инструкция за такт, он жрет очень мало энергии, и он дешевый. Частоты — до 1,6 Ггц. Предназначен для карманных компов, планшетников, и нетбуков. G>http://www.intel.com/design/intarch/atom500/index.htm?iid=ipp_embed+proc_atomz5xx G>Минус — требуется внешний мост, и непонятно, как его поднять без видеоконтроллера, который нахрен не нужен. _Пока_ непонятно.
Да это просто крутизна какая-то ! У меня сейчас тестовый сервер работает на Целероне 1.8 без каких-либо тормозов. Причем со Мнезией, кучей логов, и активным обменом данными. Правда, памяти стоит 1 гиг. У заказчиков ставится Пень 4 на 2 — 2.8 Ггц и 512 мегами.
G>Это не хорошо. Впрочем, резерв для оптимизации есть, если нужен хэш — можно использовать по месту process dictionary, это раз в 10 быстрее.
А чего тут странного ? Когда это селект был быстрым ?
G>Это понятно. io пользоваться вообще не надо по возможности. Он для диагностики и отладки. Для ввода-вывода надо использовать file — это в десятки раз быстрее.
Удобство совсем не то ! Меня это сильно не прижимало, вообще-то — ежели не выведет в лог сейчас, то выведет когда-нибудь потом. Процесс с малым приоритетом никого не напрягает.
G>Можно переехать на представление строк в виде бинарисов — в R12 бинарисы очень быстры.
Они и тогда были быстрые — но я их атомаризировал при входе. Выиграл раз 6-7 на матчинге
G>400 Мгц ARM, последней редакции. Надо будет предусмотреть, чтоб можно было 600 Мгц впаять. G>Ethernet-разъем. G>RS-232/485 разъем. Возможно, два. G>Возможно, USB-разъем, может быть два. Кстати, есть какие-нибудь стандартные промышленные USB-разъемы, чтобы завинчивались? А то больно легко зараза он вынимается, подозрительно как-то. G>Память — 128 метров, возможность допаивания еще 128 метров. G>Flash — скажем, разъем для карты памяти до 4 гиг. G>Embedded Linux, с real-time расширениями. Кстати, вопрос — а каким образом сейчас модно делать real time в линуксе?
Память лишней не бывает — она важнее, чем процессор. Но выглядит в целом очень даже неплохо. Единственное "но" — сериальные порты не нужны. Проще и надежнее поставить внешний конвертор РС485 / ТСР, ежели вдруг приспичит.
А какие типичные времена реакции ? Может, обычный Линух поставить и не заморачиваться
Здравствуйте, Gaperton, Вы писали:
G>>>Кто-нибудь пробовал? Можете описать, какие минимальные требования, как он вообще живет, и с какими проблемами столкнулись? C>>Пробовал. Запускал Erlang на MIPS'овой доске с 233Mhz CPU. Результаты, откровенно, не очень-то обрадовали. G>Скоко памяти было на доске было всего, скоко было доступно VM, включен ли был своп, и если да, то куда? Применяли ли HiPE? Что была за задача?
64Мб, была доступна почти вся. Своп включен не был, да он и не нужен особо был. Файловая система — OCFS2 на NAND-флэшке. HiPE пробовали, не помог.
Задача — сбор и обработка данных с кучи сенсоров, подключенных через несколько LAN-портов. Для работы с устройствами там надо было строить state-машину с таймаутами, т.е. идеальное применение для эрланговских процессов.
C>>Тормозит весьма сильно. Следующую версии переписали на С++ в Erlang'овом стиле. G>Профилировали? Что тормозит? Переписывание кусков на linked-in driver рассматривали?
Тормозило там всё в целом. Проблемы были в том, что срывались таймауты на сенсорах, если вдруг нагрузка получалось сильно выше средней. Для приемлимой работы пришлось отказаться от mnesia.
Насчёт переписывания кусков думали, в итоге решили переписать всё нафиг на С++. При переписывании не меняли стиль, просто заменили легковесные процессы обычными тяжеловесными. Прокатило.
G>Хм. В 98 году помнишь какие процы были? Вот мне интересно — как они в AXD301 его на тормозных ультрах поднимали.
Мне самому это было интересно.
Здравствуйте, Gaperton, Вы писали:
G>Можно Geode-ов набрать: http://www.amd.com/ru-ru/ConnectivitySolutions/ProductInformation/0,,50_2330_9863,00.html G>А можно взять Арм-ы. Которые работают до 600 Мгц, и где выбор однокристальных вариантов просто огромен.
Только сложно найти что-то подходящее и уже готовое, да ещё и с нормальной ценов в мелких партиях
G>Возможно, USB-разъем, может быть два. Кстати, есть какие-нибудь стандартные промышленные USB-разъемы, чтобы завинчивались? А то больно легко зараза он вынимается, подозрительно как-то.
Есть. Ищи по словам "captive screw terminal".
G>Память — 128 метров, возможность допаивания еще 128 метров. G>Flash — скажем, разъем для карты памяти до 4 гиг.
Лучше впаяную NAND. Производительность в разы выше.
G>Embedded Linux, с real-time расширениями. Кстати, вопрос — а каким образом сейчас модно делать real time в линуксе?
Если у тебя там один процесс будет, то можно особо не заморачиваться. Ставишь ему макс. приоритет — и вперёд.
G>Ну, формат платы типа PC-104, то есть 9 на 9 см, разъемы там, то, се. Да, еще момент — может быть такая платформа уже есть, и кто-нибудь тупо даст мне ссылку на плату? Плачу баллами
Посмотри на http://www.embeddedarm.com/products/board-detail.php?tab=options&product=TS-7800 — оно поможет прикинуть цены. При желании всё находится примерно в два раза дешевле
Здравствуйте, gandalfgrey, Вы писали:
G>Здравствуйте, Gaperton, Вы писали:
G>>Я думаю свою железку сделать, чтобы утоптать себестоимость железа в сотню долларов. Что без свопа и без Хайпа — это хорошо. Это обнадеживает. G>А реально ее сделать ? Все равно чипы будут готовые, только плата своя и обвязку выбрать можно подешевле. Но в 100 баксов все равно не влезет
Реально, и не очень дорого. В 100 баксов должно влезть точно, так как начинка почти такая же, как у приставок цифрового телевидения HD, а они уписываются в 100 баксов по себестоимости — это я знаю точно. Описываемая мной машинка выйдет совершенно однозначно дешевле баксов на 20, и эту разницу мы компенсируем увеличенным флешом.
G>>http://www.intel.com/design/intarch/atom500/index.htm?iid=ipp_embed+proc_atomz5xx G>>Минус — требуется внешний мост, и непонятно, как его поднять без видеоконтроллера, который нахрен не нужен. _Пока_ непонятно. G>Да это просто крутизна какая-то ! У меня сейчас тестовый сервер работает на Целероне 1.8 без каких-либо тормозов. Причем со Мнезией, кучей логов, и активным обменом данными. Правда, памяти стоит 1 гиг. У заказчиков ставится Пень 4 на 2 — 2.8 Ггц и 512 мегами.
Это не крутизна, он существенно слабее целерона. И дешевле.
G>>Это понятно. io пользоваться вообще не надо по возможности. Он для диагностики и отладки. Для ввода-вывода надо использовать file — это в десятки раз быстрее. G>Удобство совсем не то ! Меня это сильно не прижимало, вообще-то — ежели не выведет в лог сейчас, то выведет когда-нибудь потом. Процесс с малым приоритетом никого не напрягает.
Удобство возвращается назад с маленькой оберткой потокового ввода-вывода вокруг file . Я такую уже написал, лежит в загашнике. Хотя для логов как раз лучше io с его малым приоритетом — его не зря сделали тормозным, а чтоб AXD301 нормально работал.
G>>Можно переехать на представление строк в виде бинарисов — в R12 бинарисы очень быстры. G>Они и тогда были быстрые — но я их атомаризировал при входе. Выиграл раз 6-7 на матчинге
Да, тоже известный прием. Только таблица атомов не собирается GC — рискуешь словить переполнение памяти. Теоретически.
G>>400 Мгц ARM, последней редакции. Надо будет предусмотреть, чтоб можно было 600 Мгц впаять. G>>Ethernet-разъем. G>>RS-232/485 разъем. Возможно, два. G>>Возможно, USB-разъем, может быть два. Кстати, есть какие-нибудь стандартные промышленные USB-разъемы, чтобы завинчивались? А то больно легко зараза он вынимается, подозрительно как-то. G>>Память — 128 метров, возможность допаивания еще 128 метров. G>>Flash — скажем, разъем для карты памяти до 4 гиг. G>>Embedded Linux, с real-time расширениями. Кстати, вопрос — а каким образом сейчас модно делать real time в линуксе? G>Память лишней не бывает — она важнее, чем процессор. Но выглядит в целом очень даже неплохо. Единственное "но" — сериальные порты не нужны. Проще и надежнее поставить внешний конвертор РС485 / ТСР, ежели вдруг приспичит.
Серийные порты очень даже нужны . Причем — высокоскоростные, они должны мне давать минимум 256 кбит на максимально возможной дистанции (не менее 1200 метров, больше-лучше). Ну, и обязательно нужен 1 мегабит на 300 метров. Это не так просто сделать, надо аккуратно РС-трансиверы подбирать будет, терминировать витую пару, и пр.
G>А какие типичные времена реакции ? Может, обычный Линух поставить и не заморачиваться
RS-ом бы управлять надо...
Здравствуйте, Gaperton, Вы писали:
G>Реально, и не очень дорого. В 100 баксов должно влезть точно, так как начинка почти такая же, как у приставок цифрового телевидения HD, а они уписываются в 100 баксов по себестоимости — это я знаю точно. Описываемая мной машинка выйдет совершенно однозначно дешевле баксов на 20, и эту разницу мы компенсируем увеличенным флешом.
50 баксов — это будет себестоимость компонентов. А сдерут с вас раз в 5 больше — так как партии мелкие.
G>>А какие типичные времена реакции ? Может, обычный Линух поставить и не заморачиваться G>RS-ом бы управлять надо...
Оно обычно через UART идёт, тем более на высокоскоростных портах. Так что латентность не так критична.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, Gaperton, Вы писали:
G>>Реально, и не очень дорого. В 100 баксов должно влезть точно, так как начинка почти такая же, как у приставок цифрового телевидения HD, а они уписываются в 100 баксов по себестоимости — это я знаю точно. Описываемая мной машинка выйдет совершенно однозначно дешевле баксов на 20, и эту разницу мы компенсируем увеличенным флешом. C>50 баксов — это будет себестоимость компонентов. А сдерут с вас раз в 5 больше — так как партии мелкие.
Ну положим таки не в пять, а в два раза отличается стоимость розницы и опта (в партиях 1000 штук и выше).
Во-вторых, стоимость компонентов при заказе комплекта на 100 устройств вряд ли превысит 80 баксов. А в 20 баксов удастся уложить сборку вместе с печатной платой, я надеюсь. Ну, вместе с корпусом (который пожберем стандартный, штоб не попатсть на литье с пресс-формами) и непредвиденными расходами выйдет баксов 130 максимум. Это нормально. И это гораздо дешевле чужих готовых компов. Вообще, пусть даже 150. Все равно нормально.
G>>>А какие типичные времена реакции ? Может, обычный Линух поставить и не заморачиваться G>>RS-ом бы управлять надо... C>Оно обычно через UART идёт, тем более на высокоскоростных портах. Так что латентность не так критична.
Возможно. Надо подумать. Но real-time расширение не помешает все равно. Знаешь, как его правильно готовить в Linux?
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, Gaperton, Вы писали:
G>>>>Кто-нибудь пробовал? Можете описать, какие минимальные требования, как он вообще живет, и с какими проблемами столкнулись? C>>>Пробовал. Запускал Erlang на MIPS'овой доске с 233Mhz CPU. Результаты, откровенно, не очень-то обрадовали. G>>Скоко памяти было на доске было всего, скоко было доступно VM, включен ли был своп, и если да, то куда? Применяли ли HiPE? Что была за задача? C>64Мб, была доступна почти вся. Своп включен не был, да он и не нужен особо был. Файловая система — OCFS2 на NAND-флэшке. HiPE пробовали, не помог.
HiPE _совсем_ не помог? Во сколько раз throughput подрос?
C>Задача — сбор и обработка данных с кучи сенсоров, подключенных через несколько LAN-портов. Для работы с устройствами там надо было строить state-машину с таймаутами, т.е. идеальное применение для эрланговских процессов.
Черт. Близкая задача. Можешь описать, сколько у вас было сенсоров, и с какой частотой они гнали инфу? Ну, размер пакетов инфы, и формат тоже помог бы. Не modbus/tcp, случаем?
C>>>Тормозит весьма сильно. Следующую версии переписали на С++ в Erlang'овом стиле. G>>Профилировали? Что тормозит? Переписывание кусков на linked-in driver рассматривали? C>Тормозило там всё в целом. Проблемы были в том, что срывались таймауты на сенсорах, если вдруг нагрузка получалось сильно выше средней. Для приемлимой работы пришлось отказаться от mnesia.
Понятно, на точность таймаутов полагаться нельзя. Они, вообще, не для real-time придуманы, я подозреваю, а для реальных сетевых таймаутов по доставке, которые длинные и неточные. Кстати, надо бы завести proposal для real-time расширения, штоли. Штоб добавили ацки точный timeout. Причем, с относительно запомненной временной метки, а не просто так.
А все-таки. Какова была реальная точность таймаутов до того, как они срывались, и после? А как использовали mnesia?
C>Насчёт переписывания кусков думали, в итоге решили переписать всё нафиг на С++. При переписывании не меняли стиль, просто заменили легковесные процессы обычными тяжеловесными. Прокатило.
По Linux-процессу на сенсор заводили? Сколько их было? Подозреваю, что порядка сотен, так? Насколько стало быстрее? Если частоту втрое поднять, помогло бы?
G>>Хм. В 98 году помнишь какие процы были? Вот мне интересно — как они в AXD301 его на тормозных ультрах поднимали. C>Мне самому это было интересно.
По идее, тогдашняя ультра это примерно то же самое, что ваш MIPS. Почти идентичные процы. Это-то и странно.
Здравствуйте, Gaperton, Вы писали:
C>>64Мб, была доступна почти вся. Своп включен не был, да он и не нужен особо был. Файловая система — OCFS2 на NAND-флэшке. HiPE пробовали, не помог. G>HiPE _совсем_ не помог? Во сколько раз throughput подрос?
Он уменьшился Грешили на глючную поддержку MIPS.
G>Черт. Близкая задача. Можешь описать, сколько у вас было сенсоров, и с какой частотой они гнали инфу? Ну, размер пакетов инфы, и формат тоже помог бы. Не modbus/tcp, случаем?
Случайно нет. Сенсоры — это RFID-приёмники, в среднем где-то одно сообщение в секунду (с некоторых сенсоров могло десяток в секунду идти, с других пару сообщений в минуту).
G>А все-таки. Какова была реальная точность таймаутов до того, как они срывались, и после?
Сами таймауты где-то в 20-100 миллисекунд (время на обмен данными), с максимальной допустимой погрешностью где-то в 100-200 миллисекунд.
Проблем было две:
1) Срывало под нагрузкой некоторые таймауты.
2) Не справлялось с потоком сообщений от излишне говорливых устройств под нагрузкой.
G>А как использовали mnesia?
Mnesia хотели использовать для репликации. Устройство обычно подключено к серверу, но может работать некоторое время автономно. Так что просто использовали бы mnesia для хранения данных — оно само бы на сервер всё заливалось после его появления в сетке.
Пришлось отказаться и делать это явно.
G>По Linux-процессу на сенсор заводили? Сколько их было? Подозреваю, что порядка сотен, так? Насколько стало быстрее? Если частоту втрое поднять, помогло бы?
По потоку на сенсор + служебные потоки. Всего где-то по 200-300 потоков на устройство. Оказалось, что Линукс с таким без проблем справляется — латентность и плавность времени ответа выдерживал железно (ядро было 2.6.25). Пришлось, прадва, там слегка подкрутить размер дефолтного стека и использовать свой аллокатор.
Здравствуйте, Gaperton, Вы писали:
C>>50 баксов — это будет себестоимость компонентов. А сдерут с вас раз в 5 больше — так как партии мелкие. G>Ну положим таки не в пять, а в два раза отличается стоимость розницы и опта (в партиях 1000 штук и выше).
В партиях по 1000 штук — всего где-то в 3 раза
G>Во-вторых, стоимость компонентов при заказе комплекта на 100 устройств вряд ли превысит 80 баксов. А в 20 баксов удастся уложить сборку вместе с печатной платой, я надеюсь.
Оптимист. С нас хотели за простую металлическую коробку для монтажа платы содрать по $30 за штуку. Литую пластиковую — всего за $25, так и быть.
А ещё не забудь про блок питания и прочие мелочи типа скоб крепления.
G>Ну, вместе с корпусом (который пожберем стандартный, штоб не попатсть на литье с пресс-формами) и непредвиденными расходами выйдет баксов 130 максимум. Это нормально. И это гораздо дешевле чужих готовых компов. Вообще, пусть даже 150. Все равно нормально.
У нас в итоге около $100 изначально получилось после долгих пинаний с разработчиками. Потом снизили до $70. А подобные массовые устройства продаются по $30.
C>>Оно обычно через UART идёт, тем более на высокоскоростных портах. Так что латентность не так критична. G>Возможно. Надо подумать. Но real-time расширение не помешает все равно. Знаешь, как его правильно готовить в Linux?
Я использовал обычное realtime-ядро (в другом проекте), которое поддерживает Ingo Molnar. Там стандартный realtime-интерфейс — появляется наследование приоритетов на примитвы синхронизации, особое планирование потоков и т.п.
Здравствуйте, Cyberax, Вы писали:
C>>>64Мб, была доступна почти вся. Своп включен не был, да он и не нужен особо был. Файловая система — OCFS2 на NAND-флэшке. HiPE пробовали, не помог. G>>HiPE _совсем_ не помог? Во сколько раз throughput подрос? C>Он уменьшился Грешили на глючную поддержку MIPS.
Shit. Интересно, что с ARM.
G>>Черт. Близкая задача. Можешь описать, сколько у вас было сенсоров, и с какой частотой они гнали инфу? Ну, размер пакетов инфы, и формат тоже помог бы. Не modbus/tcp, случаем? C>Случайно нет. Сенсоры — это RFID-приёмники, в среднем где-то одно сообщение в секунду (с некоторых сенсоров могло десяток в секунду идти, с других пару сообщений в минуту).
Триста приемников, с каждого по сообщению в секунду, и всего 300 в секунду? Как-то совсем не густо.
G>>А все-таки. Какова была реальная точность таймаутов до того, как они срывались, и после? C>Сами таймауты где-то в 20-100 миллисекунд (время на обмен данными), с максимальной допустимой погрешностью где-то в 100-200 миллисекунд.
20 миллисекунд выдержать вряд-ли возможно, так как это близко к времени кванта. Это понятно. 100-200 миллисекунд... Ну короче понятно, на точные таймауты надеятся нельзя.
C>Проблем было две: C>1) Срывало под нагрузкой некоторые таймауты.
Ладно, это понятно. Рилтайм надо делать на С.
C>2) Не справлялось с потоком сообщений от излишне говорливых устройств под нагрузкой.
Это уже очень плохо, учитывая небольшое количество устройств.
G>>А как использовали mnesia? C>Mnesia хотели использовать для репликации. Устройство обычно подключено к серверу, но может работать некоторое время автономно. Так что просто использовали бы mnesia для хранения данных — оно само бы на сервер всё заливалось после его появления в сетке.
C>Пришлось отказаться и делать это явно.
Ну это была изначально больная идея ИМХО. Mnesia в расщепленной сети себя отвратительно ведет. У вас вообще ошибка должна была вылетать, нет?
G>>По Linux-процессу на сенсор заводили? Сколько их было? Подозреваю, что порядка сотен, так? Насколько стало быстрее? Если частоту втрое поднять, помогло бы? C>По потоку на сенсор + служебные потоки. Всего где-то по 200-300 потоков на устройство. Оказалось, что Линукс с таким без проблем справляется — латентность и плавность времени ответа выдерживал железно (ядро было 2.6.25). Пришлось, прадва, там слегка подкрутить размер дефолтного стека и использовать свой аллокатор.
Интересно. Все-таки странно, что так катастрофически тормозит. Бинарисы применяли в Эрланге? Или на списках работали? Модуль io не применяли случаем?
Здравствуйте, Cyberax, Вы писали:
C>А ещё не забудь про блок питания и прочие мелочи типа скоб крепления.
Нефиг блоки питания. Power over ethernet должон прокатить. На скобы фигню и логистику я щедро набросил двадцатку.
G>>Ну, вместе с корпусом (который пожберем стандартный, штоб не попатсть на литье с пресс-формами) и непредвиденными расходами выйдет баксов 130 максимум. Это нормально. И это гораздо дешевле чужих готовых компов. Вообще, пусть даже 150. Все равно нормально. C>У нас в итоге около $100 изначально получилось после долгих пинаний с разработчиками. Потом снизили до $70. А подобные массовые устройства продаются по $30.
Покажи, где подобные массовые устройства по 30 идут. Будем брать, и перешивать . Вообще — не верю. Китайцы вон тоже обещали на выставках приставки MPEG2 по 20 баксов. Вообще — не верю, это совершенно невозможно, учитывая, что со всеми расходами в России контрактная сборка _дешевле_. Чушь и балшыт.
