Jump to content
Калькуляторы

Клиент жалуется на upload

Проблема. Буду рад советам по ее решению. Мы провайдеры. Есть клиент с игровым сервером в интернете (wow если важно) гигабитным линком подключенный в ядро. Тариф 70мбит. Цепочка подключения выглядит как клиентский сервер-агрегатор-шейпер (SCE)- софтовый NAT. Начал жаловаться, что игроки стали жаловаться на лаги в игре, что раньше на канале было 40-50мегабит исходящего и 4-5 входящего, а сейчас выше 25-30 мбит исходящий не поднимается, примите меры где моя скорость.

начинаю тестировать канал.

 

по локалке с его сервера до себя:

 

iperf -c 192.168.100.1

------------------------------------------------------------

Client connecting to 192.168.100.1, TCP port 5001

TCP window size: 16.0 KByte (default)

------------------------------------------------------------

[ 3] local 10.0.10.97 port 51992 connected with 192.168.100.1 port 5001

[ ID] Interval Transfer Bandwidth

[ 3] 0.0-10.0 sec 562 MBytes 471 Mbits/sec

 

 

т.е проблем вроде не наблюдаем.

 

 

тест скорости до ната (через шейпер)

 

iperf -c nat0

------------------------------------------------------------

Client connecting to nat0, TCP port 5001

TCP window size: 16.0 KByte (default)

------------------------------------------------------------

[ 3] local 10.0.10.97 port 51504 connected with 10.10.0.25 port 5001

[ ID] Interval Transfer Bandwidth

[ 3] 0.0-10.0 sec 85.3 MBytes 71.3 Mbits/sec

 

 

т.е проблем тоже вроде нет

 

дальше тестим канал магистралов (ВСД Курск)

 

Чтобы было понятно по айпишникам расклад такой:

сервер1 77.247.1.1 - это сервер в Орле, до него от нас маршрут через Москву через центральный роутер - т.е. по сети vsd до Москвы и обратно в Орел

сервер2 77.247.2.2 - это сервер в сети vsd в Москве

сервер3 84.17.1.1 - это сервер в сети МТС в Орле, до него маршрут соответственно через Москву и далее по Интернет (думаю что в пределах М9) до МТС в Москве и назад в Орел по каналам МТС.

 

сервер1 26.9 Mbits/sec

 

iperf -c 77.247.1.1

------------------------------------------------------------

Client connecting to 77.247.1.1, TCP port 5001

TCP window size: 16.0 KByte (default)

------------------------------------------------------------

[ 3] local 10.0.10.97 port 36445 connected with 77.247.1.1 port 5001

[ ID] Interval Transfer Bandwidth

[ 3] 0.0-10.0 sec 32.1 MBytes 26.9 Mbits/sec

 

 

сервер2 26.0 Mbits/sec

 

iperf -c 77.247.2.2

------------------------------------------------------------

Client connecting to 77.247.2.2, TCP port 5001

TCP window size: 16.0 KByte (default)

------------------------------------------------------------

[ 3] local 10.0.10.97 port 59380 connected with 77.247.2.2 port 5001

[ ID] Interval Transfer Bandwidth

[ 3] 0.0-10.0 sec 31.1 MBytes 26.0 Mbits/sec

 

 

сервер3 18.0 Mbits/sec

 

iperf -c 84.17.224.13

------------------------------------------------------------

Client connecting to 84.17.224.13, TCP port 5001

TCP window size: 16.0 KByte (default)

------------------------------------------------------------

[ 3] local 10.0.10.97 port 53114 connected with 84.17.224.13 port 5001

[ ID] Interval Transfer Bandwidth

[ 3] 0.0-10.2 sec 21.9 MBytes 18.0 Mbits/sec

 

 

в один поток тарифная скорость не развивается. но в 5 ситуация меняется - до всех серверов скорость тарифная 70 мбит.

 

 

iperf -c 77.247.2.2 -P 5

------------------------------------------------------------

Client connecting to 77.247.232.27, TCP port 5001

TCP window size: 16.0 KByte (default)

------------------------------------------------------------

[ 7] local 10.0.10.97 port 37432 connected with 77.247.232.27 port 5001

[ 3] local 10.0.10.97 port 37429 connected with 77.247.232.27 port 5001

[ 5] local 10.0.10.97 port 37430 connected with 77.247.232.27 port 5001

