Перейти до

какой проц Core i7-980 или i7-2600K лучше для обработки прерываний от сетевухи E1G44


Рекомендованные сообщения

  В 22.07.2011 в 10:07, KaYot сказав:

Конечно, сравнивать надо системы отличающиеся в цене в 20 раз..

Уверен, i7-980x будет быстрее чем ваши 2x5670 во всех задачах. Даже несмотря на 5-7 кратную разницу в цене только камней, а на сколько будет дороже вся система страшно представить.

 

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

Ссылка на сообщение
Поделиться на других сайтах
  • Відповіді 145
  • Створено
  • Остання відповідь

Top Posters In This Topic

Top Posters In This Topic

Popular Posts

A ще краще поставте FreeBSD. Така машина може до 2 Гбіт. жувати.

+1

Блин, вот зачем вы его трогали? По теме: стоит Q9550 + E1G44ET, жует около 1.5 гигов, не жужжит. Нагрузка 4-х CPU ~ 40%. Особого тюнинга нет (все вроде общеизвестное), есть даже кое-какой conntrack

  В 22.07.2011 в 10:01, NEP сказав:

Ладно.

 

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

 

В результате, на нерационаьное расходование ресурсов может уйти более 50% процентов от общего времени исполнения программы, в результате того, что каждое прерывание будет нивелировать производимые процессором оптимизации.

 

Это и есть разрыв ВЫЧИСЛИТЕЛЬНОГО конвейера, а не тупо сброс конвейера инструкций :)

 

Опять же использование регистровой памяти (т.е двух ступенчатого конвейера Register - DRAM) позволяет незначительно нивелировать латентность памяти и позволяет существенно реже разрывать вычислительный конвейер.

Ооо я ждал эту порцию бреда :)

'Разрыв вычислительного конвеера' сам придумал т.к. бред с конвеером не прокатил?

 

Про регистровую память вообще 5 баллов. Хоть у яндекса спроси что оно такое перед тем как блистать.. Скоростная регистровая память, борющаяся в разрывами конвера.. В цитатник надо.

Ссылка на сообщение
Поделиться на других сайтах
  В 22.07.2011 в 09:50, NEP сказав:
  В 22.07.2011 в 09:12, andreu.mirowni4enko сказав:
  В 21.07.2011 в 15:51, NEP сказав:

 

- Системы на базе двух десктопных процессоров скажем i7 проигрывают двухпроцессорным системам на базе серверных процессоров Xeon 55/56xx

 

 

Про какие десктопные процессоры i7 вы говорите?

 

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

 

Что-то я не могу поймать вашу мысль сначала одно потом другое.

Ссылка на сообщение
Поделиться на других сайтах
  В 22.07.2011 в 10:12, KaYot сказав:

Ооо я ждал эту порцию бреда :)

'Разрыв вычислительного конвеера' сам придумал т.к. бред с конвеером не прокатил?

 

Про регистровую память вообще 5 баллов. Хоть у яндекса спроси что оно такое перед тем как блистать.. Скоростная регистровая память, борющаяся в разрывами конвера.. В цитатник надо.

 

Да, представьте себе, в процессе переключения контекста конвейер инструкций рвется перманентно, он недогружен! От сюда и нерациональное использование ресурсов процессора.

 

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

 

А вас в ПТУ не учили, что такое конвейер? Составьте из сумматора, умножителя и ... конвейер для вычисления x+y*z. Посмотрим какой вы Сухов :) Может быть тогда дойдет, что такое конвейер и зачем используют RDIMM.

Ссылка на сообщение
Поделиться на других сайтах
  В 22.07.2011 в 10:17, NEP сказав:

А вас в ПТУ не учили, что такое конвейер? Составьте из сумматора, умножителя и ... конвейер для вычисления x+y*z. Посмотрим какой вы Сухов :) Может быть тогда дойдет, что такое конвейер и зачем используют RDIMM.

Ну вот, вместо аргументов полетело говно. Стандартный ход..

