[haverlinkfor]

Покупаем гарантированные 100 мегабит канала у РОСТЕЛЕКОМ за большие деньги. Очень низкая скорость интернета через TCP соединения, максимум выживаем 25 мегабит, UDp в порядке - выживаем 90. С настройками маршрутизации все ОК, резерва очень много, проблема скорее всего либо с коммутатором, или же с патч кордами от кросса к коммутатору. Звоним в тех поддержку - говорят у вас сыпется куча ошибок и потерь пакетов. Посоветуйте хорошие патч корды и чем их обрабатывать. Так же хороший коммутатор( у нас стоит хуавей 2300s) Спасибо.

[passer]

Протереть патчкорды, проверить sfp модуля. Патчкорды протирать спиртом (и дать просохнуть обязательно !!!) или специальными чистящими приспособлениями.

 

Проверить наличие ошибок у вас на интерфейсах свитча .

 

 

Edited September 8, 2012 by passer

[haverlinkfor]

SFP модуля проверить на наличие повреждений? Ошибки на свитче никак не посмотрю, он не управляемый

[passer]

Huawei S2300 ? Если он - то таки управляемый. Фото можно?

SFP модуля проверить на наличие повреждений?

Заменить попробовать. Уровень сигнала замерить.

Edited September 8, 2012 by passer

[haverlinkfor]

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

Edited September 8, 2012 by haverlinkfor

[passer]

Тогда вызывайте их спецов и пусть проверяют. Это не дело, если состояние линка по индикации определять приходится. До их прихода проверьте/замените патчкорды и, возможно, sfp.

 

Я бы все таки подключился консолькой к свитчу и посмотрел, можно ли на него зайти. Если нельзя - тогда точно вызывать спецов.

 

 

Edited September 8, 2012 by passer

[Sonneandsky]

Покупаем гарантированные 100 мегабит канала у РОСТЕЛЕКОМ за большие деньги. Очень низкая скорость интернета через TCP соединения, максимум выживаем 25 мегабит, UDp в порядке - выживаем 90. С настройками маршрутизации все ОК, резерва очень много, проблема скорее всего либо с коммутатором, или же с патч кордами от кросса к коммутатору. Звоним в тех поддержку - говорят у вас сыпется куча ошибок и потерь пакетов

Проблема была один в один, только коммутатор был Зюксель.

У вас Ростелеком или присоединенный типа СибТелекома?

Вообще с у них там полный атас :(

Почти месяц отсылал им замеры оптики до аплинка (у нас только медюки свои в узле РТК)и длинна то смешная 650 м.

То же были предложения смените патчкорды, медюки, волокно и т.д.

Вообщем вышел на тех.директора, совместно с ком.директором за круглым столом высказал свои недовольство (письменно продублировал директору). Только после этого за шевелились все. Поставили новую Циску, пока тфу-тфу.

Сейчас решается вопрос с Мегафон о присоединении, бежать от РТК собрались, чего и вам советую ;)

[Vasmer]

у вас присоединение кольцом?

 

а так да вам бы со специалистами из ЦПД пообщаться напрямую!

[zander]

потери пакетов, вычисляйте, MTR вам в помощь

[dmvy]

если коммутатор их, то наверное и волокно их? если так, то это их зона ответственности.

[st_re]

Покупаем гарантированные 100 мегабит канала у РОСТЕЛЕКОМ за большие деньги. Очень низкая скорость интернета через TCP соединения, максимум выживаем 25 мегабит,

 

 

Я сильно извиняюсь, а как и откуда меряли ? пинг до туда какой ? а то моджет того.. при данном RTT и вашем TCP окне это нормально ? или всетаки потоков было много и РТТ маленький ? А то может и ошибки не ваши или не те :) 64к окно (кажется такое оно в винде) и 25мс РТТ даст как раз 20 мегабить....

[SergeiK]

Согласен с предыдущим оратором.

Базовые знания иногда необходимы, чтоб понимать ограничения технологий.

http://bradhedlund.com/2008/12/19/how-to-calculate-tcp-throughput-for-long-distance-links/

 

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

http://en.wikipedia.org/wiki/TCP_window_scale_option

 

При необходимости, можно посмотреть дамп трафика и посмотреть, какое окно ставиться и почему.

[haverlinkfor]

Обязательно позвоню нашему куратору в понедельник и задам вопросы про то какая должна быть у нас скорость tcp. Меряю на какой нибудь мощный http сервер,один из них altlinux.org. Пинг к нему - 19-20мс. Сразу скажу качество соединения у нас хорошее, пинг без потерь, минимальный и круглосуточно. На вопрос: при данном RTT и вашем TCP окне это нормально - не понял, расскажите пожалуйста как узнать нормально это или нет

[Saab95]

Согласен с предыдущим оратором.

Базовые знания иногда необходимы, чтоб понимать ограничения технологий.

http://bradhedlund.c...distance-links/

 

Там предлагается какая-то поделка от циски.

 

Насколько я понял, если сделать канал точка-точка с большим TCP окном на каких-то маршрутизаторах, а к нему уже подключить оконечное оборудование, то передача данных станет возможна на больших скоростях не трогая параметры TCP окна на них?

[SergeiK]

Согласен с предыдущим оратором.

Базовые знания иногда необходимы, чтоб понимать ограничения технологий.

http://bradhedlund.c...distance-links/

 

Там предлагается какая-то поделка от циски.

 

