summary refs log tree commit diff stats
path: root/results/classifier/zero-shot/105/socket/1228285
blob: 11070ed5091b663b5a03095b8b3bbf22d4be9cf4 (plain) (blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
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.]