Раз уж начал, давай, развивай мысль про скоростную буферизированную память и зачем ее используют в современных серверах. Как она борется с разрывами и каким образом может снижать латентность, принципиально являясь более медленной как раз в плане задержек.

Ссылка на сообщение
Поделиться на других сайтах
  В 22.07.2011 в 14:01, KaYot сказав:

Ну вот, вместо аргументов полетело говно. Стандартный ход..

Раз уж начал, давай, развивай мысль про скоростную буферизированную память и зачем ее используют в современных серверах. Как она борется с разрывами и каким образом может снижать латентность, принципиально являясь более медленной как раз в плане задержек.

 

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

Ссылка на сообщение
Поделиться на других сайтах
  В 22.07.2011 в 09:40, NEP сказав:

Спрашиваю в третий раз. Какие операции выполняет этот код? Ну распишите по ступеням, что в этом время происходит с конвейером. Неужели так сложно.

Сохранение регистров в стек (в т.ч. и MMX/SSE), сохранение указателя стека, изменение CR3 (смена page directory), загрузка нового указателя стека, загрузка регистров из стека, смена карты I/O портов, восстановление TLB (хотя точно не уверен, надо в код смотерть - а лень)... Конвейер в это время собссно обрабатывает эти комманды :)

 

  В 22.07.2011 в 10:01, NEP сказав:

Ладно.

 

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

 

Кеш сбрасывается при каждом вызове прерывания? :rolleyes: Ну-ну...

 

  В 22.07.2011 в 10:01, NEP сказав:
Опять же использование регистровой памяти (т.е двух ступенчатого конвейера Register - DRAM) позволяет незначительно нивелировать латентность памяти и позволяет существенно реже разрывать вычислительный конвейер.

Чтобы вы знали, registered DRAM имеет латентность больше, чем небуфферизированная. И частоты ниже. За счет того, что дополнительный такт тратится на занесение состояния лини адреса/выбора чипа в тот самый регистр. И ее плюс совсем не в том, что она быстрее - а в том, что большее кол-во модулей может работать на одной шине.

Ссылка на сообщение
Поделиться на других сайтах
  В 22.07.2011 в 15:11, NiTr0 сказав:

Сохранение регистров в стек (в т.ч. и MMX/SSE), сохранение указателя стека, изменение CR3 (смена page directory), загрузка нового указателя стека, загрузка регистров из стека, смена карты I/O портов, восстановление TLB (хотя точно не уверен, надо в код смотерть - а лень)... Конвейер в это время собссно обрабатывает эти комманды :)

 

Ну вот давайте распишем сохранение одного регистра в стек. Что там у вас с латентностью? 1 такт, да?

 

  Цитата

Кеш сбрасывается при каждом вызове прерывания? :rolleyes: Ну-ну...

 

Чукча не читатель, чукча писатель. Не сбрасывается, а залолняется новыми данными. Вся работа по оптимизации и заполнению кеша для старой задачи - становится неактуальной, в этом и заключается разрыв вычислительного конвейера и основная причина потери производительности.

 

  В 22.07.2011 в 10:01, NEP сказав:

Чтобы вы знали, registered DRAM имеет латентность больше, чем небуфферизированная. И частоты ниже. За счет того, что дополнительный такт тратится на занесение состояния лини адреса/выбора чипа в тот самый регистр. И ее плюс совсем не в том, что она быстрее - а в том, что большее кол-во модулей может работать на одной шине.

 

 

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

Ссылка на сообщение
Поделиться на других сайтах
  В 22.07.2011 в 15:31, NEP сказав:

Ну вот давайте распишем сохранение одного регистра в стек. Что там у вас с латентностью? 1 такт, да?

Что там у нас с кешами, отсутствуют да?

 

  В 22.07.2011 в 15:31, NEP сказав:
Чукча не читатель, чукча писатель. Не сбрасывается, а залолняется новыми данными. Вся работа по оптимизации и заполнению кеша для старой задачи - становится неактуальной, в этом и заключается разрыв вычислительного конвейера и основная причина потери производительности.

