Кстати насчет ссылочек. Подкиньте ссылочку, на основании которой, вы утверждали что Intel использует 2 ядра в SPEC.

matik
Охлаждая X6800 боксовым кулером от Prescott-а, NAWHI обнаружил на Core 2 Duo Extreme X6800 тротлинг...
Ну так и есть. Чтобы вписаться в TDP и не выйти за рамки в них "вшивают защиту". А что, этого не должно было быть?

matik
да уверен, на форуме IXBT.

BorisU
Я не помню у себя ни одной такой формулировки. Помню мой вопрос о том, уверены ли Вы в том, что используется только одно ядро?
Как говорится в старом анекдоте, есть нюанс ©.

U2
Ну так и есть. Чтобы вписаться в TDP и не выйти за рамки в них "вшивают защиту". А что, этого не должно было быть?
Интрига в другом. У Core 2 Duo 6800 величина TDP — 75Вт (по документации). Интеловский боксовый кулер для Prescott-а рассчитан на 125Вт TDP.
Однако с ним Core 2 Duo Extreme X6800 стал тротлиться.... Вот что странно. Разумеется, возникли вопросы. А кое-кто и намекал на всякое нехорошее

matik
http://forum.ixbt.com/topic.cgi?id=15:52933-274#8744

BorisU
Фи, какой плохой пример Вы нашли Там был гораздо более интересный
На этом четко видно, для кого я это писал

P.S. И вообще, ложитесь уже спать, а то из-за Вас и я не ложусь

matik
Однако с ним Core 2 Duo Extreme X6800 стал тротлиться....
А у того кулера с оборотами было все ОК? И наскольо праивльно он был посажен?

matik
Там был гораздо более интересный
Ну я помню, вы много чего написали, лень искать

На этом четко видно, для кого я это писал
для Шумахера?

U2
А у того кулера с оборотами было все ОК? И наскольо праивльно он был посажен?
После первого раза обороты были жестко включены на максимум. Посажен правильно, NAWHI отвечал. Он проделал измерения и с другим кулером, результаты отличались. Собственно, так и обнаружился эффект.

BorisU
для Шумахера?
Да, для местячкового

Ну я помню, вы много чего написали, лень искать
Тем не менее, такого утверждения все же не было. Было предположение в одном месте

BorisU
жалко что такую раритетную вещь потеряли
А я не потерял. Посмотрел, вот он, болтается на моем столе

matik
Он проделал измерения и с другим кулером, результаты отличались. Собственно, так и обнаружился эффект.
Не понял — с другим кулером уже не было тротлинга? Так?

U2
Не понял — с другим кулером уже не было тротлинга? Так?
Ага.

потеряли-потеряли

U2
Собственно, первоисточник

Обсуждение

BorisU: Прямые измерения fcenter вас не устраивают?
О, вот Вы как запели... Помнится, когда в аналогичном случае речь шла об AMD вы с присущим брезгливым скепсисом отмахивались, мол "неизвестно что они еще там меряют".

> флажочек поищите
Да что Вы переживаете за чужой флажочек? Все робко и тайно мечтаете? Напрасно.

Цитата:

---

Да что Вы переживаете за чужой флажочек?

---

Народ..Об чём вообще разговор..Кто и чё стырил\потерял?

matik, второй (коммутируемый) вариант показывает лучшие ТТХ в случае малой загрузки ядер (когда реально работает одно ядро, а остальные, практически, на холостом ходу). При высокой же загрузке всех ядер — параметры латентности для произвольно взятого ядра становятся вообще непредсказуемыми. Можно говорить только о том, что они будут "не хуже" максимально возможной величины, но о том, что задержка для всех ядер будет одинаковая, — даже и мечтать нельзя. Следовательно, систему будет лихорадить и дергать. Это плохо.

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

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

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

Да и красиво получается, черт возьми (нарисовал — самому понравилось), а красивое — почти всегда правильно...

Stranger_NN

Я могу понять твое желание одновременной работы контроллера памяти и ввода-вывода, ну так добавь в структуру второе маркерное кольцо (меньшей ПС), как раз для контроллера ввода-вывода.

