nickyat Опубликовано 25 ноября, 2010 (изменено) · Жалоба Проблема. Буду рад советам по ее решению. Мы провайдеры. Есть клиент с игровым сервером в интернете (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 мбит или есть какие-то ограничения? лаги продолжаются... Изменено 25 ноября, 2010 пользователем nickyat Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Saab95 Опубликовано 25 ноября, 2010 · Жалоба Я у себя тоже стал последнее время замечать, что интернет работает как-то не так. Сайты открываются медленно, а вот скачки в несколько потоков просто летают. Возможно кто-то где-то=) ждем информации, все всегда переваливают ответственность на вышестоящих. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
dsk Опубликовано 25 ноября, 2010 · Жалоба Интернет интернетом, а эффект у топикстартера вполне возможен из за какой-то кривой реализации port-channel-а где-то. Но может быть все что угодно по пути. Вспоминаю случай у себя, на одном из арендованных каналов был косяк с TCP. UDP бегал нормально, в соответствии с шириной трубы, а TCP не поднималось больше 7-ми мбит. Голова ломалась долго, но виновного нашли, им оказался один из транзитных свичей. Вылечилось сменой ПО на нем. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
caz Опубликовано 26 ноября, 2010 · Жалоба Интернет интернетом, а эффект у топикстартера вполне возможен из за какой-то кривой реализации port-channel-а где-то. Но может быть все что угодно по пути. можно с этого места по подробнее? чем port-channel-ы провинились? их к слову сказать аж 3 на пути трафика этого сервера в мир и до прошлой недели все прекрасно работало. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
dsk Опубликовано 26 ноября, 2010 · Жалоба Про port-channel-ы напросилось логически, в один поток плохо, в четыре хорошо, может кто-то балансит криво. А вообще вам надо вспоминать, что делалось на прошлой неделе, и пытать всех тех, кто мог что-то сделать. Может софт где меняли, алгоритм балансировки порт-канала, и т.п., и вот оно вылезло. Может проблема в вашем ВСД, если он из порт-канала состоит - попробуйте разобрать его, или сменить алгоритм балансировки. А может просто полка в каком-то порт-канале. В общем это все гадание, тут надо тестить каждое транзитное устройство, и не важно, будь оно l3 или l2. Можете сюда также выложить топологию, где у вас там серверы, откуда эти три порт-канала, свичи и т.д., может народных идей возникнет больше. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Nailer Опубликовано 26 ноября, 2010 · Жалоба 1. TCP не будет разгоняться при больших задержках и/или больших потерях на канале. Что рисует длинный не менее 1000 пакетов пинг с размером пакета в 1400 байт? 2. На каком размере пакета вы меряете полосу пропускания на каналах? 3. По какому протоколу (TCP/UDP) работает игровой сервер? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
caz Опубликовано 26 ноября, 2010 · Жалоба Про 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 менять не стоит. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
dsk Опубликовано 26 ноября, 2010 · Жалоба ВСД попинайте, может они что делали. В локалке вашей, порт-каналы можно не смотреть, там по вашим же результатам все нормально. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
nickyat Опубликовано 26 ноября, 2010 (изменено) · Жалоба сервер работает по протоколу 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) работает игровой сервер? Изменено 26 ноября, 2010 пользователем nickyat Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
dsk Опубликовано 26 ноября, 2010 · Жалоба Проведите тест с вашего "софтового нат", чтоб обойти агрегатор и SCE, также если есть возможность, подключите что-то напрямую в всд и проведите замеры. От этого и пляшите. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Дегтярев Илья Опубликовано 26 ноября, 2010 · Жалоба теперь тестим по 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 не запустили. При пройденном тесте вам скажут процент потерянных пакетов. И он явно будет большим. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
caz Опубликовано 26 ноября, 2010 (изменено) · Жалоба все стало немного интересней, если запустить iperf c любого другого NATa до 77.247.2.2 скорость нормальная, до 500-700мбит, так же если запустить с NATa на котором первоначально проводились тесты(который выдавал не большую скорость) до любого дургогоа NATa, скорость так же в порядке 500-700мбит. Единственная разница между этим NATом и остальными во внешней адресации(ip из подсети NAT1 - 91.205.x.x, остальные - 109.63x.x.) Изменено 26 ноября, 2010 пользователем caz Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
