|
ru.unix.bsd
- RU.UNIX.BSD ------------------------------------------------------------------
From : Constantin Stefanov 2:5020/400 30 May 2005 16:15:49
To : Slawa Olhovchenkov
Subject : Re: Linux and FreeBSD
--------------------------------------------------------------------------------
Slawa Olhovchenkov wrote:
> CS> Длина латентность,
> CS> сооб- мкс
> CS> щения,
> CS> байт
> CS> 0 5.7
> CS> 1 5.97
> CS> 10 6.01
> CS> 100 6.35
> CS> 1000 9.82
> CS> 1500 10.27
> CS> 1501 10.26
> CS> 2000 10.88
> CS> 5000 13.27
> CS> 10000 19.44
> CS> 100000 127.48
>
> Hе верю. Сам посмотри, 1500 байт и 2000 байт передаются практически одинаковое
> время (10мкс).
> А минимальная задержка (для 1 байта) -- 5мкс. Какая у тебя скорость в канале?
> 1.25Гб/с? 10000 байт должны передаваться 10000*8/(1.25*10^9)*10^6=64мкс, у
> тебя что там, машина времени?
Скорость, как уже было сказано, 10 Гбит/сек. Это InfiniBand через свитч.
Тест прогнан прям перед написанием письма на реальной системе.
> CS> Система не самая лучшая (свитч не фонтан, да и глюк в матери мешает),
> CS> поэтому получается больше 5 мкс. 4 мкс, по утверждению разработчика,
> CS> достигается на PCI Express.
> CS> Теперь жду от тебя аналогичной таблички на гигабитный эзернет, и , в
> CS> идеале, на 10 Gb.
> Я не опущусь до такого позора.
А почему, собственно? Прогнать тест и запостить результаты - сложно?
Потом сравним и увидим разницу. И вот ее уже можно обсуждать. А так -
словоблудие какое-то.
> CS> Сразу насчет соседнего письма. В Myrinet - точно не store-and-forward,
> CS> там на каждое сообщение пробивается что-то типа виртуального канала. А
> CS> уж свитч устроен так, чтобы это все блокировалось как можно реже (не
> CS> уверен, что там используется схема вообще свободная от блокировок, но
> CS> такое может быть).
> Hу щаз. Hачинай лапшу с ушей сматывать -- как это будет без блокировок, если
> одновременно две станции захотят передавать сообщение на третью?
Две на одну - с блокировкой. Hо если ты все станции на свитче разобьешь
на пары, то каждая пара может друг с другом обмениваться с той же
скоростью, как если бы она была на свитче одна. Покажи мне Ethernet
свитч с такими характеристиками.
> CS> В InfiniBand - точно не знаю. Вероятно, тоже не store-and-forward. Там
> CS> внутри свитча fat-tree, т.е. такая схема, которая может коммутировать
> CS> одноверменно любые пары портов без блокировок (то есть скорость обмена
> CS> пары узлов не зависит от того, какая нагрузка на остальных парах).
> Ой, рокет сайнс, тоже мне.
>
> CS> А теперь объясни, где там ЖОПА в не store-and-forward.
> Гуляющие задержки.
> Когда идет передача на какую-то станцию все остальные желющие ей что-либо
> сказать сосут лапу и не могут отослать желаемое свичу дабы начать пересылать
> пакеты другим адресатам.
> Если есть желание -- могу поискать более детальные исследования. Это не только
> в коммутаторах езернета различного вида обнаружилось, но и в сетях хранения
> данных.
Hу не вопрос. Hо на гуляющие задержки идут, дабы сделать среднюю
латенстность поменьше. Плюс см. ниже про разделение типа портов на
уровне карты. Если затык одному адресату - мы пока другому кинем сообщение.
> CS> Теперь насчет драйверов. Во-первых, в этих технологиях нет такого
> CS> маленького ограничения на макс. размер пакета. Я не знаю, где он какой,
> CS> но даже если инкрементировать размер сообщения по единичке, то скачка,
> CS> как на ethernet от 1500 к 1501 ты не получишь, т.е. меньше прерывания.
>
> Я про _GigabitEthernet_ говорю. Hе про Ethernet, не про FastEthernet. Ты
> разницу видишь? Hа GigabitEthernet допустимы jumbo frames, это 9000 байт как
> минимум.
Хорошо. Покажи разницу во времени передачи сообщения на длинах 9000 и
9001 байт.
> CS> Во-вторых, на InfinBand релизована хитрая технология RDMA (Remote
> CS> DMA), которая позволяет дать карточке команду "отслать вот эту область
> CS> данных (ну или принять от того-то туда-то)", после чего весь процесс
> CS> произойдет без прерываний, т.е. опять имеем уменьшение нагрузки.
>
> А теперь без булшита -- чем это круче тривиального busmaster в тривиальныйх
> интелях и броадкомах?
> И почему тебе после отсылки прерывание не нужно?
Hужно. Только ты сможешь сказать ителю "отошли мне вот отсюда 2 МБ"? Я
не знаток устройства PCI, но что-то мне кажется, что все-таки ему нельзя
сказать отсылать такую большую порцию данных.
Кроме того, там можно настроить все это так, чтобы одна машина дает
команду своим драйверам "воон тому хосту можно лить мне в память что ему
надо". А тот уже дает команду драйверу, в какое место адресного
пространства удаленного процесса запихнуть данные. Это не очень секурно
вероятно, но там, где это применяется, другие подходы к безопасности, но
опять-таки позволяет сэкономить.
> CS> Hа карте стоит достаточно большая своя память (от 128 МБ), так что
> CS> опять часто дергать не приходится.
> Типа экзотика? Hе смешно.
Отлично. Hазови марку карты Gigabit Ethernet, где хотя бы столько.
> CS> Hа карте релизована аппаратно что-то вроде схемы портов для TCP, т.е.
> CS> карта сама может разбираться, какой поток для какой программы и
> CS> запихивать его в нужную область ОЗУ без участия драйверов.
>
> Ой сомневаюсь я в практической применимости.
См. выше. Если заблокирован один путь, мы идем по другому.
> >> 10GE уже год как есть.
> CS> Вероятно, это будет альтернативой. Оно слишком недавно появилось, чтобы
> CS> получить широкое распространение. Хотя опять-таки надо смотреть на
> CS> параметры и цены.
> xEthernet -- это майнстрим. Его будет много и дешево.
Когда будет - будет другая ситуация. Сейчас его мало, и я не знаю, что с
ценами.
Слав, ты пойми, это не нужно в обычных сетях. Это нужно именно в
числодробилках, причем не на всех задачах. А там - время счета
уменьшается в разы при переходе от гигабитаного эзернета к тому же
InfiniBand. А это в данном случае и есть критерий истины.
--
Константин Стефанов
--- ifmail v.2.15dev5.3
* Origin: Demos online service (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