[ 4] local 10.0.10.97 port 37428 connected with 77.247.232.27 port 5001

[ 6] local 10.0.10.97 port 37431 connected with 77.247.232.27 port 5001

[ ID] Interval Transfer Bandwidth

[ 3] 0.0-10.0 sec 14.8 MBytes 12.4 Mbits/sec

[ 5] 0.0-10.0 sec 21.2 MBytes 17.7 Mbits/sec

[ 4] 0.0-10.0 sec 16.3 MBytes 13.6 Mbits/sec

[ 7] 0.0-10.0 sec 20.3 MBytes 17.0 Mbits/sec

[ 6] 0.0-10.1 sec 16.6 MBytes 13.8 Mbits/sec

[sUM] 0.0-10.1 sec 89.2 MBytes 74.2 Mbits/sec

 

 

 

теперь тестим по UDP (на серверах iperf запущен с нужными ключами)

 

сервер1 99 мбит

сервер2 и сервер3 аналогично

 

 

iperf -c 77.247.1.1 -u -b 100m

------------------------------------------------------------

Client connecting to 77.247.232.27, UDP port 5001

Sending 1470 byte datagrams

UDP buffer size: 122 KByte (default)

------------------------------------------------------------

[ 3] local 10.0.10.97 port 40550 connected with 77.247.1.1 port 5001

[ ID] Interval Transfer Bandwidth

[ 3] 0.0-10.0 sec 119 MBytes 99.8 Mbits/sec

[ 3] Sent 85471 datagrams

read failed: Connection refused

[ 3] WARNING: did not receive ack of last datagram after 1 tries.

 

 

т.е. по TCP одна сессия не поднимается выше 30мбит, хотя по UDP поднимается.

тех. поддержка разводит руками на эти цифры и говорит "а может так и должно быть - в несколько потоков скорость достаточная, а почему в одну нет - а может это нормально".

Вот и я уже начинаю думать - может я тестирую не так? а как еще? должно быть в один поток 70 мбит или есть какие-то ограничения? лаги продолжаются...

 

Edited by nickyat

Share this post


Link to post
Share on other sites

Я у себя тоже стал последнее время замечать, что интернет работает как-то не так. Сайты открываются медленно, а вот скачки в несколько потоков просто летают. Возможно кто-то где-то=) ждем информации, все всегда переваливают ответственность на вышестоящих.

Share this post


Link to post
Share on other sites

Интернет интернетом, а эффект у топикстартера вполне возможен из за какой-то кривой реализации port-channel-а где-то. Но может быть все что угодно по пути.

Вспоминаю случай у себя, на одном из арендованных каналов был косяк с TCP. UDP бегал нормально, в соответствии с шириной трубы, а TCP не поднималось больше 7-ми мбит. Голова ломалась долго, но виновного нашли, им оказался один из транзитных свичей. Вылечилось сменой ПО на нем.

Share this post


Link to post
Share on other sites
Интернет интернетом, а эффект у топикстартера вполне возможен из за какой-то кривой реализации port-channel-а где-то. Но может быть все что угодно по пути.

можно с этого места по подробнее? чем port-channel-ы провинились? их к слову сказать аж 3 на пути трафика этого сервера в мир и до прошлой недели все прекрасно работало.

Share this post


Link to post
Share on other sites

Про port-channel-ы напросилось логически, в один поток плохо, в четыре хорошо, может кто-то балансит криво.

А вообще вам надо вспоминать, что делалось на прошлой неделе, и пытать всех тех, кто мог что-то сделать. Может софт где меняли, алгоритм балансировки порт-канала, и т.п., и вот оно вылезло. Может проблема в вашем ВСД, если он из порт-канала состоит - попробуйте разобрать его, или сменить алгоритм балансировки. А может просто полка в каком-то порт-канале.

В общем это все гадание, тут надо тестить каждое транзитное устройство, и не важно, будь оно l3 или l2.

Можете сюда также выложить топологию, где у вас там серверы, откуда эти три порт-канала, свичи и т.д., может народных идей возникнет больше.

Share this post


Link to post
Share on other sites

1. TCP не будет разгоняться при больших задержках и/или больших потерях на канале. Что рисует длинный не менее 1000 пакетов пинг с размером пакета в 1400 байт?

 

2. На каком размере пакета вы меряете полосу пропускания на каналах?

 

3. По какому протоколу (TCP/UDP) работает игровой сервер?

Share this post


