NEP

Такой сильной грозы в Харькове еще не видел. По результату: ничего не вылетело и ничего не согрело. FTTH, кабель в КК УТ, на узел ИБП с двойным преобразованием, телекоммуникационное заземление. Аналогичная ситуация у УТ, телефоны гудяд, модемы работают. Что мы делаем не так?

Это ваша сексуальная фантазия? Так, на будущее. Количество прерываний слабо коррелирует с пропускной способностью. У меня средний размер пакетов 80-90байт. Такого траффика 2-3Г "в каждую сторону" Латентность памяти зависит не столько от таймингов, сколько от типа используемой памяти. Поэтому для систем свыше 10Mpps я выбирают SUP720-3cxl TCAM которых построены на базе статической памяти. А вы уныло подбираете тайминги.

Могу калькулятор выслать наложенным платежем новой почтой, что б в будущем предварительно просчитывать ересь которую пишите. Для гипитетического 2Ггц квада с конвеером в 25 стадий на серьезно нагруженном роутере(200к прерываний/с) получается аж 0.025% падения скорости из-за простоев, полный разрыв.. А для реального, с конвеером в 14 стадий и частотой в 3Ггц еще раза в 3 меньше. А можете простенький конвейер для вычисления функции x+y*x составить? Нет? Или вы тоже любитель порассуждать о шуме леса не разу там не побывав? Цитируемое вами сообщение это просто условная модель, условного

А что, я не понятно написал? Я использую такой вариант установки: На фото 9-ти розеточный PDU BACHMANN. В стойке 4-е таким образом установленных PDU по два на каждый ввод. Такой способ установки и выбор 9-ти розеточных PDU позволяет не перекрывать юниты с тыльной стороны стойки и полностью закрывает потребности по количеству разьемов для стойки 42U. Место положение стойки г. Франкфурт-на-Майне. Второй вариант - это ZeroUnit PDU под разьемы С13/С14. И как бы никаких переносок прикрученных стяжками. Все это хозяйство представлено в первом посте и почему то у меня не вызывает у

Мне не надо рассказывать. Вы не владеете ни терминологией ни должным опытом. Вы рассказываете как шумит лес и при этом никогда не были в лесу! Берите ручку, бумагу - рисуйте! Ну вот такой себе soft-router с 8-мью 1Г интерфейсами! Причем тут такты? Латентность динамической памяти порядка 50-200 нс. Вы понимаете о какой латентности идет речь?

Так это вы расскажите! Вот возьмите ручку, листик и распишите по ступеням работу конвейера и блоков процессора при переключении контекста! Отсканируете, а потом вместе полюбуемся, что там с кешами. Судя по потерям производительности при интенсивной обработке прирываний нептристойно! высока. На маршрутизаторе мне нужна не "быстрая" память, а память имеющая наименьшую латентность.

Что значит розетки "сразу" в NewTelco? NewTelco предоставляет стойку и силовой провод подведенный к стойке с автоматом на вводе. Все. Потому что у каждого оператора свое оборудование и свои требования от C13 до трехфазных IEC 60309. Так простите, у меня в стойке не Блинки, а 38 DELL 610 с метровой глубиной на рельсах. Что теоретики будут делать в такой стойке с 7-мю китайскими PDU?

Ну вот давайте распишем сохранение одного регистра в стек. Что там у вас с латентностью? 1 такт, да? Чукча не читатель, чукча писатель. Не сбрасывается, а залолняется новыми данными. Вся работа по оптимизации и заполнению кеша для старой задачи - становится неактуальной, в этом и заключается разрыв вычислительного конвейера и основная причина потери производительности. Therefore, for two or more DIMMs per channel, RDIMMs will have lower latency and better bandwidth than UDIMMs. http://en.community.dell.com/dell-blogs/enterprise/b/tech-center/archive/2009/04/08/nehalem-

Давайте. Только сначала составьте конвейер для вычисления простенькой функции: x+y*z. Используя сумматор, умножитель и ... Когда составите - придет понимание.

"Переноски" говорите... Аренда стойки в приличном ДЦ - это порядка 1000 Евро в месяц. Добраться до приличного ДЦ (за исключением NewTelco Киев) это еще минимум 1000 Евро и время на перелет. Как вы думаете, сколько есть желающих единоразово сэкономить на питании 40Евро на блоках распределения питания и получить потенциальную угрозу расплавления и замыкания при 16А на блок? Schroff, BACHMANN - ONLY! Второе, у вас 7 "переносок" по 6 розеток дают 42 гнезда. А куда эти "переноски" предложите установить в шкаф?!! Занять задние 7 юнитов и закрыть доступ к 7-ми серверам, т.е. выкидывать в ме

