Xen users - Jun 2010 - Slow TCP performance between Windows Vista and Xen PV-on-HVM guest

I am running a Xen HVM guest with netfront PV drivers. This is running SLES10
SP3 inside the guest. The Dom0 is also SLES10 SP3.

Now I am trying to communicate from that HVM guest to a Windows Visa or also
Windows 7 machine and I am getting really poor TCP performance. When tracing on
the network traffic, I can see that no packets are dropped or missing or
anything, but what happens is that the Vista machine does not seem to send an
ACK back to the Xen guest, and then the Xen guest is doing a retransmit after a
while. But this is causing huge delays and SCP, for example, mostly fails
completely because of the poor performance. I am thinking that perhaps the
problem here could be that the Windows machine is using the delayed ACK
mechanism but the Xen guest does not actually send further data so things
deadlock until the retransmit timer kicks in. But I don''t really
understand why this is happening and what I can do to fix this problem.

Now you could think that perhaps this has nothing to do with Xen. However,
strangely enough we had exactly the same setup but a VMWare SLES10 SP3 guest
instead of a Xen guest. And with this we did not see this problem at all. So now
I am wondering if this might be to do with the Xen network drivers? Has anyone
else ever experienced this? TCP works absolutely fine between any Linux guests.

Thanks,
Anna


_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

> 
> I am running a Xen HVM guest with netfront PV drivers. This is running
SLES10
> SP3 inside the guest. The Dom0 is also SLES10 SP3.
> 
> Now I am trying to communicate from that HVM guest to a Windows Visa
or also
> Windows 7 machine and I am getting really poor TCP performance. When
tracing
> on the network traffic, I can see that no packets are dropped or
missing or
> anything, but what happens is that the Vista machine does not seem to
send an
> ACK back to the Xen guest, and then the Xen guest is doing a
retransmit after
> a while.
Are you capturing packets on the windows machine or on the Dom0?

If you are using tcpdump on dom0, make sure you use ''-s0'' so
that you
capture the entire packup, and possibly ''-v'' as well. Without
capturing
the entire packet, tcpdump can''t tell you if the checksum is correct or
not. Even if the checksum is incorrect on Dom0 it doesn''t necessarily
tell you that there is a problem though. A bad checksum on received
packets on the windows machine would definitely suggest a problem
though.

James



_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

> Subject: RE: [Xen-users] Slow TCP performance between Windows Vista and
> XenPV-on-HVM guest
> 
> >
> > I am running a Xen HVM guest with netfront PV drivers. This is running
> SLES10
> > SP3 inside the guest. The Dom0 is also SLES10 SP3.
> >
> > Now I am trying to communicate from that HVM guest to a Windows Visa
> or also
> > Windows 7 machine and I am getting really poor TCP performance. When
> tracing
> > on the network traffic, I can see that no packets are dropped or
> missing or
> > anything, but what happens is that the Vista machine does not seem to
> send an
> > ACK back to the Xen guest, and then the Xen guest is doing a
> retransmit after
> > a while.
> 
> Are you capturing packets on the windows machine or on the Dom0?
Dom0. Note that the Windows machine doesn''t even run Xen or anything,
it is just some random machine on the network. Only the Linux guest runs on Xen.

> If you are using tcpdump on dom0, make sure you use ''-s0''
so that you
> capture the entire packup, and possibly ''-v'' as well.
Without capturing
> the entire packet, tcpdump can''t tell you if the checksum is
correct or
> not. Even if the checksum is incorrect on Dom0 it doesn''t
necessarily
> tell you that there is a problem though. A bad checksum on received
> packets on the windows machine would definitely suggest a problem
> though.
I capture with Ethereal. I definitely catch all packet. If this was a checksum
problem, then communication wouldn''t work at all. However, SSH and
other (slower) connections work just fine. The problem is only on bulk data
transfer using TCP. If the Linux guest was sending a packet with an invalid
checksum, then the Windows guest would *never* send out the ACK. However, it is
actually sending out the ACK, but only after the retransmit, to ACK the
*retransmitted* packet. If this was a checksum problem, then the retransmitted
packet would also have an invalid checksum and so it would basically never be
ACKed.

