NiTr0

по несколько раз на день будет моргать линком (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.

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

сами прерывания - никак. а вот вынести оработку из контекста прерывания в воркеры - RPS. echo 0f >/sys/class/net/eth1/queues/rx-0/rps_cpus echo 0f >/sys/class/net/eth1/queues/rx-1/rps_cpus echo 0f >/sys/class/net/eth1/queues/rx-2/rps_cpus echo 0f >/sys/class/net/eth1/queues/rx-3/rps_cpus ессно, отключить HT (от него в роутинге только вред - кеш вымывает) и задать 4 очереди.

таки был. нечто уровня какого-нить биостара или элиттрупа. угу, с экономией на питальниках проца, с экономией на радиаторах (из-за чего платы с нвидией дохли как мухи), экономией на конденсаторах, и прочим, прочим, прочим... единственное чем он в свое время выделялся - любовью к нетрадиционным извращениям. ну там, полноценный агп и полноценный пси-экспресс на одной плате. или плата со слотом для дочерней платы апгрейда проца (с новым сокетом). или современный чипсет под ископаемый проц (i945 под 478 сокет, или 760g под 754 сокет). или, наоборот, старый чипсет под нов

можно, но накой? проще собрать тазик. тем более - серверный комплект (мать+проц+память) на 1156 сокете баксов около 100 будет стоить... памяти гига 2 для начала более чем. а по поводу биллинга - да что угодно что поддерживает микротик (а его вроде все биллинги поддерживают). навскидку - абиллс 0.5х (или 0.7 - не помню как там с бесплатностью для малого кол-ва юзеров, вроде тоже до нескольких сот бесплатно), микбилл, убиллинг. нодени тоже наверное (не смотрел в его сторону).

не, вланы не реализовывал. да и смысла особо не вижу, проще порт антегом настроить.

вам на сколько каналов? 4 или 8?

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

3.10 точно стабильно работает, годами. и вроде как 4.12 тоже нормально по отзывам. с 3.14 или 3.18 (не помню) были грабли при удалении правил шейпера по завершении сессии (race condition), пришлось поправить скрипт шейпера, перекинуть удаление старых правил с if-down в if-up. с 3.18-3.19 по 4.8-4.9 были грабли порой с race condition при создании-удалении pppoe ифейсов (хотя вроде в 4.9 ветке это таки уже пофиксили). там скорее вымывание кеша будет. чем жирнее табличка - тем хуже кешам. хотя да, 10 минут - как по мне перебор. хотя бы несколько часов оставить.

там не в умножении дело, а в частоте измерений (раз в 5 минут), ну и отображении этого в rrdtools ступеньками, а не ломаной...

ну если так - то с абонента прилетает флуд, раз 800 мбит - это гигабитный клиент явно. да не факт, от свичей зависит. s2228f при флуде в абонвлане пропадает из сети к примеру. да и другие свичи если у них какие-то софтфичи типа опции 82 включены - тоже от флуда кукожатся.

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