|
ru.unix.bsd
- RU.UNIX.BSD ------------------------------------------------------------------
From : Constantin Stefanov 2:5020/400 30 May 2005 18:41:14
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мкс, у тебя что там, машина времени?
> 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. У тебя меньше минимальная, на
> коротких пакетах.
Которая очень часто играет большую роль при решении рассчетных задач. И
именно поэтому стремятся уменьшить латентность.
Кстати, почему меньше средняя задержка, я так и не понял. Задержка
считается не до момента конца передачи, а от начала передачи до конца
приема (именно это играет роль). И как ее может уменьшить
store-and-forward в случае блокировки, я не понимаю. Какая разница, где
пакет будет висеть - где-то по пути, или в свитче. Все равно пока
предыдущий не пройдет, этот не поедет.
> >> 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%
Это теория, а не практика. Hо пусть так. 1/9001 - это 0.011%. Вот и
получается, что увеличение размера пакета на 0.011% приводит к
увеличению времени передачи на 0.6%. Т.е. относительная разница - почти
в 60 раз. Таким образом, появляются дипазоны размеров сообщений, где
реальная скорость передачи падает (условная 1 на 9000 и 0.94 на 9001).
Как такое учесть при написании программы высокого уровня?
> >> CS> Во-вторых, на InfinBand релизована хитрая технология RDMA (Remote
> >> CS> DMA), которая позволяет дать карточке команду "отслать вот эту
> >> CS> область данных (ну или принять от того-то туда-то)", после чего весь
> >> CS> процесс произойдет без прерываний, т.е. опять имеем уменьшение
> >> CS> нагрузки.
> >>
> >> А теперь без булшита -- чем это круче тривиального busmaster в
> >> тривиальныйх интелях и броадкомах? И почему тебе после отсылки прерывание
> >> не нужно?
> CS> Hужно. Только ты сможешь сказать ителю "отошли мне вот отсюда 2 МБ"? Я
> CS> не знаток устройства PCI, но что-то мне кажется, что все-таки ему нельзя
> CS> сказать отсылать такую большую порцию данных.
>
> Тут не PCI, тут IP с [G]Ethernet тебе подлянку сделают.
> Hо ему можно дать очередь пакетов на отправку. Т.е. можно сказать отослать 100
> пакетов, каждый по 9000 байт.
Дать очередь - это по одному дать указание, или все же одним командой
"отсюда 2 МБ"? Опять же упираемся в максимальный размер пакета. В
ethernet на пакеты все режет софт. А тут - карта. Сколько прерываний
экономим?
> CS> Кроме того, там можно настроить все это так, чтобы одна машина дает
> CS> команду своим драйверам "воон тому хосту можно лить мне в память что ему
> CS> надо". А тот уже дает команду драйверу, в какое место адресного
> CS> пространства удаленного процесса запихнуть данные. Это не очень секурно
> CS> вероятно, но там, где это применяется, другие подходы к безопасности, но
> CS> опять-таки позволяет сэкономить.
>
> Я не уверен что это реально применимо. Hе по соображениям секурности, а по
> возможности все это проинтегрировать друг с другом и синхронизировать доступ к
> данным. Могу ошибаться.
Работает. Реально.
> CS> Слав, ты пойми, это не нужно в обычных сетях. Это нужно именно в
> CS> числодробилках, причем не на всех задачах. А там - время счета
> CS> уменьшается в разы при переходе от гигабитаного эзернета к тому же
> CS> InfiniBand. А это в данном случае и есть критерий истины.
>
> Это были прямые эксперементы на современном оборудовании? Hе на железяках 1996
> года (все что я видел уши имели оттуда)?
> Если так -- буду знать на будущее.
Вполне современное. Приехало в ноябре прошлого года, декабрь-март
собирали и отлаживали, вот недавно пользователям отдали. Это кластер из
80 двухпроцессорных Оптеронов, связанных InfiniBand. Там же есть и
гигабит, по нему бегает NFS и всякие управляющие вещи типа rsh или ssh.
Если интересны подробности - http://parallel.ru/cluster/ant-config.html
, а также http://parallel.ru/cluster/ , там описаны другие кластеры, что
стоят у нас.
--
Константин Стефанов
--- ifmail v.2.15dev5.3
* Origin: Demos online service (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
