NiTr0

То и значит. Код с достаточно высокой вероятностью уже будет в кеше. Зависит от объема кеша, объема обрабатываемого кода/данных и частоты вызова определенных участков кода. Так, если между 2 прерываниями обращение происходило скажем к 3 МБ данных, при этом код обработчика прерывания занимает 500КБ и код юзерспейс софта занимает 200 КБ, а кеш 6 МБ - вероятность того, что код при следующем вызове прерывания будет в кеше, равна 100%. Не? И как это вообще соотносится с упоминаемым вами переключением контекста/"разрывом конвейера"? Кстати, какой объем данных пакета считывается и анализирует

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

Если действительно большую часть процессорного времени занимает обработка прерываний - соответстывенно, код с достаточной вероятностью уже будет в кеше. Опять же, зависит от объема кеша; 6-8 МБ - вполне достаточный объем к слову, о 24+ МБ на ксеонах вообще не говорю - у меня роутерный дистрибутив занимает в минимальной развертке 13МБ оперативки, с рамдиском и т.п., следовательно, cache miss для него будут весьма редким явлением. Содержимое пакета уже исполняет конвейер?

И? Какова вероятность сбоя в памяти при штатной работе десктопного железа? Толку от ЕСС мне, если и без него аптайм серверов ограничивается в первую очередь стабильностью их энергоснабжения и остановками на профилактику (чистка от пыли)? Не говоря уже о RDIMM (буфферизация актуальна только для большого кол-ва модулей) - мне от нее как-то ни жарко, ни холодно на роутерах/бордюрах/брасах, ибо потребление памяти там редко переваливает за 500 МБ (на брасах, учитывая 200-300МБ логов). Кстати, десктопные AMD ECC память прекрасно поддерживают... Регистровую - официально нет, неофициально - у кое-ко

Обосновать потрудитесь? Или одного вашего "авторитетного мнения" как обоснования хватит? Сброс конвейера вообще никоим образом не завязан с cache miss. И cache miss происходят с тем же успехом и во время штатной работы задачи без переключения контекста. Кстати, как и сброс конвейера (да-да, блок предсказания переходов не всегда отрабатывает как надо).

Кстати, если гражданка буйная - можно попытаться ее ненавязчиво спровоцировать на нанесение телесных поврежений, при свидетелях и в идеале с аудиовидеозапиью камерами наблюдения. С соответствующим заявлением в "органы", пускай даже по статье "хулиганство". Думаю, труда не составит - банальные обоснованные обвинения во лжи весьма подобных субъектов злят. Опять же, бонус вам на суде и в опровергающем интервью.