I have read about Vista''s TCP "auto-tuning" feature, and I
wonder if something like this might be the problem here that the Xen guest
cannot cope with?

Thanks,
Anna

_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

> > Subject: RE: [Xen-users] Slow TCP performance between Windows Vista
> and
> > XenPV-on-HVM guest
> >
> > >
> > > I am running a Xen HVM guest with netfront PV drivers. This is
> running
> > SLES10
> > > SP3 inside the guest. The Dom0 is also SLES10 SP3.
> > >
> > > Now I am trying to communicate from that HVM guest to a Windows
Visa
> > or also
> > > Windows 7 machine and I am getting really poor TCP performance.
When
> > tracing
> > > on the network traffic, I can see that no packets are dropped or
> > missing or
> > > anything, but what happens is that the Vista machine does not
seem
> to
> > send an
> > > ACK back to the Xen guest, and then the Xen guest is doing a
> > retransmit after
> > > a while.
> >
> > Are you capturing packets on the windows machine or on the Dom0?
> 
> Dom0. Note that the Windows machine doesn''t even run Xen or
anything, it
> is just some random machine on the network. Only the Linux guest runs on
> Xen.
> 
> 
> > If you are using tcpdump on dom0, make sure you use
''-s0'' so that you
> > capture the entire packup, and possibly ''-v'' as
well. Without
> capturing
> > the entire packet, tcpdump can''t tell you if the checksum is
correct
> or
> > not. Even if the checksum is incorrect on Dom0 it doesn''t
necessarily
> > tell you that there is a problem though. A bad checksum on received
> > packets on the windows machine would definitely suggest a problem
> > though.
> 
> I capture with Ethereal. I definitely catch all packet. If this was a
> checksum problem, then communication wouldn''t work at all.
However, SSH
> and other (slower) connections work just fine. The problem is only on
> bulk data transfer using TCP. If the Linux guest was sending a packet
> with an invalid checksum, then the Windows guest would *never* send out
> the ACK. However, it is actually sending out the ACK, but only after the
> retransmit, to ACK the *retransmitted* packet. If this was a checksum
> problem, then the retransmitted packet would also have an invalid
> checksum and so it would basically never be ACKed.
> 
> I have read about Vista''s TCP "auto-tuning" feature, and
I wonder if
> something like this might be the problem here that the Xen guest cannot
> cope with?
Also, note that bulk data transfers between the Linux guest and any other
*Linux* machine does work just fine as well. The problem is only when talking to
Windows Vista and Windows 7 (I have not yet tried Windows XP) machines. So if
this was a checksum problem, then communication with Linux machines should fail,
too, as Linux also discards packets with invalid checksums.

Anna

_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

> > Are you capturing packets on the windows machine or on the Dom0?
> 
> Dom0. Note that the Windows machine doesn''t even run Xen or
anything,
it is
> just some random machine on the network. Only the Linux guest runs on
Xen.

Yes, I''d figured that.
> 
> 
> > If you are using tcpdump on dom0, make sure you use
''-s0'' so that
you
> > capture the entire packup, and possibly ''-v'' as
well. Without
capturing
> > the entire packet, tcpdump can''t tell you if the checksum is
correct
or
> > not. Even if the checksum is incorrect on Dom0 it doesn''t
necessarily
> > tell you that there is a problem though. A bad checksum on received
> > packets on the windows machine would definitely suggest a problem
> > though.
> 
> I capture with Ethereal. I definitely catch all packet. If this was a
checksum
> problem, then communication wouldn''t work at all. However, SSH and
other
> (slower) connections work just fine. The problem is only on bulk data
transfer
> using TCP. If the Linux guest was sending a packet with an invalid
checksum,
> then the Windows guest would *never* send out the ACK. However, it is
actually
> sending out the ACK, but only after the retransmit, to ACK the
*retransmitted*
> packet. If this was a checksum problem, then the retransmitted packet
would
> also have an invalid checksum and so it would basically never be
ACKed.
> 
> I have read about Vista''s TCP "auto-tuning" feature, and
I wonder if
something
> like this might be the problem here that the Xen guest cannot cope
with?
> 
It might then be a ''large send'' problem. That would manifest
itself as
low volume traffic being mostly okay, but as the throughput
increased,
>MTU sized packets would be sent from DomU via Dom0, with the intent
that the hardware will split them up into <=MTU sized. If those were
dropped somewhere then the retransmit would happen, and the retransmit
would typically not use the ''large'' packet, so it would
probably work.