Повторюсь: 3 МБ данных обработано между прерываниями, обрабатывались они пускай 500кб кода, + 200 кб кода обработчик прерываний. Какова вероятность того, что в кеше объемом 6 МБ будет отсутствовать код обработчика прерывания?

 

  В 22.07.2011 в 15:31, NEP сказав:
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

При одинаковых таймингах модулей и одинаковых частотах - да. Т.к. command rate будет 1T против 2Т у unbuffered (другие тайминги не меняются-то при этом). Но вот незадача, unbuffered память имеет более низкие тайминги и более высокую рабочую частоту.

Кстати, влияние 1T/2T command rate на деле ничтожно (можете сами проверить, поклацав биосе своего десктопа данный параметр). Но нужно же производителям как-то обосновать, почему всем и всегда нужна именно регистровая медленная мамять, а не быстрая небуфферизированная - даже на серверах с 2 слотами на канал КП.

Ссылка на сообщение
Поделиться на других сайтах
  В 22.07.2011 в 15:58, NiTr0 сказав:

Что там у нас с кешами, отсутствуют да?

 

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

 

  Цитата

Повторюсь: 3 МБ данных обработано между прерываниями, обрабатывались они пускай 500кб кода, + 200 кб кода обработчик прерываний. Какова вероятность того, что в кеше объемом 6 МБ будет отсутствовать код обработчика прерывания?

 

Судя по потерям производительности при интенсивной обработке прирываний нептристойно! высока.

 

  Цитата

При одинаковых таймингах модулей и одинаковых частотах - да. Т.к. command rate будет 1T против 2Т у unbuffered (другие тайминги не меняются-то при этом). Но вот незадача, unbuffered память имеет более низкие тайминги и более высокую рабочую частоту.

Кстати, влияние 1T/2T command rate на деле ничтожно (можете сами проверить, поклацав биосе своего десктопа данный параметр). Но нужно же производителям как-то обосновать, почему всем и всегда нужна именно регистровая медленная мамять, а не быстрая небуфферизированная - даже на серверах с 2 слотами на канал КП.

 

На маршрутизаторе мне нужна не "быстрая" память, а память имеющая наименьшую латентность.

Ссылка на сообщение
Поделиться на других сайтах
  В 22.07.2011 в 16:09, NEP сказав:

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

Чего вам рассказывать? Что переход при обработке прерывания в другой сегмент того же аппаратного контекста задачи (ибо переключение контекста приложений чисто программное) не приводит ни к сбросу кешей, ни тем более к их отключению на запись?

 

  В 22.07.2011 в 16:09, NEP сказав:
Судя по потерям производительности при интенсивной обработке прирываний нептристойно! высока.

Только в случае 100-200 тысяч(!) прерываний в секунду.

 

  В 22.07.2011 в 16:09, NEP сказав:
На маршрутизаторе мне нужна не "быстрая" память, а память имеющая наименьшую латентность.

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

Ссылка на сообщение
Поделиться на других сайтах
  В 22.07.2011 в 17:15, NiTr0 сказав:

Чего вам рассказывать? Что переход при обработке прерывания в другой сегмент того же аппаратного контекста задачи (ибо переключение контекста приложений чисто программное) не приводит ни к сбросу кешей, ни тем более к их отключению на запись?

 

Мне не надо рассказывать. Вы не владеете ни терминологией ни должным опытом. Вы рассказываете как шумит лес и при этом никогда не были в лесу! Берите ручку, бумагу - рисуйте!

 

  Цитата

Только в случае 100-200 тысяч(!) прерываний в секунду.

 

Ну вот такой себе soft-router с 8-мью 1Г интерфейсами!

 

  В 22.07.2011 в 16:09, NEP сказав:

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

 

Причем тут такты? Латентность динамической памяти порядка 50-200 нс. Вы понимаете о какой латентности идет речь?

Ссылка на сообщение
Поделиться на других сайтах
  В 22.07.2011 в 17:39, NEP сказав:

