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

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

Пока что склоняюсь к тому чтобы сделать множество пингов и потом вывести среднее значение, поделённое на 2
"Красота - как специи, которые хорошую еду делают ещё вкуснее, а без еды есть невозможно."
 
Блиин. Ты что там творишь?  :) Зачем изобретать велосипед?
Вариант 1
iperf, netperf
Вариант 2
Исходники онs[ - если они оба не устраивает.
 
Цитата
SOLDIER пишет:
Блиин. Ты что там творишь?    Зачем изобретать велосипед?

Вариант 1

iperf, netperf

Вариант 2

Исходники оных - если они оба не устраивает.
 
Эт я так неуклюже поправил.  :oops:
 
Цитата
SOLDIER пишет:
iperf, netperf
Спасибо за ссылки. Посмотрел описание. Они работают на верхних уровнях сетевого взаимодействия. А статистику по Ethernet кадрам покажут?
"Красота - как специи, которые хорошую еду делают ещё вкуснее, а без еды есть невозможно."
 
Мне кажется, что они только 3-й уровень показывают - PPS, и прочую лабуду. Вот честно - сам не запускал/не проверял/не гонял. А второй уровень - это тебе, судя по всему статистику с самих интерфейсов снимать надо. ifconfig и ethtool? Это если в Линухе. В ИОС - sh int название summary? Проверять лень.
 
Цитата
SOLDIER пишет:
В ИОС - sh int название summary?
Это что такое?
"Красота - как специи, которые хорошую еду делают ещё вкуснее, а без еды есть невозможно."
 
Цитата
Shanker пишет:
Это что такое?

Ща покажу. Настойчивый ты наш. :) Это команда в консоли сиськи.
 
Monlink_Core#sh int gi0/2 sum

*: interface is up
IHQ: pkts in input hold queue     IQD: pkts dropped from input queue
OHQ: pkts in output hold queue    OQD: pkts dropped from output queue
RXBS: rx rate (bits/sec)          RXPS: rx rate (pkts/sec)
TXBS: tx rate (bits/sec)          TXPS: tx rate (pkts/sec)
TRTL: throttle count

 Interface           IHQ   IQD  OHQ   OQD  RXBS RXPS  TXBS TXPS TRTL
---------------------------------------------------------------------
* GigabitEthernet0/2    0     0    0     0 37581000  7069 45632000  8817    0
NOTE:No separate counters are maintained for subinterfaces
    Hence Details of subinterface are not shown
 
А вот просто вывод статистики с интерфейса
Цитата

sh int gi0/2
GigabitEthernet0/2 is up, line protocol is up (connected)
 Hardware is Gigabit Ethernet, address is 0013.19fa.8f1a (bia 0013.19fa.8f1a)
 Description: Gig_Link_on_Infolink
 MTU 1500 bytes, BW 1000000 Kbit, DLY 10 usec,
    reliability 255/255, txload 11/255, rxload 9/255
 Encapsulation ARPA, loopback not set
 Keepalive set (10 sec)
 Full-duplex, 1000Mb/s, media type is T
 input flow-control is off, output flow-control is on
 ARP type: ARPA, ARP Timeout 04:00:00
 Last input never, output 00:00:01, output hang never
 Last clearing of "show interface" counters never
 Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
 Queueing strategy: fifo
 Output queue: 0/40 (size/max)
 5 minute input rate 37705000 bits/sec, 7087 packets/sec
 5 minute output rate 45610000 bits/sec, 8825 packets/sec
    1897704028 packets input, 1557533207 bytes, 0 no buffer
    Received 112030640 broadcasts (0 multicast)
    0 runts, 0 giants, 0 throttles
    0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
    0 watchdog, 0 multicast, 1629 pause input
    0 input packets with dribble condition detected
 
Он про сиськи
 
А, я не сразу догнал что ИОС - IOS :)))
"Красота - как специи, которые хорошую еду делают ещё вкуснее, а без еды есть невозможно."
 
ifconfig, на сколько я вижу, не выводит времени передачи... К тому же мне нужна по идее довольно высокая точность - до 10^(-6) сек
Изменено: Shanker - 17.03.2010 23:43:11
"Красота - как специи, которые хорошую еду делают ещё вкуснее, а без еды есть невозможно."
 
Cacti, отец. Как вариант. Тебе попросту надо снимать информацию с интерфейсов. Но все ведь старо, как мир. По тому же по старейшему протоколу SNMP. Повторюсь - не надо изобретать велосипед. "Все украдено до Вас!"  ;)
Изменено: SOLDIER - 18.03.2010 00:01:20
 
Цитата
Shanker пишет:
Необходимо замерить скорость доставки кадра от одного компьютера к другому. Как это сделать?
а вам зачем такая глупость? =) производительность коммутаторов, даже самых дешевых измеряется в mpps'ах.

Цитата
Shanker пишет:
В том случае, если в процессе обратного прохождения возникнет коллизия.
а откуда она вообще возникнет, если by default включен flow control и сеть коммутируемая? =)

Цитата
Shanker пишет:
Или уйдёт время на обработку пакета принимающей станцией перед ответом.

оно всегда уйдет на это. потому что драйвер/чип сетевой карточки должен вытащить payload, надо посчитать crc для ip-пакета и отдать это в юзерспейс. опять же, зависит от загруженности процессор[а/ов] и механизмов обработки трафика(прерывания, опрос, комбинированный вариант).

вам вообще зачем?
 
Нужно для диплома. Есть формула, которая рассчитывает скорость доставки пакета от одного узла к другому. Это теоритическая оценка. Необходимо проверить на практике её достоверность. Понятно, что будут некоторые отхождения теории от практики, потому как на практике сложно реализовать условия теории и наоборот. К примеру, в формуле не учитывается обработка данных коммутатором. И уж тем более - конечным компьютером. Чтоб свести это всё к минимуму - необходимо замерить скорость передачи пакета только в одну сторону. А т.к. длина кадра (с учётом всех полей) для Ethernet 1526 байт - время будет очень маленьким. Ну или можно в цикле такие пакеты отправлять. Но всё равно вопрос остаётся - в довольно точном замере скорости передачи в одну сторону
"Красота - как специи, которые хорошую еду делают ещё вкуснее, а без еды есть невозможно."
 
ужос какой. сферический конь в вакууме. вам нужен скорее осциллограф или какой-то анализатор сигналов. пингами вы ничего не померите. посчитайте относительную погрешность вашего метода и ужаснитесь.
 
Цитата
^rage^ пишет:
вам нужен скорее осциллограф или какой-то анализатор сигналов
Думал об этом... но надеялся обойтись без этого :)
Для грубой оценки можно попытаться кучу пакетов в цикле отправлять... Хотя не знаю покатит ли...
"Красота - как специи, которые хорошую еду делают ещё вкуснее, а без еды есть невозможно."
 
Цитата
Shanker пишет:
Для грубой оценки можно попытаться кучу пакетов в цикле отправлять... Хотя не знаю покатит ли...
нет. объясню даже почему. есть такая штука, как interrupt moderation/mitigation.  т.е. когда прерываний немного, получение каждого фрейма приводит к обработке прерывания, переключения контекста итп.
когда прерываний становится больше - прерывания вызываются каждый 2,3,4...n фрейм. т.е. циферки будут очень красиво плавать.
я уж молчу о режиме с отключенными прерываниями и опросе карточки самой ОС.
(см device polling во freebsd и NAPI в linux. Interrupt moderation/mitigation есть почти у всех более-менее приличных карточек).
Страницы: 1
Читают тему