Скорость канала ≠ скорость TCP потока

[sind]

Доброго времени суток, коллеги.

 

Предоставляем клиентам услуги Интернета по выделенной линии на разных скоростях, от 1 мбит/сек - 1 гбит/сек.

Сеть довольно большая, клиенты бывают довольно удаленные.

 

Иногда, бывают случаи, когда клиент покупает канал в 100+ мбит/сек и подразумевает получения этого 100+ в 1 TCP поток. Т.е. хочет видит такую скорость через speedtest.net, 2ip.ru и прочее подобные ресурсы. Но, увы, при выходе из нашей AS клиент получает 10-15 мс задержки, соответственно, дальше по пути задержка только прибавляется. Как известно, чем больше задержка, тем меньше скорость по 1-й TCP сессии (даже описано http://habrahabr.ru/post/115527/). В итоге, уже при выходе из нашей сети, скорость не будет больше 10-20 мбит/сек по 1-й TCP сессии.

 

Собственно вопрос: Как бороться с такими клиентами объяснить такому клиенту, что скорость больше не будет? Ну можно конечно поиграться с TCP Window Size, но на сколько это эффективно?

[Ivan_83]

Использование cc=htcp на стороне сервера очень помогает. Есть ещё куча всяких тюнингов, но в целом 100 мегабит в одном тцп скорее экзотика.

Скорость с тестилки (нод спидтеста и тп) очень сильно зависит от настроек самого сервера, опять же htcp, буфера сокетов и некоторые параметры тцп.

[legioner0]

предложите клиенту погонять тесты httperf

[sind]

Использование cc=htcp на стороне сервера очень помогает. Есть ещё куча всяких тюнингов, но в целом 100 мегабит в одном тцп скорее экзотика.

Скорость с тестилки (нод спидтеста и тп) очень сильно зависит от настроек самого сервера, опять же htcp, буфера сокетов и некоторые параметры тцп.

 

А каким наглядным способом можно продемонстрировать, что канал функционирует нормально? Сейчас делаем тест между точкой клиента и своей тестовой точкой IPErf-ом или JPErf-ом. Получить желаемые 100 мбит/сек получается в 3 потока.

 

предложите клиенту погонять тесты httperf

 

Нашел ее только под линуксы.

 

Может быть, что взаимосвязь между задержкой и скоростью описана где то в RFC? Может быть есть документы на которые можно официально сослаться?

Edited December 20, 2013 by sind

[Ivan_83]

А каким наглядным способом можно продемонстрировать, что канал функционирует нормально? Сейчас делаем тест между точкой клиента и своей тестовой точкой IPErf-ом или JPErf-ом.

Есть приборы для замера пропускной способности. Дешёвый вариант с иперфом.

[sind]

Тут вопрос более стоит так, как обьяснить клиенту, что по-другому просто быть не может? В договоре про количество потоков не указано, и абонент хочет видеть все в 1 поток. В RFC не нашел такого, что скорость зависит от задержки/потери и тп.

Edited December 19, 2013 by sind

[Ivan_83]

Так скорость одного тцп зависит от кучи разных факторов, не только от задержки.

Есть всякие расширения в тцп для ускорений, размер окна, ну и сам алгоритм контроля перегрузки (cc) на стороне сервера, размера буферов сокета с обоих сторон и тп.

[kosmich7]

Тут вопрос более стоит так, как обьяснить клиенту, что по-другому просто быть не может? В договоре про количество потоков не указано, и абонент хочет видеть все в 1 поток. В RFC не нашел такого, что скорость зависит от задержки/потери и тп.

Ну так покажите ему 100Мбит в пределах вашей сети :)

Абонент минет завтра захочет - будете обьяснять ? или красиво пошлете...

Абонент настолько серьЁзно башляет ?

Обьяснить простым нет ТВ 100Мбит в один поток - иначе пусть хоть застрелится :-)

Подозреваю в договоре и про 100Мбит в один поток тоже ничего не написано)

[vladd]

У нас при задержках 40-50 мс спидтесты показывают 70-90 мбит на московских серверах.

 

Боритесь с потерями. Нещадно. Даже 0.5% потерь при таких задержках снижают скорость до 1-5 мбит/c в один поток. Вылизывайте сеть. Трясите магистралов, если проблема у них.

 

Edited December 19, 2013 by vladd

[Дятел]

А каким наглядным способом можно продемонстрировать, что канал функционирует нормально?

 

Торрентом на популярной раздаче )

[sind]

Ну так покажите ему 100Мбит в пределах вашей сети :)

Абонент минет завтра захочет - будете обьяснять ? или красиво пошлете...

Абонент настолько серьЁзно башляет ?

Обьяснить простым нет ТВ 100Мбит в один поток - иначе пусть хоть застрелится :-)

Подозреваю в договоре и про 100Мбит в один поток тоже ничего не написано)

 

Какая разница сколько он "башляет". Что плохого в том, чтоб корректно объяснить и обосновать клиенту, что он не прав. А еще лучше - на что то сослаться.

 

У нас при задержках 40-50 мс спидтесты показывают 70-90 мбит на московских серверах.

 

