У нас есть пара новых разветвленных каналов Ethernet 1 Гбит / с между точками на расстоянии около 200 миль. «Клиент» - это новый достаточно мощный компьютер (HP DL380 G6, двойные E56xx Xeons, 48 ГБ DDR3, пара R1 300 ГБ дисков SAS 10krpm в минуту, W2K8R2-x64), а «сервер» тоже достаточно приличный компьютер (HP BL460c G6 два E55xx Xeons, 72 ГБ, пара R1 из 146 ГБ дисков SAS 10 кбит / с, двухпортовый HBA-адаптер Emulex 4 Гбит / с, подключенный к двум Cisco MDS9509, затем к выделенному HP EVA 8400 с 128 x 450 ГБ 15 кбит / с FC-дисками, RHEL 5.3-x64).
Используя SFTP от клиента, мы видим пропускную способность около 40 Кбит / с при использовании больших (> 2 ГБ) файлов. Мы выполнили тесты с сервера на «другой локальный сервер» и увидели около 500 Мбит / с через локальные коммутаторы (Cat 6509), мы собираемся сделать то же самое на стороне клиента, но это через день или около того.
Какие еще методы тестирования вы бы использовали, чтобы доказать провайдерам ссылок, что проблема в их?
источник
Ответы:
Настройка слона:
это может потребовать настройки, вероятно, здесь не проблема, как говорит pQd. Этот вид связи известен как «Длинная, толстая труба» или слон (см. RFC 1072 ). Поскольку это толстый гигабитный канал, проходящий через расстояние (в данном случае это действительно время / задержка), окно приема tcp должно быть большим (см. Иллюстрации в TCP / IP, том 1, раздел «Расширения TCP»).
Чтобы выяснить, каким должно быть окно приема, вы вычисляете произведение задержки полосы пропускания:
Если задержка составляет 10 мс, этот калькулятор оценивает, что вы хотите получить окно приема размером около 1,2 мегабайта. Мы можем сделать расчет самостоятельно по приведенной выше формуле:
Таким образом, вы можете запустить дамп пакета, чтобы увидеть, если масштабирование окна tcp (расширение TCP, которое позволяет использовать большие окна), чтобы точно настроить это, как только вы выясните, в чем заключается большая проблема.
Граница окна:
Если это проблема, то размер окна ограничен без масштабирования, я ожидаю следующих результатов, если нет масштабирования окна и имеется задержка около 200 мс независимо от размера канала:
Так:
Для того, чтобы получить результаты, которые вы видите, вам просто нужно решить для задержки, которая будет:
Итак (для 40 кБайт / с):
(Пожалуйста, проверьте мою математику, и они, конечно, не включают все издержки протокола / заголовка)
источник
40 кбит / с - это очень мало [до такой степени, что я бы заподозрил неисправные медиаконвертеры / несоответствие дуплекса [но у вас гигабит, поэтому нет места для полудуплекса!] И т. Д.]. должны быть потери пакетов или очень высокий джиттер.
iperf - это первый инструмент, который мне приходит в голову, чтобы измерить доступную пропускную способность. бежать с одной стороны
а с другой:
затем вы можете поменяться ролями клиент / сервер, использовать -d для дуплекса и т. д. запустить mtr между двумя компьютерами до начала теста и посмотреть, какие задержки / потери пакетов у вас возникают на неиспользуемой ссылке, и как они изменяются во время передачи данных.
Вы хотели бы видеть: очень маленький джиттер и отсутствие потерь пакетов, пока канал не будет заполнен до 90 с чем-то процентов своей емкости.
iperf для * nix и win , читайте здесь и здесь об этом.
mtr для * nix и победа .
источник
tracepath может показать вам проблемы маршрутизации между двумя сайтами.
iperf, ttcp и bwping могут дать вам полезную информацию.
Знаете ли вы, как эта ссылка 1GB предоставляется? Вы соединяете или маршрутизируете по этой ссылке? Какой у вас SLA по ссылке? Вы могли бы быть сформированы вашим поставщиком ссылок?
если вы получаете только 40 КБ, то есть серьезная проблема, вы уверены, что это не ссылка 1 МБ, а не ссылка 1 ГБ / с. Вы, вероятно, обнаружите, что скорость ссылки не такая, как вы думаете :-)
источник
RFC 2544 или Y.156sam
Это сетевые тесты, которые выполняются для подтверждения SLA оператором. IPERF и т.п. не являются проверяемыми методами тестирования сети.
источник