Hi,
in a Windows 2003 64bit VM I have the following problem with the GPLPV driver
(newest version 0.10.0.138 ):
Receiving is very fast, but sending is ugly slow. The host system is Scientific
Linux 5.4. Any Idea what I can do?
[root@gar-ha-xen01 ~]# iperf -s
------------------------------------------------------------
Server listening on TCP port 5001
TCP window size: 85.3 KByte (default)
------------------------------------------------------------
[ 4] local 192.168.160.130 port 5001 connected with 192.168.160.72 port 4992
[ ID] Interval Transfer Bandwidth
[ 4] 0.0-10.9 sec 544 KBytes 411 Kbits/sec
[root@gar-ha-xen01 ~]# iperf -c tsm
------------------------------------------------------------
Client connecting to tsm, TCP port 5001
TCP window size: 16.0 KByte (default)
------------------------------------------------------------
[ 3] local 192.168.160.130 port 33337 connected with 192.168.160.72 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-10.0 sec 587 MBytes 493 Mbits/sec
[root@gar-ha-xen01 ~]#
[root@gar-ha-xen01 ~]#
[root@gar-ha-xen01 ~]# ethtool -k eth2
Offload parameters for eth2:
Cannot get device udp large send offload settings: Operation not supported
Cannot get device GRO settings: Operation not supported
rx-checksumming: on
tx-checksumming: on
scatter-gather: on
tcp segmentation offload: on
udp fragmentation offload: off
generic segmentation offload: off
generic-receive-offload: off
[root@gar-ha-xen01 ~]# ethtool eth2
Settings for eth2:
Supported ports: [ FIBRE ]
Supported link modes:
Supports auto-negotiation: No
Advertised link modes: 10000baseT/Full
Advertised auto-negotiation: No
Speed: 10000Mb/s
Duplex: Full
Port: FIBRE
PHYAD: 0
Transceiver: external
Auto-negotiation: on
Supports Wake-on: d
Wake-on: d
Current message level: 0x00000007 (7)
Link detected: yes
[root@gar-ha-xen01 ~]#
Sincerly,
Klaus
_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users
On Fri, Dec 4, 2009 at 4:07 PM, Klaus Steinberger <klaus.steinberger@physik.uni-muenchen.de> wrote:> Hi, > > in a Windows 2003 64bit VM I have the following problem with the GPLPV driver > (newest version 0.10.0.138 ): > > > Receiving is very fast, but sending is ugly slow. The host system is Scientific > Linux 5.4. Any Idea what I can do?Have you tried changing TCP offload settings on Windows side? -- Fajar _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Quoting "Fajar A. Nugraha" <fajar@fajar.net>:> On Fri, Dec 4, 2009 at 4:07 PM, Klaus Steinberger > <klaus.steinberger@physik.uni-muenchen.de> wrote: >> Hi, >> >> in a Windows 2003 64bit VM I have the following problem with the >> GPLPV driver >> (newest version 0.10.0.138 ): >> >> >> Receiving is very fast, but sending is ugly slow. The host system >> is Scientific >> Linux 5.4. Any Idea what I can do? > > Have you tried changing TCP offload settings on Windows side?Ah, that''s the solution. I switched off now Large Send Offload. Probably the somewhat old XEN which is used by RHEL doesn''t do the right things with it. Only bad point: Switching it off killed the network connection and only a reboot off the windows guest solved that. Now I have the following numbers: [root@gar-ha-xen01 ~]# iperf -s ------------------------------------------------------------ Server listening on TCP port 5001 TCP window size: 85.3 KByte (default) ------------------------------------------------------------ [ 4] local 192.168.160.130 port 5001 connected with 192.168.160.72 port 1278 [ ID] Interval Transfer Bandwidth [ 4] 0.0-10.0 sec 281 MBytes 236 Mbits/sec [root@gar-ha-xen01 ~]# iperf -c tsm ------------------------------------------------------------ Client connecting to tsm, TCP port 5001 TCP window size: 16.0 KByte (default) ------------------------------------------------------------ [ 3] local 192.168.160.130 port 35137 connected with 192.168.160.72 port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0-10.0 sec 831 MBytes 697 Mbits/sec [root@gar-ha-xen01 ~]# Sincerly, Klaus -- Klaus Steinberger Beschleunigerlaboratorium Phone: (+49 89)289 14287 Am Coulombwall 6, D-85748 Garching, Germany FAX: (+49 89)289 14280 EMail: Klaus.Steinberger@Physik.Uni-Muenchen.DE URL: http://www.physik.uni-muenchen.de/~Klaus.Steinberger/ ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
> > > > Have you tried changing TCP offload settings on Windows side? > > Ah, that''s the solution. I switched off now Large Send Offload. > Probably the somewhat old XEN which is used by RHEL doesn''t do the > right things with it. > Only bad point: Switching it off killed the network connection and > only a reboot off the windows guest solved that. Now I have the > following numbers: >Just out of interest, is the send being done to a physical machine or another VM? Offload is a bit of a funny thing... in my case I have problems when the packet goes from a Windows DomU running GPLPV with offload or even Linux with offload onto a bridge in Dom0 and then out a vlan on a physical adapter. It looks like my network adapter doesn''t support offload and vlan tagging when used together, but Linux doesn''t seem to be aware of that and tries to give the card a packet to be offloaded, with obvious results. James _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Hi James,> Just out of interest, is the send being done to a physical machine or > another VM? Offload is a bit of a funny thing... in my case I haveThe test was from DomU to the hosting Dom0, but I did the test because I had performance problems from DomU to a external physical machine.> problems when the packet goes from a Windows DomU running GPLPV with > offload or even Linux with offload onto a bridge in Dom0 and then out a > vlan on a physical adapter. It looks like my network adapter doesn''tUhh, it was a VLAN, probably that is the culprit? Sincerly, Klaus _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
> Hi James, > > > Just out of interest, is the send being done to a physical machineor> > another VM? Offload is a bit of a funny thing... in my case I have > > The test was from DomU to the hosting Dom0, but I did the test becauseI had> performance problems from DomU to a external physical machine. > > > > problems when the packet goes from a Windows DomU running GPLPV with > > offload or even Linux with offload onto a bridge in Dom0 and thenout a> > vlan on a physical adapter. It looks like my network adapter doesn''t > > Uhh, it was a VLAN, probably that is the culprit? >Could be, but if it went from DomU->Dom0 and didn''t cross a physical adapter then I wouldn''t have thought so. James _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
> > > problems when the packet goes from a Windows DomU running GPLPVwith> > > offload or even Linux with offload onto a bridge in Dom0 and then > out a > > > vlan on a physical adapter. It looks like my network adapterdoesn''t> > > > Uhh, it was a VLAN, probably that is the culprit? > > > > Could be, but if it went from DomU->Dom0 and didn''t cross a physical > adapter then I wouldn''t have thought so. >Thinking about it some more... it could be that the offload code on the Linux side makes some bad decisions about how to handle offload when it knows that the physical adapter doesn''t support it... James _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users