Como eu verifico o conjunto de parâmetros usando o comando tc?

1

Estou precisando simular uma conexão de alta latência e baixa largura de banda para um teste de desempenho do meu aplicativo. Eu passei por várias páginas descrevendo o comando tc . Mas não consegui validar os números que defini. Por exemplo:

Eu peguei os seguintes valores de comando de: link

tc qdisc add dev eth0 root tbf rate 1mbit burst 32kbit latency 400ms

Com isso aplicado (digamos, máquina A), de acordo com a descrição na página, estou assumindo que minha taxa de saída deve ser de 128 kBps (pelo menos aproximadamente). Para testar isso, eu comecei a transferir um arquivo de 2 GB usando scp da máquina A para outra máquina "B" que estão na mesma LAN. As taxas de transferência sem nenhuma deficiência adicional atingem até 12 MBps nesta rede. Mas, quando a transferência começou, a taxa estava em 2 MBps, então ela continuou protelando e caindo até quando começou a balançar e parar entre 11 kBps e 24 kBps.

Eu usei nmon para monitorar o throughput da rede em ambos os lados durante a transferência, mas nunca foi acima de 24 kBps (exceto por alguns valores lendo 54 e 62).

Eu também tentei aumentar a taxa e o tamanho do depósito, mas o comportamento durante o scp é o mesmo. Tentei o seguinte comando para aumentar o tamanho do intervalo e a taxa:

tc qdisc add dev eth0 root tbf rate 1024kbps burst 1024kb latency 500

E scp ainda parou e girou em torno das mesmas taxas (11-30 kBps).

Estou inferindo o termo "taxa" errado aqui? Eu olhei para a man page para tc e parece que minha interpretação está correta. Alguém poderia me explicar qual seria a melhor maneira de testar os parâmetros definidos (supondo que fiz corretamente)?

    
por james 18.11.2015 / 16:39

2 respostas

0

Para induzir a latência, você precisa usar o qdisc 'netem'.

Você se distraiu com o parâmetro 'latency' para o qdisc TBF. Para o qdisc TBF, esse parâmetro define apenas a latência máxima que será permitida para pacotes enfileirados. Portanto, por exemplo, se a fila for profunda o suficiente para que a latência de um pacote individual seja de 400 ms, o pacote será descartado. Isso não ajuda a simular a alta latência que você espera.

Sugiro usar algo como:

tc qdisc add dev eth0 root netem delay 400ms rate 1024kbps

Nota: Você quer dizer kbit, embora?

A ferramenta tc refere-se a kilobits por segundo como 'kbit' e kilobytes por segundo como 'kbps'.

    
por 25.11.2015 / 23:56
0

@ 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
    
por 27.11.2015 / 05:51