On Wed, Jul 07, 2004 at 10:55:44PM +0700, Ian Zagorskih wrote:
> [...]
> A: tcpdump icmp
> B: ping -n -c10 192.168.100.37 | tee log
> 
> ---cut A---
> # tcpdump icmp
> tcpdump: listening on rtk0
> 22:39:41.711857 192.168.100.250 > 192.168.100.37: icmp: echo request seq 0
> 22:39:41.711885 192.168.100.37 > 192.168.100.250: icmp: echo reply seq 0
> 22:39:48.809249 192.168.100.250 > 192.168.100.37: icmp: echo request seq 1
> 22:39:48.809276 192.168.100.37 > 192.168.100.250: icmp: echo reply seq 1
> 22:39:49.609254 192.168.100.250 > 192.168.100.37: icmp: echo request seq 2
> 22:39:49.609281 192.168.100.37 > 192.168.100.250: icmp: echo reply seq 2
> 22:40:07.210211 192.168.100.250 > 192.168.100.37: icmp: echo request seq 3
> 22:40:07.210237 192.168.100.37 > 192.168.100.250: icmp: echo reply seq 3
> 22:40:07.600214 192.168.100.250 > 192.168.100.37: icmp: echo request seq 4
> 22:40:07.600242 192.168.100.37 > 192.168.100.250: icmp: echo reply seq 4
> 22:40:25.021156 192.168.100.250 > 192.168.100.37: icmp: echo request seq 5
> 22:40:25.021184 192.168.100.37 > 192.168.100.250: icmp: echo reply seq 5
> 22:40:25.571182 192.168.100.250 > 192.168.100.37: icmp: echo request seq 6
> 22:40:25.571210 192.168.100.37 > 192.168.100.250: icmp: echo reply seq 6
> 22:40:42.912132 192.168.100.250 > 192.168.100.37: icmp: echo request seq 7
> 22:40:42.912161 192.168.100.37 > 192.168.100.250: icmp: echo reply seq 7
> 22:40:43.592142 192.168.100.250 > 192.168.100.37: icmp: echo request seq 8
> 22:40:43.592168 192.168.100.37 > 192.168.100.250: icmp: echo reply seq 8
> 22:40:59.192976 192.168.100.250 > 192.168.100.37: icmp: echo request seq 9
> 22:40:59.193002 192.168.100.37 > 192.168.100.250: icmp: echo reply seq 9
> ---cut A---
> 
> ---cut B---
> PING 192.168.100.37 (192.168.100.37): 56 data bytes
> 64 bytes from 192.168.100.37: icmp_seq=0 ttl=255 time=53.798 ms
> 64 bytes from 192.168.100.37: icmp_seq=1 ttl=255 time=48.679 ms
> 64 bytes from 192.168.100.37: icmp_seq=2 ttl=255 time=49.832 ms
> 64 bytes from 192.168.100.37: icmp_seq=3 ttl=255 time=53.813 ms
> 64 bytes from 192.168.100.37: icmp_seq=4 ttl=255 time=54.165 ms
> 64 bytes from 192.168.100.37: icmp_seq=5 ttl=255 time=54.893 ms
> 64 bytes from 192.168.100.37: icmp_seq=6 ttl=255 time=54.293 ms
> 64 bytes from 192.168.100.37: icmp_seq=7 ttl=255 time=52.639 ms
> 64 bytes from 192.168.100.37: icmp_seq=8 ttl=255 time=54.390 ms
> 64 bytes from 192.168.100.37: icmp_seq=9 ttl=255 time=54.551 ms
> 
> ----192.168.100.37 PING Statistics----
> 10 packets transmitted, 10 packets received, 0.0% packet loss
> round-trip min/avg/max/stddev = 48.679/53.105/54.893/2.134 ms
> ---cut B---
> 
> B -> A looks like to be veery delayed.

And tcpdump on a shows that A aserws properly. A tcpdump on B at the same
time could be usefull, but see below.

> 
> > Well...it's a bit of a long shot, but I've seen similar problems in
> > circumstances that lead me to speculate that on B, the interrupt the
> > card is actually generating and the interrupt the driver is expecting
> > are different.  (The dmesg, which I cut, says "irq 11"; that's what the
> > driver is expecting interrupts on, so my speculation amounts to
> > guessing that the card is actually interrupting on some other IRQ.)
> 
> Part of dmesg on B:
> 
> ---cut---
> rtk0 at pci0 dev 10 function 0: Realtek 8139 10/100BaseTX
> rtk0: interrupting at irq 15
> rtk0: Ethernet address 00:05:b7:00:2a:f6
> ohci0 at pci0 dev 19 function 0: Compaq USB Controller (rev. 0x06)
> ohci0: interrupting at irq 15
> ohci0: OHCI version 1.0, legacy support
> ---cut---
> 
> According to BIOS output at boot time NIC is pre-configured to use IRQ 15 same 
> as USB controller. Maybe shared PCI IRQs is the problem ?

I've got problems with shared IRQ in the past, with ohci involved.
Can you try disabling ohci in the BIOS ?

-- 
Manuel Bouyer <bouyer@antioche.eu.org>
     NetBSD: 26 ans d'experience feront toujours la difference
--