[/b/] [/d/] [/tu/] [/a/] [/ph/] [/wa/] [/cg/] [/t/] [/p/]

[Burichan] [Foliant] [Futaba] [Greenhell] [Gurochan] [Photon] - [Home] [Manage] [Archive]
[Return]
Posting mode: Reply
Leave these fields empty (spam trap):
Name
Link
Subject
Comment
File
Verification
Password (for post and file deletion)
  • Supported file types are: GIF, JPG, PDF, PNG
  • Maximum file size allowed is 20480 KB.
  • Images greater than 200x200 pixels will be thumbnailed.
File: 1494531716161.jpg -(394631 B, 1400x780) Thumbnail displayed, click image for full size.
394631 No.140147  

Какой tcp congestion control аlgorithm лучше всего подходит для сотовых сетей со слабым уровнем сигнала?

>> No.140208  

Сотовая сеть это link layer, TCP congestion control вообще увидит только то, что RTT большой и сильно рандомный. Юзай то что по дефолту и не трогай (в Linux Cubic, скоро станет BBR).

>> No.140219  

>>140208
Так вот и вопрос, что лучше всего подходит для большого и рандомного RTT, еще и с потерями

>> No.140396  

>>140219
Да нет никаких потерь на радиолинке. Потери все убирает уровень RLC. Если link layer сделан как надо, то потери могут быть только из-за того, что роутер специально удалил пакет, потому что на нем начали копиться пакеты и нужно снизить скорость передачи.

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

А проблемы медленного роста скорости передачи при большом RTT уже давно решили в Cubic. У него скорость роста окна вообще привязана ко времени и от RTT не зависит.

>> No.140400  

>>140396

> Да нет никаких потерь на радиолинке.

Расскажи это утилите ping.

> нужно жаловаться оператору на плохое покрытие

Может сразу в спортлото?


Delete Post []
Password

[/b/] [/d/] [/tu/] [/a/] [/ph/] [/wa/] [/cg/] [/t/] [/p/]

- wakaba 3.0.7 + futaba + futallaby -