Pull to refresh
Comments 11
Круто, восполнил некоторое количество пробелов в своем образовании. Интересно сколько же реально времени занимает прохождение RFC2544. Понятно что там есть вариативность, но можт есть какие-нибудь типовые/грубые примеры
Можно сказать так, что самый влиятельный параметр — это время теста, задаваемое пользователем, что очевидно. Если вы задаете какое-то время, то для каждого выбранного размера фрейма будет выполнятся сове тестирование, что увеличивает общее время тестирования пропорционально количеству фреймов.
Полагаю, что вопрос не ограничивается желанием пользователя установить время тестирования, так что можно рассмотреть зависимость от других параметров.
Возьмем для примера, пропускную способность. Поскольку она измеряется так
  1. изначально проверяется заданная скорость
  2. если есть потери, то скорость тестового потока уменьшается в половину
  3. если потерь нет, то увеличивается на половину текущей
  4. если снова потери, то снова уменьшается и так далее

то задача нахождения «обеспеченной» скорости фактически решается численным методом за полиномиальное время, т.е. временные затраты на ее решение определяются достаточной для нас точностью этого измерения.
Для тестов задержки и back-to-back фактором времени будет необходимая повторяемость (для задержки 1 тест в 60 сек, а для back-to-back требуется не менее 50 измерений)

Если интересна реальная цифра — могу без проблем запустить настоящий тест и приложить скриншоты с параметрами теста и результатами.
Главный недостаток — мало пользы при тестировании беспроводных соединений.
Что вы имеете ввиду? Ведь если рассматривать беспроводные мосты, радиодоступ и даже wifi всего лишь как транспортную среду, то тестирование канала ничем не отличается. Я имею ввиду, что если вы покупаете канал с определенными параметрами и для вас это «черный» ящик, то тестируя его на соответствие параметрам, для вас как наблюдателя нет никакой разницы «а что в черном ящике?». Если же имеется ввиду wifi сети и тестирование с уклоном на их топологию, например эмуляции 20..200..2000 клиентов, то конечно же этот тест не показателен.
Да, зачем эмуляция. Просто если это беспроводной канал точка-точка, то еще возможно как-то измерять.
А если это базовая станция с 20 клиентами, настроенными приоритетами и адаптивным маркерным доступом, тестирование теряет всяческий смысл. Это будет гадание на кофейной гуще. Либо нужно будет тестировать раз 10 с разными параметрами на разных клиентах и бегать от точки к точке. Собственно, я так и делал.
Совершенно верно. Методология предполагает тестирование каналов, а не базовой станции все таки, для этого существуют другие системы, в том числе распределенные. Например, когда в нужных точках устанавливаются сенсоры, а управляются они из центра. Из самого простого что приходит в голову — TWAMP во всех его проявлениях.
Было бы здорово, если бы заинтересованные хабражители написали бы сюда, в личку или на почту (для тех кто не зарегистрирован) какие практические аспекты хотели бы видеть. Т.е. я могу конечно сделать «ванильный» тест и приложить сриншоты, но это будет не многим лучше чем текущий формат. Хотелось бы несколько оживить материал, придать ему динамики.
> “описывает и определяет набор тестов для определения характеристик устройств межсетевых соединений”,
не согласен, в оригинале «Network Interconnection Devices», т.е. что-то вроде «связующих сетевых устройств».
межсетевые, это традиционно — «internetworking» — шлюзы/маршрутизаторы, а тут речь везде про кадры, т.е. явный Л2.
Only those users with full accounts are able to leave comments. Log in, please.