Comments 15
UFO just landed and posted this here
Вот как-то не приходилось сталкиваться с таким поведением. Было правда дело TCP Window Size высчитывали, но не flow control, но это совсем другая история.
Flow control — зло. Не надо им пользоваться. Родного congestion management средствами TCP (на основании дропов пакетов, в чем нет ничего страшного, или на основании возрастающей задержки при включении шейпинга) достаточно для ограничения скорости передачи данных, и с ним куда меньше проблем. Для UDP сервисов, лишенных возможности перепосылки, надо делать QoS в любом случае.
Есть PFC. Он лучше, так как более избирательный, но все равно его используют лишь для FCoE и тому подобных протоколов, абсолютно нетерпимых к потерям.
Есть PFC. Он лучше, так как более избирательный, но все равно его используют лишь для FCoE и тому подобных протоколов, абсолютно нетерпимых к потерям.
UFO just landed and posted this here
Родного congestion management средствами TCP (на основании дропов пакетов, в чем нет ничего страшного, или на основании возрастающей задержки при включении шейпинга) достаточно для ограничения скорости передачи данных, и с ним куда меньше проблем.
Достаточно для ограничения скорости. А проблемы возникают, когда становиться необходимым использовать всю доступную в канале скорость, а не некоторую ее часть и чем больше скорость и длиннее труба с Ethernet'ом высокого давления, тем проблем больше.
Кстати у TCP не существует «родного» congestion management алгоритма, а есть N > 0 алгоритмов, которые в одинаковых условиях ведут себя очень по разному (Эффективность может легко отличаться раз в 10).
С FlowControl на уровне Ethernet я пока не сталкивался, но есть шанс посмотреть на него на практике в обозримом промежутке времени.
чем больше скорость и длиннее труба с Ethernet'ом высокого давления, тем проблем больше.
Со стандартными окнами TCP тут ничто кроме многопоточности не поможет. Скажем, торренты будут летать. Хочется прожечь LFN по полной одним потоком — надо window scaling factor повышать.
у TCP не существует «родного» congestion management алгоритма
Заменить «родной» на «встроенный». Может, я не так выразился…
Те, что обычно идут по дефолту во всех ОС, предполагают «дроп пакета = congestion», что, само собой, не всегда соответствует действительности. Некоторые гораздо быстрее поднимают размер окна после дропа. Вариантов полно.
Заменить «родной» на «встроенный». Может, я не так выразился…
Это ничего не изменит ибо непонятно, какой из 13 алгоритмов доступных на ближайшем ко мне Linux считать встроенным или родным :) Но это так, беспредметный спор…
Вариантов полно.
Вот именно по этому и доступно для ограничения скорости. Не доступное железо ограничивает скорость, а алгоритм.
Хочется прожечь LFN по полной одним потоком — надо window scaling factor повышать.
Не вытянет. Не в нем проблема, а в адекватности реакции на потери (например, в некоторых случаях быстрое наращивание скорости и медленный сброс) и адекватности предсказания — из-за перегрузки эта потеря или звезды так сложились и скорость понижать не надо, а только перепослать сегмент.
ничто кроме многопоточности не поможет.
Задачи, когда хотелось бы эффективности вполне имеют место быть. Да и усложняет многопоточность решения конкретных задач.
Спасибо за ссылку, прочитаю.
А еще, скажите пожалуйста, не сталкивались ли Вы с технологиями RDMAoE?
какой из 13 алгоритмов доступных на ближайшем ко мне Linux считать встроенным или родным
Какой по дефолту применяется, если ничего не менять?
У меня в винде вообще только два… Мне хватает. Даже ноутбуком сидя на вайфае, я выжимаю одним потоком цифры, близкие к возможностям вайфая или каналов между площадками (т.е. сотни мегабит).
Не вытянет.
Рекорд — вроде десяток гигабит на линке с RTT 200мс или около того — одним потоком. Да, дропов не было. Буферы — гигабайтные.
Но на практике обычно ширина аплинка на порядок (порядки) выше ширины линка до конечной системы. На аплинках будет много потоков. TCP в итоге будет эффективен. Любой алгоритм congestion management у TCP.
RDMAoE
В той сфере, где я работаю, HPCшные концепции непопулярны. Но опять же, если ему требуется lossless транспорт, надо делать PFC и тому подобное. Если требование «ни одного дропа» отсутствует, то проще оставить все как есть.
Спасибо, статья хороша. Кстати, было бы здорово сразу дампы к статье прикреплять, чтобы можно было самому потыкать.
>> Как нужно вести себя
Картинка из «Бойцовского клуба» (81:16)
Картинка из «Бойцовского клуба» (81:16)
Важно помнить, что некие недобросовестные люди могут воспользоваться этим протоколом для организации DoS-атаки на сегмент сети (я же делал это из любопытства с моей собственной локальной сетью, никто не пострадал)
Хорошо, что это возможно в пределах сегмента сети. Иначе туго бы пришлось сетям, если бы их удалённо бомбили такими вот пакетами
Хорошо, что это возможно в пределах сегмента сети. Иначе туго бы пришлось сетям, если бы их удалённо бомбили такими вот пакетами
Sign up to leave a comment.
Что такое Slow Protocols