Python Popen Stdout Замораживание
Я прочитал много вопросов, касающихся печати стандартного stdout, включая ответ от решения JF Sebastian's Python 3, чтобы прочитать стандартный вывод.
Однако пока его решение работает по этому сценарию:
with Popen(['ping'] + ['169.254.79.191'] + ['-c'] + ['5'], stdout=PIPE, bufsize=1, universal_newlines=True) as p:
for line in p.stdout:
print(line, end='')
Это не работает, как я ожидаю, с приложением, которое я на самом деле хочу использовать:
with Popen(['iperf3', '-c', '169.254.79.191', 'b', '100000000', '-p', '5202', 't', '5', '-R', '-V', '-u'], stdout=PIPE, bufsize=1, universal_newlines=True) as p:
for line in p.stdout:
print(line, end='')
Для сценария проверки связи каждая строка печатается так, как будто я запускаю ее вручную. С iperf он останавливается после двух строк вывода и сбрасывает все, когда приложение готово. Если я выполняю их друг за другом в скрипте, я получаю такой вывод:
pi@raspberrypi2:~/project $ python3.4 stdout_RT_test.py
PING 169.254.79.191 (169.254.79.191) 56(84) bytes of data.
64 bytes from 169.254.79.191: icmp_seq=1 ttl=64 time=0.854 ms
64 bytes from 169.254.79.191: icmp_seq=2 ttl=64 time=0.867 ms
64 bytes from 169.254.79.191: icmp_seq=3 ttl=64 time=0.877 ms
64 bytes from 169.254.79.191: icmp_seq=4 ttl=64 time=0.842 ms
64 bytes from 169.254.79.191: icmp_seq=5 ttl=64 time=0.834 ms
--- 169.254.79.191 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 3998ms
rtt min/avg/max/mdev = 0.834/0.854/0.877/0.040 ms
iperf 3.0.7
Linux raspberrypi2 4.4.50-v7+ #970 SMP Mon Feb 20 19:18:29 GMT 2017 armv7l GNU/Linux
ВСЁ ПОСЛЕ ЭТОЙ ЛИНИИ ПОКАЗАНО ПОСЛЕ IPERF УСТРАНЕНО
Time: Wed, 29 Mar 2017 14:46:48 GMT
Connecting to host 169.254.79.191, port 5202
Reverse mode, remote host 169.254.79.191 is sending
Cookie: raspberrypi2.1490798808.947399.0490a
[ 4] local 169.254.181.167 port 41415 connected to 169.254.79.191 port 5202
Starting Test: protocol: UDP, 1 streams, 8192 byte blocks, omitting 0 seconds, 10 second test
[ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams
[ 4] 0.00-1.00 sec 136 KBytes 1.11 Mbits/sec 1.907 ms 0/17 (0%)
[ 4] 1.00-2.00 sec 128 KBytes 1.05 Mbits/sec 0.966 ms 0/16 (0%)
[ 4] 2.00-3.00 sec 128 KBytes 1.05 Mbits/sec 0.634 ms 0/16 (0%)
[ 4] 3.00-4.00 sec 128 KBytes 1.05 Mbits/sec 0.522 ms 0/16 (0%)
[ 4] 4.00-5.00 sec 128 KBytes 1.05 Mbits/sec 0.466 ms 0/16 (0%)
[ 4] 5.00-6.00 sec 128 KBytes 1.05 Mbits/sec 0.456 ms 0/16 (0%)
[ 4] 6.00-7.00 sec 128 KBytes 1.05 Mbits/sec 0.452 ms 0/16 (0%)
[ 4] 7.00-8.00 sec 128 KBytes 1.05 Mbits/sec 0.447 ms 0/16 (0%)
[ 4] 8.00-9.00 sec 128 KBytes 1.05 Mbits/sec 0.451 ms 0/16 (0%)
[ 4] 9.00-10.00 sec 128 KBytes 1.05 Mbits/sec 0.460 ms 0/16 (0%)
- - - - - - - - - - - - - - - - - - - - - - - - -
Test Complete. Summary Results:
[ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams
[ 4] 0.00-10.00 sec 1.26 MBytes 1.06 Mbits/sec 0.460 ms 0/161 (0%)
[ 4] Sent 161 datagrams
CPU Utilization: local/receiver 0.5% (0.0%u/0.5%s), remote/sender 0.0% (0.0%u/0.0%s)
iperf Done.
Как видно из столбца "Интервал", если я запускаю ту же команду вручную, то печатается примерно одна строка в секунду. Я новичок в Python, поэтому любая ошибка возможна. Я пробовал несколько других способов кэширования стандартного вывода, но они также замораживают вывод, как этот. Можно ли это как-то решить?
БР Андреас
РЕДАКТИРОВАТЬ: я думал о том, что проблема заключается в том, что iperf не сбрасывает, но, поскольку он явно пишет новую строку каждую секунду, должен быть способ поймать его перед сбросом. При выполнении более длинных тестов я заметил, что буфер stdout в конечном итоге заполнен и будет сбрасывать много строк и продолжаться до тех пор, пока он снова не заполнится.
1 ответ
Попробуйте --forceflush флаг командной строки для iperf3. Это заставляет iperf3 сбрасывать вывод после каждой строки вывода.
Вы также можете изменить значения буфера, используя:
stdbuf -i0 -o0 -e0 iperf3 ...