tcpdump should show >1500 byte packets in Dom0 on the vif interface
belonging to the DomU, and in the DomU if this is happening.

Use ethtool in DomU to disable as many offload features as possible and
see if things improve.

James


_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

> Subject: RE: [Xen-users] Slow TCP performance between Windows Vista and
> XenPV-on-HVM guest
> 
> > > Are you capturing packets on the windows machine or on the Dom0?
> >
> > Dom0. Note that the Windows machine doesn''t even run Xen or
anything,
> it is
> > just some random machine on the network. Only the Linux guest runs on
> Xen.
> 
> Yes, I''d figured that.
> 
> >
> >
> > > If you are using tcpdump on dom0, make sure you use
''-s0'' so that
> you
> > > capture the entire packup, and possibly ''-v'' as
well. Without
> capturing
> > > the entire packet, tcpdump can''t tell you if the
checksum is correct
> or
> > > not. Even if the checksum is incorrect on Dom0 it
doesn''t
> necessarily
> > > tell you that there is a problem though. A bad checksum on
received
> > > packets on the windows machine would definitely suggest a problem
> > > though.
> >
> > I capture with Ethereal. I definitely catch all packet. If this was a
> checksum
> > problem, then communication wouldn''t work at all. However,
SSH and
> other
> > (slower) connections work just fine. The problem is only on bulk data
> transfer
> > using TCP. If the Linux guest was sending a packet with an invalid
> checksum,
> > then the Windows guest would *never* send out the ACK. However, it is
> actually
> > sending out the ACK, but only after the retransmit, to ACK the
> *retransmitted*
> > packet. If this was a checksum problem, then the retransmitted packet
> would
> > also have an invalid checksum and so it would basically never be
> ACKed.
> >
> > I have read about Vista''s TCP "auto-tuning"
feature, and I wonder if
> something
> > like this might be the problem here that the Xen guest cannot cope
> with?
> >
> 
> It might then be a ''large send'' problem. 
Yes, my guess was that it must be something like this.
> That would manifest itself as
> low volume traffic being mostly okay, but as the throughput increased,
> >MTU sized packets would be sent from DomU via Dom0, with the intent
> that the hardware will split them up into <=MTU sized. If those were
> dropped somewhere then the retransmit would happen, and the retransmit
> would typically not use the ''large'' packet, so it would
probably work.
Is that so? I don''t know much about the TCP implementation, but would
it disable offloading for a retransmit?

> tcpdump should show >1500 byte packets in Dom0 on the vif interface
> belonging to the DomU, and in the DomU if this is happening.
No, I only see < 1500. I capture on the VIF and on the physical device in
Dom0.

> Use ethtool in DomU to disable as many offload features as possible and
> see if things improve.
Hardware offload is disabled on the NIC inside the Linux guest, on the VIF in
Dom0 and also on the NIC in Dom0. All offload features, including checksum
offload. My guess was also that this must be the problem, as I said before it
actually works with exactly the same guest running on VMWare. But obviously on
VMWare it doesn''t run the Xen netfront/netback drivers, so my guess was
that some configuration on there might be the issue. But as I said, switching
off hardware offload does not make any difference at all. At the moment it does
not run any HW offloading.

Thanks,
Anna

_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

I have always had to disable LSO in my setups (Although the other
acceleration features work fine). Could it possibly be a NIC driver
issue in Dom0?


Rob