Мне не надо рассказывать. Вы не владеете ни терминологией ни должным опытом. Вы рассказываете как шумит лес и при этом никогда не были в лесу! Берите ручку, бумагу - рисуйте!

Что рисовать? что при сохранении значения в стек оно попадет сначала в кеш, который write-back? Или что при вызове прерывания кеш не переключается в write-through и не отключается?

 

  В 22.07.2011 в 17:39, NEP сказав:
Ну вот такой себе soft-router с 8-мью 1Г интерфейсами!

Или 500-800 мбит в каждую из сторон для сетевух без interrupt moderation...

 

  В 22.07.2011 в 17:39, NEP сказав:
Причем тут такты? Латентность динамической памяти порядка 50-200 нс. Вы понимаете о какой латентности идет речь?

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

Повторюсь: проведите эксперимент, возьмите мат. плату c DDR2 и плашку быстрой памяти, поставьте тайминги 5-5-5-15, частоту в 667 МГц, command rate = 1T (типовые параметры для registered DDR2 DIMM), измерьте латентность. Потом поставьте command rate = 2T, частоту 1066МГц, тайминги 4-4-4-12 и измерьте латентность. Во 2-м случае латентность будет ниже.

Опять же, 2Т задержки ставятся только в случае установки 2 модулей на канале, с одним модулем - command rate равно 1Т, как и у регистровой.

Ссылка на сообщение
Поделиться на других сайтах
  В 22.07.2011 в 17:39, NEP сказав:
  В 22.07.2011 в 16:09, NEP сказав:

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

Причем тут такты? Латентность динамической памяти порядка 50-200 нс. Вы понимаете о какой латентности идет речь?

NEP уже сам с собой спорит? :)

trollface-3078_preview.jpg

Ссылка на сообщение
Поделиться на других сайтах
  В 22.07.2011 в 20:06, Abram сказав:
  В 22.07.2011 в 17:39, NEP сказав:
  В 22.07.2011 в 16:09, NEP сказав:

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

Причем тут такты? Латентность динамической памяти порядка 50-200 нс. Вы понимаете о какой латентности идет речь?

NEP уже сам с собой спорит? :)

trollface-3078_preview.jpg

не, то кто-то переудалил лишний тег цитаты, но получилось забавно ))

топикстартера жалко, он так и не узнает, какой же проц лучше, зато прослушал универский курс микропроцессорной техники почти бесплатно ))

Ссылка на сообщение
Поделиться на других сайтах

Так это нормально. Сам зачем-то завел разговор о конвеерах и их разрывах в совершенно левой теме, по мере нарастания контраргументов плавно переехал на стоимость каналов в европе, потом на то что сервера должны быть сугубо кошерными, блеснул познаниями в регистровой памяти, послал всех в сад и ушел спать с чувством выполненного долга :rolleyes:

Ссылка на сообщение
Поделиться на других сайтах
  В 19.07.2011 в 08:44, NEP сказав:

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

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

Ссылка на сообщение
Поделиться на других сайтах
  В 22.07.2011 в 20:22, alk0v сказав:

не, то кто-то переудалил лишний тег цитаты, но получилось забавно ))

Я заметил. По-моему, изначально процитированный пост был от NiTr0. Потому и вставил троллфейс. :rolleyes:

Ссылка на сообщение
Поделиться на других сайтах
  В 22.07.2011 в 20:59, KaYot сказав:
  В 19.07.2011 в 08:44, NEP сказав:

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

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

 

А можете простенький конвейер для вычисления функции x+y*x составить? Нет? Или вы тоже любитель порассуждать о шуме леса не разу там не побывав?

 

Цитируемое вами сообщение это просто условная модель, условного процессора облегчающая понимание процесса для солдата и матроса.

 

Читать до полного просветления:

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

 

В результате, на нерационаьное расходование ресурсов может уйти более 50% процентов от общего времени исполнения программы, в результате того, что каждое прерывание будет нивелировать производимые процессором оптимизации.

 

