NiTr0

Никакими. Ибо все "критерии" грамотно настроенный линуксовый тазик аккуратно вам похерит user agent - херится transparent proxy, ttl - в mangle правится, и т.д. Опять же, вы в жизни не докажете, что у юзера пионернет, а не пара домашних компов. Да, в борьбе с мельницами все средства одинаково хороши Если у админа пионернета руки под х*й заточены - да, меняется. Иначе - нет, не меняется.

Сохранение регистров в стек (в т.ч. и MMX/SSE), сохранение указателя стека, изменение CR3 (смена page directory), загрузка нового указателя стека, загрузка регистров из стека, смена карты I/O портов, восстановление TLB (хотя точно не уверен, надо в код смотерть - а лень)... Конвейер в это время собссно обрабатывает эти комманды Кеш сбрасывается при каждом вызове прерывания? Ну-ну... Чтобы вы знали, registered DRAM имеет латентность больше, чем небуфферизированная. И частоты ниже. За счет того, что дополнительный такт тратится на занесение состояния лини адреса/выбора чипа в тот самый регистр. И ее плюс совсем не в том, что она быстрее - а в том, что большее кол-во модулей может работать на одной шине.

Не поверите - само ядро линукса, которое собссно и занимается переключением контекста задачи. Аппаратная смена контекста в линуксе на х86 не пользуется, а в х86_64 - вообще отсутствует как таковая. Ну если вам лень погуглить - почитайте это и это. Вроде как понятным языком расписано, как именно выполняется программное переключение контекста задачи. Не поверите - кодом, выполняющим переключение контекста задачи

Навряд поможет. А у нее будет повод поднять вонь по поводу "бандитов"... Разве что если эти "крепкие ребята" будут таки из милиции, с корочками К примеру, сымитируют предварительный разговор перед возбуждением уголовного дела за клевету, потребуют у нее показать копии тех 13 решений суда, попугают грозящим сроком, пожалуются на переполненные камеры и плохое финансирование милиции в целом и исправительных заведений в частности...

Такая?

Неужто все это время он очищается? Очистился себе, и ждет пока его работой нагрузят. Довольно малое время. А далее - начинает выполнять собссно "смену контекста". К слову, почитайте о многозадачности на x86_64 и на реализации многозадачности под линем на x86, весьма интересное чтиво... Поймете, в частности, почему TLB не всегда сбрасывается (или правильнее сказать - вообще не сбрасывается, а инициализируется заранее сохраненными данными)

Писали вам уже: переключение контекста, т.е. сохранение регистров старой задачи и загрузка регистров новой задачи, и попутно - очистка конвейера, сброс TLB (кстати, сбрасывается он далеко не всегда) и прочие мелочи.

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

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

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

И? Какова вероятность сбоя в памяти при штатной работе десктопного железа? Толку от ЕСС мне, если и без него аптайм серверов ограничивается в первую очередь стабильностью их энергоснабжения и остановками на профилактику (чистка от пыли)? Не говоря уже о RDIMM (буфферизация актуальна только для большого кол-ва модулей) - мне от нее как-то ни жарко, ни холодно на роутерах/бордюрах/брасах, ибо потребление памяти там редко переваливает за 500 МБ (на брасах, учитывая 200-300МБ логов). Кстати, десктопные AMD ECC память прекрасно поддерживают... Регистровую - официально нет, неофициально - у кое-кого заводилась (s939 venice не помню какого степпинга). По соотношению "цена/производительность"? А оно сильно надо в типичном сервере? Не, конечно, если это мегахранилище с 5-6 SAS контроллерами, или мегароутер с десятком 4-портовых карточек (или 10GE карт), то да. В остальном - 2-4 слотов x4 хватает с головой. Ну конечно, вы как экстрасенс всегда можете предсказать, что данных в кеше процессора не будет Опять же, обработка cache miss занимает далеко не основное время при переключении контекста.

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

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

Работаем с десктопным железом с 2004г. Серьезных проблем со стабильностью нет, проблемы с питанием/пассивными элементами/аплинком возникают намного чаще, чем проблемы с серверами. Соответственно, повышать стабильность еще больше я не вижу смысла - суммарная надежность не возрастет ибо ограничена в большей мере прочими факторами. А если нужно будет увеличивать надежность - уж проще будет сделать решение на VRRP с 2 десктопными тазиками. Надежность результирующая будет выше, чем при использовании одного сервера, стоимость - меньше, время на восстановление из-за отказа - меньше (ибо комплектуха покупается за полчаса или на крайняк выдирается из домашнего/служебного компа, а новый сервер в случае чего придется ждать не день и не два). Бред. Переключение контекста неразрывно связано с очисткой конвейера. Связано. Только потери времени из-за очистки конвейера на несколько порядков меньше, чем собссно полные потери времени на переключение контекста. И при даже 5000 прерываний в секунду потери времени на очистку конвеера будет всего лишь 25*2*5000 = 250000 тактов, или (при тактовой частоте 3 ГГц) 67 мкс - т.е. накладные расходы на очистку конвеера менее 0.01%.

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

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

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

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

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

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

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

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

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

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

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