Re: Linux and FreeBSD

From

Valentin Nechayev (2:5020/400)

To

Vladimir Stvolov

Date

2005-06-01T10:25:54Z

Area

RU.UNIX.BSD

From: Valentin Nechayev <netch@segfault.kiev.ua>


>>> Vladimir Stvolov wrote: 

 VN>> Знают. Но проблема в том, что cut-through, fragment-free и прочие
 VN>> настолько сильно усложняют свич, что он не может выйти на требуемые
 VN>> сейчас скорости. Потому и получилось у кошки что эти методы окончились
 VN>> на 19xx и 29xx.
VS>     По мере появления технологий свичевания было как раз от простого к сложному
VS> - cut-through, fragment-free и теперь store-and-forward.

cut-through и fragment-free не проще, а сложнее. Потому что требуется
аккуратная синхронизация скорости приёма и передачи, учёт разницы скоростей
(как надо делать если принимаем на 10Mbit а отдаём на 100Mbit? Принять с
запасом или целиком? и так далее...), внутренний одновременный захват двух
портов... словом, если программировали многонитевые приложения, знаете, какой
это гимор. А в железе - тем более гимор. Принять пакет целиком, пожевать
его и отдать опять же целиком - куда проще.

VS> И последний вытеснил
VS> остальных лишь потому, что позволяет делать с полученным пакетом все, что
VS> угодно - как то - залезть внутрь пакета, посчитать контрольную сумму и в случае
VS> несовпадения дропнуть принятый пакет, QoS опять же, acl проверить и пр.

Нет. Контрольная сумма на cut-through и fragment-free не проверяется
принципиально, это типа как плата за скорость. Для остального же требуется
не весь пакет (кроме случая анализа payload'а... и то часто можно обойтись
ip заголовком), а лишь его начало. (Разумеется, это сильное усложнение
логики; с какого момента мы можем включать код обработки payload'а? А как
заказывать отложенную обработку через 20 октетов и как кэшировать результаты
разбора того что уже пришло?) У нас 1912 с dot1q даже работают,
если повар нам не врёт; Вы думаете - они при этом переключаются в полный
store-and-forward? Что-то слабо верится.

VS> учитывая, что все это сейчас делается не процессором а ASIC - то просто имеется
VS> запас в производительности и экономить его уже нет смысла. Лишь этим

Те ASIC'и давно самостоятельные процессоры, а страдания Cisco про "ах,
мы не успеваем процессором всё обрабатывать" просто смешны. Juniper почему-то
успевает, а эти - нет :)

VS> определяется свичевание store-and-forward и практически отсутствие первых
VS> двух... разумеется речь об управляемых свичах L2+ (в терминах 3com - на мой
VS> взгляд вполне удачном) :-)
VS> Cisco ICND v.2.1, volume 1, 1-7 "Frame Transmission Modes"...

Ну как всегда в такой книжке можно верить ровно половине данных и утверждений.
Остальное - перегибы, натяжки и так далее.

Лучше скажите - что там поют по поводу jumbo frames? Тотальный
store-and-forward для пакета, например, в 32K меня не радует.


-netch-
--- ifmail v.2.15dev5.3
 * Origin: Dark side of coredump (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