kolobok0

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

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

Может типо этого? * 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 не было вроде как.) (круглый)

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

Да оно и так всё понятно, без отзывов....