Поиск  Пользователи  Правила 
Закрыть
Логин:
Пароль:
Забыли свой пароль?
Войти
 
Страницы: 1 2 След.
RSS
Количество коллизий в сегменте сети, Как определить средствами ОС?
 
Сеть Ethernet. Требуется определить количество произошедших коллизий. Как это сделать в ОС семейства Linux и Windows?
"Красота - как специи, которые хорошую еду делают ещё вкуснее, а без еды есть невозможно."
 
Вот на сервере под управлением Linux.
Первый вариант.
Код
 ifconfig eth0
eth0      Link encap:Ethernet  HWaddr 00:1e:8c:02:1b:20
          inet addr:83.179.207.242  Bcast:83.179.207.243  Mask:255.255.255.252
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:107669652301 errors:0 dropped:24503 overruns:0 frame:0
          TX packets:94840894111 errors:0 dropped:0 overruns:0 carrier:0
          [B]collisions:0[/B] txqueuelen:5000
          RX bytes:83804145483609 (76.2 TiB)  TX bytes:38979166689471 (35.4 TiB)
          Memory:d4200000-d4220000


Второй вариант
Код
 ethtool -S eth0
NIC statistics:
     rx_packets: 107670358735
     tx_packets: 94841663260
     rx_bytes: 84235252728280
     tx_bytes: 39522496423347
     rx_broadcast: 44
     tx_broadcast: 61
     rx_multicast: 3758
     tx_multicast: 0
     rx_errors: 0
     tx_errors: 0
     tx_dropped: 0
     multicast: 3758
     [B]collisions: 0[/B]
     rx_length_errors: 0
     rx_over_errors: 0
     rx_crc_errors: 0
     rx_frame_errors: 0
     rx_no_buffer_count: 253148
     rx_missed_errors: 24503
     tx_aborted_errors: 0
     tx_carrier_errors: 0
     tx_fifo_errors: 0
     tx_heartbeat_errors: 0
     tx_window_errors: 0
     tx_abort_late_coll: 0
     tx_deferred_ok: 0
     tx_single_coll_ok: 0
     tx_multi_coll_ok: 0
     tx_timeout_count: 0
     tx_restart_queue: 0
     rx_long_length_errors: 0
     rx_short_length_errors: 0
     rx_align_errors: 0
     tx_tcp_seg_good: 153455
     tx_tcp_seg_failed: 0
     rx_flow_control_xon: 0
     rx_flow_control_xoff: 0
     tx_flow_control_xon: 0
     tx_flow_control_xoff: 0
     rx_long_byte_count: 84235252728280
     rx_csum_offload_good: 105285698392
     rx_csum_offload_errors: 40019257
     rx_header_split: 0
     alloc_rx_buff_failed: 0
     tx_smbus: 0
     rx_smbus: 0
     dropped_smbus: 0
     rx_dma_failed: 0
     tx_dma_failed: 0
Изменено: SOLDIER - 16.03.2010 23:21:32
 
С тэгом "Код" не выделилось, к сожалению. См. слово - collisions
 
Спасибо это я тоже у себя наблюдаю, но как-то не поверил и поэтому спросил... Уверен, что этому можно доверять?

Вот смотри: общее количество пакетов в твоём примере около 200 миллиардов!!! А коллизии - ни одной. Исходя из теории (если она, конечно, верна) в сети Ethernet 100 Мбит/с из 1 коммутатора и 5 компов вероятность коллизии 0,006. Т.е. несколько сотен тысяч должно быть. Но никак не 0
"Красота - как специи, которые хорошую еду делают ещё вкуснее, а без еды есть невозможно."
 
Черт его знает. Мне хотелось бы верить, что этому можно доверять. :) Кроме того - информация с интерфейсов циски 3550 и 2800 вроде как тоже подтверждают эти данные. Днем, если не забуду - выложу чего там показывает.
 
фулдуплекс? длинна провода минимум метров? - я думаю все эти параметры должны влиять на количество коллизий...
 
Коллизии были раньше, когда использовался коаксиал или пассивные хабы.
Естественно при этом был falf-duplex, тоесть в одном сегменте сети мог передавать данные только один "сетевой интерфейс".

Сейчас же, и уже наверное лет 10,  используются свичи с буфером, которого хватает, на несколько десятков пакетов. При этом мы всегда получаем full-duplex.
Коллизий в современных ethernet сетях построенных на свичах, пусть даже на самых простых, быть не может по определению. Но при большой загруженности канала и плохих проводах/помехах могут быть потери пакетов.

