G'day Klaus, replying below the 'rude' way, sorry.
--matt
On Wed, 13 Jul 2005, Klaus Fehlker wrote:
> I dumped the traffic of a successful "local" commit and it shows "checksum
> incorrect" for each packet sent by the client. I dumped it on the client, so
> there is no interference with the network. Thus, i suppose it is some
> Ethereal bug, would you agree?
> Can it be that checksum computation is done on hardware and the software
> beforehand just fills it with random bytes?
Yeah, if your NIC does so-called hardware checksum offload then libpcap
will see the packet with uninitialised checksums, and according to the
Ethereal FAQ at:
http://www.ethereal.com/faq.html#q5.14
this will cause bogus error messages when there's nothing really wrong.
Apparently, libpcap doesn't realise that the NIC's doing checksum offload
so libpcap shouldn't validate the checksums. You could try disabling
checksum offload. Someone should hack on libpcap...
If your NIC isn't doing checksum offload then I suppose libpcap's checksum
validation is broken. Beware, just cos the NIC claims to support checksum
offload doesn't mean your OS's driver for it is using that feature - the
firmware may implement it buggily, or the OS doesn't support checksum
offload, or some similar problem.
But so this checksum problem also looks like a seperate issue, unrelated
to your original problem re intermittently failing commits. So on to the
next candidate, packet loss...
> We have a packetshaper in between dropping packets depending on the load.
> But this should be transparent to Apache / SVN isn't it?
Yup, TCP will notice the missing packets, retransmit them and the apps
will just notice lower throughput, that's all - within reason. If you drop
a *lot* of packets then this might be the source of your problems. But
you'd have to drop a lot of packets, not just the odd one here and there.
Once the three-way handshake is complete, TCP doesn't give up on the
connection easily; things just get reeeaally sloooow.
Do you absolutely need to drop packets? That sounds scary. Could you try
disabling this traffic shaping and see if that fixes things? I think this
could well be the source of your problems.
> So in the end it would be good to see what the server receives and not what
> the client sends. I try to get that asap.
I reckon get both, and compare them. Or even, simultaneously log packet
data at the client, at the server, and also at selected point(s)
approximately evenly spaced (in terms of hops) in between client and
server, then compare the captured data, and thus you can do a binary
search to find the bad gateway/router/whatever.
Since you say in next later post that you've proved that this problem
isn't exclusive to Subversion, shall we take this thread off-list?
I'm pretty sure that the problem is with your network, or maybe with the
TCP/IP stacks involved, but almost certainly not with SVN, Apache or
libneon etc directly.
HTH,
--matt
Matthew Sanderson
Senior Programmer (UNIX)
TCG Information Systems Pty Ltd
Sydney, Australia
matthew@formtrap.com
http://www.formtrap.com/
+61 (02) 8303 2407
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Jul 15 05:00:02 2005