kolobok0

Тут ещё пол копейки. Есть подход гитлаба (халява при поднятии своего, для мелких проектов - самое то) ну или заюзать вэб сервис от поставщика. Так вот гитлаб может отрабатывать pipeline скрипт которых настраивается как yaml файл лежащий прямо в репе (или даже группа файлов). При этом перенос очень прост - меняется именно этот файл при переносе в другую репу. Пайпа отрабатывается в ранерах гитлаба. По уму это разные тачки и ранеров может быть много. В пайпе можно делать параллельные и последовательные зависимости, ловить разные глаголы(не только мёрдж реквест), есть связи с мессэнджэрами, почтой, различными зоопарками. Немного глючноват, но терпимо. На пайпах можно вызывать отработку любых докер контейнеров. А что внутри них вы отрабатываете - фигня вопрос. Хоть баши, хоть питоны, хоть пых-пыхи и т.д. и т.п.. Можно собирать артифакты которые легко переносятся между ранерами автоматом (один билдовка например, а второй крутиться на таргет машине. направили на развёртывание в таргет машину - тут же раскатали в продакшен)... как то так (круглый) ЗЫ Гит флоу вытекает из ворк-флоу. Обычно на бранчах работа быстрая, без изменений исходников. Например простановка тэгов. Причём имя генерируется с указанием имени бранча и уникального счётчика(привет кастом атрибутам). Выставляем тэг. На данный тэг можно ссылаться внешней автоматикой для дальнейшей сборки-CI. На мёрдже реквесте(точнее при его подготовке) идёт проверка исходников = билдовка, прогон тестов, наращивание версии (если пушим в мастер или релиз), коммит изменений, выставление тэга. Можно прерывать пайпу и выходить на дальнейшее ручное проталкивание. Либо от настроек на проекте выставленные внешней автоматикой мы идём по нужным настройкам - например собирать ли, куда выкладывать, куда раскатывать и т.д. и т.п...

сосредоточьтесь - речь шла НЕ об услышал-не услышал.... либо переформулируйте Вашу мысль...

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

Может типо этого? * Samsung Exynos5422 Cortex™-A15 2Ghz and Cortex™-A7 Octa core CPUs* Mali-T628 MP6(OpenGL ES 3.1/2.0/1.1 and OpenCL 1.2 Full profile)* 2Gbyte LPDDR3 RAM PoP stacked* eMMC5.0 HS400 Flash Storage* 2 x USB 3.0 Host, 1 x USB 2.0 Host* Gigabit Ethernet port* HDMI 1.4a for display* Size : 83 x 58 x 20 mm approx.(excluding cooler)* Power: 5V/4A input не реклама, если что... (круглый)

улучшить: чисто из опыта, - как минимум все опен библиотеки ( это относится и к lwip) надо проверять глазками. Хотя-бы схемотоз. А лучше перерыть. Звучит как минимум странно но увы, без контроля халявы можно нарваться совсем на костыли. В своё время приходилось править и lwip стэк, к сожалению. некоторые вещи пошустрее сделал, где то явный ляп подправил... на таком уровне. но это уже наверное устаревшая инфа - было не вчера... все мы родились не с клавами под мышками. сделать можно - диагностику добавить. Например сбор ключевых сетевых счётчиков и ответ собранной статистикой по запросу. рекомендую так-же сделать контроль стэков (глубину их использования. можно поставить на переключении, если многозадачная ось есть) и сбор как можно побольше инфы при падеже (пошёл по такому пути - запись во флэш и при рестарте проверка наличия свежего падежа и перенос уже на микро-сд в лог...).

выше прозвучало не от Вас. (думаю не принципиально в контексте) т.е. разница лишь реализация ответной части от iperf либо свой огород (в профиль то же самое). и на писюке iperf или то же самое но самопальное... выбор(лично для мну очевиден). да и для Вас как я понял... ЗЫ С Вами завязалась беседа в струе ответа AlexandrY

