sind Опубликовано 18 декабря, 2013 · Жалоба Доброго времени суток, коллеги. Предоставляем клиентам услуги Интернета по выделенной линии на разных скоростях, от 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, но на сколько это эффективно? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan_83 Опубликовано 18 декабря, 2013 · Жалоба Использование cc=htcp на стороне сервера очень помогает. Есть ещё куча всяких тюнингов, но в целом 100 мегабит в одном тцп скорее экзотика. Скорость с тестилки (нод спидтеста и тп) очень сильно зависит от настроек самого сервера, опять же htcp, буфера сокетов и некоторые параметры тцп. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
legioner0 Опубликовано 19 декабря, 2013 · Жалоба предложите клиенту погонять тесты httperf Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
sind Опубликовано 19 декабря, 2013 (изменено) · Жалоба Использование cc=htcp на стороне сервера очень помогает. Есть ещё куча всяких тюнингов, но в целом 100 мегабит в одном тцп скорее экзотика. Скорость с тестилки (нод спидтеста и тп) очень сильно зависит от настроек самого сервера, опять же htcp, буфера сокетов и некоторые параметры тцп. А каким наглядным способом можно продемонстрировать, что канал функционирует нормально? Сейчас делаем тест между точкой клиента и своей тестовой точкой IPErf-ом или JPErf-ом. Получить желаемые 100 мбит/сек получается в 3 потока. предложите клиенту погонять тесты httperf Нашел ее только под линуксы. Может быть, что взаимосвязь между задержкой и скоростью описана где то в RFC? Может быть есть документы на которые можно официально сослаться? Изменено 20 декабря, 2013 пользователем sind Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan_83 Опубликовано 19 декабря, 2013 · Жалоба А каким наглядным способом можно продемонстрировать, что канал функционирует нормально? Сейчас делаем тест между точкой клиента и своей тестовой точкой IPErf-ом или JPErf-ом. Есть приборы для замера пропускной способности. Дешёвый вариант с иперфом. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
sind Опубликовано 19 декабря, 2013 (изменено) · Жалоба Тут вопрос более стоит так, как обьяснить клиенту, что по-другому просто быть не может? В договоре про количество потоков не указано, и абонент хочет видеть все в 1 поток. В RFC не нашел такого, что скорость зависит от задержки/потери и тп. Изменено 19 декабря, 2013 пользователем sind Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan_83 Опубликовано 19 декабря, 2013 · Жалоба Так скорость одного тцп зависит от кучи разных факторов, не только от задержки. Есть всякие расширения в тцп для ускорений, размер окна, ну и сам алгоритм контроля перегрузки (cc) на стороне сервера, размера буферов сокета с обоих сторон и тп. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kosmich7 Опубликовано 19 декабря, 2013 · Жалоба Тут вопрос более стоит так, как обьяснить клиенту, что по-другому просто быть не может? В договоре про количество потоков не указано, и абонент хочет видеть все в 1 поток. В RFC не нашел такого, что скорость зависит от задержки/потери и тп. Ну так покажите ему 100Мбит в пределах вашей сети :)Абонент минет завтра захочет - будете обьяснять ? или красиво пошлете... Абонент настолько серьЁзно башляет ? Обьяснить простым нет ТВ 100Мбит в один поток - иначе пусть хоть застрелится :-) Подозреваю в договоре и про 100Мбит в один поток тоже ничего не написано) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vladd Опубликовано 19 декабря, 2013 (изменено) · Жалоба У нас при задержках 40-50 мс спидтесты показывают 70-90 мбит на московских серверах. Боритесь с потерями. Нещадно. Даже 0.5% потерь при таких задержках снижают скорость до 1-5 мбит/c в один поток. Вылизывайте сеть. Трясите магистралов, если проблема у них. Изменено 19 декабря, 2013 пользователем vladd Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Дятел Опубликовано 19 декабря, 2013 · Жалоба А каким наглядным способом можно продемонстрировать, что канал функционирует нормально? Торрентом на популярной раздаче ) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
sind Опубликовано 19 декабря, 2013 · Жалоба Ну так покажите ему 100Мбит в пределах вашей сети :) Абонент минет завтра захочет - будете обьяснять ? или красиво пошлете... Абонент настолько серьЁзно башляет ? Обьяснить простым нет ТВ 100Мбит в один поток - иначе пусть хоть застрелится :-) Подозреваю в договоре и про 100Мбит в один поток тоже ничего не написано) Какая разница сколько он "башляет". Что плохого в том, чтоб корректно объяснить и обосновать клиенту, что он не прав. А еще лучше - на что то сослаться. У нас при задержках 40-50 мс спидтесты показывают 70-90 мбит на московских серверах. Боритесь с потерями. Нещадно. Даже 0.5% потерь при таких задержках снижают скорость до 1-5 мбит/c в один поток. Вылизывайте сеть. Трясите магистралов, если проблема у них. Выше писали, что со спидтестами не все так просто. Потерь нет. Торрентом на популярной раздаче ) Ну это да. Только, акт о тестировании с такими данными не подпишешь. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
dmvy Опубликовано 19 декабря, 2013 · Жалоба Объясните, что вы продукте ip связность, а протоколы L4 уровня реализует ПО абонента или сервера где-то в интернете. Можно налить на них флуд 100мбит и в диспетчера задач на вкладке сеть увидят, что интерфейс утилизированы на 100% Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Дятел Опубликовано 19 декабря, 2013 · Жалоба Торрентом на популярной раздаче ) Ну это да. Только, акт о тестировании с такими данными не подпишешь. почему? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
mystic Опубликовано 19 декабря, 2013 · Жалоба Напишите свой спидтест, который и будет всегда показывать 100ку. :) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
EShirokiy Опубликовано 19 декабря, 2013 · Жалоба mystic, днс подкрутить у себя и кидать абонента на свой "спидтест", где скорость будет всегда соотвествовать тарифу) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
pawel40 Опубликовано 19 декабря, 2013 · Жалоба mystic, днс подкрутить у себя и кидать абонента на свой "спидтест", где скорость будет всегда соотвествовать тарифу) Фишка с днс уже не работает. Приходиться на прозрачном прокси заворачивать ссылки на тестовые картинки. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan_83 Опубликовано 19 декабря, 2013 · Жалоба "Свой" спид тест не освобождает от необходимости очень вдумчиво его настроить, дабы он отдавал на максимуме. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Alex/AT Опубликовано 20 декабря, 2013 · Жалоба Самый дешевый вариант показать абоненту 100 Мбит/с (и выше) - торрент. Если вы его не режете, конечно :) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
BiWiS Опубликовано 20 декабря, 2013 · Жалоба Я тут пытался торрентом померить скорость больше 200мбит (utorrent 3.3.1) на ~210 мбит клиент под виндой падал, больше 10 попыток и все завершались падением на одной и той же примерно скорости :) При этом процессор был не загружен и памяти свободной была еще куча. Может с другим клиентом такого не случится, но вот с этим, на мой взгляд самым популярным, такие пироги. Так что и у торрента будет предел замера скоростей :) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Дятел Опубликовано 20 декабря, 2013 · Жалоба Есть у меня одна комбинация материнской и винта, которая дает аналогичный результат, разбираться не стал.... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Yarlan Zey Опубликовано 20 декабря, 2013 · Жалоба по торренту... поиграйтесь с кешем в его настройках... ибо на больших скоростях стабильно - жесткий диск перегружен. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan_83 Опубликовано 20 декабря, 2013 · Жалоба Хз какие у вас диски, но 200 мегабит мои диски пишут и отдают легко, правда в один поток :) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
wtyd Опубликовано 20 декабря, 2013 · Жалоба Доброго времени суток, коллеги. Предоставляем клиентам услуги Интернета по выделенной линии на разных скоростях, от 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% :). Надо считать экономику такого решения. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
dignity Опубликовано 20 декабря, 2013 · Жалоба Вы абонентам что продаёте ? TCP или IP ? Думаю, что второе. Значит надо скорость на ip и мерить. Попробуйте так: запустите долгоиграющую закачку. Когда скорость устаканится, то ip -s li sh dev eth0 ; sleep 60 ; ip -s li sh dev eth0. Дальше смотрим соответствующие каунтеры, вычитаем из большего меньшее и делим на 60 -- получаем скорость на IP, т.е. скорость ip-пакетов, ключая их заголовки. Бредово. Так только торрент оттестить можно, но на tcp в один поток будет печаль. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Saab95 Опубликовано 20 декабря, 2013 · Жалоба Я тут пытался торрентом померить скорость больше 200мбит (utorrent 3.3.1) на ~210 мбит клиент под виндой падал, больше 10 попыток и все завершались падением на одной и той же примерно скорости :) При этом процессор был не загружен и памяти свободной была еще куча. Может с другим клиентом такого не случится, но вот с этим, на мой взгляд самым популярным, такие пироги. Так что и у торрента будет предел замера скоростей :) Попробуйте через DC++, он и более высокие скорости нормально лопатит. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...