diff options
Diffstat (limited to 'results/classifier/105/socket/1228285')
| -rw-r--r-- | results/classifier/105/socket/1228285 | 79 |
1 files changed, 79 insertions, 0 deletions
diff --git a/results/classifier/105/socket/1228285 b/results/classifier/105/socket/1228285 new file mode 100644 index 00000000..11070ed5 --- /dev/null +++ b/results/classifier/105/socket/1228285 @@ -0,0 +1,79 @@ +socket: 0.946 +network: 0.904 +device: 0.814 +vnc: 0.797 +semantic: 0.786 +other: 0.675 +instruction: 0.642 +mistranslation: 0.632 +assembly: 0.608 +graphic: 0.597 +boot: 0.432 +KVM: 0.394 + +e1000 nic TCP performances + +Hi, + +Here is the context : + +$ qemu -name A -m 1024 -net nic vlan=0,model=e1000 -net socket,vlan=0,listen=127.0.0.1:7000 +$ qemu -name B -m 1024 -net nic vlan=0,model=e1000 -net socket,vlan=0,connect=127.0.0.1:7000 + +The bandwidth is really tiny : + + . Iperf3 reports about 30 Mb/sec + . NetPerf reports about 50 Mb/sec + + +With UDP sockets, there is no problem at all : + + . Iperf3 reports about 1 Gb/sec + . NetPerf reports about 950 Mb/sec + + +I've noticed this fact only with the e1000 NIC, not with others (rtl8139,virtio, etc.) +I've used the main GIT version of QEMU. + + +Thanks in advance. + +See you, +VInce + +On Fri, Sep 20, 2013 at 05:21:23PM -0000, Vincent Autefage wrote: +> Here is the context : +> +> $ qemu -name A -m 1024 -net nic vlan=0,model=e1000 -net socket,vlan=0,listen=127.0.0.1:7000 +> $ qemu -name B -m 1024 -net nic vlan=0,model=e1000 -net socket,vlan=0,connect=127.0.0.1:7000 +> +> The bandwidth is really tiny : +> +> . Iperf3 reports about 30 Mb/sec +> . NetPerf reports about 50 Mb/sec +> +> +> With UDP sockets, there is no problem at all : +> +> . Iperf3 reports about 1 Gb/sec +> . NetPerf reports about 950 Mb/sec +> +> +> I've noticed this fact only with the e1000 NIC, not with others (rtl8139,virtio, etc.) +> I've used the main GIT version of QEMU. + +It's interesting that you see good performance over -netdev socket TCP +with the other NIC models. + +I don't know what the issue would be, you'll probably need to dig +further to discover the problem. Using wireshark might be a good start. +Try to figure out where the delay is incurred and then instrument that +code to find out the cause. + +Stefan + + +Looking through old bug tickets... can you still reproduce this issue with the latest version of QEMU? Or could we close this ticket nowadays? + +[Expired for QEMU because there has been no activity for 60 days.] + |