Problema do visualizador de tubos com a alteração do limite de taxa

Question

Estou usando pv para enviar arquivos via ssh .

Eu posso alterar "active pv" o limite em menos de 100M sem nenhum problema. Quando eu configuro o processo pv ativo para 100M ou 1G ou superior, não consigo mais mudar a taxa ...

MAS! Se eu mudar 5-10 vezes 1M para 2M, 2M para 1M pv pode definir, por vezes, a nova taxa.

Não encontrei solução para o problema. Alguma idéia?

Exemplos:

pv -R "15778"  -f -F "%p***%t***%e***%r***%b" -L 1M  
pv -R "15778"  -f -F "%p***%t***%e***%r***%b" -L 1G  
pv -R "15778"  -f -F "%p***%t***%e***%r***%b" -L 1M (not working anymore)  

    

Answer 1

Isso é causado pela contabilização em pv , o que efetivamente significa que sua limitação de taxa é limitada por leitura em vez de limitada por gravação. Observando o código-fonte mostra que o limite de taxa é impulsionado por um "alvo", que é o montante restante para enviar. Se a limitação de taxa estiver ativada, uma vez por ciclo de avaliação do limite de taxa, a meta será aumentada, embora devamos enviar de acordo com o limite de taxa; o alvo é então diminuído, por mais que seja realmente escrito. Isso significa que, se você definir o limite de taxa para um valor maior que a capacidade real de gravação, o alvo continuará subindo; A redução do limite de taxa não terá efeito algum até que pv alcance sua meta (incluindo o que é permitido gravar de acordo com o novo limite de taxa).

Para ver isso em ação, inicie um% básicopv:

pv /dev/zero /dev/null

Em seguida, controle isso:

pv -R 32605 -L 1M; sleep 10; pv -R 32605 -L 1G; sleep 1; pv -R 32605 -L 1M

Você verá o impacto dos cálculos do alvo variando a duração do segundo sono ...

Devido à limitação de gravação, isso só causa um problema quando você define o limite de taxa para um valor maior que a capacidade de gravação.

Com um pouco mais de detalhes, veja como a contabilidade funciona com um fluxo inicialmente limitado a 1M, depois para 1G por 5s e, em seguida, de volta para 1M, em uma conexão capaz de transmitir 400M:

Time    Rate     Target Sent    Remaining
1       1M       1M     1M      0
2       1G       1G     400M    600M
3       1G       1.6G   400M    1.2G
4       1G       2.2G   400M    1.8G
5       1G       2.8G   400M    2.4G
6       1G       3.4G   400M    3G
7       1M       3001M  400M    2601M
8       1M       2602M  400M    2202M
9       1M       2203M  400M    1803M
10      1M       1804M  400M    1404M
11      1M       1405M  400M    1005M
12      1M       1006M  400M    606M
13      1M       607M   400M    207M
14      1M       208M   208M    0
15      1M       1M     1M      0

São necessários 7 segundos para que o limite de taxa seja aplicado novamente. Quanto maior o tempo gasto com um limite de taxa alta, mais tempo será necessário para que o limite de taxa reduzida seja aplicado ...

A correção para isso é bastante simples, se você puder recompilar pv : em loop.c , altere a linha 154 para target = (de target += ), resultando em

                   || (cur_time.tv_sec == next_ratecheck.tv_sec
                       && cur_time.tv_usec >=
                       next_ratecheck.tv_usec)) {
                       target =
                           ((long double) (state->rate_limit)) /
                           (long double) (1000000 /
                                          RATE_GRANULARITY);

Uma vez feito isso, as reduções de limite de taxa são aplicadas imediatamente (bem, dentro de um ciclo de limite de taxa).

    

Answer 2

Parece ser um problema de buffer. Aqui está o meu banco de testes:

pv --pidfile /tmp/pv.pid --rate-limit 1K </dev/zero |
    ssh remote 'cat>/dev/null'

e aqui está o meu controle:

pv --rate-limit 100M --remote $(cat /tmp/pv.pid)
sleep 1
pv --rate-limit 1K --remote $(cat /tmp/pv.pid)

Com um intervalo de um segundo, leva cerca de 13 segundos para que o pv em execução reduza sua tentativa de 100MB / s (1Gb / s) até o objetivo final de 1KB / s. Aumentar o intervalo sleep em 1 segundo aumenta o tempo para atingir o objetivo final em quase 10 segundos:

Sleep   Delay
 1       13
 2       22
 3       28
 4       37

Quatro amostras não são suficientes para uma linha de tendência, por isso vou evitar sugerir que é uma correlação linear.

    

Answer 3

Estou me corrigindo; pv pode mudar a velocidade .. Eu não sei porque, mas precisa de algum tempo de acordo com o seu limite de velocidade ... Se você definir como 1G, terá que esperar 45 segundos para reduzir a velocidade.
5G - 5 min.
10G - 7 min.

Por exemplo:

Comandos:

pv --pidfile /tmp/pv.pid --rate-limit 10G </dev/zero | ssh 10.1.1.5 'cat>/dev/null'
pv --rate-limit 1M --remote $(cat /tmp/pv.pid)

Placa de rede de 10 Gb / s:

3.99GiB 0:02:26 [ 157MiB/s] (Right here i just changed to 1M)
26.1GiB 0:02:30 [ 160MiB/s]
77.6GiB 0:09:38 [1.01MiB/s]

Após 7 minutos, a velocidade mudou finalmente ...

- Placa de rede de 1 Gb / s:

Eu comecei novamente com limite de 10G.

770MiB 0:00:07 [ 112MiB/s]
44.5GiB 0:06:49 [ 111MiB/s]
46.4GiB 0:07:31 [1.00MiB/s]

Os resultados são os mesmos. Se você mudar a velocidade de 10G para 1M, você precisa esperar pelo menos 7min. Mas se você mudar a velocidade de 1M para 10G você não precisa esperar nenhum segundo. Eu não acho que é apenas com buffer porque 7min (45Gb) deve ser grande demais para buffer. mas esta é apenas a minha opinião.