NiTr0

APC smart ups если не боитесь калибровки (правда заряжать батареи будет долго - ток там небольшой). Ну или русельфы/люксеоны

Да, это тупое зарядное с ограничением тока и напряжения. Ибо никакой интеллектуальностью там и не пахнет. Не, конечно, веселее, чем всякие forte (где кроме тора и амперметра ничего нет), но все же примитивное. У вас заметно разряженный аккумулятор. Включается 220, и упс начинает параллельно с зарядным заряжать аккумулятор. И хреначит в него все 40+ ампер (36 от зарядного и 5-10, или сколько там, от упса). Хозяин же, оставив генератор, уехал по делам. Вопрос - насколько поплохеет аккумулятору от того, что его заряжают током более 0.2C?

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

Угу, и прожарит аккумулятор 36А током... Повторяюсь еще раз - упс с двойным преобразованием заводского исполнения б/у будет в итоге дешевле и в разы надежнее собранного на коленке егойного приблизительного аналога. Попробуйте подкрутить частоту генератора (возьмите частотомер у кого-то, или купите), поставьте где-то 52Гц. Если не поможет - ну что ж, не судьба, ищите либо упс с двойным преобразованием, либо генератор более другой/инверторный.

И откуда она будет знать, какой ток нагрузки и, соответственно, какой ток выдават на аккум чтобы ему не поплохело? А главное - нахрена городить огород, если дешевле будет взять нормальный б/у упс и/или инверторный генератор?

У нас рекорд - 8 лет работы батареи из 4 аккумов (после чего один помер окончательно, остальные - в полуживом состоянии были сданы в металлолом т.к. и емкость упала, со свежим аккумом не поставит вместе, и самое главное - в другие места, где требовался 1 аккум, их не поставить было). У нас такое было - 1.5 года проработал на ура, а потом - высушил батарею. Впрочем, батарея не умерла, вроде сейчас где-то работает. Что стало причиной - не знаю.

А что будет с аккумулятором, если нагрузка будет не 800Вт, а около 0, и при этом на него подать 36 ампер? А что будет с зарядным, если нагрузка будет скажем 1.3кВт? Не, можно конечно лепить онлайн упс из говна и палок, но результат будет соответствующим.

120Вт с натяжкой потреблять может, если БП 80+, и процы не на 100% загружены.

Да-да, 40А от зарядника на аккумы выдавать...

Упсы с нормальным ВЧ инвертором внутри вместо 50Гц трансформатора. Если у вас цель питать микротик с медиком - скорее всего микроваттовских с головой хватит. Если не требуется мониторинг и т.п. Или вообще минвел взять, с 12В или 24В выходом, + понижающие преобразователи навешать...

А главное - к квагге применимы цисковские примеры. Которых еще больше. И которые весьма сгодятся для обучения. А потом, когда придет осознание - что, куда, и зачем нужно, и чего сделать на квагге нельзя без костылей но очень хочется, можно и на bird переползти...

Дедлок не должен появляться. Ибо лок вызывается только в auth.pm, в одном месте кода, и сразу на всю таблицу сессий. А дедлок вылезает в acct.pm - где нет ни локов, ни транзакций, ибо нет сложных операций.

А не подумывали ли что-то более адекватное чем МТ, заюзать? Ну хотя бы линь какой, или бздю на крайняк... Чтобы с подземными стуками тика не бороться методом перебора опций конфига...

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