Насколько я понял, если сделать канал точка-точка с большим TCP окном на каких-то маршрутизаторах, а к нему уже подключить оконечное оборудование, то передача данных станет возможна на больших скоростях не трогая параметры TCP окна на них?

Ну это да, в конце есть такое. Не обязательно Cisco, но есть технологии оптимизации трафика, которые помогают решить и эту проблему.

 

Но я это не заметил :), я имел в виду саму начальную матиматику.

Стандартное максимальное окно TCP - 65К. После этого надо получить подтверждение, что все пакеты хорошо дошли.

Если RTD 30ms, то получается, что скорость не более чем 65Кбайт / 0,03ms = 2,17Мбайт или 17Мбит для одной TCP сессии.

 

Есть довольно давно RFC 1323, которые решает эту проблему TCP, но не факт, что всегда используется.

[agr]

Обязательно позвоню нашему куратору в понедельник и задам вопросы про то какая должна быть у нас скорость tcp. Меряю на какой нибудь мощный http сервер,один из них altlinux.org. Пинг к нему - 19-20мс. Сразу скажу качество соединения у нас хорошее, пинг без потерь, минимальный и круглосуточно. На вопрос: при данном RTT и вашем TCP окне это нормально - не понял, расскажите пожалуйста как узнать нормально это или нет

 

Мерять скорость загрузкой файлов по http не самый хороший метод. Померьте утилитой iperf с разным количеством потоков. Возможно проблемы в настройках burst'ов на полисере у РТК. Во время замера скорости снимите дамп трафика tcpdump'ом и посмотрите есть ли retransmit'ы,если есть, то дело однозначно в настройках полисера.

[st_re]

На вопрос: при данном RTT и вашем TCP окне это нормально - не понял, расскажите пожалуйста как узнать нормально это или нет

 

http://www.ozon.ru/context/detail/id/1354276/

 

 

еще раз, на Ваших 20+ ms и таком параметре TCP как размер окна равном 64 килобайта (а если Вы не знаете что это такое, то оно такое и есть) Вы не получите на 1 потоке скорости больше 20 мегабит.

64*8/(20/1000)=25600 килобит/с (20 тут - это Ваши 20 мс) + надо не забывать, что это включая все заголовки, т.е. в браузере вы увидите как раз чуть выше 20. И куратор Вам не поможет. игра с настройками этим параметром на Вашей стороне может не дать эффекта, есть еще та сторона, которая Вам не подконтрольна, и что там стоит Вы не знаете.

 

http://forum.nag.ru/forum/index.php?showtopic=68349&view=findpost&p=631534

[ichthyandr]

потери пакетов, вычисляйте, MTR вам в помощь

MTR может не дать реальной картины, так как на магистралях бывает настраивают ограничение на ICMP трафик.

 

Покупаем гарантированные 100 мегабит канала у РОСТЕЛЕКОМ ...

iperf -ом желательно проверить

[haverlinkfor]

iperf я так понимаю умеет только отправлять? У меня получилось только проверить исходящую скорость, вписывал разные http сервера,к примеру к ya.ru отправил одним потоком 80 мегабит, несколько потоков - результат в сумме тот же самый.

[agr]

Что вы отсылали на http сервера?? iperf надо тестировать с iperf серверами, с http он не работает. Если нет возможности установить свой iperf сервера со стороны РТК, то воспользуйте публичным iperf сервером, например iperf.eltel.net. Команда

iperf -c iperf.eltel.net -P <кол-во потоков> -t 100 -i 10

[haverlinkfor]

Пример 4 (загрузка канала пустым трафиком, с обратной стороны сервера iperf может и не быть):

>iperf -c 192.168.3.125 -u -b 100m -t 60

Здесь в качестве IP адреса (192.168.3.125) может быть даже отсутствующий (невидимый) в сети host, протокол указан UDP (-u), указана полоса загрузки 100 мегабит (-b 100m), время посылки пакетов 60 секунд (-t 60). Этот вариант не подходит?

[agr]

у вас же вроде с TCP проблемы? Замерьте TCP с вышеуказанным публичным сервером

[st_re]

2 haverlinkfor Эта команда покажет гигабит в модем 19к200.

[haverlinkfor]

Созвонился с куратором, сказал запустит iperf у себя в течение 2 дней и свяжется.

[namake]

На вопрос: при данном RTT и вашем TCP окне это нормально - не понял, расскажите пожалуйста как узнать нормально это или нет

 

http://www.ozon.ru/context/detail/id/1354276/

 

 

еще раз, на Ваших 20+ ms и таком параметре TCP как размер окна равном 64 килобайта (а если Вы не знаете что это такое, то оно такое и есть) Вы не получите на 1 потоке скорости больше 20 мегабит.

64*8/(20/1000)=25600 килобит/с (20 тут - это Ваши 20 мс) + надо не забывать, что это включая все заголовки, т.е. в браузере вы увидите как раз чуть выше 20. И куратор Вам не поможет. игра с настройками этим параметром на Вашей стороне может не дать эффекта, есть еще та сторона, которая Вам не подконтрольна, и что там стоит Вы не знаете.

 

http://forum.nag.ru/forum/index.php?showtopic=68349&view=findpost&p=631534

 

В TCP уже давно реализован SACK (RFC 2018) и Delayed Acknowledgement (RFC 1122). Смотрю FullHD с ютуба в Хабаровске, поток 15-18 Мбит/с, 130 мс.

Edited September 15, 2012 by namake