NEP

Мне не надо рассказывать. Вы не владеете ни терминологией ни должным опытом. Вы рассказываете как шумит лес и при этом никогда не были в лесу! Берите ручку, бумагу - рисуйте! Ну вот такой себе 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-and-memory-configurations.aspx

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

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

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

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

Ладно. В результате обработки прерывания/переключения контекста практически все блоки процессора оптимизирующие его работу, направленные на ускорение выполнения программы, улетучиваются как с белых яблонь дым (кэш, конвейер инструкций, таблица адресов переходов и TLB наполняются новыми данными, которые вытесняют существующие), а "старый" процесс оказывается заблокированным даже несмотря на то, что в системе есть ресурсы для его исполнения. В результате, на нерационаьное расходование ресурсов может уйти более 50% процентов от общего времени исполнения программы, в результате того, что каждое прерывание будет нивелировать производимые процессором оптимизации. Это и есть разрыв ВЫЧИСЛИТЕЛЬНОГО конвейера, а не тупо сброс конвейера инструкций Опять же использование регистровой памяти (т.е двух ступенчатого конвейера Register - DRAM) позволяет незначительно нивелировать латентность памяти и позволяет существенно реже разрывать вычислительный конвейер.

Про какие десктопные процессоры 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 его нет?)) Вы сначала обьясните чем "простой" отличается от разрыва конвейера. И чем обработка прерывания отличается от обработки пакета в iptables.

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

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

Так процессор же не только прерывания обрабатывает! Или джедаи научились заставлять x86 процессор заниматься исключительно обработкой прерываний от Ethernet контроллеров?

Так собственно это происходит и при получении прерывания! Вот и все, что следоало понять еще не прошлой странице при упоминании словосочетания - разрыв конвейера.

Бред. Что значит достаточно редки? В чем измеряется "достаточная редкость"? The Intel Ethernet Controller write packet data... куда?

Т.е следует полагать, что вы можете гарантировать что они там будут всегда для каждой последующей задачи? У меня простой вопрос. Куда сетевой контроллер разместит полученные пакеты? И каков порядок их дальнейшей обработки?