NiTr0

Есть разные вагоны/поезда; есть эдак годов 70-х без капремонта, есть и вполне адекватные, даже с кондиционером; есть отреставрированные те же 70-х гг - со стеклопакетами и обшитыми заново полками, но не более. Розеток массово кстати не замечал в них - разве что в районе сортира. Что в купе, что в плацкарте. А по поводу проекта - ИМХО бред. 3g какбы покрытие от опсосов есть кому надо, а кому не особо надо - тому и ваймакс не поможет ничем (сколько там комплект оборудования стоит?).

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

Грн по 4 - взял бы десяток на всякий случай (если вдруг понадобится - чтобы не паять из витухи и разъемов), если "новой почтой" или "ночником" вышлете...

Бред. Смертельна именно противофазная составляющая (10-15В с достаточным током гарантированно уничтожат входные цепи). Синфазная - только в случае импульса, который прошивает трансформаторную сборку либо прошивает входные цепи перед сборкой, образуя при этом несимметрию (доп. синфазный фильтр при этом не спасет). Почему - банально: входной трансформатор средей точкой обмоток подключен к массе или плюсу источника питания напрямую, и синфазная наводка, поступающая через емкость обмоток, сливается на массу

Пишите в саппорт, что вас двойной ответ от мозга свича раздражает. Хотя, уверен, толку от этого скорее всего не будет - ибо они гораздо более серьезные проблемы свичей не шибко чешутся исправлять... Было бы очень плохо - продажи свичей бы скукожились и свичи бы исчезли из ассортимента адекватных поставщиков (ибо никто не закупал бы неходовой товар, который к тому же регулярно возвращают взад с матами), + весь рунет бы пестрил криками "какое ховно эти 1210-28". А так - особо выдающегося шума нет, значит - типичная китайская кака средней степени пригодности к употреблению.

Вы свич сам пингуете? Если да - то собссно возникает вопрос: чем вам двойной ответ от свича мешает-то? Ну бредит их китайский мозг немного...

Угу, все на eth1 При пинге чего именно? Шлюза, указаного в $gw? Или же чего-то еще за этим шлюзом? Вам виднее. А он когда-то не работал?

Угу. А это уже эксперименты покажут. Коннтрак-то таблица не такая уж и большая. Хотя как по мне, 2 тазика с распараллеливанием на L3 будут всяко быстрее чем 1 2-головый. Как минимум ввиду уменьшения размера таблицы коннтрака. NUMA если не ошибаюсь.

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

В зависимости от мощности, "7-ка" (7000 BTU) - вроде как 600-700Вт, "12-ка" - 1.1-1.2 кВт, "24-ка" - 2.4кВт. Стартовый ток у неинверторных моделей - 4-5 крат от номинала, в течение 0.5-1сек.

Я спрашивал не о таймаутах, а о размере хеша коннтрака. Указывается параметром при загрузке модуля (options nf_conntrack hashsize=262144 к прмиеру в /etc/modprobe.conf), посмотреть можно по cat /proc/sys/net/netfilter/nf_conntrack_buckets. Если памяти много - увеличивайте хеш, быстрее соединения будут искаться в таблице. А вообще - загляните-ка в wive-ng-rtnl на предмет fastnat'а и прочих оффлоадов, мож чего и себе прикрутите

Ну коннтраку надеюсь размер хеша увеличили и ядро обновили, прежде чем что-то переписывать? Ядро рекомендую 2.6.35.13 (у нас крутится, проблем со стабильностью нет; 2.6.37..39 вроде как по отзывам крашились с шейперами и еще чем-то - пофиксили это или нет не смотрел). А вообще - коннтрак-то для ненужных пакетов можно (и нужно) отключать, -j NOTRACK в помощь. Не думаю, что вам нужны state всех сессий - не нат же ведь...

Это ваша сексуальная фантазия? Нет, ваша: Так, на будущее. Средний размер пакета типичного soho траффика - в районе 800-1000 байт. 800 мбит обеспечивает где-то 100 кппс. Т.е. - при отсутствии interrupt moderation 100000 прерываний в секунду. 80-90 байт? При том, что 40 байт - только заголовок пакета? У вас что, основной объем траффика - ACK-пакеты и короткие ICMP? Это что получается, для 3 гбит в каждую сторону у вас 8 Мппс в сумме??? Открою вам огромный секрет: латентность - это и есть те самые тайминги. В чем измеряется - в наносекундах или в тактах шины, или в попуг

Что рисовать? что при сохранении значения в стек оно попадет сначала в кеш, который write-back? Или что при вызове прерывания кеш не переключается в write-through и не отключается? Или 500-800 мбит в каждую из сторон для сетевух без interrupt moderation... Ланентность памяти вообще-то зависит от таймингов. Которые указываются в тактах (неожиданно?). И латентность доступа к памяти определяется исходя из таймингов (как задержек выборки строки, столбца, смены строк и т.п., так и задержкой перед подачей следующей комманды) и рабочей частоты плашки. Повторюсь: проведите эксперимент, в

Чего вам рассказывать? Что переход при обработке прерывания в другой сегмент того же аппаратного контекста задачи (ибо переключение контекста приложений чисто программное) не приводит ни к сбросу кешей, ни тем более к их отключению на запись? Только в случае 100-200 тысяч(!) прерываний в секунду. Память PC4200 (533MHz) с таймингами 5-5-5-15 будет иметь меньшую латентность, чем память PC8500(1066MHz) с таймингами 4-4-4-12? За счет того, что задержка между коммандами составляет не 2 такта, а 1? Вам пора с такими заявлениями на Нобелевскую подавать... Ессно, если доказать сможете.

Что там у нас с кешами, отсутствуют да? Повторюсь: 3 МБ данных обработано между прерываниями, обрабатывались они пускай 500кб кода, + 200 кб кода обработчик прерываний. Какова вероятность того, что в кеше объемом 6 МБ будет отсутствовать код обработчика прерывания? При одинаковых таймингах модулей и одинаковых частотах - да. Т.к. command rate будет 1T против 2Т у unbuffered (другие тайминги не меняются-то при этом). Но вот незадача, unbuffered память имеет более низкие тайминги и более высокую рабочую частоту. Кстати, влияние 1T/2T command rate на деле ничтожно (можете сами провер

Никакими. Ибо все "критерии" грамотно настроенный линуксовый тазик аккуратно вам похерит 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%. Не? И как это вообще соотносится с упоминаемым вами переключением контекста/"разрывом конвейера"? Кстати, какой объем данных пакета считывается и анализирует

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