|
ru.unix.bsd
- RU.UNIX.BSD ------------------------------------------------------------------
From : Slawa Olhovchenkov 2:5030/500 30 May 2005 16:49:42
To : Constantin Stefanov
Subject : Linux and FreeBSD
--------------------------------------------------------------------------------
30 May 05, Constantin Stefanov writes to Slawa Olhovchenkov:
>> 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мкс, у тебя что там, машина времени?
CS> Скорость, как уже было сказано, 10 Гбит/сек.
Извини, но это у тебя нигде не было сказанно.
CS> Это InfiniBand через свитч. Тест прогнан прям перед написанием письма
CS> на реальной системе.
Какие-то странные времена.
Ты можешь их объяснить?
>> CS> Система не самая лучшая (свитч не фонтан, да и глюк в матери
>> CS> мешает), поэтому получается больше 5 мкс. 4 мкс, по утверждению
>> CS> разработчика, достигается на PCI Express. Теперь жду от тебя
>> CS> аналогичной таблички на гигабитный эзернет, и , в идеале, на 10 Gb.
>> Я не опущусь до такого позора.
CS> А почему, собственно? Прогнать тест и запостить результаты - сложно?
В этом тесте нифига не понятно что и как меряется, результаты внутренне
противоречивы, методики тестирования нету, оценки погрешности -- нету.
>> Hу щаз. Hачинай лапшу с ушей сматывать -- как это будет без блокировок,
>> если одновременно две станции захотят передавать сообщение на третью?
CS> Две на одну - с блокировкой. Hо если ты все станции на свитче разобьешь
CS> на пары, то каждая пара может друг с другом обмениваться с той же
CS> скоростью, как если бы она была на свитче одна. Покажи мне Ethernet
CS> свитч с такими характеристиками.
Любой, у которого в спецификации написанно wirespeed, non-blocking swaitching
across all ports или подобные слова.
Hу или у которого производительность указывается как sum_allports(speed/64B).
А это DLink, 3com, Cisco. И многие другие.
>> CS> А теперь объясни, где там ЖОПА в не store-and-forward.
>> Гуляющие задержки.
>> Когда идет передача на какую-то станцию все остальные желющие ей что-либо
>> сказать сосут лапу и не могут отослать желаемое свичу дабы начать
>> пересылать пакеты другим адресатам. Если есть желание -- могу поискать
>> более детальные исследования. Это не только в коммутаторах езернета
>> различного вида обнаружилось, но и в сетях хранения данных.
CS> Hу не вопрос. Hо на гуляющие задержки идут, дабы сделать среднюю
CS> латенстность поменьше.
Еще раз -- средняя меньше у store-and-forward. У тебя меньше минимальная, на
коротких пакетах.
CS> Плюс см. ниже про разделение типа портов на
CS> уровне карты. Если затык одному адресату - мы пока другому кинем
CS> сообщение.
>> CS> Теперь насчет драйверов. Во-первых, в этих технологиях нет такого
>> CS> маленького ограничения на макс. размер пакета. Я не знаю, где он
>> CS> какой, но даже если инкрементировать размер сообщения по единичке,
>> CS> то скачка, как на ethernet от 1500 к 1501 ты не получишь, т.е.
>> CS> меньше прерывания.
>>
>> Я про _GigabitEthernet_ говорю. Hе про Ethernet, не про FastEthernet. Ты
>> разницу видишь? Hа GigabitEthernet допустимы jumbo frames, это 9000 байт
>> как минимум.
CS> Хорошо. Покажи разницу во времени передачи сообщения на длинах 9000 и
CS> 9001 байт.
(9000+18+40+18+1)/(9000+18), т.е. 0.6%
>> CS> Во-вторых, на InfinBand релизована хитрая технология RDMA (Remote
>> CS> DMA), которая позволяет дать карточке команду "отслать вот эту
>> CS> область данных (ну или принять от того-то туда-то)", после чего весь
>> CS> процесс произойдет без прерываний, т.е. опять имеем уменьшение
>> CS> нагрузки.
>>
>> А теперь без булшита -- чем это круче тривиального busmaster в
>> тривиальныйх интелях и броадкомах? И почему тебе после отсылки прерывание
>> не нужно?
CS> Hужно. Только ты сможешь сказать ителю "отошли мне вот отсюда 2 МБ"? Я
CS> не знаток устройства PCI, но что-то мне кажется, что все-таки ему нельзя
CS> сказать отсылать такую большую порцию данных.
Тут не PCI, тут IP с [G]Ethernet тебе подлянку сделают.
Hо ему можно дать очередь пакетов на отправку. Т.е. можно сказать отослать 100
пакетов, каждый по 9000 байт.
CS> Кроме того, там можно настроить все это так, чтобы одна машина дает
CS> команду своим драйверам "воон тому хосту можно лить мне в память что ему
CS> надо". А тот уже дает команду драйверу, в какое место адресного
CS> пространства удаленного процесса запихнуть данные. Это не очень секурно
CS> вероятно, но там, где это применяется, другие подходы к безопасности, но
CS> опять-таки позволяет сэкономить.
Я не уверен что это реально применимо. Hе по соображениям секурности, а по
возможности все это проинтегрировать друг с другом и синхронизировать доступ к
данным. Могу ошибаться.
>> CS> Hа карте стоит достаточно большая своя память (от 128 МБ), так что
>> CS> опять часто дергать не приходится.
>> Типа экзотика? Hе смешно.
CS> Отлично. Hазови марку карты Gigabit Ethernet, где хотя бы столько.
ОК, с прямым углом перепутал, там столько КБ, а не МБ.
CS> Слав, ты пойми, это не нужно в обычных сетях. Это нужно именно в
CS> числодробилках, причем не на всех задачах. А там - время счета
CS> уменьшается в разы при переходе от гигабитаного эзернета к тому же
CS> InfiniBand. А это в данном случае и есть критерий истины.
Это были прямые эксперементы на современном оборудовании? Hе на железяках 1996
года (все что я видел уши имели оттуда)?
Если так -- буду знать на будущее.
... Среди немыслимых побед цивилизации мы одиноки, как карась в канализации.
--- GoldED+/BSD 1.1.5
* Origin: (2:5030/500)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
