Re: Linux and FreeBSD

From

Dmitry Miloserdov (2:5020/400)

To

Slawa Olhovchenkov (2:5054/37.63)

Date

2005-05-31T14:54:10Z

Area

RU.UNIX.BSD

From: "Dmitry Miloserdov" <dmitry@bis.ru>

Hello, Slawa!
You wrote to Constantin Stefanov on Mon, 30 May 2005 17:57:08 +0400:
 CS>> Кстати, почему меньше средняя задержка, я так и не понял. Задержка
 CS>> считается не до момента конца передачи, а от начала передачи до конца
 CS>> приема (именно это играет роль). И как ее может уменьшить
 CS>> store-and-forward в случае блокировки, я не понимаю. Какая разница,
 CS>> где пакет будет висеть - где-то по пути, или в свитче. Все равно пока
 CS>> предыдущий не пройдет, этот не поедет.
 SO> на другие порты можно передавать. в системе существенно более 2-х
 SO> машин. соответственно блокироваться будет только пакеты на dst порт, а
 SO> все остальные добегут куда надо.
 SO> Напрмер, с п1 и п2 хотят передать пакеты на порты 3 3 4 5 6 и 3 3 7 8 9
 SO> соответственно. В системе без буферизации:
 SO> п1-3
 SO> п2-3
 SO> п1-3
 SO> п2-3
 SO> п1-4 п2-7
 SO> п1-5 п2-8
 SO> п1-6 п2-9
ну для начала п2-3 не мешает п1-4 так что схема немного неверна

 SO> в системе с буферизацией:
 SO> п1-3 п2-3
 SO> п1-3 п2-3 3:п2
 SO> п1-4 п2-7 3:п1
 SO> п1-5 п2-8 3:п2
 SO> п1-6 п2-9
возможно так работают системы с буфферизацией но разговор был
про store-n-forward а он должен сработать так:

 in:1-3 in:2-3
 in:1-3 in:2-3 out:1-3
 in:1-4 in:2-7 out:2-3
 in:1-5 in:2-8 out:1-3 out:1-4 out: 2-7
 in:1-6 in:2-9 out:2-3 out:1-5 out: 2-8
 out:1-6 out:2-9
т.е для второго пакета из 2 в 3 получили задержку ~288мкс (если это 9k
пакеты на
гигабитном линке) которую никак невозможно предсказать.
В реальных железках будет еще хуже - этот пакет скорее всего вообще не будет
доставлен.
В случае же "без буфферизации" задержка как минимум видна отправляющему
устройству и он может переставить пакеты. Это если мы не говорим про
эзернет.
Если же случай "без буферизации" тоже относился к эзернету то он
должен был называться (в цисковской интерпретации) cut-through или
fragment-free.
Но в этих технологиях буферизация есть и задержка в них существенно меньше.
Выглядеть это должно примерно так:
 in:1-3 in:2-3 sleep(s) out:1-3
 in:1-3 in:2-3 sleep(s) out:2-3
 in:1-4 in:2-7 sleep(s) out:1-3 out:1-4 out: 2-7
 in:1-5 in:2-8 sleep(s) out:2-3 out:1-5 out: 2-8
 in:1-6 in:2-9 sleep(s) out:1-6 out:2-9
где s ~50ns для cut-through и ~500ns для fragment-free
Так что store-n-forward гораздо медленнее конкурентов если мы про эзернет.
Если же мы про какую либо другую технологию позволяющую проверить
незанятость канала от источника до приемника то буферизацию на свитчах
обычно даже не предусматривают.


PS: Везде где в этом сообщении я написал "пакет" я имел ввиду "фрейм".

With best regards, Dmitry Miloserdov.  E-mail: dmitry@bis.ru

--- 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