diff options
Diffstat (limited to 'results/classifier/105/socket/1228285')
| -rw-r--r-- | results/classifier/105/socket/1228285 | 79 |
1 files changed, 0 insertions, 79 deletions
diff --git a/results/classifier/105/socket/1228285 b/results/classifier/105/socket/1228285 deleted file mode 100644 index 11070ed5..00000000 --- a/results/classifier/105/socket/1228285 +++ /dev/null @@ -1,79 +0,0 @@ -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.] - |