Link to post
Share on other sites
Про port-channel-ы напросилось логически, в один поток плохо, в четыре хорошо, может кто-то балансит криво.

А вообще вам надо вспоминать, что делалось на прошлой неделе, и пытать всех тех, кто мог что-то сделать. Может софт где меняли, алгоритм балансировки порт-канала, и т.п., и вот оно вылезло. Может проблема в вашем ВСД, если он из порт-канала состоит - попробуйте разобрать его, или сменить алгоритм балансировки. А может просто полка в каком-то порт-канале.

В общем это все гадание, тут надо тестить каждое транзитное устройство, и не важно, будь оно l3 или l2.

Можете сюда также выложить топологию, где у вас там серверы, откуда эти три порт-канала, свичи и т.д., может народных идей возникнет больше.

в том-то и дело ничего не трогали.

1-й sup2(1) - hp 6200(1) состоит из 4-х линков работает давно, ничего не меняли, нагрузка на линки разспределяется ровно

2-й hp6200(2) - sup2(2) состоит из 8-х линков работает давно, ничего не меняли, нагрузка на линки разспределяется ровно

3-й bigiron - h3c(оборудование ВСД) состоит из 4-х линков работает относительно давно, со своей стороны мы ничего не меняли, нагрузка на линки разспределяется ровно.

 

сменить алгоритм балансировки на bigiron можно на switch или server =) сейчас switch. и что-то мне подсказывает, что на server менять не стоит.

Share this post


Link to post
Share on other sites

ВСД попинайте, может они что делали. В локалке вашей, порт-каналы можно не смотреть, там по вашим же результатам все нормально.

Share this post


Link to post
Share on other sites

сервер работает по протоколу TCP

размер пакета каким измеряет иперф - это? TCP window size: 16.0 KByte (default)

 

ping -c 1000 -s 1400 77.247.1.1

 

--- 77.247.1.1 ping statistics ---

1000 packets transmitted, 1000 received, 0% packet loss, time 1000540ms

rtt min/avg/max/mdev = 14.257/14.796/15.465/0.251 ms

 

 

 

1. TCP не будет разгоняться при больших задержках и/или больших потерях на канале. Что рисует длинный не менее 1000 пакетов пинг с размером пакета в 1400 байт?

 

2. На каком размере пакета вы меряете полосу пропускания на каналах?

 

3. По какому протоколу (TCP/UDP) работает игровой сервер?

Edited by nickyat

Share this post


Link to post
Share on other sites

Проведите тест с вашего "софтового нат", чтоб обойти агрегатор и SCE, также если есть возможность, подключите что-то напрямую в всд и проведите замеры. От этого и пляшите.

Share this post


Link to post
Share on other sites
теперь тестим по UDP (на серверах iperf запущен с нужными ключами)

 

сервер1 99 мбит

сервер2 и сервер3 аналогично

 

 

iperf -c 77.247.1.1 -u -b 100m

------------------------------------------------------------

Client connecting to 77.247.232.27, UDP port 5001

Sending 1470 byte datagrams

UDP buffer size: 122 KByte (default)

------------------------------------------------------------

[ 3] local 10.0.10.97 port 40550 connected with 77.247.1.1 port 5001

[ ID] Interval Transfer Bandwidth

[ 3] 0.0-10.0 sec 119 MBytes 99.8 Mbits/sec

[ 3] Sent 85471 datagrams

read failed: Connection refused

[ 3] WARNING: did not receive ack of last datagram after 1 tries.

 

 

т.е. по TCP одна сессия не поднимается выше 30мбит, хотя по UDP поднимается.

А еще вы читать не умеете. Где вы видите, что по UDP все 99 мбит пришли.

iperf сругался (read failed: Connection refused), что с другой стороны вообще ничего не вернулось.

Просто сервер с опцией -u не запустили.

При пройденном тесте вам скажут процент потерянных пакетов. И он явно будет большим.

Share this post


Link to post
Share on other sites

все стало немного интересней, если запустить iperf c любого другого NATa до 77.247.2.2 скорость нормальная, до 500-700мбит, так же если запустить с NATa на котором первоначально проводились тесты(который выдавал не большую скорость) до любого дургогоа NATa, скорость так же в порядке 500-700мбит. Единственная разница между этим NATом и остальными во внешней адресации(ip из подсети NAT1 - 91.205.x.x, остальные - 109.63x.x.)

Edited by caz

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this