Comments 32
UFO just landed and posted this here
К сожалению, не все так радужно.
В наших тестах UDT оказывался в среднем медленнее TCP на канале 1 Гбит/с, RTT~5-6мс. Плюс UDT демонстрировал более медленный разгон, по этому для коротких по времени сессий он может значительно проигрывать TCP. А для полной утилизации этого канала в разных условиях требовалось всего от 2 до 5 параллельных TCP-сессий.
Не буду скрывать, нас подобный результат удивил, по этому наши эксперименты в этой области продолжаются.
В наших тестах UDT оказывался в среднем медленнее TCP на канале 1 Гбит/с, RTT~5-6мс. Плюс UDT демонстрировал более медленный разгон, по этому для коротких по времени сессий он может значительно проигрывать TCP. А для полной утилизации этого канала в разных условиях требовалось всего от 2 до 5 параллельных TCP-сессий.
Не буду скрывать, нас подобный результат удивил, по этому наши эксперименты в этой области продолжаются.
UFO just landed and posted this here
UFO just landed and posted this here
Да, именно такое поведение мы и наблюдали, но глубоко в теорию вопроса и формулы пока не копали.
Но затея по написанию своего CCC, когда штатный TCP может давать неплохие результаты мне кажется странной, как и идея мультиплексирования нескольких TCP-сессий в одну UDT(это спорная часть моего мнения).
Сессии у нас измеряются десятками гигабайт переданных данных, но нам, в текущей архитектуре, желательно поддерживать пул соединений, из которых в каждый момент времени активны будут порядка 1-10%, а TCP похоже с этим справляется получше.
P.S. Это не я. Да и из нашей исследовательской группы, как и из моих оффлайн друзей, на хабре есть только я.
Но затея по написанию своего CCC, когда штатный TCP может давать неплохие результаты мне кажется странной, как и идея мультиплексирования нескольких TCP-сессий в одну UDT(это спорная часть моего мнения).
Сессии у нас измеряются десятками гигабайт переданных данных, но нам, в текущей архитектуре, желательно поддерживать пул соединений, из которых в каждый момент времени активны будут порядка 1-10%, а TCP похоже с этим справляется получше.
P.S. Это не я. Да и из нашей исследовательской группы, как и из моих оффлайн друзей, на хабре есть только я.
UFO just landed and posted this here
А почему таймаут в 1с приемлем? Я как-то был в больнице с одной бесплатной йотой (и без телефона, чтобы авторизовать банковский платёж и закинуть денег с банковской карты) — так там у меня соединения по 5-10 секунд открывались. Не надо портить то, что уже есть.
Стриминг, скачка больших файлов, и еще целая куча своеобразных сервисов, не имеют смысла на плохих каналах.
Я как-то в молодости месяц выкачивал нужную мне исошку линукса на диалапе. Я вполне могу себе представить ситуацию, когда нужно, но доступен только говёный инет. И получать отлуп от сервера только на том основании, что у меня медленный канал с потерей пакетов будет очень и очень обидно. Не для этого TCP изобретался.
1. Это было давно
2. Обычной почтой выйдет быстрее
3. Мне обидно потерять 10% из-за теоретических ситуаций
4. Когда изобретался TCP вряд ли кто-то думал о том, что файлы будут по 5Гб.
ЗЫ: Если владелец сервиса решит пожертвовать, то он пожертвует. Можно протестовать, рисовать на него фотожабы, писать в спортлото и устроить голодовку, но это бизнес.
2. Обычной почтой выйдет быстрее
3. Мне обидно потерять 10% из-за теоретических ситуаций
4. Когда изобретался TCP вряд ли кто-то думал о том, что файлы будут по 5Гб.
ЗЫ: Если владелец сервиса решит пожертвовать, то он пожертвует. Можно протестовать, рисовать на него фотожабы, писать в спортлото и устроить голодовку, но это бизнес.
>Стриминг, скачка больших файлов, и еще целая куча своеобразных сервисов, не имеют смысла на плохих каналах.
«За мкадом жизни нет»?
«За мкадом жизни нет»?
UFO just landed and posted this here
1. IW10 в linux >= 2.6.38
4. PRR в linux >= 3.2
4. PRR в linux >= 3.2
TCP Fast Open серверная часть >=3.7, клиентская часть >3.6. Про Windows ничего не сказано, но «We also coordinated with the developers of Chrome to implement TFO support within the browser». То есть если даже сделают только для Chrome, все остальные ускорения не увидят.
Все сервера на Centos идут лесом, включая Centos 6.3, т.к. kernel vesion 2.6.32.
Все сервера на Centos идут лесом, включая Centos 6.3, т.к. kernel vesion 2.6.32.
как всё это включить в Linux?
Поддерживаю! И вот комментарий в +1: habrahabr.ru/blogs/network_technologies/136926/#comment_4559184
Товарищи знающие, делитесь знаниями, а то раскулачим! :-)
Товарищи знающие, делитесь знаниями, а то раскулачим! :-)
Из комментариев к источнику:
Linux kernel versions of the changes were applied:Другой комментарий утверждает, что Fast Open есть в 2.6.34, ссылаясь на [1]. Но в целом итак понятно, что разработчики ядра linux не дремлют.
1. Initial Congestion Window of 10 packets: 2.6.39-rc1
2. Initial Retransmission Timeout of 1sec: 3.1-rc1
3. Proportional Rate Reduction: 3.2-rc1
4. Fast Open: not yet. It's the most complicated change. We are still testing the patches internally and will upstream when it's ready.
UFO just landed and posted this here
Много разговоров ни о чем.
Где конкретика?
Как проверить и подкрутить эти параметры на реальной системе?
Где конкретика?
Как проверить и подкрутить эти параметры на реальной системе?
UFO just landed and posted this here
UFO just landed and posted this here
Sign up to leave a comment.
Сделаем TCP быстрее