Боритесь с потерями. Нещадно. Даже 0.5% потерь при таких задержках снижают скорость до 1-5 мбит/c в один поток. Вылизывайте сеть. Трясите магистралов, если проблема у них.

 

 

Выше писали, что со спидтестами не все так просто. Потерь нет.

 

Торрентом на популярной раздаче )

 

Ну это да. Только, акт о тестировании с такими данными не подпишешь.

[dmvy]

Объясните, что вы продукте ip связность, а протоколы L4 уровня реализует ПО абонента или сервера где-то в интернете. Можно налить на них флуд 100мбит и в диспетчера задач на вкладке сеть увидят, что интерфейс утилизированы на 100%

[Дятел]

 

Торрентом на популярной раздаче )

 

Ну это да. Только, акт о тестировании с такими данными не подпишешь.

почему?

[mystic]

Напишите свой спидтест, который и будет всегда показывать 100ку. :)

[EShirokiy]

mystic, днс подкрутить у себя и кидать абонента на свой "спидтест", где скорость будет всегда соотвествовать тарифу)

[pawel40]

mystic, днс подкрутить у себя и кидать абонента на свой "спидтест", где скорость будет всегда соотвествовать тарифу)

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

[Ivan_83]

"Свой" спид тест не освобождает от необходимости очень вдумчиво его настроить, дабы он отдавал на максимуме.

[Alex/AT]

Самый дешевый вариант показать абоненту 100 Мбит/с (и выше) - торрент. Если вы его не режете, конечно :)

[BiWiS]

Я тут пытался торрентом померить скорость больше 200мбит (utorrent 3.3.1) на ~210 мбит клиент под виндой падал, больше 10 попыток и все завершались падением на одной и той же примерно скорости :) При этом процессор был не загружен и памяти свободной была еще куча. Может с другим клиентом такого не случится, но вот с этим, на мой взгляд самым популярным, такие пироги.

 

Так что и у торрента будет предел замера скоростей :)

[Дятел]

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

[Yarlan Zey]

по торренту... поиграйтесь с кешем в его настройках... ибо на больших скоростях стабильно - жесткий диск перегружен.

[Ivan_83]

Хз какие у вас диски, но 200 мегабит мои диски пишут и отдают легко, правда в один поток :)

[wtyd]

Доброго времени суток, коллеги.

 

Предоставляем клиентам услуги Интернета по выделенной линии на разных скоростях, от 1 мбит/сек - 1 гбит/сек.

Сеть довольно большая, клиенты бывают довольно удаленные.

 

Иногда, бывают случаи, когда клиент покупает канал в 100+ мбит/сек и подразумевает получения этого 100+ в 1 TCP поток. Т.е. хочет видит такую скорость через speedtest.net, 2ip.ru и прочее подобные ресурсы. Но, увы, при выходе из нашей AS клиент получает 10-15 мс задержки, соответственно, дальше по пути задержка только прибавляется. Как известно, чем больше задержка, тем меньше скорость по 1-й TCP сессии (даже описано http://habrahabr.ru/post/115527/). В итоге, уже при выходе из нашей сети, скорость не будет больше 10-20 мбит/сек по 1-й TCP сессии.

 

Собственно вопрос: Как бороться с такими клиентами объяснить такому клиенту, что скорость больше не будет? Ну можно конечно поиграться с TCP Window Size, но на сколько это эффективно?

 

Вы абонентам что продаёте ? TCP или IP ? Думаю, что второе. Значит надо скорость на ip и мерить. Попробуйте так: запустите долгоиграющую закачку. Когда скорость устаканится, то ip -s li sh dev eth0 ; sleep 60 ; ip -s li sh dev eth0. Дальше смотрим соответствующие каунтеры, вычитаем из большего меньшее и делим на 60 -- получаем скорость на IP, т.е. скорость ip-пакетов, ключая их заголовки.

 

Сперва конечно сами проверьте, может это тоже клиента не устроит. Это для придирчивых, которые акты не хотят подписывать. Для массового применения не подходит. Обычно те абоненты, что требуют акты, платят значительно больше остальных, остальным ваще пофик уже обычно. Ещё можно добавить такому абоненту +7% :). Надо считать экономику такого решения.

[dignity]

Вы абонентам что продаёте ? TCP или IP ? Думаю, что второе. Значит надо скорость на ip и мерить. Попробуйте так: запустите долгоиграющую закачку. Когда скорость устаканится, то ip -s li sh dev eth0 ; sleep 60 ; ip -s li sh dev eth0. Дальше смотрим соответствующие каунтеры, вычитаем из большего меньшее и делим на 60 -- получаем скорость на IP, т.е. скорость ip-пакетов, ключая их заголовки.

Бредово. Так только торрент оттестить можно, но на tcp в один поток будет печаль.

[Saab95]

Я тут пытался торрентом померить скорость больше 200мбит (utorrent 3.3.1) на ~210 мбит клиент под виндой падал, больше 10 попыток и все завершались падением на одной и той же примерно скорости :) При этом процессор был не загружен и памяти свободной была еще куча. Может с другим клиентом такого не случится, но вот с этим, на мой взгляд самым популярным, такие пироги.

 

Так что и у торрента будет предел замера скоростей :)

 

Попробуйте через DC++, он и более высокие скорости нормально лопатит.