Что другие алгоритмы управления перегрузкой особенно разработаны для беспроводных сетей с потерями как LTE и WiMax?

Устраните группу и полномочия записи других на файлах, но дайте им полномочия записи на каталогах так, чтобы все могли удалить файлы. Затем когда пользователь хочет изменить файл, они должны удалить исходный файл и записать другому в его месте.

С другой стороны, Вы могли позволить sudo chown (не позволяя sudo использоваться для других команд). Это вынудило бы пользователей взять владение перед редактированием.

2
24.09.2016, 17:14
2 ответа

Неустанным TCP был бы самый неустанный TCP, который Вы могли получить.

0
27.01.2020, 22:23
  • 1
    Интернет хотел бы воспользоваться этой возможностью, чтобы поблагодарить Вас за то, что не был протестирован TCP, Неустанный на нем :-P. –  sourcejedi 24.09.2016, 17:57

BBR :).

Если скорость потери пакетов ниже 15%, то BBR может полностью использовать путь (достигая link_bandwidth*(1 - loss_rate)). Этот порог в 15% является параметром проектирования, а не фундаментальным ограничением

Я затрудняюсь объяснить точное значение этого. Вот Эрик Дюмазе:

По сравнению с Cubic, в средах с потерями разница составляет от 2 до 4 порядков величины.

Пример 100 мс rtt и 1% потери пакетов. Cubic показывает очень плохие результаты.

$ netperf -H 10.246.7.152 -l 30 -- -K cubic
MIGRATED TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 10.246.7.152 () port 0 AF_INET
Recv   Send    Send                          
Socket Socket  Message  Elapsed              
Size   Size    Size     Time     Throughput  
bytes  bytes   bytes    secs.    10^6bits/sec  

 87380  16384  16384    40.00       3.27   

$ netperf -H 10.246.7.152 -l 30 -- -K bbr  
MIGRATED TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 10.246.7.152 () port 0 AF_INET
Recv   Send    Send                          
Socket Socket  Message  Elapsed              
Size   Size    Size     Time     Throughput  
bytes  bytes   bytes    secs.    10^6bits/sec  

 87380  16384  16384    30.25    9150.01

Стороннее тестирование показало / вызвало объяснение, что текущий код ожидает полного буфера (BDP) в узком месте, если есть конкуренция. Это известная цель для дальнейшего улучшения. Если условие не выполняется, это увеличивает уровень потерь. Тогда традиционные TCP будут практически голодать.

Если буфера больше, чем 1 BDP, потоки BBR будут сотрудничать, чтобы избежать заполнения избыточного буфера, следовательно, ограничивая задержку в очереди, как вы просили. Традиционные TCP имеют тенденцию заполнять весь буфер. Когда оба конкурируют, BBR не может волшебным образом исправить поведение традиционных TCP-потоков, однако я не думаю, что это вредит BBR каким-либо другим образом.

Если вышеупомянутое условие не выполняется, задержка приложения будет страдать (необходимость повторной передачи потерянных пакетов).

https://groups.google.com/forum/#!forum/bbr-dev

https://www.google.co.uk/search?q=tcp-bbr

[PATCH v4 net-next 00/16] tcp: Алгоритм управления перегрузками BBR

1
27.01.2020, 22:23

Теги

Похожие вопросы