Лучше кольцо Мебиуса

Мне нравится идея, но мне кажется истина, как всегда, где-то посередине. Вы же сами приводите примеры преимуществ TR на числе узлов > 10. ИМХО, кольцевая топология будет реализована в будущих многоядерных архитектурах, но не как полная замена коммутаторов. Она может взять на себя определенные функции (например, снуп интерфейсы, поддержку когерентности и т.д.). Такая шина гарантирует плавность и высокую скорость обмема данных прогнозируемого объема (т.е. не превышающего определенную величину) между всеми источниками/потребителями. Но коммутация дает значительно лучший пиковый результат при интенсивном обмене данных между парами функциональных узлов. Если при помощи кольцевой маркерной шины снять фоновую нагрузку, то и эффективность коммутации может вырасти в разы

Stranger_NN
В системе же с кольцевой маркерной шиной — латентность для каждого ядра фиксированная и никак не зависит от степени загрузки, что, помимо прочего, еще и облегчает работу многопоточных приложений, выполняющихся на нескольких ядрах одновременно
Нееее Только в том случае, если суммарной ПСП шины хватает для всех пересылок. Если НЕ хватает — система с коммутатором намного лучше. Потому что легче переносит пики нагрузки.

Я могу понять твое желание одновременной работы контроллера памяти и ввода-вывода, ну так добавь в структуру второе маркерное кольцо (меньшей ПС), как раз для контроллера ввода-вывода
Гы А для обмена между ядрами добавить третье кольцо? Тебе не кажется, что твоя система перестала быть простой?

Да и красиво получается, черт возьми (нарисовал — самому понравилось), а красивое — почти всегда правильно...
Не, с коммутатором красивее. Топология "звезда" выгоднее по латентностям, чем топология "кольцо". Просто потому, что в первой латентность пересылок меньше.

matik

Цитата:

---

Нееее Только в том случае, если суммарной ПСП шины хватает для всех пересылок. Если НЕ хватает — система с коммутатором намного лучше. Потому что легче переносит пики нагрузки.

---

Наоборот. Ровно наоборот. Система с коммутатором переносит пики нагрузок, только в том случае, если порт назначения свободен*. Например, если у тебя сетевой коммутатор с 24 портами по 100 и двумя (в транке) по 1000mbps. Вот в этом случае — да. А если порты имеют одинаковую скорость — то возникают проблемы совместного доступа к ресурсу, особенно, если система неоднородная, а она таки — неоднородная, контроллеры памяти и ввода-вывода являются общими для всех ядер. Маркерная же система как раз замечательно работает под любой нагрузкой с портами равной скорости обеспечивая близкую к 100% утилизацию ПС.

Цитата:

---

Гы А для обмена между ядрами добавить третье кольцо? Тебе не кажется, что твоя система перестала быть простой?

---

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

Цитата:

---

Не, с коммутатором красивее. Топология "звезда" выгоднее по латентностям, чем топология "кольцо". Просто потому, что в первой латентность пересылок меньше.

---

Почему это меньше? Согласен, нет времени ожидания маркера, передавать можно немедленно, но пакет нужно полностью буферизовать в коммутаторе (помнишь, мы об этом говорили в аське), и потом, убедившись в доступности порта назначения — "переизлучить" туда. Т.е., выполнить пересылку пакета ДВА раза. Один раз — от источника к коммутатору, и второй — от коммутатора к адресату. Плюс, собственно, анализ пакета коммутатором.Может быть, для системы с большим количеством абонентов маркерная система и проиграет несколько (из-за длительности прохождения маркера), но для 4-8 ядер — точно, нет. Впрочем, для большого количества абонентов (16 и больше, скажем) можно иметь несколько колец..

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

С другой стороны, система с маркерным кольцом — в принципе лишена описываемых проблем, да еще и лишена самого коммутатора, как такового. При гарантированном и неизменном уровне латентности и доступной ПС при любых нагрузках.

--
* — McZag
>Но коммутация дает значительно лучший пиковый результат при интенсивном обмене данных между парами функциональных узлов.

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