Работаем с десктопным железом с 2004г. Серьезных проблем со стабильностью нет, проблемы с питанием/пассивными элементами/аплинком возникают намного чаще, чем проблемы с серверами. Соответственно, повышать стабильность еще больше я не вижу смысла - суммарная надежность не возрастет ибо ограничена в большей мере прочими факторами. А если нужно будет увеличивать надежность - уж проще будет сделать решение на VRRP с 2 десктопными тазиками. Надежность результирующая будет выше, чем при использовании одного сервера, стоимость - меньше, время на восстановление из-за отказа - меньше (ибо комплектуха п

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

Дык в профиле город указан 1-я часть туч обошла как-то хитро с севера и юга, ждем далее

Итак, в нашем районе уже начинается Пока что скромно покапало и немного погремело, но, думается, этим не ограничится - по прогнозам на сутки гроза. Ожидаем...

А нахрена softflowd/fprobe/что там еще есть в юзерлевеле пользовать, если есть ядреный ipt_NETFLOW модуль?

Может конечно линуксовый полисиер не совсем корректно работал... Но факт остается фактом. + ко всему - ИМХО полисинг будет хуже вести себя с войсом и т.п. когда канал близок к полке. О сожительстве чего-то рядом с торрентом при этом речи ИМХО вообще не идет.

Заметят, будут спидтесты и т.д. пучить, только торрент сможет высосать все из канала. Когда у нас был полисинг на аплоад - юзеры жаловались на то что спидтесты странно себя ведут. С шейпером - красота

Я к примеру никаких проблем с ветвлением нигде не наблюдал. Если сделано все по человечески ессно в самих правилах. Пакет обработался правилом цепочки FORWARD к примеру, передался на обработку в цепочку TABLE1, там обработался с результатом ACCEPT/REJECT/DROP - на этом дальнейшая обработка его прекращается. Можете сами проверить. Да ну?

У нас в регионе вроде как длинки пользуются вместо хуевеев...

Гарантированный канал без приставки "до", IPoE вместо туннелей/веб-авторизации (если пользуются туннели/веб-авторизация), ессно - vlan per user + возможно выделение подсети запрошенной ширины (не только /32 или /30) с соответствующим увеличением стоимости, включение оптикой (для повышения надежности), кругосуточная техподдержка (если ее еще нет) и устранение поломки в течение суток + лимитирование макс. времени простоя в месяц, и прочие плюшки.

Да ну? И это с ядерным ipt_NETFLOW модулем? или таки при сборке юзерлевел софтом через libpcap? Если 2й вариант - ровняйте руки, прежде чем какашками метаться. А то я тоже могу начать кричать, что бздя говно потому как в ней natd тупой и медленный по сравнению с ядреным натом линукса

Аптайм год на одном из роутеров, собранных на десктопном железе (еще сокет а; после его апгрейда - оказалось что половина кондеров попухла). Ребуты/висы бордюров - уже и не припомню когда были по причине кернел паники или каких-либо еще проблем с софтом/железом. ЧЯДНТ? Поверьте, сброс конвейера по сравнению с переключением контекста - всего лишь незаметная мелочь. softirq - время исполнения всего в ядре, что не входит в обработчики прерываний и не является циклами простоя. а в Sqeeze это не пофиксили? (и какие у разработчиков вообще планы не известно)? Нет, это фикситс

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

Версия ядра, версия драйвера, что говорит oprofile? Я уже говорил, что 2-ядерный феном спокойно жует 500 мбит в каждую из сторон практически не напрягаясь. И он же жевал до 600 мбит с forcedeth сетевухами. Неудивительно. Ознакомьтесь прежде, что такое softirq что ли... cat /proc/interrupts подтвердить ничего не может. Принципиально. Порядка 2000 прерываний/сек на ядро собссно есть норма, при сравнительно нешироком канале - проц при этом загружен % на 3.

У импульсного преобразователя, который потребляет от сети практически постоянную мощность, и у которого ток портебления растет при снижении напряжения? Ну-ну... За сколько пробивается разрядник, за сколько сгорает предохранитель, и какое сопротивление плазмы внутри перегоревшего предохранителя если до этого в нем протекал ток в десятки (если не сотни) ампер? Нагрузка на отсутствующие варисторы БП? Мне что-то в БП свичей варисторы не попадались как-то

Часть энергии уйдет. Но опять же все зависит от крутизны фронта и его амплитуды. Если фронт будет пологим и небольшой амплитуды (эдак вольт 700-800) - "разрядник" не пробъется, а импульса хватит чтобы минимум БП поджарить... При мощном импульсе - "разрядник" испарится, БП опять же поджарится

Что крутится на тазике-то? Шейпер/нат/файрвол? Займитесь для начала профайлингом, посмотрите, кто конкретно много кушает. Его и оптимизируйте. Гигабит для короквада ИМХО семечки. У нас 500 мбит жует феном x2 (небольшой файрвол, нат части адресов + приоритезация траффика канала) - загрузка % 10 от силы...

Что раскладывать-то? Что плазма внутри колбы, образовавшаяся после перегорания проволоки, является хорошим проводником и гаснет только (в лучшем случае) при переходе напряжения через 0? Или что при импульсе перенапряжения достаточной энергии (эдак 1 кДж при длительности в 100 мксек скажем) и достаточного напряжения разности потенциалов на поверхности (ввиду опять же большого тока) + вспомогательных факторов (как УФ излучение дуги, наличие потянувшей влагу пыли и т.п.) будет достаточно для ионизации воздуха возле колбы с последующим разрядом по ее поверхности?

Предохранитель без батареи варисторов за ним от грозового перенапряжения ничего не защитит Да и с батареей варисторов - при грозовом перенапряжении от 20мм предохранителя к примеру толку нет вообще. Ибо после сгорания нити разряд начинается не только внутри колбы, но и на ее поверхности. Я видел примерно такой предохранитель (только все же перегоревший) лично. P.S. Даже более того: во всех блоках питания на входе стоят предохранители. Однако даже при наличии варисторов за ними в небольшом кол-ве (ибо много и крупных в БП не влезет) БП успешно подгорают.