Это и есть разрыв ВЫЧИСЛИТЕЛЬНОГО конвейера, а не тупо сброс конвейера инструкций

 

Опять же использование регистровой памяти (т.е двух ступенчатого конвейера Register - DRAM) позволяет незначительно [http://en.community.dell.com/dell-blogs/enterprise/b/tech-center/archive/2009/04/08/nehalem-and-memory-configurations.aspx] нивелировать латентность памяти и позволяет существенно реже разрывать вычислительный конвейер.

Ссылка на сообщение
Поделиться на других сайтах
  Цитата

Что рисовать? что при сохранении значения в стек оно попадет сначала в кеш, который write-back? Или что при вызове прерывания кеш не переключается в write-through и не отключается?

 

Это ваша сексуальная фантазия?

 

  Цитата

Или 500-800 мбит в каждую из сторон для сетевух без interrupt moderation...

 

Так, на будущее. Количество прерываний слабо коррелирует с пропускной способностью. У меня средний размер пакетов 80-90байт. Такого траффика 2-3Г "в каждую сторону"

 

  Цитата

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

Повторюсь: проведите эксперимент, возьмите мат. плату c DDR2 и плашку быстрой памяти, поставьте тайминги 5-5-5-15, частоту в 667 МГц, command rate = 1T (типовые параметры для registered DDR2 DIMM), измерьте латентность. Потом поставьте command rate = 2T, частоту 1066МГц, тайминги 4-4-4-12 и измерьте латентность. Во 2-м случае латентность будет ниже.

Опять же, 2Т задержки ставятся только в случае установки 2 модулей на канале, с одним модулем - command rate равно 1Т, как и у регистровой.

 

Латентность памяти зависит не столько от таймингов, сколько от типа используемой памяти. Поэтому для систем свыше 10Mpps я выбирают SUP720-3cxl TCAM которых построены на базе статической памяти. А вы уныло подбираете тайминги.

Ссылка на сообщение
Поделиться на других сайтах
  В 23.07.2011 в 06:27, NEP сказав:

А можете простенький конвейер для вычисления функции x+y*x составить? Нет? Или вы тоже любитель порассуждать о шуме леса не разу там не побывав?

Я не являюсь разработчиком микропроцессоров, к чему ваши призывы? Если будем спорить о весе силикатных и глиняных кирпичей, просишь построить сарайчик перед тем как рассуждать?

  В 23.07.2011 в 06:27, NEP сказав:

Это и есть разрыв ВЫЧИСЛИТЕЛЬНОГО конвейера, а не тупо сброс конвейера инструкций

Изначально ты говорил конкретно о сбросе конвеера инструкций. Аж такты простоя посчитал. Уже потом, постепенно понимая что несешь бред, начал вставлять везде 'вычислительный конвеер'. Что само по себе достаточно нелепо.

  В 23.07.2011 в 06:27, NEP сказав:

Опять же использование регистровой памяти (т.е двух ступенчатого конвейера Register - DRAM) позволяет незначительно [http://en.community.dell.com/dell-blogs/enterprise/b/tech-center/archive/2009/04/08/nehalem-and-memory-configurations.aspx] нивелировать латентность памяти и позволяет существенно реже разрывать вычислительный конвейер.

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

Незнаю где ты откопал ссылку, и даже не вижу что в ней(видимо, секретный текст для почитателей саппорта фирмы dell), но вот выдержка из википедии:

  Цитата

Регистровая память (англ. Registered Memory, RDIMM, иногда buffered memory) — вид компьютерной оперативной памяти, модули которой содержат регистр между микросхемами памяти и системным контроллером памяти. Наличие регистров уменьшает электрическую нагрузку на контроллер и позволяет устанавливать больше модулей памяти в одном канале.

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

Ссылка на сообщение
Поделиться на других сайтах
  В 23.07.2011 в 06:36, NEP сказав:

Латентность памяти зависит не столько от таймингов, сколько от типа используемой памяти. Поэтому для систем свыше 10Mpps я выбирают SUP720-3cxl TCAM которых построены на базе статической памяти. А вы уныло подбираете тайминги.

Молодец, хороший выбор. А как это соотносится с данной темой, выбором CPU и твоим утверждением что регистровая память быстрее и борется с разрывами?

Латентность же DRAM зависит сугубо от частоты и таймингов. Естественно есть физическое ограничение самих чипов, тут никакое DDRы ничего нового не приносят, но все равно разница между модулями есть и часто многократная.

Ссылка на сообщение
Поделиться на других сайтах
  В 23.07.2011 в 11:20, KaYot сказав:

Я не являюсь разработчиком микропроцессоров, к чему ваши призывы? Если будем спорить о весе силикатных и глиняных кирпичей, просишь построить сарайчик перед тем как рассуждать?

 

Да это простой тест на наличие и качество полученного высшего образования по специальности. Вы не можете составить конвейер из трех блоков для вычисления самой тривиальной функции, которую только можно придумать! При этом лихо рассуждаете о структуре процессора! Я же говорю, вы рассуждаете о том как шумит лес, при этом сами там никогда не были!

 

  Цитата

Изначально ты говорил конкретно о сбросе конвеера инструкций. Аж такты простоя посчитал. Уже потом, постепенно понимая что несешь бред, начал вставлять везде

 

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

 

  Цитата

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

Незнаю где ты откопал ссылку, и даже не вижу что в ней(видимо, секретный текст для почитателей саппорта фирмы dell), но вот выдержка из википедии:

 

Википедия ссылается на эту статью!

 

http://en.wikipedia.org/wiki/Registered_memory

2# ^ http://en.community.dell.com/dell-blogs/enterprise/b/tech-center/archive/2009/04/08/nehalem-and-memory-configurations.aspx

Ссылка на сообщение
Поделиться на других сайтах
  В 23.07.2011 в 11:28, NEP сказав:

Интересная статья. Вот только дочитай ее до конца внимательно.

Самая быстрая конфигурация - 3 канала UDIMM, по 1 модулю на канал.

RDIMM быстрее чем UDIMM только если ставить 2 или 3 модуля на канал, 6(и 9) модулей может быть нужно серверу баз данных или хостерам, но никак не роутеру..

Кстати, я со статьей не совсем согласен. В тестах фцентра и хобота самый быстрый режим вообще - 2 канала, 3тий добавлен сугубо для поддержки большего объема памяти. Разница минимальна, но она не в пользу 3ех канального редима! Поэтому платформы 1156 и 1366 при всем желании не отличаются по скорости, хотя 2 канала против 3ех.. И у декстопного санди по той же причине 3тий канал изъяли.

 

Про героическую борьбу RDIMM с разрывами конвеера там кстати так ничего и нет)

Відредаговано KaYot
Ссылка на сообщение
Поделиться на других сайтах
  В 23.07.2011 в 12:29, KaYot сказав:
  В 23.07.2011 в 11:28, NEP сказав:

Интересная статья. Вот только дочитай ее до конца внимательно.

Самая быстрая конфигурация - 3 канала UDIMM, по 1 модулю на канал.

RDIMM быстрее чем UDIMM только если ставить 2 или 3 модуля на канал, 6(и 9) модулей может быть нужно серверу баз данных или хостерам, но никак не роутеру..

 

Про героическую борьбу RDIMM с разрывами конвеера там кстати так ничего и нет)

 

У меня в топовых soft-router-ах именно по 6 RDIMM 1G.

Ссылка на сообщение
Поделиться на других сайтах

Создайте аккаунт или войдите в него для комментирования

Вы должны быть пользователем, чтобы оставить комментарий

Создать аккаунт

Зарегистрируйтесь для получения аккаунта. Это просто!

Зарегистрировать аккаунт

Вхід

Уже зарегистрированы? Войдите здесь.

Войти сейчас
  • Зараз на сторінці   0 користувачів

    Немає користувачів, що переглядають цю сторінку.


×
×
  • Створити нове...