Stranger_NN
Система с коммутатором переносит пики нагрузок, только в том случае, если порт назначения свободен
Если он занят, любая система будет переносить нагрузки плохо Потому что если контроллер памяти занят — ждут все остальные потребители. Они ВСЕ РАВНО ждут. И не важно, насколько эффективна система доставки.

Достаточно, например, ввести в структуру мультиадресный пакет, который одновременно направляется всем другимм ядрам и контроллеру памяти — например при модификации данных.. Заодно, заметь, мы гарантированно, и в один такт решаем проблему поддержания когерентности кэшей любого числа ядер..
Неа, не решаем. Мы всего лишь оповещаем одновременно. Эти данные надо еще найти всем (включая контроллер памяти), затем их изменить, и только затем все произошло.
То же самое одновременное извещение можно сделать и с коммутатором. Никаких проблем. Кстати, сама по себе идея с извещениями хороша Надо будет попинать AMD

пакет нужно полностью буферизовать в коммутаторе
Звучит страшно. Если забыть, что речь о 64 байтах, которые все равно будут буферизированы, потому что контроллер памяти — самое медленное устройство.

и доступной ПС при любых нагрузках
Ты все время хочешь забыть, что максимально доступная полоса пропускания для каждого из абонентов равна полосе пропускания шины, деленной на количество устройств. То есть для 4 ядер — 1\4 (!) от общей пропускной способности шины.
А с коммутатором — каждому ядру доступна ВСЯ полоса (если нет пересечения по адресатам приема данных)

McZag
ИМХО, кольцевая топология будет реализована в будущих многоядерных архитектурах, но не как полная замена коммутаторов. Она может взять на себя определенные функции (например, снуп интерфейсы, поддержку когерентности и т.д.). Такая шина гарантирует плавность и высокую скорость обмема данных прогнозируемого объема (т.е. не превышающего определенную величину) между всеми источниками/потребителями. Но коммутация дает значительно лучший пиковый результат при интенсивном обмене данных между парами функциональных узлов. Если при помощи кольцевой маркерной шины снять фоновую нагрузку, то и эффективность коммутации может вырасти в разы

matik

Цитата:

---

Если он занят, любая система будет переносить нагрузки плохо Потому что если контроллер памяти занят — ждут все остальные потребители. Они ВСЕ РАВНО ждут. И не важно, насколько эффективна система доставки.

---

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

Цитата:

---

Неа, не решаем. Мы всего лишь оповещаем одновременно. Эти данные надо еще найти всем (включая контроллер памяти), затем их изменить, и только затем все произошло.

---

А дальше — это уже внутренние проблемы узлов, в любом случае исполнение с неверными данными с этого момента становится невозможным.

Цитата:

---

То же самое одновременное извещение можно сделать и с коммутатором. Никаких проблем. Кстати, сама по себе идея с извещениями хороша Надо будет попинать AMD

---

Ага, точно. И называется это на языке сетевиков "широковещательный шторм". Т.е., при 8 абонентах пакет нужно будет переизлучить 7 раз... При совершенно неизвестном состоянии очередей этих портов — то ли в этом такте, то-ли там уже очередь и извещение дойдет до адресата такта через 3-4...

Цитата:

---

Звучит страшно. Если забыть, что речь о 64 байтах, которые все равно будут буферизированы, потому что контроллер памяти — самое медленное устройство.

---

При ширине канала в 64 бита — это 8 тактов на прием пакета и 8 тактов на отправку (итого 16). Минимум. При мгновенной коммутации и свободном порту назначения. Если же он занят — то 8 на передачу в коммутатор, и, если пакет стоит всего лишь вторым — еще 16 на передачу (итого — уже 24).. А для маркерной шины — этих тактов всего 8... Всегда 8, независимо от нагрузки — 8. И фиксированное время ожидания маркера..

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

Цитата:

---

