Про уровни выше физического мы не говорим - задача несколько иная: только Ethernet и только физический (ну может ещё канальный)

Вы имели ввиду 10^(-56) и 1526, наверное?
Да нет, не много данных потеряется. А если сравнить с вероятностью оборудования на отказ?

Их, вроде, и так днём с огнём не сыскать

А чем не нравится соединение патч-кордом через 100 Мбит/с коммутатор? Это, вроде, пока не история..

Trinity,
Вот ещё ссылочка по теме, недавно наткнулся:
http://www.jurnal.org/articles/2009/inf15.html

Насчё1т коллизий - вы немножко опоздали, это я уже понял Я имел ввиду потерю пакетов

Но это совсем не означает, что пакеты не теряются - в теории не может быть вероятность = 1. Например, если в коммутатор будут поступать пакеты быстрей, чем он их обрабатывает - весь его буфер забьётся и некоторые пакеты придётся выбросить

Думал об этом... но надеялся обойтись без этого
Для грубой оценки можно попытаться кучу пакетов в цикле отправлять... Хотя не знаю покатит ли...

Предположим, что да.

К словам ^rage^ добавлю: там ещё и помехи другого качества, которые приходится учитывать (в проводных этого можно не делать). Да и вообще нюансов куча. По беспроводным могу посоветовать "Широкополосные беспроводные сети передачи информации".[Вишневский В.М., Ляхов А.И., Портной С.Л., Шахнович И.В.] Там куча теории по wi-fi и куча формул. Только вот, на мой взгляд, применять их довольно затруднительно... Если что получится - дай знать

Ну и по Теории массового обслуживания почитать стоит - на основе этого большинство моделей реализуют

Нужно для диплома. Есть формула, которая рассчитывает скорость доставки пакета от одного узла к другому. Это теоритическая оценка. Необходимо проверить на практике её достоверность. Понятно, что будут некоторые отхождения теории от практики, потому как на практике сложно реализовать условия теории и наоборот. К примеру, в формуле не учитывается обработка данных коммутатором. И уж тем более - конечным компьютером. Чтоб свести это всё к минимуму - необходимо замерить скорость передачи пакета только в одну сторону. А т.к. длина кадра (с учётом всех полей) для Ethernet 1526 байт - время будет очень маленьким. Ну или можно в цикле такие пакеты отправлять. Но всё равно вопрос остаётся - в довольно точном замере скорости передачи в одну сторону

ifconfig, на сколько я вижу, не выводит времени передачи... К тому же мне нужна по идее довольно высокая точность - до 10^(-6) сек

А, я не сразу догнал что ИОС - IOS ))

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

Это что такое?

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

Спасибо за ссылки. Посмотрел описание. Они работают на верхних уровнях сетевого взаимодействия. А статистику по Ethernet кадрам покажут?

Ну да

Да, надобно проверить... но если буфера не будет - значит, коллизии появятся. В железе-то и вопрос... Для тестов нужен нормальный хаб. А его на сегодняшний день днём с огнём не найти. С управляемым придётся промучиться и неизвестно чем всё это кончится... Собсно, поэтому заранее и спросил...

Ситуация следующая: имеем коммутатор, к которому подключены компьютеры. Необходимо замерить скорость доставки кадра от одного компьютера к другому. Как это сделать?

Сначала была идея тупо взять пинг и поделить время пинга на 2. Но это не самый лучший вариант: время доставки в одну сторону может отличаться от времени обратного прохождения. В том случае, если в процессе обратного прохождения возникнет коллизия. Или  уйдёт время на обработку пакета принимающей станцией перед ответом.

Пока что склоняюсь к тому чтобы сделать множество пингов и потом вывести среднее значение, поделённое на 2

А если у меня коммутатор управляемый настроен в режим работы как повторитель (зеркалирует со всех портов на все) - тогда у меня должны появиться коллизии несмотря на полный дуплекс, верно?

Да, оказывается, та теория, которая у меня есть, ориентирована на топологию общей шины.

А коллизий не будет даже в том случае, если через коммутатор 2 компьютера непрерывно друг другу передают пакеты? Т.е. не запрос-ответ, например, а  оба в одни и те же промежутки времени работают на передачу и приём

Необходимо послать в локальную сеть (Ethernet) произвольные биты. Сначала думал в сторону libcap/winpcap но, как я понимаю, они не походят: они позволяют сделать наполнитель, а контрольную сумму и преамбулу сами создают. А я хочу более низкого доступа к сети. Чем сотворить?

Спасибо это я тоже у себя наблюдаю, но как-то не поверил и поэтому спросил... Уверен, что этому можно доверять?

Вот смотри: общее количество пакетов в твоём примере около 200 миллиардов!!! А коллизии - ни одной. Исходя из теории (если она, конечно, верна) в сети Ethernet 100 Мбит/с из 1 коммутатора и 5 компов вероятность коллизии 0,006. Т.е. несколько сотен тысяч должно быть. Но никак не 0

Сеть Ethernet. Требуется определить количество произошедших коллизий. Как это сделать в ОС семейства Linux и Windows?

У меня что-то был тупняк - никак не мог определить как у гугла спросить
Спасибо всем отозвавшимся