Перейти к содержимому
Калькуляторы

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

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

 

Предоставляем клиентам услуги Интернета по выделенной линии на разных скоростях, от 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, но на сколько это эффективно?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

 

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

 

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

 

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

 

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

Изменено пользователем sind

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Изменено пользователем sind

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

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

 

3175165401.png

Изменено пользователем vladd

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

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

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

 

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

 

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

 

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

 

 

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

 

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

 

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

 

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

почему?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

Предоставляем клиентам услуги Интернета по выделенной линии на разных скоростях, от 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% :). Надо считать экономику такого решения.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.