@ user144844 Aprecie a resposta. Apenas FYI, netem
não possui um argumento de taxa.
Eu entendo os parâmetros tbf
razoavelmente bem. Também estou ciente do latency
como parte de um filtro de token bucket e da latência de rede em geral. O problema, como já mencionei, é que não consegui ver a taxa sendo acelerada no valor rate
definido quando testada por scp
para um arquivo de 2 GB.
Voltando à pergunta original: Decidi prosseguir com minha simulação real com vários usuários virtuais que realizam determinadas transações no servidor em que defino uma largura de banda de 256 kbps. No final, ficou claro que o conjunto rate
tinha sido aplicado desde que minha taxa de transferência caiu de 968 kbps (em condições de LAN) para 249 kbps (taxa aplicada usando tbf
). O mesmo persistiu quando eu aumentei a carga para duas vezes e três vezes o original e pude ver o tempo de resposta sendo impactado. Então, acredito que os parâmetros definidos funcionem. scp
não é a melhor maneira de testá-lo.
Eu usei os seguintes comandos para definir minhas condições de rede:
# tc qdisc add dev eth0 root handle 1: tbf rate 256kbit burst 256kbit latency 200ms
# tc qdisc add dev eth0 parent 1:1 handle 11: netem delay 50ms
# tc qdisc show
qdisc tbf 1: dev eth0 root refcnt 2 rate 256000bit burst 32Kb lat 200.0ms
qdisc netem 11: dev eth0 parent 1:1 limit 1000 delay 50.0ms