Сохранение статуса при каждом изменении объекта - да, это нормально. Для критичных данных. И получение статуса из базы каждый раз - это тоже нормально для критичных данных. Особенно - если планируется когда-нибудь строить отказоустойчивый кластер, или балансировать нагрузку. А делать заведомо немасштабируемую систему, которая допускает возможность утери важных данных при краше - это ненормально. Дедлок таки проскакивает в аккаунтинге, если радиус собран с поддержкой потоков (как в дебиане). Но откуда он вылазить может - я не представляю, негде ему там взяться вроде бы... 2014-10-23 16:12:44 LOG_ERR: [] UPDATE dv_calls SET status='1', started=FROM_UNIXTIME(UNIX_TIMESTAMP()), lupdated=UNIX_TIMESTAMP(), nas_port_id='98903', acct_session_id='81c04921', CID='E8:94:F6:xx:xx:xx', CONNECT_INFO='' WHERE user_name='xxxx' AND nas_id='2' AND acct_session_id='IP' AND (framed_ip_address=INET_ATON('10.140.0.22') OR framed_ip_address=0) ORDER BY started LIMIT 1; --1213 --AutoCommit: 1 --Deadlock found when trying to get lock; try restarting transaction at /usr/abills/libexec/../Abills/mysql/main.pm line 126 main::query2('Acct=HASH(0x8e4c450)', 'UPDATE dv_calls SET\x{a} status=\'1\',\x{a} started=F...', 'do') called at /usr/abills/libexec/../Abills/mysql/Acct.pm line 121 Acct::accounting('Acct=HASH(0x8e4c450)', 'HASH(0x6031348)', 'Nas=HASH(0x7ffdbc0af9f0)') called at /usr/abills/libexec/racct.pl line 372 main::acct('DBI::db=HASH(0x64aa468)', 'HASH(0x6031348)', 'Nas=HASH(0x7ffdbc0af9f0)') called at /usr/abills/libexec/rlm_perl.pl line 132 main::accounting called at /usr/abills/libexec/rlm_perl.pl line 0 eval {...} called at /usr/abills/libexec/rlm_perl.pl line 0

Ну я ж и грю - как минимум переписывать mysqlclient библиотеку...

А кроме фильтров - еще в райпе прописать ассет, и пнуть аплинка на всякий чтобы обновил...

Покажи мне асинхронный MySQL запрос Я что-то не припомню таковой реализации в мускуле, как и в других СУБД. Опять же, другой работой заняться не получится особо - потому как ничего читать-писать из таблицы сессий/ип адресов не выйдет в это время, придется ждать.

Не в производительности счастье. Тазики еще производительнее. Но их что-то в энтерпрайзе на роутинг не ставят.

Логика и так в отдельном процессе. А вы предлагаете вынести из СУБД именно хранение текущего актуального состояния в отдельный процесс. Из которого запихивать данные в СУБД раз в N времени и надеяться, что процесс не упадет и сохраненные данные о состоянии не потеряются. Что есть бредом. Не, понятно, оно будет работать быстрее - но кому нужна скорость в ущерб надежности? Куда гоняли? SQL - это не обращение к дисковой подсистеме в общем-то, уже давным-давно СУБД обзавелась кешами, из которых все и читается. А сохраняется на диск только статус. Но - да, при каждой его смене, а не раз в 5 секунд. Лок в одном участке, где между получением статуса и его сохранением идет обработка данных (при этом остальные потоки ожидают, если обратились к данному участку), или глобально однопоточное приложение, где один-единственный поток молотит данные - что будет быстрее? Даже если лок будет на весь вызов процедуры (в худшем случае из возможых) - получаем 1 работающий поток и остальные ожидающие. Т.е. - скорость, сопоставимую с "асинхронным" однопоточным приложением.

Дык а кто вам сказал, что SQL - это I/O? А главное - как вы SQL асинхронным-то сделаете, если это даже I/O? Свой SQL сервер напишете, с асинхроннстью и однопоточностью? Итоги подведем: никакого i/o активного нет и в помине (запрос в 5 секунд) - значит, асинхронность в один поток есть бред. Для сети в 300-500 человек - да, пофиг какой говнокод А если радиус будет обрабатывать эдак 500+ запросов в секунду? С чего бы это не прижились? Вполне себе прижились, и активно используются. В том же rlm_perl

http://www.ebay.com/itm/Cisco-WS-C6506-E-Switch-Bundle-W-WS-C6506-E-FAN-2-WS-SUP720-WS-CAC-3000W-DD-/231284457867?pt=US_Network_Switches&hash=item35d9a0c18b к примеру - нищебродский железный бордер/ядро для тех, кто не любит готовить тазики. Хоть и фулл целиком не влезет, и жрет как калорифер - но в первом придлижении вполне юзабельна.

Ну разве что )))) Только аплинков-то 2, а значит дефолт не катит.

А с чего вы взяли, что все упирается в i/o, а не в CPU? А главное - как предлагаете с SQL запросами быть? Мускул клиент вроде как не предлагает асинхронный обработчик. А главное - в итоге получится стремная солянка, которая крутится на одном ядре, и распараллелить которую невозможно без полного переписывания с нуля... К слову, перловые потоки таки нормальные потоки. http://letsgetdugg.com/2009/04/19/fun-perl-benchmark/ в помощь если не верите. То на питоне из-за GIL с потоками грусть-печаль

А в чем годнота? В отсутствии масштабируемости?