Хотите получить коллизии сделайте пассивный хаб на резисторах, или просто запаралельте все пары, на расстоянии до 5 метров мощности сигнала вроде должно хватить. Создайте нагрузку на сеть, хотя бы, в виде копирования файлов с одного на два компьютера. И вы увидите свои коллизии даже в сети из 3-х компьютеров.
Изменено: Mity Hiden - 17.03.2010 14:13:35
 
Да, оказывается, та теория, которая у меня есть, ориентирована на топологию общей шины.

А коллизий не будет даже в том случае, если через коммутатор 2 компьютера непрерывно друг другу передают пакеты? Т.е. не запрос-ответ, например, а  оба в одни и те же промежутки времени работают на передачу и приём
"Красота - как специи, которые хорошую еду делают ещё вкуснее, а без еды есть невозможно."
 
Коллизии будут появлятся только на falf duplex, когда мы имеем одну линию передачи для входящих и исходящих данных.

Если выставит falf duplex принудительно, в свойствах сетевой карты, то коллизий также не будет, так как физически линий передачи всё равно две. Этим мы только сообщим сетевой карте, чтобы она не начинала передавать данные когда идёт их приём.
 
half duplex все-таки.  ;)
 
А если у меня коммутатор управляемый настроен в режим работы как повторитель (зеркалирует со всех портов на все) - тогда у меня должны появиться коллизии несмотря на полный дуплекс, верно?
"Красота - как специи, которые хорошую еду делают ещё вкуснее, а без еды есть невозможно."
 
Shanker, железо есть? Включи и доложи - верно или нет. ИМХО, неверно. Суть коллизий тебе выше изложили.
 
И что ты, собственно, понимаешь под "зеркалированием"? Искуственную ситуацию превращения свича в хаб? То, что в циске назвается CPAN (чи как там? В общем суть, что на ещё один порт идет именно зеркалирование - дублирование трафика, поступающего на другой порт).
 
Цитата
SOLDIER пишет:
И что ты, собственно, понимаешь под "зеркалированием"? Искуственную ситуацию превращения свича в хаб? То, что в циске назвается CPAN (чи как там? В общем суть, что на ещё один порт идет именно зеркалирование - дублирование трафика, поступающего на другой порт).
Ну да

Цитата
SOLDIER пишет:
Shanker, железо есть? Включи и доложи - верно или нет. ИМХО, неверно. Суть коллизий тебе выше изложили.
Да, надобно проверить... но если буфера не будет - значит, коллизии появятся. В железе-то и вопрос... Для тестов нужен нормальный хаб. А его на сегодняшний день днём с огнём не найти. С управляемым придётся промучиться и неизвестно чем всё это кончится... Собсно, поэтому заранее и спросил...
"Красота - как специи, которые хорошую еду делают ещё вкуснее, а без еды есть невозможно."
 
Управляемых хабов не бывает.  ;) Наверное?
 
Я имел ввиду, что управляемый коммутатор можно перевести в режим хаба. НО. скорее всего, это будет только некое приближение...
"Красота - как специи, которые хорошую еду делают ещё вкуснее, а без еды есть невозможно."
 
Переведение управляемого коммутатора в состояние хаба = его взлому. :) Ценлая статья была в свое время на наге про это. ссылку дать или сам найдешь? :) Суть в том, что это НЕШТАТНЫЙ режим свича.
 
Ты имеешь ввиду затопить порт коммутатора пакетами с разными МАС-ами чтоб он перешёл в режим коммутатора?
"Красота - как специи, которые хорошую еду делают ещё вкуснее, а без еды есть невозможно."
 
Именно так.
 
Цитата
Shanker пишет:
Вот смотри: общее количество пакетов в твоём примере около 200 миллиардов!!! А коллизии - ни одной. Исходя из теории (если она, конечно, верна) в сети Ethernet 100 Мбит/с из 1 коммутатора и 5 компов вероятность коллизии 0,006.

вот начитаются всяких древних книжек... ну откуда коллизии, если есть коммутируемая сеть и flow control?
и как тут число коммутаторов влияет? большинство из них сейчас - store and forward. ну занят порт для посылки фрейма, пошлем чуть позже.
Страницы: 1 2 След.
Читают тему