Ты все время хочешь забыть, что максимально доступная полоса пропускания для каждого из абонентов равна полосе пропускания шины, деленной на количество устройств. То есть для 4 ядер — 1\4 (!) от общей пропускной способности шины. А с коммутатором — каждому ядру доступна ВСЯ полоса (если нет пересечения по адресатам приема данных)

---

А пересечения будут, и будут постоянно. Узкие места я уже показал. ДА и при межъядерном обмене постоянно будут лишние такты на оповещения уходить.. Еще и подтверждения придется вводить, от греха-то...

Все ужасы коммутатора действительны только в одном случае.
Когда ПС коммутирующей матрицы ниже суммарной ПС портов.
В случае адекватной матрицы — Full Bisectional Bandwidth с гарантированной задержкой

GNUS inc, ага, при равномерном распределении нагрузки (исходящей и входящей тож) по портам. В этом случае совершенно верно. А в случае неравномерной нагрузки и одинаковой скорости портов — все совсем не так. Самые "популярные" порты, суммарная нагрузка на которые превосходит их ПС — оказываются узким местом и начинаются спецэффекты..

GNUS inc
Все ужасы коммутатора действительны только в одном случае.

Ужасы коммутатора действительны в NUMA-подобных системах с количеством процессоров > 4. Как вы думаете, почему АМД не залепил 4-й НТ линк год или два назад? Неужели это так сложно технологически? Ведь можно было бы организовывать более продвинутые архитектуры. А вместо этого АМД тратит кучу сил на продвижение НТ 3.0, главная идея которого не архитектурные изыски, а увеличенный BW? Ответ прост. В реальной, плохо сбалансированной, с динамически меняющимися нагрузками по узлам системе, более сложная архитектура начнет есть ресурсы на обслуживание самой себя, оставив данным узенький канальчик. И никакие NUMA-ядра ОС не могут тут помочь. В нагруженной системе, в любую единицу времени, всегда есть узел, количество запросов на коммутацию с которым превышает возможности его интерфейса.
Шаг 1. Снятие некоторых ограничений на коммутацию (увеличение ПСП, буферизация, снижение латентности).
Шаг 2. Введение дополнительных шин, берущих на себя обслуживание системы и расчищающих дорогу данным.

1. Очевидно, что шаг 2 плохо реализуется на точечных соединениях. Это слишком дорогое удовольствие — проще придумать НТ4.0, НТ5.0 etc
2. Броадкаст тоже никуда не годится. При количестве узлов ~ больше 8 он начнет есть сам себя.
3. Серийный интерфейс имеет очень высокую латентность и в рамках вычислительных систем схемотехнически смотрится угрюмо.
4. Центральный коммутатор (ака Хорус) также является узким местом и, вдобавок, может быть расчитан на строго определенное число коммутируемых подузлов.
Остается маркерное кольцо, предложенное Ильей. Голосую "за". Но, как я уже поянил, не в качестве замены, а в качестве дополнительного интерфейса. Основное преимущество кольца — гарантированный уровень задержек и ПСП. Если не перестаратся и возложить на кольцо строго определенный набор функций, то отдача от него может быть очень высокой. Например, данные из памяти одного процессора перемещаются в кэш другого процессора через еще один процессор. Синронизация этих операций (т.е. командные данные, поддержка когерентности) может осуществляться через кольцевой интерфейс. Доставка сообщений, и при необходимости, получение ответа на них не будет затрагивать каналы данных.
Еще один плюс такой системы ее простота. Реализация TR-like интерфейса достаточно проста и универсальна. В системе даже могут быть устройства, которые не имеют коммутирущиего интерфейса, а обладают только кольцевым.

Примеров реализации гибридных интерфейсов хоть пруд пруди. Например, тот же FBDIMM имеет независимые шины. И кстати командный интерфейс очень-очень похож на маркерное кольцо.

McZag, да, возможно, истина где-то посередине, но я не могу отделаться от того грустного факта, что для внутрипроцессорной коммутации неизбежно утыкание в некоторые узкие места.. Возможно, конечно, дополнительная кольцевая шина и поможет расшить некоторые узкие места, но глобальной проблемы коммутатции — конкуренции за порт назначения, и соответственно, непредсказуемо изменяющейся задержки доставки — дополнительная шина решить не сможет.. Проблема..

