Поиск  Пользователи  Правила 
Закрыть
Логин:
Пароль:
Забыли свой пароль?
Войти
 
Страницы: Пред. 1 2
RSS
Количество коллизий в сегменте сети, Как определить средствами ОС?
 
Цитата
Shanker пишет:
А если у меня коммутатор управляемый настроен в режим работы как повторитель (зеркалирует со всех портов на все) - тогда у меня должны появиться коллизии несмотря на полный дуплекс, верно?
неверно. span port просто собирает трафик из соотв. vlan'ов в один конкретный порт. опять же, плюшки архитектуры store and forward.

Цитата
Shanker пишет:
Ты имеешь ввиду затопить порт коммутатора пакетами с разными МАС-ами чтоб он перешёл в режим коммутатора?

заполнить TCAM и заставить коммутатор заниматся рассылкой трафика по всем портам?
можно, но зачем? на дешевых длинковских мыльницах TCAM ~ на 1k адресов.
 
Цитата
Shanker пишет:
Для тестов нужен нормальный хаб. А его на сегодняшний день днём с огнём не найти.
Был бы ты из Москвы, я бы тебе дал концентратор на побаловаться. Я так извиняй...
 
Цитата
^rage^ пишет:
вот начитаются всяких древних книжек... ну откуда коллизии, если есть коммутируемая сеть и flow control?
Насчё1т коллизий - вы немножко опоздали, это я уже понял :) Я имел ввиду потерю пакетов

Цитата
^rage^ пишет:
ну занят порт для посылки фрейма, пошлем чуть позже.
Но это совсем не означает, что пакеты не теряются - в теории не может быть вероятность = 1. Например, если в коммутатор будут поступать пакеты быстрей, чем он их обрабатывает - весь его буфер забьётся и некоторые пакеты придётся выбросить
"Красота - как специи, которые хорошую еду делают ещё вкуснее, а без еды есть невозможно."
 
обовсём и попорядку:
1. насчёт зеркала - если ставишь порт в зеркалирование, он больше не принимает пакеты, а только шлёт копию в то место куда ты указал. Коллизий нет.
2. насчёт "если в коммутатор будут поступать пакеты быстрей, чем он их обрабатывает - весь его буфер забьётся и некоторые пакеты придётся выбросить" - поскольку первым делом когда ты тыкаешь провод в коммутатор, он с твоей сетевой догаваривается в каком режиме будет работать half/full; 10/100/1000, всё это говорит о том по скольки парам он будет передавать и на кокой частоте.
3. "Но это совсем не означает, что пакеты не теряются - в теории не может быть вероятность = 1" вот тут ты обсалютно прав, существует несколько причин почему при передачи идёт не 100%
а) 2 человека шлют в один порт, порту требуется скорость не 100 а 200мбит/с, нету , но тут это дело решают в TCP/IP, тем что на пакеты требуется подтверждение, дождался подтверждения - шли ещё :)
б) пришёл пакет с помехами  и тут коммутатор не может распознать что есть сигнал а что шум (хочешь шкаф на провод поставь, хочешь 10 узлов сделай, а хочешь просто 200метровым круском соедини)
в) гдет не хватает питания - а вот тут стоит что-ть отнести на свалку, смотреть по ситуации
 
Цитата
Shanker пишет:
Но это совсем не означает, что пакеты не теряются - в теории не может быть вероятность = 1.
ну, например, вероятность 1^-56 - это тоже вероятность, про при стандартном кадре в 1536 байт - это очень много данных.

Цитата
Shanker пишет:
Например, если в коммутатор будут поступать пакеты быстрей, чем он их обрабатывает - весь его буфер забьётся и некоторые пакеты придётся выбросить
здравая мысль. но для того чтобы такое случилось, это должен быть коммутатор с плохим внутренним дизайном.
получить на тупом форвардинге десятки mfps могут даже реалтековские чипы. почти всегда коммутаторы спроектированы так, что суммарная пропускная способность портов не превышает возможности чипа.
 
хотя, да, есть 1 вариант: гигабитный коммутатор, 48 портов. и все ломятся на 1 конкретный порт. но тут ещё зависит от 802.1p ;)
и да, дропы будут.
 
Цитата
[mad]Mega пишет:
а) 2 человека шлют в один порт, порту требуется скорость не 100 а 200мбит/с, нету , но тут это дело решают в TCP/IP, тем что на пакеты требуется подтверждение, дождался подтверждения - шли ещё smile:)
Про уровни выше физического мы не говорим - задача несколько иная: только Ethernet и только физический (ну может ещё канальный)

Цитата
^rage^ пишет:
ну, например, вероятность 1^-56 - это тоже вероятность, про при стандартном кадре в 1536 байт - это очень много данных.
Вы имели ввиду 10^(-56) и 1526, наверное? :)
Да нет, не много данных потеряется. А если сравнить с вероятностью оборудования на отказ?
"Красота - как специи, которые хорошую еду делают ещё вкуснее, а без еды есть невозможно."
 
Провёл небольшой эксперимент и получил интересный результат...

к коммутатору подключены 2 компа. Один посылает пакеты другому в цикле, без пауз. Другой только принимает, но не обрабатывает. Если Payload < 65 байт - наблюдаем потери пакетов. Судя по всему, коммутатор не успевает их обрабатывать. В случае когда Payload > 65 байт - потерь не возникает. Во всяком случае, такой результат достигнут при генерации от 1 000 000 до 10 000 000 пакетов
"Красота - как специи, которые хорошую еду делают ещё вкуснее, а без еды есть невозможно."
 
Цитата
Shanker пишет:
Если Payload < 65 байт - наблюдаем потери пакетов.
Накладные расходы.
 
Судя по всему - да. Но, как выяснилось, потеря пакетов идёт не в коммутаторе, а в принимающем компьютере: в ifconfig параметр overruns: становится больше 0
"Красота - как специи, которые хорошую еду делают ещё вкуснее, а без еды есть невозможно."
 
Цитата
Shanker пишет:
Во всяком случае, такой результат достигнут при генерации от 1 000 000 до 10 000 000 пакетов
вы 1mpps на 100мбитах? =))))) а 10mpps - на 1Гигабите?
 
Я был не прав? оказывается, это не коммутатор не справляется, а компьютер-получатель. Это хорошо заметно по возрастающему значению overruns в ifconfig получателя
"Красота - как специи, которые хорошую еду делают ещё вкуснее, а без еды есть невозможно."
 
пара слов: "неблокируемый коммутатор" )
Страницы: Пред. 1 2
Читают тему