On Sun, Dec 30, 2012 at 10:54:47AM +0800, Amos Kong wrote: > On Sat, Dec 29, 2012 at 03:45:54PM +0800, wenli wrote: > > On 12/29/2012 09:18 AM, Amos Kong wrote: > > >On Fri, Dec 28, 2012 at 07:21:29PM -0200, Lucas Meneghel Rodrigues wrote: > > >>Looks good, applied, thanks! > > >Thanks, attached a final result. > > > > Amos, the throughput looks good/stable, > > Wenli, > > Thanks for your feedback. > > > but there are still lot of dates looks strange in your results, could you > > check it. > > your example should be caused by known mpstat bug, how about other > 'strange datas' you found? Can you list all of them to me, I will > check and fix them. > > > copy one of strange lines in your results, look at > > CPU/rx_pkts/tx_pkts..... parts , they are too small and unbelievable > > : > > > > size| sessions| throughput| CPU| thr_per_CPU| > > rx_pkts| tx_pkts| rx_byts| tx_byts| re_pkts| rx_intr| > > tx_intr| io_exit| irq_i > > > > 512| 4| 4913.86| 1.12| 4387.37| > > 39| 3| 2374| 158| 0| 39| > > 0| 324| 23 > > [amos@t430s ext-loc-netperf-result20121228]$ vim > virt.kvm.repeat16.localhost.virtio_blk.smp2.virtio_net.RHEL.6.3.x86_64.netperf.host_guest/debug/virt.kvm.repeat16.localhost.virtio_blk.smp2.virtio_net.RHEL.6.3.x86_64.netperf.host_guest.DEBUG > ... > 12/28 22:33:56 DEBUG|base_utils:0077| Running 'mpstat 1 59 |tail -n 1' > > ^^^ (mpstat only executed 1 second wrongly), it's the should > be the problem of mpstat, as you know I have a workaround > for internal, which I didn't use in my testing.
I was wrong, mpstat executed aout 60 seconds. 12/28 22:32:25 DEBUG|base_utils:0077| Running 'rm -f /tmp/netperf.3476.nf' 12/28 22:32:25 DEBUG|base_utils:0077| Running '/tmp/netperf-2.6.0/src/netperf -D 1 -H 10.66.7.53 -l 90.0 -C -c -t TCP_STREAM -- -m 512 >> /tmp/netperf.3476.nf' 12/28 22:32:25 DEBUG|base_utils:0077| Running '/tmp/netperf-2.6.0/src/netperf -D 1 -H 10.66.7.53 -l 90.0 -C -c -t TCP_STREAM -- -m 512 >> /tmp/netperf.3476.nf' 12/28 22:32:25 DEBUG|base_utils:0077| Running '/tmp/netperf-2.6.0/src/netperf -D 1 -H 10.66.7.53 -l 90.0 -C -c -t TCP_STREAM -- -m 512 >> /tmp/netperf.3476.nf' 12/28 22:32:25 DEBUG|base_utils:0077| Running 'cat /tmp/netperf.3476.nf' 12/28 22:32:25 DEBUG|base_utils:0077| Running '/tmp/netperf-2.6.0/src/netperf -D 1 -H 10.66.7.53 -l 90.0 -C -c -t TCP_STREAM -- -m 512 >> /tmp/netperf.3476.nf' (start to check) 12/28 22:33:55 DEBUG|base_utils:0077| Running 'cat /tmp/netperf.3476.nf' 12/28 22:33:55 DEBUG|base_utils:0077| Running 'cat /tmp/netperf.3476.nf' 12/28 22:33:55 DEBUG|base_utils:0077| Running 'cat /tmp/netperf.3476.nf' 12/28 22:33:55 DEBUG|base_utils:0077| Running 'cat /tmp/netperf.3476.nf' 12/28 22:33:55 DEBUG|base_utils:0077| Running 'cat /tmp/netperf.3476.nf' 12/28 22:33:55 DEBUG| netperf:0528| All netperf clients start to work. it took about 90 seconds. (threads works) 12/28 22:33:55 DEBUG| aexpect:1245| Sending command: ifconfig 12/28 22:33:55 DEBUG| aexpect:1245| Sending command: find /sys/devices|grep net/eth0/statistics/rx_packets|xargs cat;find /sys/devices|grep net/eth0/statistics/tx_packets|xargs cat;find /sys/devices|grep net/eth0/statistics/rx_bytes|xargs cat;find /sys/devices|grep net/eth0/statistics/tx_bytes|xargs cat We read realtime data from guest by network, but the guest network may be heavy loaded. I will test if it only happns on my env. If it's a general issue, I will change the design, such as, using the timestamp. Amos. _______________________________________________ Autotest-kernel mailing list [email protected] https://www.redhat.com/mailman/listinfo/autotest-kernel