Stranger_NN
Самые "популярные" порты, суммарная нагрузка на которые превосходит их ПС — оказываются узким местом и начинаются спецэффекты..
И все равно при адекватной матрице деградации не будет.
А при кольце — упрется в скорость кольца и все.

McZag
Как вы думаете, почему АМД не залепил 4-й НТ линк год или два назад? Неужели это так сложно технологически? Ведь можно было бы организовывать более продвинутые архитектуры.
Потому что АМД умеет считать бапки
И образцы с 4 линками у них были годы назад.
При очевидном удорожании системы (упаковка не 940 ножек, а много больше, сложнее платы и т.д.) выгоды не слишком много.

GNUS inc

Цитата:

---

И все равно при адекватной матрице деградации не будет.
А при кольце — упрется в скорость кольца и все.

---

Увы, дело в том, что матрица тут совершенно не при чем. Даже при идеальной матрице на портах назначения общих для многих пар соединений устройств (контроллеров памяти и ввода-вывода) будут образовываться неравновесные очереди с произвольно меняющимся временем доставки сообщения. Ничего с этим в коммутируемой структуре с портами равной ПС сделать нельзя. Единственный вариант — это как в сетевых коммутаторах XX*100+1/2*1000, подключать "сервер" через канал с увеличенной ПС.

Но это малореально, как вы понимаете.. Каналы и так нужно делать предельно быстрыми, так что с одной стороны создание еще более мощного канала проблематично, а с другой — урезать каналы абонентов тоже как-то не очень правильно. Впрочем, проблемы двойного (в идеале) времени доставки сообщения это все равно не решит..

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

Единственным недостатком маркерного кольца является увеличенная латентность на "холостом ходу", когда работают одно-два ядра, но им все равно приходится ждать, пока маркер добежит по кругу. Эта проблема может быть решена с помощью механизма ускоренной передачи маркера — если ядро не желает ничего "сказать", то задающее устройство не дожидаясь истечения тайм-аута (8 тактов в нашем примере, хотя для широкого кольца может быть и 4, а то и 2 такта) передает "право слова" следующему абоненту. Такой подход поможет избежать появления непродуктивных задержек (простоев маркера на неактивных абонентах) в кольцевой маркерной системе.

В данном случае получается система практически без изъянов. Для количества ядер ~16 недостатков по ср. с коммутируемой архитектурой я не вижу... А дальше.. Такие кольца можно соединять и через коммутатор, и через кольцо второго уровня — это уже завист от разумности ОС и уровня межкольцевого обмена. И, опять же, для нескольких колец данных может быть единое кольцо ввода-вывода и поддержания когерентности кэшей..

Stranger_NN
В данном случае получается система практически без изъянов
Ну да, конечно! ©

Ты оцени объем служебных вычислений для маркерного кольца (а то и двух, трех, и так далее). А затем подумай, сколько дополнительных задержек возникнет из-за этих вычислений. Их кто делать будет, Пушкин?

я не могу отделаться от того грустного факта, что для внутрипроцессорной коммутации неизбежно утыкание в некоторые узкие места..
О каком вообще количестве портов ты говоришь? О 4-х? Нет там никакой проблемы: у тебя только ввод\вывод, два ядра, и контроллер памяти. Максимум, что ты можешь коммутировать — две пары устройств. Какие неравновесные очереди? Что за проблему ты создал?

Когда\если появится 4 ядра, тоже никаких особых проблем не будет. Проблемы могут быть с десятками ядер, которые обращаются к десяткам периферийных устройств. Вот для таких массивов ядер понадобится гибридная архитектура, согласен: данные коммутировать, а управление — по кольцевой (или любой другой общей шине).
Но до этого момента никаких особых проблем нет, и быть не может.

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

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


Братство колец © у тебя получилось, а не система. "что знают трое..." Так как ты нарисовал нельзя. Максимум что можно себе позволить — две асинхронные подсиcтемы переноса данных/команд.

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

