Hi.

>>Please help me even your wildest speculations are welcome :)
> 
> 
> Have you tried a kernel without SMP support? The problem might be related
> to the current locking scheme in multiprocessor kernels.

I tried that and it helped a little bit.
After connecting to the second network interface (wm0) i experienced 
that ping response times weren't that high anymore but still >1ms:
64 bytes from 192.168.0.50: icmp_seq=29866 ttl=255 time=1.125 ms

Another point concerns load averages. When i'm running some (~10-15) bc 
processes calculating 2^9999999 to produce some load i only get pings 
 >1ms very rarely (every now and then. But when i'm starting to use my 
R5 via Raidframe (for example initialisation, parity checking or iozone) 
almost every second or third ping reponse time is above 1ms.
Just at the moment a newfs on my raid finished:
64 bytes from 192.168.0.50: icmp_seq=54521 ttl=255 time=126701.449 ms
64 bytes from 192.168.0.50: icmp_seq=54522 ttl=255 time=125691.541 ms
[..]
64 bytes from 192.168.0.50: icmp_seq=54544 ttl=255 time=103473.454 ms
64 bytes from 192.168.0.50: icmp_seq=54545 ttl=255 time=102463.533 ms
This is what it looks like when newfs finished writing the last 
superblock but didn't give me back the prompt yet. It takes a while 
where this long pings occur and ssh gets very sluggish (not to say 
inaccessible) and finally after a minute or so everything returns to 
normal operation.

To make a little conclusion:
-Ping response time >1ms on a cross linked connection
-On the fxp0 device even more worse than on the wm0
-Disabling SMP helps
-Using a software raid with raidframe makes it even worse
-Load from different processes (e.g. bc or gcc) doesn't have such an impact.

Best Regards,

Jochen Keil