Por que temporariamente parece que o limite de transferência do comando pv não é mais aplicado quando eu saio da suspensão para ram?

Question

Eu tenho este perl script e eu discovered pv comando e decidiu usá-lo para obter algum feedback sobre o que está acontecendo com a aleatoriedade em termos de taxa de transferência. Depois de alguns testes ¹ eu decidi acelera o comando, assim:

perl_commands < /dev/urandom | pv -L 512k | tr -cd SET

5.5MiB 0:00:11 [ 529kiB/s] [                    <=>                             ]

Eu suspendo para ram usando systemctl suspend ( Archbang ). Quando eu retomo, o comando ainda é executado e inclui o tempo decorrido desde a suspensão em sua caixa de diálogo, mas parece que o limite que eu configurei não é mais imposto, a taxa de transferência é de 2-3MiB / s e a CPU é mais alta - como sem limite. Depois de algum tempo, isso diminui e eu posso ver que o limite ainda é imposto.

Por exemplo, se eu executar o comando por apenas alguns segundos, levará segundos para que a taxa de transferência retorne ao limite definido. Por outro lado, gerando 815Mb de dados durante uma hora, depois suspendendo por 30 minutos, demora cerca de 5 minutos para o comando retornar ao limite que eu defini - e o uso da CPU é como sem a aceleração durante esse tempo. / p>

Portanto, não é que o limite não seja aplicado, mas sim que sair da suspensão para o ram parece impactar a taxa de transferência nesse contexto. Por que e esse comportamento pode ser alterado?

^{1. O comando usa um núcleo da CPU quando não está regulado. Com um limite de 512KiB \ s, o uso da CPU é de cerca de 10-15% ou menos. Demora cerca de 2GB de aleatoriedade (e algum tempo) para preencher minha janela de terminal 80x40 (dependendo do SET).}

    

Answer 1

pv não sabe sobre os estados de energia do sistema. Tudo o que se vê é que o relógio mudou muito em algum momento.

Meu palpite é que pv não se importa se a quantidade de tempo entre duas leituras de clock ficar grande e apenas calcular a taxa de transferência com base no intervalo de tempo. Como o intervalo é muito grande, parece que a taxa de transferência é muito baixa.

O cálculo do throughput é medido em várias leituras do relógio (cerca de 5min em suas observações). Contanto que o intervalo considerado inclua o tempo gasto em suspensão, o valor da taxa de transferência calculada será muito baixo. Quando o intervalo novamente consistir apenas em tempo acordado, a taxa de transferência retornará ao esperado.

Por exemplo, suponha que você tenha suspendido por cinco minutos. Então, logo após retomar, pv calcula que 500kB foram transferidos nos últimos 5min, significando um throughput de apenas cerca de 1.7kB / s. Isso está bem abaixo do limite de 500kB, então pv transfere mais dados por um tempo para compensar. Eventualmente, o cálculo da taxa de transferência se estabilizará novamente.

Suspender o sistema não é como suspender o processo pv . Suspender o sistema é transparente para programas. Suspender o processo envia um sinal SIGCONT quando acordar. pv tem um manipulador de sinal para o SIGCONT que faz com que ele subtraia mais ou menos o tempo que ele passou suspenso (não chequei exatamente o que ele faria se ele fosse suspenso com um sinal SIGSTOP não detectável, mas não deveria causar muito grande uma perturbação, ao contrário da suspensão do sistema).

    

Answer 2

Em um cenário como este, onde garantir que permanecemos abaixo do limite é o fator mais importante, você pode tentar esta alternativa - cstream (com resumo da taxa de transferência a cada 2 minutos aqui):

cstream -t -512k -T 120

A opção de taxa de transferência, que permite um número negativo, parece projetada para essa situação:

-t num     Limit the throughput of the data stream to num bytes/second.
           Limiting is done at the input side, you can rely on cstream not
           accepting more than this rate. If the number you give is posi-
           tive, cstream accumulates errors and tries to keep the overall
           rate at the specified value, for the whole session. If you give
           a negative number, it is an upper limit for each read/write
           system call pair. In other words: the negative number will
           never exceed that limit, the positive number will exceed it to
           make good for previous underutilization.

Funciona com a suspensão do processo ou do sistema.