-----Original Message-----
From: xen-users-bounces@lists.xensource.com
[mailto:xen-users-bounces@lists.xensource.com] On Behalf Of Fischer,
Anna
Sent: 12 June 2010 04:40
To: James Harper; xen-users@lists.xensource.com
Subject: RE: [Xen-users] Slow TCP performance between Windows Vista
andXenPV-on-HVM guest
> Subject: RE: [Xen-users] Slow TCP performance between Windows Vista
and
> XenPV-on-HVM guest
> 
> > > Are you capturing packets on the windows machine or on the Dom0?
> >
> > Dom0. Note that the Windows machine doesn''t even run Xen or
anything,
> it is
> > just some random machine on the network. Only the Linux guest runs
on
> Xen.
> 
> Yes, I''d figured that.
> 
> >
> >
> > > If you are using tcpdump on dom0, make sure you use
''-s0'' so that
> you
> > > capture the entire packup, and possibly ''-v'' as
well. Without
> capturing
> > > the entire packet, tcpdump can''t tell you if the
checksum is
correct
> or
> > > not. Even if the checksum is incorrect on Dom0 it
doesn''t
> necessarily
> > > tell you that there is a problem though. A bad checksum on
received
> > > packets on the windows machine would definitely suggest a problem
> > > though.
> >
> > I capture with Ethereal. I definitely catch all packet. If this was
a
> checksum
> > problem, then communication wouldn''t work at all. However,
SSH and
> other
> > (slower) connections work just fine. The problem is only on bulk
data
> transfer
> > using TCP. If the Linux guest was sending a packet with an invalid
> checksum,
> > then the Windows guest would *never* send out the ACK. However, it
is
> actually
> > sending out the ACK, but only after the retransmit, to ACK the
> *retransmitted*
> > packet. If this was a checksum problem, then the retransmitted
packet
> would
> > also have an invalid checksum and so it would basically never be
> ACKed.
> >
> > I have read about Vista''s TCP "auto-tuning"
feature, and I wonder if
> something
> > like this might be the problem here that the Xen guest cannot cope
> with?
> >
> 
> It might then be a ''large send'' problem. 
Yes, my guess was that it must be something like this.
> That would manifest itself as
> low volume traffic being mostly okay, but as the throughput increased,
> >MTU sized packets would be sent from DomU via Dom0, with the intent
> that the hardware will split them up into <=MTU sized. If those were
> dropped somewhere then the retransmit would happen, and the retransmit
> would typically not use the ''large'' packet, so it would
probably work.
Is that so? I don''t know much about the TCP implementation, but would
it
disable offloading for a retransmit?

> tcpdump should show >1500 byte packets in Dom0 on the vif interface
> belonging to the DomU, and in the DomU if this is happening.
No, I only see < 1500. I capture on the VIF and on the physical device
in Dom0.

> Use ethtool in DomU to disable as many offload features as possible
and
> see if things improve.
Hardware offload is disabled on the NIC inside the Linux guest, on the
VIF in Dom0 and also on the NIC in Dom0. All offload features, including
checksum offload. My guess was also that this must be the problem, as I
said before it actually works with exactly the same guest running on
VMWare. But obviously on VMWare it doesn''t run the Xen netfront/netback
drivers, so my guess was that some configuration on there might be the
issue. But as I said, switching off hardware offload does not make any
difference at all. At the moment it does not run any HW offloading.

Thanks,
Anna

_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

The SAQ Group

Registered Office: 18 Chapel Street, Petersfield, Hampshire GU32 3DZ
SAQ is the trading name of SEMTEC Limited. Registered in England & Wales
Company Number: 06481952

http://www.saqnet.co.uk AS29219

SAQ Group Delivers high quality, honestly priced communication and I.T. services
to UK Business.

Broadband : Domains : Email : Hosting : CoLo : Servers : Racks : Transit :
Backups : Managed Networks : Remote Support.

ISPA Member


_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

