Можно попробовать закоротить вход и понаблюдать за температурой - никто не обещал отсутствия шумов за пределами слышимости. Потом аналогично с отключенной нагрузкой.
Если верить заявленным 85мА тока покоя - то пара ватт при питании 20-25в должна рассеиваться радиатором без заметного нагрева.
Tech, лучше - не значит что будет что-то делать магически. А так - незаметно/невидимо пронести до бэкэнда запрос и вернуть его так же прозрачно назад - типовая задача.
Вопрос скорее к бэку и его лишней инициативе (получив в 80 порт, срыгнуть редирект на 443), которая либо убивается на корню на бэке, либо просто балансировщик стучится туда куда желает бэк, а несоответствие сертификата имени - либо игнорится (ssl verify none), либо хачится в локальном dns
Stalker_RED, правда чуть иная:
- монитор в темноте - явно подсветку надо делать не 100%
- те самые "драйверы светодиодов" aka источники тока - давно не делают в виде токовых стабилизаторов постоянного тока по типу параметрических - используются импульсные dc-dc преобразователи - читай шим в другом ракурсе. Не зря типовые даташиты дискретных led-drivers требуют внешней катушки индуктивности, а конвейерные содержат её в корпусе
В итоге получаем неизбежный прямоугольник мерцания, слегка искажённый индуктивностями и нелинейностями светодиодов = хороший такой набор иголочек и домиков в спектре
При двух, а то и пяти источниках (монитор + лампа, которая может быть rgbw) - получаем в математике весёлую картинку в виде матрицы разниц частот каждой пары гармоник - интермодуляции. И там вполне достаточно весёлостей в районе 0..25Гц
Мозг это типа "не замечает" явно, но вот повышенное утомление, песок в глазах и т.п. - гарантированы)
Можно поиграться с карандашным тестом и результат может удивить...
p.s. а вообще мне было интересно поименное перечисление мониторов с переключаемой подсветкой, где на низких яркостях светит меньшее число светодиодов, что существенно уменьшает диапазон скважности шим... но очень серьёзно удорожает сам монитор
Василий Банников, В темноте - это как носить обувь на размер меньше, зато кайфовать дома сняв её)))))
В принципе конечно мониторы умеют в широком диапазоне регулировать яркость и ШИМы там килогерцовые, но сайдэффекты граничных яркостей всё равно у подавляющего большинства мониторов есть.
а так - у филипса в телевизорах давно уже есть эмбилайт и если уж делать - то что-то подобное... в упрощённом варианте - светильник на потолке
p.s. ну и да: как правило led светильники имеют свой ШИМ со своим задающим генератором... дальше добро пожаловать в тригонометрию на предмет произведения синусов, не забывая про фурье и гармоники с интермодуляциями))
Александр Ананьев, ping x.x.x.255 например в win может выдать интересный результат
Ну и собственно можно попробовать разрезолвить все ip->mac, перебрав в цикле все адреса в рамках сети
Как мне кажется стоит задачу разделить на несколько:
- отобрать подмножество адресов в сети, которые откликнулись
- это подмножество опросить на предмет "а контроллер-то там или принтер?"
- контроллеры опрашивать уже на специфичное им
Vitsliputsli, только вот фигня: когда я в такой схеме обращаюсь к сайту xxx.com - то dns имя ресолвится в ip балансировщика и туда же прилетают запросы, а за ним сидят какие-то бэкэнды с условными адресами b1.xxx.local...bN.xxx.local и нужны во-первых некие танцы с таким пробросом и невалидными сертами с CN xxx.com на хостах bx.xxx.local, во-вторых при большом N и необновлённой парочке сертов - будет весело, в-третьих при использовании того же letsencrypt с certbot - потребуется наворотить кастомную кучку правил.
Да, это всё преодолимо, но повышает количество точек отказа и без принципиальных допусловий - существенно проще и "коробочней" то что предложил я.
Vitsliputsli, а есть ли смысл/задача/требование шифровать между haproxy и backend?
Да, в больших корпорациях иногда и между подами mTLS+ пользуют, но в общем случае проще и комфортнее терминировать ssl на балансировщике и дальше ему с бэками общаться по http
Как один из вариантов гибрида PLC+WiFi + бонусом mesh - tp-link deco p9
То есть его базы умеют вязаться между собой в mesh не только через wifi, но и по plc
Vitsliputsli, разницы почти не будет, но если haproxy будет регулярно нюхать живость бэка, притом нюхать и l3/l4 и l7 - то информации в логах и статистике будет больше и всё это будет информативнее -> позволит более точно выявить проблему.
В том числе можно нюхать как ресурс, так и его носитель (nginx/apache/kestrel/wildfly/etc).
Vitsliputsli, д'артаньянов нету, просто современные методолгии применяют уже проверенный временем метод конвейера. Сейчас это в программировании. Термин "кодер" не на пустом месте появился.
Vitsliputsli, именно таковая тенденция ныне. Всех сотрудников максимально загоняют в состояние зашоренных винтиков и под давлением аджайла эти винтики пашут на конвейере "от сих до сих", а та самая девопс часть и является той самой склейкой отдельных декомпозированных кусков в единое целое...
Drno, немного иначе.
В какой-то мере ныне DevOps - это скорее программист упрощёнными программистами aka кодерами.
То бишь аналитики - нааналитят, кодеры - накодят, куски/микросервисы а вот девопсу потом из этой разрозненной части надо собрать (и не руками) целое, адекватно отражающее то, что наархитектирили архитекторы)
Естественно всё что касается сетей/сисадминства - оный должен не знать, а жить этим. А со стороны программирования, не будучи винтиком - ну так же уметь понять и поправить косяк (зачастую - почуять проблему в коде не заглядывая туда).
Это если уходить от розовых понятий команды, где каждый заодно и девопс.