|
ru.networks
- RU.NETWORKS ------------------------------------------------------------------
From : Yuri PQ 2:5010/2.2 23 May 2002 14:23:46
To : Slav Matveev
Subject : правило 999999 свитчей
--------------------------------------------------------------------------------
Ку!
[020523] Slav Matveev (2:5020/968.222) Д. Yuri PQ
SM>>> пинге 1000мс. Соответственно если пакет бегает дольше, то
SM>>> коннекта не будет.
YP>> ах вот ты про что? ну это к делу не относится.
SM> Ты будешь отрицать существование таймаутов протоколов верхнего
SM> уровня? И будешь утверждать что протоколы вехрнего уровня
SM> будут работать при любых значениях задержки в линке?
нет, конечно! только маршрутизаторы вносят более существенную задержку, нежели
свитчи, но тем не менее, если верхнеуровневые протоколы умудряются работать при
30 хопах (и более), то рискну предположить, что 300 свитчей в цепочке не сильно
превысят допустимые задержки...
DT>>>> Какую задержку дает один свич?
SM>>> конечную.
DT>>>> Hу и хаб, для сравнения ;)
SM>>> чуть меньше чем свитч.
YP>> вот тут ты ошибаешься. хаб просто усиливает сигнал,
SM> Ты будешь утверждать что хаб мнгновенно транслирует сигнал
SM> на все выходы и ограничение в 2 и 4 хаба связаны не
SM> с задержкой?
читай дальше. и не собирался. мне просто не понравилось слово "чуть". оно лишено
смысла при сравнении задержек "из разных опер".
YP>> а свитч как минимум должен принять адрес назначения. так что не
YP>> "чуть"... просто смысл "задержки" у хаба один (обнаружение коллизий),
YP>> а у свитча - соовершенно другой (к коллизиям никакого отношения). не
YP>> путай человека!
SM> Смысл задержки один - интервал времени между приходом пакета
SM> на вход и выдачей его на выходе.
SM> И канал хаб-свитч-хаб даст суммарную
SM> задержку меньше, чем канал свитч-свитч-свитч, и коллизи тут
SM> совершенно не причем. (ес-но полагая что пакет бежит в гордом
SM> одиночестве)
SM> Или будешь оспаривать?
при подсчете задержки пакета для высокоуровневых протоколов задержкой пакета на
цепочке из 4 хабов можно пренебречь. :) более того, на "канале" из одних свитчей
нет коллизий в принципе, поэтому еще раз рискну предположить, что пакеты
высокоуровневых протоколов будут меньше "тормозить", чем в "канале", содержащем
хоть один хаб. :)
YP>> число подрядстоящих свитчей зависит только от размера таблиц. и то,
YP>> если учесть, что нормальный свитч при переполнении своей таблицы
YP>> обязан работать (хотя бы как хаб), а не виснуть, то вообще ограничений
YP>> быть не должно.
SM> Родимый, ты в конце концов получишь задержку в пути пакета такую,
SM> что ни один протокол не дождется ответа. Это так тяжело понять?
SM> Что если задержка на коммутатор t, а таймаут T, до достаточно
SM> поставить T/t +1 коммутаторов, что бы сеть не работала?
чтобы сеть не работала, нужно чтобы все протоколы не работали. хорошо, возьмем
единственный протокол, и будем считать, что если не работает т-мэйл, не работает
ничего. :) задержка в 1 секунду (для т-мэйла) - это до фига! даже если у нас
такие тормозные свитчи, что дают задержку в 1 миллисекунду, то 999 штук в
цепочку я могу поставить без напряга! тебе так трудно было произвести в уме эти
вычисления? :) но реально ни один свитч такой большой задержки в 1 миллисекунду
не даст, так что не надо паники.
Ку! 8*{PQ}
... Last reboot was 02/05/22 at 19:02:35
---
* Origin: TEAM * MD! (2:5010/2.2)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
