nickyat Опубликовано 17 марта, 2011 · Жалоба Помогите разобраться! мы городской интернет провайдер. в одном районе недавно (третий день бъемся) появилась проблема - деградация качества интернета, особенно заметная на скоростных (>50мбит) тарифах. тесты до проблем - скриншотов не привожу, мерил через teamviewer абоненты (все под windows): speedtest Химки 90-95 мбит speedtest локальный 97мбит iperf до сервера на порте коммутатор ядра 97 мбит те все замечательно, упираемся только в физический предел интерфейсов. цепочка абоненты-коммутатор доступа - агрегатор - коммутатор ядра-шейпер-бордер Теперь проблема: speedtest химки видно как после 2-3 сек резко скорость падает с 70-80 мбит до 12-14 и в итоге 12мбит download причем тотже torent разгоняется до 10 мегабайт/c (без локальных пиров) картина повторяется у нескольких абонентов iperf до ядра D:\>iperf -c 192.168.200.187 ------------------------------------------------------------ Client connecting to 192.168.200.187, TCP port 5001 TCP window size: 16.00 KByte (default) ------------------------------------------------------------ [1912] local 192.168.1.2 port 1322 connected with 192.168.200.187 port 5001 [ ID] Interval Transfer Bandwidth [1912] 0.0-130.0 sec 84.6 MBytes 5.46 Mbits/sec похожие результаты на трех абонентских компьютерах где еще 3 дня назад все было ок теперь то что собственно взрывает мозг. грузимся на этих же компах с linux livecd: спидтест химки график: iperf [sluser@livecd ~]$ iperf -c 192.168.200.187 ------------------------------------------------------------ Client connecting to 192.168.200.187, TCP port 5001 TCP window size: 16.0 KByte (default) ------------------------------------------------------------ [ 3] local 192.168.1.103 port 51552 connected with 192.168.200.187 port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0-10.0 sec 113 MBytes 94.4 Mbits/sec результаты сходны +-5% на разных компьютерах после нескольких повторов. Чем же объяснить такую разницу? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
mschedrin Опубликовано 17 марта, 2011 · Жалоба Самое время запустить wireshark и смотреть там что происходит. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
sdy_moscow Опубликовано 17 марта, 2011 · Жалоба посмотрите как ходят большие пакеты и не фрагментированные ping -l ping -f -l Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
zep Опубликовано 17 марта, 2011 · Жалоба Инет через PPP ? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Abram Опубликовано 17 марта, 2011 (изменено) · Жалоба Вариант: обновились все и словили какую-то регрессию. Если клиенты между собой знакомы, тогда искать общий софт (как правило, среди знакомых его очень много, и у всех потом вылазит одна и та же проблема). Изменено 17 марта, 2011 пользователем Abram Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ilya Evseev Опубликовано 18 марта, 2011 · Жалоба Я бы попробовал повторить тест с Windows LiveCD. Если скорость окажется нормальной, можно смело советовать пользователям переустановку. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Mikhalich Опубликовано 18 марта, 2011 (изменено) · Жалоба Может поможет: у нас частенько свичи блочат клиентов по броадкаст шторму из-за нового Мэйл.РУ агента. А так да: как уже посоветовали, нужно запускать акулу и смотреть. Изменено 18 марта, 2011 пользователем Mikhalich Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
caz Опубликовано 18 марта, 2011 (изменено) · Жалоба Все как-то немного печальней. 1. мерию скорость iperf c любой виндовой машины, до сервера freebsd, где весит iperf: tcpdump на стороне сервера 10:17:21.078413 IP (tos 0x0, ttl 125, id 61450, offset 0, flags [DF], proto TCP (6), length 932) 192.168.100.13.37024 > 192.168.200.187.5001: P, cksum 0x4b70 (correct), 79002781:79003673(892) ack 1 win 65535 10:17:21.078422 IP (tos 0x0, ttl 125, id 61452, offset 0, flags [DF], proto TCP (6), length 40) 192.168.100.13.37024 > 192.168.200.187.5001: F, cksum 0x3c24 (correct), 79003673:79003673(0) ack 1 win 65535 10:17:21.078439 IP (tos 0x0, ttl 64, id 65026, offset 0, flags [DF], proto TCP (6), length 40) 192.168.200.187.5001 > 192.168.100.13.37024: ., cksum 0xae34 (incorrect (-> 0x3c24), 1:1(0) ack 79003674 win 65535 каждый 3 с некорректной чексуммой, нагуглил что ifconfig em0 -txcsum должно спасти, но что-то мне подсказывает, что это не совсем правильно, в итоге 09:52.122373 IP (tos 0x0, ttl 125, id 60684, offset 0, flags [DF], proto TCP (6), length 40) 192.168.100.13.36820 > 192.168.200.187.5001: F, cksum 0x6839 (correct), 30916608:30916608(0) ack 1 win 65535 10:09:52.122388 IP (tos 0x0, ttl 64, id 3151, offset 0, flags [DF], proto TCP (6), length 40) 192.168.200.187.5001 > 192.168.100.13.36820: ., cksum 0x6839 (correct), 1:1(0) ack 30916609 win 65535 соедиенени все равно весит еще 50 секунд. т.е. в сумме 1 минуту, потом автоматически закрывается и соответственно выдается результат с низкой скоростью. Если выставить iperf -i10, то промежуточное значение будет 94мбит, т.е. в норме. а на серваке тем временем: tcp4 0 0 192.168.200.187.5001 192.168.100.13.38205 CLOSE_WAIT tcp4 0 0 192.168.200.187.5001 192.168.100.11.44210 CLOSE_WAIT tcp4 0 0 192.168.200.187.5001 192.168.100.11.44209 CLOSE_WAIT tcp4 0 0 192.168.200.187.5001 192.168.100.11.44208 CLOSE_WAIT tcp4 0 0 192.168.200.187.5001 192.168.100.11.44207 CLOSE_WAIT tcp4 0 0 192.168.200.187.5001 192.168.100.13.37101 CLOSE_WAIT tcp4 0 0 192.168.200.187.5001 192.168.100.13.37024 CLOSE_WAIT tcp4 0 0 192.168.200.187.5001 192.168.100.13.36820 CLOSE_WAIT tcp4 0 0 192.168.200.187.5001 192.168.100.11.45928 CLOSE_WAIT tcp4 0 0 192.168.200.187.5001 192.168.100.13.36680 CLOSE_WAIT tcp4 0 0 192.168.200.187.5001 192.168.100.13.36673 CLOSE_WAIT Если мерить с компа на линуксе, то: tcpdump на стороне сервера 10:27:09.782443 IP (tos 0x0, ttl 61, id 27414, offset 0, flags [DF], proto TCP (6), length 1068) 192.168.100.11.44210 > 192.168.200.187.5001: FP, cksum 0xcd0c (correct), 91601953:91602969(1016) ack 1 win 92 <nop,nop,timestamp 1176410 3467353417> 10:27:09.782451 IP (tos 0x0, ttl 64, id 64433, offset 0, flags [DF], proto TCP (6), length 52) 192.168.200.187.5001 > 192.168.100.11.44210: ., cksum 0xfc63 (correct), 1:1(0) ack 91601953 win 28806 <nop,nop,timestamp 3467353438 1176410> 10:27:09.782464 IP (tos 0x0, ttl 64, id 64434, offset 0, flags [DF], proto TCP (6), length 52) 192.168.200.187.5001 > 192.168.100.11.44210: ., cksum 0xf8e9 (correct), 1:1(0) ack 91602970 win 28679 <nop,nop,timestamp 3467353438 1176410> p.s. ping -f -l3 192.168.200.187 PING 192.168.200.187 (192.168.200.187) 56(84) bytes of data. .... --- 192.168.200.187 ping statistics --- 105423 packets transmitted, 105421 received, 0% packet loss, time 16317ms rtt min/avg/max/mdev = 0.237/0.426/5.442/0.183 ms, pipe 3, ipg/ewma 0.154/0.402 ms p.s.s. мерию скорость iperf c любой виндовой машины, до сервера с gentoo, все отлично Изменено 18 марта, 2011 пользователем caz Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
andriko Опубликовано 18 марта, 2011 · Жалоба sysctl net.inet.tcp.delayed_ack=0 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...