LINUX.ORG.RU

Потеря скорости соединения


0

1

Добрый день !

Сервер - 192.168.1.1
Клиент - 192.168.1.4
Сервер раздает интернет клиенту, по средством nat

На сервере:
eth0 - смотрит в интернет через pptp
eth1 - представляет собой гигабитную сетевую карту напрямую подключенную к 192.168.1.4
Замеряю от 192.168.1.4 до 192.168.1.1

iperf -c 192.168.1.1
[  4]  0.0-10.0 sec   745 MBytes   625 Mbits/sec
Замеряю от 192.168.1.4 до iperf.eltel.net
iperf -c iperf.eltel.net
[  3]  0.0-10.0 sec  39.9 MBytes  33.3 Mbits/sec
В среднем 36 Mbits/s
Замеряю от Сервера 192.168.1.1 до iperf.eltel.net
iperf -c iperf.eltel.net
[  3]  0.0-10.0 sec  55.4 MBytes  46.3 Mbits/sec
То есть в среднем на 10 Mbit/s больше.

В чем тут дело ? Куда деваются 10mbit/s ?

tc я еще не настраивал:

qdisc pfifo_fast 0: dev eth0 root refcnt 2 bands 3 priomap  1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
qdisc pfifo_fast 0: dev eth1 root refcnt 2 bands 3 priomap  1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
qdisc mq 0: dev wlan0 root 
qdisc mq 0: dev mon.wlan0 root 
qdisc pfifo_fast 0: dev ppp0 root refcnt 2 bands 3 priomap  1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1


А какой при этом размер окна tcp? Попробуйте его увеличить до 256 кбайт (опция -w).

mky ★★★★★ ()
Ответ на: комментарий от mky

Это уже интересно

А какой при этом размер окна tcp? Попробуйте его увеличить до 256 кбайт (опция -w).

Странно, но с окном 256K на сервере пишет:
запуск с 192.168.1.1

[root@SRV:/]# iperf  -w 256K -c iperf.eltel.net
------------------------------------------------------------
Client connecting to iperf.eltel.net, TCP port 5001
TCP window size:  320 KByte (WARNING: requested  256 KByte)
------------------------------------------------------------
[  3] local 94.24.156.80 port 47089 connected with 217.170.67.78 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.1 sec  23.0 MBytes  19.2 Mbits/sec
Я не знаю почему, но на сервере окно 256K не принимает, и устанавливает его в 320K.
запуск с 192.168.1.4
[root@PK-Note:/]# iperf -w 256K -c iperf.eltel.net
------------------------------------------------------------
Client connecting to iperf.eltel.net, TCP port 5001
TCP window size:  256 KByte (WARNING: requested  256 KByte)
------------------------------------------------------------
[  3] local 192.168.1.4 port 53449 connected with 217.170.67.78 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.0 sec  42.5 MBytes  35.6 Mbits/sec
Также как видите скорость на клиенте осталась такой-же , а на сервере наоборот в среднем ниже. Учитывая что сервер раздает интернет, то это взрывает мне мозг.

В общем я все это дело тестил торрентом, там все нормально, видимо iperf что-то не то показывает. Теперь меня интересует вопрос про окно, почему окно в 256K iperf запущенный с сервера не хочет принимать, а на клиенте все нормально ? Связано ли это с MTU ?

demsi ()
Ответ на: Это уже интересно от demsi

Теперь меня интересует вопрос про окно, почему окно в 256K iperf запущенный с сервера не хочет принимать, а на клиенте все нормально ?

Приложение не может чётко «скомандовать» ядру какой размер окна установить, оно лишь может попросить минимальный размер. От чего зависит, какой размер установит ядро я не знаю. Кроме опции -w у iperf ещё есть -l, она тоже может влиять.

видимо iperf что-то не то показывает

Да нет, iperf показывает всё как есть, но правда в том, что у tcp есть разные опции (размер окна, выборочное подтверждение {selective ack}, может что-то ещё) и не всегда опции tcp оказываются оптимальными для данного канала с определённой задержкой передачи пакета и процентом потерь. iperf не занимается изменением этих параметов с целью выжать из соединения максимум. Какое соедиение согласовалось, по тому и работает.

Чтобы понять что именно происходит, вам нужно детально изучить несколько rfc, описывающих tcp и его расширения, получить tcpdump'ом пакеты от iperf и долго их анализировать. Не думаю, что у вас есть желание этим заниматься. Может быть много чего, может оказаться, что 192.168.1.4 по факту работает с недостаточно большим размером окна и теряет время на ожидании подтверждения от iperf.eltel.net, а может быть, что 192.168.1.4 в начале передачи разом отправляет по гигабиту слишком много пакетов и 192.168.1.1 не может засунуть их всех в 100 Мбит интерфейс, пакеты теряются, Congestion Control...

mky ★★★★★ ()
Ответ на: комментарий от mky

Очень интересно. С удовольствием почитаю сети. Какую литературу посоветуете кроме: Таненбаума, Стивенса и RFC ? Или этого будет достаточно дабы разобраться со всем ?

demsi ()
Ответ на: комментарий от demsi

Таненбаум, про компьютерные сети, да, возможно даже одновременно с первыми RFC на tcp, где ещё не было всяких наворотов типа window scaling.

Стивенс, если я правильно помню, рассматривает программирование, а не сам tcp. У вас при одинаковой работе с сокетом (подключились, пишем данные) получаются разные скорости, вам важнее пакеты. ИМХО, здесь Стивенс не нужен.

Можете для получения дампов тестового траффика качать короткие http-странички wget'ом. И на время этих закачек для начала отключить все расширения (sack, timestamps, window scaling) через /proc, http://www.opennet.ru/tips/info/273.shtml , чтобы получать дамп попроще.

Не знаю, насколько хорошо описаны в rfc различные алгоритмы Congestion Control (в которые обычно всё и упирается). Под «хорошестью» я подразумевал не только описание алгоритма, но и его сравнение с другими и объяснение какие недостатки других алгоритмов он пытается исправить. Возможно, тут нужно будет поискать в инете научные статьи. Удачи.

mky ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.