Re: Linux and FreeBSD

From

Constantin Stefanov (2:5020/400)

To

Valentin Davydov

Date

2005-06-01T18:41:52Z

Area

RU.UNIX.BSD

From: Constantin Stefanov <cstef@mail.ru>

Valentin Davydov wrote:
>>>>Погоди, SCI -- это бублик, я правильно помню?
>>>>Воткни гигабитные карточки друг в друга, без свича -- то же самое и
>>>>выйдет.
>>CS> Бублик - есть тор двумерный. SCI может работать еще и в одномерном
>>CS> режиме (кольцо), и в трехмерном. Но это к слову. Во-первых, даже если ты
>>CS> натычешь по четыре гигабитаи все объединишь в тор,
>>Можно ставить четырехголовые интеловые карты.
> И делать из них четырёхмерные кубики о 16 узлах, как тут довольно давно Игорь
> предлагал. С четырьмя хопами максимум. Или вообще четырёхмерный симплекс из
> 5 узлов с одним-единственным хопом между каждыми. Кстати, в симплексной
> топологии до некоторых пор имеет смысл ставить в каждую тачку по несколько
> карт, поскольку локальные ресурсы не тратятся на форвардинг пакетов.
> На тыщу с хвостиком уе можно три карты натолкать, плюс порт на мамке -
> итого 14 узлов, плюс под сотню кабелей по $1.
Куб имеет тот недостаток, что есть "особые" узлы - крайние, из которых 
пути до других в среднем длиннее. Замыкая куб в тор мы занедорого 
получаем одинковую среднюю длину пути до всех остальных из любого узла. 
А связь все со всеми имеет число соединений квадратично от числа узлов, 
что очень быстро приводит к невозможности в этом разобраться. А если 
делать маленькие кубики, то получаем неоднородную сеть, что сильно 
усложняет программирование, либо, если мы плюем на ее неоднородность, мы 
рискуем нарваться на узкие места на связях между кубиками.

>>CS> а тут все на карточке. А во-вторых, я что-то не уверен, что даже если
>>CS> ты воткнешь два гигабита друг в друга, ты получишь латенстность
>>CS> порядка 2 мкс
>>
>>А куда ж оно денется.
>>
>>CS> (хотя как проверить, не знаю).
>>
>>Да, земр столь малых времен -- проблема.
> 
> Дык, как обычно производительность меряют. Берут стандартную задачу
> и смотрят, за сколько времени она считается.
В результате ты получишь результат, зависящий от многих факторов. А 
хочется замерить именно задержку в передаче пакета, без влияния всего 
остального. Или ты знаешь такую задачу, которая после счета выдаст тебе 
эту задержку в единицах времени? Тогда поделись, пожалуйста - было бы 
приятно иметь универсальный инструмент, пригодный для любой сети.

-- 
Константин Стефанов
--- ifmail v.2.15dev5.3
 * Origin: Demos online service (2:5020/400)
SEEN-BY: 46/50 50/203 520 400/814 450/159 186 247 1024 451/30 461/43 132 640
SEEN-BY: 469/999 550/196 4616/3 4625/8 4627/10 4635/4 4652/15 5000/76 5000
SEEN-BY: 5006/1 5007/1 5010/70 5011/13 5015/10 5019/31 5020/52 118 154 175 194
SEEN-BY: 5020/400 545 549 604 715 758 830 937 1057 1523 1604 1630 1922 2020
SEEN-BY: 5020/2142 2238 2450 2590 4441 5021/29 5022/128 5025/3 750 5026/45
SEEN-BY: 5027/16 5029/32 5030/49 115 473 500 556 966 1063 1900 5031/70 72
SEEN-BY: 5034/13 5035/3 38 5036/1 34 5042/13 5049/1 50 97 5051/15 5054/1 4 8 9
SEEN-BY: 5054/28 35 36 37 63 66 67 70 75 81 84 85 5055/95 5057/1 5060/88
SEEN-BY: 5061/15 120 5062/1 10 5063/3 5066/18 5067/2 5069/7 5070/1222 5074/9
SEEN-BY: 5075/5 35 5079/23 5080/80 1003 5081/2 5082/6 5083/21 5085/13 5090/108
SEEN-BY: 5095/20 5096/18 6000/12 254 6001/3 10

PATH: 5020/400 4441 545 5054/1 37