> Subject: RE: [Xen-users] Slow TCP performance between Windows Vista
> andXenPV-on-HVM guest
> 
> I have always had to disable LSO in my setups (Although the other
> acceleration features work fine). Could it possibly be a NIC driver
> issue in Dom0?
> 
> 
> Rob
> 
> -----Original Message-----
> From: xen-users-bounces@lists.xensource.com
> [mailto:xen-users-bounces@lists.xensource.com] On Behalf Of Fischer,
> Anna
> Sent: 12 June 2010 04:40
> To: James Harper; xen-users@lists.xensource.com
> Subject: RE: [Xen-users] Slow TCP performance between Windows Vista
> andXenPV-on-HVM guest
> 
> > Subject: RE: [Xen-users] Slow TCP performance between Windows Vista
> and
> > XenPV-on-HVM guest
> >
> > > > Are you capturing packets on the windows machine or on the
Dom0?
> > >
> > > Dom0. Note that the Windows machine doesn''t even run Xen
or
> anything,
> > it is
> > > just some random machine on the network. Only the Linux guest
runs
> on
> > Xen.
> >
> > Yes, I''d figured that.
> >
> > >
> > >
> > > > If you are using tcpdump on dom0, make sure you use
''-s0'' so that
> > you
> > > > capture the entire packup, and possibly
''-v'' as well. Without
> > capturing
> > > > the entire packet, tcpdump can''t tell you if the
checksum is
> correct
> > or
> > > > not. Even if the checksum is incorrect on Dom0 it
doesn''t
> > necessarily
> > > > tell you that there is a problem though. A bad checksum on
> received
> > > > packets on the windows machine would definitely suggest a
problem
> > > > though.
> > >
> > > I capture with Ethereal. I definitely catch all packet. If this
was
> a
> > checksum
> > > problem, then communication wouldn''t work at all.
However, SSH and
> > other
> > > (slower) connections work just fine. The problem is only on bulk
> data
> > transfer
> > > using TCP. If the Linux guest was sending a packet with an
invalid
> > checksum,
> > > then the Windows guest would *never* send out the ACK. However,
it
> is
> > actually
> > > sending out the ACK, but only after the retransmit, to ACK the
> > *retransmitted*
> > > packet. If this was a checksum problem, then the retransmitted
> packet
> > would
> > > also have an invalid checksum and so it would basically never be
> > ACKed.
> > >
> > > I have read about Vista''s TCP "auto-tuning"
feature, and I wonder if
> > something
> > > like this might be the problem here that the Xen guest cannot
cope
> > with?
> > >
> >
> > It might then be a ''large send'' problem.
> 
> Yes, my guess was that it must be something like this.
> 
> > That would manifest itself as
> > low volume traffic being mostly okay, but as the throughput increased,
> > >MTU sized packets would be sent from DomU via Dom0, with the
intent
> > that the hardware will split them up into <=MTU sized. If those
were
> > dropped somewhere then the retransmit would happen, and the retransmit
> > would typically not use the ''large'' packet, so it
would probably work.
> 
> Is that so? I don''t know much about the TCP implementation, but
would it
> disable offloading for a retransmit?
> 
> 
> > tcpdump should show >1500 byte packets in Dom0 on the vif interface
> > belonging to the DomU, and in the DomU if this is happening.
> 
> No, I only see < 1500. I capture on the VIF and on the physical device
> in Dom0.
> 
> 
> > Use ethtool in DomU to disable as many offload features as possible
> and
> > see if things improve.
> 
> Hardware offload is disabled on the NIC inside the Linux guest, on the
> VIF in Dom0 and also on the NIC in Dom0. All offload features, including
> checksum offload. My guess was also that this must be the problem, as I
> said before it actually works with exactly the same guest running on
> VMWare. But obviously on VMWare it doesn''t run the Xen
netfront/netback
> drivers, so my guess was that some configuration on there might be the
> issue. But as I said, switching off hardware offload does not make any
> difference at all. At the moment it does not run any HW offloading.
> 
I have found out by now that the problem is a bug in the NAT function in Dom0,
e.g. in the TCP connection tracking module. It fails to rewrite Delayed ACK
packets from newer Windows (Vista / 7) machines. When I configure the Windows
TCP stack with TCP_NODELAY then it all works.

Anna

_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

> >
> > Hardware offload is disabled on the NIC inside the Linux guest, on
the
> > VIF in Dom0 and also on the NIC in Dom0. All offload features,
including
> > checksum offload. My guess was also that this must be the problem,
as I
> > said before it actually works with exactly the same guest running on
> > VMWare. But obviously on VMWare it doesn''t run the Xen
netfront/netback
> > drivers, so my guess was that some configuration on there might be
the
> > issue. But as I said, switching off hardware offload does not make
any
> > difference at all. At the moment it does not run any HW offloading.
> >
> 
> I have found out by now that the problem is a bug in the NAT function
in Dom0,
> e.g. in the TCP connection tracking module. It fails to rewrite
Delayed ACK
> packets from newer Windows (Vista / 7) machines. When I configure the
Windows
> TCP stack with TCP_NODELAY then it all works.
> 
Thanks for posting that! Do you know if the problem is resolved in newer
kernels?

