Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: Linux, сетевая производительность
Форум на CrossPlatform.RU > Библиотеки > Другие библиотеки
ViGOur
C сетевых интерфейсов снимается статистика таким образом:
cat /proc/net/dev | grep : | grep -v lo | sed -e 's/:/ /'| awk '{print $1,$2,$10}'

потом через заданный интервал времени снимаю снова тут же статистику...

После чего происходят нехитрые математические расчеты с вычитанием, делением на интервал и переводом из байтов в биты.

Проблема заключается в том, что если та же операция будет происходить на железке (как я понимаю оптимизированной для работы с сетью), то показатели идут с небольшой погрешностью от тех, что генерирует iperf или ixia (железка такая для прогонки трафика).
Если же это делается на той же убунту сервер или другой ОС без иксов с минимальным набором сервисов, то погрешность в рамках 0.5-3 %, что очень много по моему (например из 30Mbit/s погрешность в ~1 Mbit/s).

Как мне добиться минимальной погрешности? Пните в нужном направлении... :)
Iron Bug
а как ты считаешь интервалы и как получаешь разницу, в процентах?
в системные файлы попадает статистика из драйвера сетевого девайса. так что она там довольно точная. насчёт iperf не уверена. пишут, что он иногда даёт неточные данные и есть более точные утилиты для измерения трафика.
ViGOur
Извини, что не сразу ответил, в отпуске был. :)

Интервал измеряется обычным sleep линуксовым. Разница в процентах считается можно сказать на калькуляторе, имея несколько срезов трафика.
Я понимаю, что статистика попадает из сетевого драйвера попадает и она должна быть точной, и как я уже показал, выше замер происходит на сетевых интерфейсах.
НО!
Если поставить железку оптимизированную для работы с сетью и измерения трафика в разрыв между двумя моими железками, которые делают примерно то же самое, то на них отличаются данные от реального трафика, который генерирует IXIA (дорогая железка для генерации трафика) и она точно генерирует именно тот трафик, что ей скажут...
Нажмите для просмотра прикрепленного файла
На картинке
1. IXIA
2. Моя железка
3. Железка для замера трафика
4. Моя железка

Трафик идет так, как указал стрелками. Железки работают как CISCO подобные маршрутизаторы... Сеть построили правильно.
1. IXIA генерирует трафик 94000 Кbit/s
2. Моя железка показывает 91 623 Кbit/s
3. Железка для замера трафика показывает 92 397 Кbit/s
4. Моя железка показывает 91670 Кbit/s

Так как не может быть, чтобы железка приняла меньше чем отправила дальше, то я сделал вывод, что сетевой драйвер при интенсивном трафике не успевает инкрементировать счетчики, в заданное время, как я понимаю он через какое-то время покажет правильный результат, но мне нужно почти реалтайм!
Отсюда и вопрос, как и что подкрутить, чтобы сетевой драйвер все успевал?
Iron Bug
почему железка не может принять больше, чем отправить дальше? взять хотя бы ошибки в пакетах, дуплицирование или пакеты, у которых истек таймаут. в сети всегда много мусора и далеко не весь он обязательно пересылается.
драйвер считает всё. он не может "забыть" что-то посчитать. система его дёргает примерно раз в секунду, чтобы запросить статистику.
ViGOur
Другими словами, ты предполагаешь, что в данном случае между 2 -> 3 может гулять мусор, а между 1 -> 2 и 3 -> 4 нет?
Iron Bug
"мусор", т.е. помехи и перепосылки пакетов, может быть везде. кроме того, сами линюксовые машины часто тоже генерят свой трафик для рассылки всяких сетевых сообщений.
если хочешь детализацию - снимай логи всех пакетов и смотри, что там у тебя ходит внутри сетки. но это очень геморно.
ViGOur
Проблема оказалась проще чем я мог подумать, так как в основном погрешность составляла ~2,4% я решил проверить, как сервер (который писал не я и который рисует графики) переводит биты в кило биты...

Догадаетесь как или сразу сказать? Конечно же там было деление на 1024!!! :D
Что-то вроде:
int nBit = 99555;
int nKbit = nBit / 1024;
Я тоже хорош, мог бы и сравнить результат выдаваемый моим приложением с результатом отображаемым на сервере... Короче будем писать горе писателям писавшим сервер, чтобы исправляли ошибку. :)
JohnZ
Цитата(ViGOur @ 16.9.2015, 17:58) *
Проблема оказалась проще чем я мог подумать, так как в основном погрешность составляла ~2,4% я решил проверить, как сервер (который писал не я и который рисует графики) переводит биты в кило биты...

Догадаетесь как или сразу сказать? Конечно же там было деление на 1024!!! :D
Что-то вроде:
int nBit = 99555;
int nKbit = nBit / 1024;
Я тоже хорош, мог бы и сравнить результат выдаваемый моим приложением с результатом отображаемым на сервере... Короче будем писать горе писателям писавшим сервер, чтобы исправляли ошибку. :)

Прошу прощения что влажу в тесную компанию, и за "глупый" вопрос :)
Почему ошибку ? А как по-другому перевести биты в кило-биты ?
К стати, где-то в и-нете читал, по-моему на скифе, почти все производители сетевого оборудования,
скорость указывают в кило-битах поделив не на 1024, а на 1000 ! Так у них принято. Почему ?
Да потому-что "в попугаях значительно длиннее чем в мартышках или слонёнках" :D
ViGOur
Да нет, все на много проще, начальный курс информатики:
1 Kbyte = 1024 byte (тоесть 2 в 10 степени)
1 Kbit = 1000 bit (тоесть 10 в 3 степени)
;)

JohnZ
Цитата(ViGOur @ 12.10.2015, 9:24) *
Да нет, все на много проще, начальный курс информатики:
1 Kbyte = 1024 byte (тоесть 2 в 10 степени)
1 Kbit = 1000 bit (тоесть 10 в 3 степени);)

Дык счёт по степеням 2 или 10-ки ? Или уже изобрели процессор на степенях 10-ки ? ;)
Процессор-же работает по степеням 2-ки ! По нему и счёт должОн быть.
Для получения степени 10-ки, он должен излишне напрячься :)
1 Kbit = 1024 bit == 1024/8 = 128 byte (imho)
В физическом канале, на самом деле этот 1 Kbit выглядит ведь совсем иначе,
т.е. + старт-стоп, +чётность, + ... поэтому заранее сложно сказать, какой
объём полезной инф-ции содержится в принятых/переданных 1024 битах.
Цитата
1 Kbit = 1000 bit (тоесть 10 в 3 степени) ;)

Вот я ж и говорю, счёт в попугаях :) (imho)
К стати, и производители флэш-памяти тоже считают в попугаях.
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Форум IP.Board © 2001-2024 IPS, Inc.