Re: [Xen-users] Slow network solved.

["Ulrich Windl" <ulrich.windl@xxxxxxxxxxxxxxxxxxxx>]

On 12 Jan 2007 at 3:48, Christopher G. Stach II wrote:

> IT wrote: > The solution was as simple as "ethtool -K eth0 tx off" on
> the domU's and "ethtool -K eth0 tx on" on the dom0's. After turning the
> tx checksumming off the network speed is faster and doesn't seem to be
> dropping packets at all anymore. 
> 
> I bet you'd find that at least 100 times in the list archives. :)

Still the explanation is missing: If one interface sends out an incorrect 
packet, 
other network interfaces should leave the packet as it is. So either "tx on" 
does 
something right, or it does something wrong. I don't see the relation in which 
domain these commands are used. Aren't they all virtual interfaces? Why not 
mess 
with the physical one as well?
Much more interesting is the question _why_ are there packets with bad 
checksums 
leaving XEN boxes? Only some packets are wrong, not every packet.

Things like:
Portmap V2 DUMP Reply [Unreassembled Packet [incorrect TCP checksum]]
Source port: sunrpc (111)
Destination port: 37960 (37960)
Sequence number: 2301860783
Next sequence number: 2301861183
Acknowledgement number: 1071929957
Header length: 32 bytes
Flags: 0x0018 (PSH, ACK)
Window size: 5792
Checksum: 0x6cec [incorrect, should be 0x278a]
Options: (12 bytes)

I believe very much in a software bug.

Regards,
Ulrich


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