Проблема узких мест есть в любой системе. Но лучше всего с пиковыми нагрузками справляется именно прямая коммутация, и с этим спорить бессмысленно (правильнее сказать "наилучший пиковый результат дает прямая коммутация"). Даже если 50% ресурсов системы одномоментно простаивает из-за недостаточной пропускной способности коммутаторов, такая система будет более эффективна, чем любая другая. Потому что другие 50% работают на 100%. Этой системе можно помочь, убрав из траффика ряд сообщений, что существенно уменьшит латентность системы в целом. Я не берусь сказать сколько это в количественном отношении. Если взять за основу НТ 3.0, соответствующие скорости ввода вывода и 16 процессорных ядер (4х4 на трех наружних линках НТ), то смочив палец слюной, я бы предположил цифру 10-20% "бесплатного" увеличения пропускной способности в среднем по больнице и до 50% в самых худших случаях, когда возникает кросс-файер. Вот и считай, что проще Пока что АМД идет "экстенсивным" путем наращивая мощи НТ. Что будет дальше — узнаем не раньше 2008 года, имхо. Но что-то мне подсказывает, что АМД и Со с бОльшей вероятностью создаст Хорусо-подобное решение и получит очень жесткую 64-ядерную систему уже в следующем году, чем будет мучиться с новой кольцевой идеологией

McZag

Цитата:

---

Братство колец © у тебя получилось, а не система. "что знают трое..." Так как ты нарисовал нельзя. Максимум что можно себе позволить — две асинхронные подсиcтемы переноса данных/команд.

---

Ничего подобного! Если у меня хватит решимости я даже попробую в Visio изобразить структурку... Получается все совершенно гладко. Без каких-либо буферизаций, плавающих задержек, лишних транзисторов и прочей невкусной коммутаторной шняги..

Цитата:

---

Но лучше всего с пиковыми нагрузками справляется именно прямая коммутация, и с этим спорить бессмысленно (правильнее сказать "наилучший пиковый результат дает прямая коммутация")

---

Да, но только при том, что состояние порта назначения на момент начала передачи неизвестно (и, более того, резонно предположить, что порт контроллера памяти скорее всего занят), то неизбежным будет и механизм с промежуточной буферизацией и очередями на портах коммутатора.. Т.е., про коммутацию "на лету" можно забыть с самого начала.

Цитата:

---

Но что-то мне подсказывает, что АМД и Со с бОльшей вероятностью создаст Хорусо-подобное решение и получит очень жесткую 64-ядерную систему уже в следующем году, чем будет мучиться с новой кольцевой идеологией

---

Да, скорее всего так и будет. Что совершенно не меняет принципиального положения дел.

Да, я маньяк. Я их нарисовал.


Итак, простейший случай — односокетная систем, время кругового пробега маркера в которой (с учетом вышеописанного механизма экономии времени) нас устраивает:

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

И, наконец, случай односокетной системы с числом ядер большим, чем целесообразно размещать на одном кольце:

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


Не надо пугаться кажущейся сложности структуры. Внутреннее содержание коммутатора с ТТХ, какие потребны для реализованной на картинке №3 структуры — пугает меня куда как больше..

Stranger_NN
Без каких-либо буферизаций
Никаких особых буферизаций там нет, кроме заранее предусмотренных в блоке ввода\вывода. Не нужны они там.

Но лучше всего с пиковыми нагрузками справляется именно прямая коммутация, и с этим спорить бессмысленно
Отож!


P.S. Илья, ну ты и маньяк!

Stranger_NN
Внутреннее содержание коммутатора с ТТХ, какие потребны для реализованной на картинке №3 структуры — пугает меня куда как больше..
Я так и не понял, почему оно тебя пугает. У тебя есть несколько портов с пропускной способностью ну пусть 12GB\sec. Тебе надо скоммутировать их. Для этого достаточно матрицы на с пропускной способностью 6*N, где N — количество портов. Для четырех портов это 24Gbit\sec, очень небольшие требования для внутрипроцессорного коммутатора.
Например, в Infiniband-коммутаторах используются матрицы до 4Тbit (!)