Читаю... "Нужно протестировать максимальную скорость обмена по этому порту" Поясните пожалуйста: заявленным характеристикам (тот кто проверяет) железки не верят(100Mbit), стандартным прожкам не верят(iperf, ping), но верят Вашим попугаям???? Или всё же воткнули устройство в сетку и прогнали стандартные тулзы типа pinga и iperf ? И используем эту методу дальше для поиска узких мест при эксплуатации. Что надо то? PS т.е. проверяют Вас или устройство???? ЗЫ ЗЫ Возможно ещё варианты - проверять скорострельность функционала, который реализует Ваше устройство. Ну тогда это вообще не на железке и свои типы счётчиков и свои методологии уже...кмк.

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

С точки зрения целесообразности точности измерения, или правдивости измерений - это всё условности в сети. Потому как ситуация может поменяться в любой момент времени. Исходя из этого, делать что то своё в плане диагностики - путь тупиковый, т.к. вызывает больше вопросов чем даёт ответов. Правильнее, как тут прозвучало выше (типо iperf, ping), поддержать стандарт утилит которые а) понятно как использовать любому линуксоиду б) понятен результат выводимый ими. Измерять более честно, правдиво и иже - зачем? Чтоб чтобы что? погордиться, что в момент икс была скорострельность канала 5 попугаев? Обычно те, кто занимаются сетями действуют по следующей цепочке => детектирование проблемы, быстрая проверка возможных причин, детектирование причины проблемы, устранение. Так вот, "быстрая проверка возможных причин" достигается применением и осмыслением полученных результатов стандартных утилит. Подозрение на маленькую скорость? прогнали iperf между узлами, увидели порядки чисел около 9xx мегабит в секунду - значит данный канал 1 гигабит выдаёт... Кстати при реализации поддержки стандартных протоколов, можно собирать и выдавать свою статистику - которая на Ваш взгляд может более полно ответить на те вопросы которые помогли бы в решении практических задач либо по узлу либо по связи. Например собирать статистику по "плохим" IP пакетам, или там кол-ву всего принятых пакетов и т.д.. Но как правило всё уже придумано до нас, и инфу по всевозможным счётчикам Вы сможете найти на любом управляемом свитче или роутере. с уважением (круглый)

как было сказано выше... 1) они не имеют адреса, что упрощает пусконаладку. 2) они чувствительны к помехам. не везде и не всегда и достаточно редко. по первости мы их меняли(в одном, на целую линейку изделий) , потом изменив схематику детектировали переход в термостат и возвращали обратно в режим датчика.с тех пор головняка нет. 3) их действительно к сожалению сняли с производства. аналогов нет...увы. ЗЫ Попробуйте подключить его с управлением по питанию и программно скинуть в режим термодатчика. очень большая вероятность что это этот случай...но как понимаете - без изменения схемного решения к вам будут периодически обращаться с этим головняком.

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

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

Нет не нормально. 1) Как тут прозвучало - объективные средства контроля (ваершак в данном случае, будет более правильным средством) 2) Смотреть программку по обслуживанию UDP. Профилировать код, если своё или сваливать временные поинты в лог. 3) Что говорит пинг на этот комп? Используется ли асинхронный доступ к сокету? Наверное (если свой код) имеет смысл сделать минимум-миниморэ балванку и выложить на профильных форумах. как то так, для начала... (круглый)

У Вас тактовая камня сколько? Если предположить, что большинство МК это сотни мГц, а писюк - единицы гигагерц...то вот Вам и есть этот порядок просадки. Если Вы пихаете в передатчик изернета не в рукопашную, а полуавтоматом - то расходы на подготовку пакетов минимальна(по секрету - вы можете отправлять с железки и по максимуму 65к :) на IP уровне. правда это немного не по фэншую но явных ограничений в RFC не было вроде как.) (круглый)

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