James

_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

Hi,

Does this have any relevance to my issue?

Ian



-----Original Message-----
From: xen-users-bounces@lists.xensource.com
[mailto:xen-users-bounces@lists.xensource.com] On Behalf Of James Harper
Sent: 15 June 2010 05:54
To: Fischer, Anna; Robert Dunkley; xen-users@lists.xensource.com
Subject: RE: [Xen-users] Slow TCP performance between Windows
VistaandXenPV-on-HVM guest
> >
> > Hardware offload is disabled on the NIC inside the Linux guest, on
the
> > VIF in Dom0 and also on the NIC in Dom0. All offload features,
including
> > checksum offload. My guess was also that this must be the problem,
as I
> > said before it actually works with exactly the same guest running on
> > VMWare. But obviously on VMWare it doesn''t run the Xen
netfront/netback
> > drivers, so my guess was that some configuration on there might be
the
> > issue. But as I said, switching off hardware offload does not make
any
> > difference at all. At the moment it does not run any HW offloading.
> >
> 
> I have found out by now that the problem is a bug in the NAT function
in Dom0,
> e.g. in the TCP connection tracking module. It fails to rewrite
Delayed ACK
> packets from newer Windows (Vista / 7) machines. When I configure the
Windows
> TCP stack with TCP_NODELAY then it all works.
> 
Thanks for posting that! Do you know if the problem is resolved in newer
kernels?

James

_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users



_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

I haven''t followed your email thread, but the bug I am talking about is
purely related to the TCP connection tracking module in the Dom0 kernel. If you
are not using NAT at all then you will probably have a different issue. The
problem is potentially also very specific to the Dom0 kernel you/I run, I run
Novel SLES 10 Xen which is some modified 2.6.16 kernel. I have not yet tracked
down the exact kernel code lines that are causing this bug.

Anna
> -----Original Message-----
> From: Ian Tobin [mailto:itobin@tidyhosts.com]
> Sent: 15 June 2010 09:53
> To: James Harper; Fischer, Anna; Robert Dunkley; xen-
> users@lists.xensource.com
> Subject: RE: [Xen-users] Slow TCP performance between Windows
> VistaandXenPV-on-HVM guest
> 
> Hi,
> 
> Does this have any relevance to my issue?
> 
> Ian
> 
> 
> 
> -----Original Message-----
> From: xen-users-bounces@lists.xensource.com
> [mailto:xen-users-bounces@lists.xensource.com] On Behalf Of James Harper
> Sent: 15 June 2010 05:54
> To: Fischer, Anna; Robert Dunkley; xen-users@lists.xensource.com
> Subject: RE: [Xen-users] Slow TCP performance between Windows
> VistaandXenPV-on-HVM guest
> 
> > >
> > > Hardware offload is disabled on the NIC inside the Linux guest,
on
> the
> > > VIF in Dom0 and also on the NIC in Dom0. All offload features,
> including
> > > checksum offload. My guess was also that this must be the
problem,
> as I
> > > said before it actually works with exactly the same guest running
on
> > > VMWare. But obviously on VMWare it doesn''t run the Xen
> netfront/netback
> > > drivers, so my guess was that some configuration on there might
be
> the
> > > issue. But as I said, switching off hardware offload does not
make
> any
> > > difference at all. At the moment it does not run any HW
offloading.
> > >
> >
> > I have found out by now that the problem is a bug in the NAT function
> in Dom0,
> > e.g. in the TCP connection tracking module. It fails to rewrite
> Delayed ACK
> > packets from newer Windows (Vista / 7) machines. When I configure the
> Windows
> > TCP stack with TCP_NODELAY then it all works.
> >
> 
> Thanks for posting that! Do you know if the problem is resolved in newer
> kernels?
> 
> James
> 
> _______________________________________________
> Xen-users mailing list
> Xen-users@lists.xensource.com
> http://lists.xensource.com/xen-users
> 

_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users