NiTr0

меньше полупериода. вполне защищает если есть запас по напряжению (ну т.е. при напряжении гарантированного пробоя варистора БП еще не горит). все зависит от заложенного "запаса прочности" в БП.

чем они помогут от 380В 50Гц при обрыве нуля? тут только ограничить напряжение варисторами (или варисторы + разрядник). помогает обычно неплохо.

несколько 470в 20мм варисторов параллельно, ессно - с предохранителем перед ними. вполне могут спасти, и даже сами выжить (кроме предохранителя ессно).

да, к слову, на али попалось пару интересных вариантов: https://ru.aliexpress.com/item/4-NIC-3-5-Q4005UG4-P/32842541918.html и https://ru.aliexpress.com/item/Celeron-3215U-Desktop/32678238195.html это если хочется чтобы и экономично и компактно, на одной плате.

ок, платы новой ревизии как раз вчера получил, + еще кое-какая комплектуха едет. думаю, на следующей неделе соберу, отпишусь потом в личку.

у девайса сейчас 4 (с возможностью расширения до 8 доп.блоком, либо больше с минимальными изменениями) входов для измерения напряжения, + выход реле с группой переключающих контактов. которые в принципе можно использовать где угодно, управляя ним по SNMP, с одной оговоркой: реле отключается как только на одном из каналов напряжение проседает ниже заданного порогового (сейчас - минимум 10.5В, но в принципе ограничение, думаю, стоит заменить предупреждением) либо вообще пропадает. т.е. - отследить какой аккум как быстро разряжается, как и отследить отключение напряжения (по графику напряжения аккумов либо навешав на один из каналов незаупсованный БП), вполне можно. ну и релюхой можно нагрузку в принципе перекидывать между группами. да, питание - 12В (вернее - от 9 до 15, ниже 9 - работать будет, вплоть до 5, но не факт что сработает реле) да, каналы абсолютно независимы друг от друга, с опторазвязкой. у реле - переключающая группа контактов, рассчитанная на 220В (10А размыкающие контакты, 20А замыкающие согласно даташиту). можно удаленно по SNMP включить реле - на определенное время до 2 суток, либо просто включить "навсегда", с последующим отключением по SNMP либо по факту разряда одного из аккумов ниже заданного порогового напряжения. при пропадании питания девайса - релюха просто вернется в изначальное состояние.

16А - это 3+ кВт. 1 кВт бойлер - и ничего не отдыхает... ну да, грется 6-8 часов, но... микроволновка - 750Вт. стиралка тоже не постоянно воду кипятит. чайник - пару минут греется. так что жить можно, хоть и неудобно.

на наге длинный тред был. со счастливыми случаями. если на плате есть jtag (а он там вроде есть) - шить на ура на плате можно.

на предыдущей страничке выкладывали:

мож и повезло. вообще - марвелы глюкнутые в этом плане, и 8052 и 8056. иногда - раз в пару суток "моргают", иногда - каждый час, от трафика не зависит, от чего зависит - хз. ну если так и не планируется его дальнейшая эксплуатация... современный атом (даже копеечный N3050) будет существенно быстрее. возможно - даже раза в 2-3. особенно - с нормальными сетевухами (82576 встречаются за весьма недорого, при этом - они достаточно экономичные, ну или 82571 но они кушают поболее).

по несколько раз на день будет моргать линком (tx unit hang). скорее всего 700 мбит in+out потолок для нее будет (pci шина) корки 2 поддерживает, так что кипятильник можно смело менять на что-то более адекватное. зачем, если пакетов более 1500 байт (1522 со всеми заголовками включая влан теги) не бегает?

адовая печь с производительностью атома D525. поставьте туда хотя бы какой-то E2180 (раз ддр3 - то там явно свежая плата). сетевки к слову какие?

на микротике - вот чего не знаю того не знаю. но как для домашнего тазика с парой десятков тысяч нат трансляций (люый торрено) и куцым файрволом - думаю гигабит легко промолотит. были бы там сетевки хотя бы i210 (к реалтеку как-то доверия нет) - я бы сказал что она даже в роли браса с натом на линуксе 500-700 пппое хомяков легко бы пережевала и не поперхнулась.

GA-J3455N-D3H + гиг памяти + pico psu + флэшка под роутерный дистр (ну или если хочется медиацентром его заюзать - какой-то б/у винт бучный) + DC 12V БП для LED лент ватт на 30-50 с запасом. камень кушает 10Вт при полной нагрузке (ладно, 15Вт на весь тазик), в простое (90% времени) - ватт 5 будет все кушать.

вот username и прилетает (ну и CID если память не подводит). на LUA надо формировать username (в зависимости от opt82 либо еще как - тут уже дело фантазии), краткий мануал с примером под длинк - тут https://accel-ppp.org/wiki/doku.php?id=ru:ipoe_dhcp_lua можно и просто интерфейс возвращать (если это vlan per user). я подпиливал под хуавеи и бдкомы.

снять исправный, сфотать плату с двух сторон, поставить на место. по плате (горелой + фоткам целой) отрисовать схему. тем более - у ШИМки там схема включения вероятно типовая/близкая к типовой. другое дело что выгорание дорожек - нештатное поведение (если конечно дорожкой не реализован бюджетный вариант предохранителя на случай "все пропало"). а политика конторы - в принципе вполне понятна, "чтобы конкуренты/китайцы не упёрли". т.к. стоимость производства в Китае намного ниже, особенно - для крупных партий. внутри-то ничего цифрового умного (где защита от копирования - прошивка), а аналоговое устройство - копируется на ура.

accel по радиусу на ура с биллингом общается для ipoe. ну разве что пароля нет, только логин в остальном - разницы особо нет, аттрибуты те же. я крутил к абиллсу на стенде (когда еще не было толком поддержки акселя), проблем особых не возникло.

платы новой ревизии (с выведенным наружу разъемом 1-wire + мелкими правками разводки) заказал, думаю недели через 3-4 приедут. пока осталось 2 штуки первой ревизии основного блока, и кучка плат блока расширения.

дык в том-то и дело - в одном тупаре flow control может быть потушен, в другом - включен. и если включен на свиче и в роутере - начинается веселье...

"реализован" он может быть только "включен" и "выключен" (tx и rx - либо по отдельности либо вместе). нет. flow control есть во всех свиччипах. включается перемычками либо конфигом в еепромке.

вангую - на этих свичах страпами настроен flow control. и у туполинков он включен на порту. итог - веселое колбасево с переполнением буфера пакетов свича при малейших всплесках флуда в сети.

таки нет. получение пакета из сетевухи и вычисление хеша по заголовку - копеечная по ресурсам операция. потому выделять под это отдельное ядро смысла нет. тут вся суть - распределить ресурсоемкую маршрутизацию пакетов на более чем одно ядро. да и не факт что cache miss будут меньше при отдельном ядре под прием пакетов. зачем? чем мешают тут мультиочереди?

ну т.е. вы хотите сказать, что включение RPS в случае одной очереди прерываний (либо PPPoE пакетов, которые падают в одну и ту же очередь, делая аппаратные очереди бесполезными) снизит производительность? при том, что в реальном мире все ровно с точностью до наоборот?

а в чем собссно проблема-то? и какой смысл для очереди, в которую идут ВСЕ прерывания, указывать worker'ом только одно ядро??? это ни разу не аффинити. это - RPS.

ну то да, все пакеты будут падать в одну очередь прерывания, но по ядрам нагрузка будет размазываться равномерно.