Да, представьте себе, в процессе переключения контекста конвейер инструкций рвется перманентно, он недогружен! От сюда и нерациональное использование ресурсов процессора. Что касается вычислительного конвейера. Есть процессор, который выполняет определенный набор задач. У процессора есть блоки, которые образуют вычислительный конвейер, который включает в себя кеш (регистры), таблицы адресов, конвейер инструкций, fpu... В свою очередь блоки процессора также могут иметь параллельно конвейерную архитектуру, к примеру блоки реализующие команды SSE... А вас в ПТУ не учили, что такое конве

Да какая цена... Ну смотрите 4-е 1Г канала в Европе обходятся в 8к Евро в месяц. Стоимость системы на базе 2x5670 4-5к Евро. Да, представье себе, это меньше чем оплата каналов за две недели. Срок службы системы 4-5 лет. Я уже не говорю об экономии места в стойке, которая там стоит под 1000Евро в мес без учета питания.

Ладно. В результате обработки прерывания/переключения контекста практически все блоки процессора оптимизирующие его работу, направленные на ускорение выполнения программы, улетучиваются как с белых яблонь дым (кэш, конвейер инструкций, таблица адресов переходов и TLB наполняются новыми данными, которые вытесняют существующие), а "старый" процесс оказывается заблокированным даже несмотря на то, что в системе есть ресурсы для его исполнения. В результате, на нерационаьное расходование ресурсов может уйти более 50% процентов от общего времени исполнения программы, в результате того, что

Про какие десктопные процессоры i7 вы говорите? 2-е системы на базе Core i7-970 против одной на базе двух Xeon 5670 в задачах маршрутизации.

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

Бред. извините, не удержался

А кто его нагрузит работой если "регистры старой задачи" еще не сохранились, а "регистры новой задачи" еще не занеслись? Ну распишите, как он собссно выполняет "смену контекста"? Ну по командам. Вы же дистрибутивы от Эльдара сами составляете. Неужели так сложно четко ответить на вопрос. Чем и как загружен конвейер в процессе как вы утверждаете сохранения "регистров старой задачи"? Я уже даже стараюсь писать вам понятными терминами.

Что в это время делает конвейер? Он пошел погулять или участвует в проекте folding@home?

Где я писал о "сбросе"?!!!

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

У, как все запущено. Речь не о протоколе TCP, а о стеке TCP/IP. Вы поинтересуйтесь словосочетанием - стек TCP/IP. С TCP все просто. Есть установленное соединение, соотв. есть сессия. А как для UDP будем "сессии" считать? Когда "сессия установилась", когда "разорвалась"?

Ничем. Я в течении 2 страниц пытаюсь узнать чем же так страшен простой в пару десятков тактов(по идее 14 для core) в сравнении с тысячами тактов на переключение задачи и сотнями и тысячами тактов на прием многострадального пакета от сетевого интерфейса в память. Тут даже до фаерволов и собственно роутинга дело не дошло, с многими десятками тысяч тиков.. Так страшно тем, что пока переключается контекст - конвейер считается разорваным.

При интенсивной обработке прерываний? 90% - это бред. Я даже не удивлен ответу, он становится классикой. Пруфлинк в студию. Т.е. вы хотите сказать, что 1-о прерывание (получен сетевой пакет) приводит к потере 11к тактов? Пакет после приема будет отправлен в iptables, почему бы и не 10к тактов? Очень старое. Возобновлено в i7. TLB. TLB понятно, он наверное еще с 286ого появился. Непонятно с какого лешего его очищать при каждом 'разрыве конвеера' и как(скорее даже зачем) оно в таком случае вообще работает? И что там возобновили в i7? В i5 его нет?)) Вы сначала об

При интенсивной обработке прерываний? 90% - это бред. Т.е. вы хотите сказать, что тупо одно прерывание (скажем получен сетевой пакет) приводит к потере 11к тактов? А чем "простой" отличается от разрыва конвейера? Очень старое. Обновлено в i7. TLB.

Да притом, что при переключении контекста первым делом разрывается конвейер, очищается буфер ассоциативной трансляции... Я честно говоря не думал, что прийдется обьяснять такие прописные истины.