Bug 11473 - Sun PCI QFE in Ultra 5/10 doesn't receive packets immediately.
Sun PCI QFE in Ultra 5/10 doesn't receive packets immediately.
Status: CLOSED ERRATA
Product: Red Hat Linux
Classification: Retired
Component: kernel (Show other bugs)
6.2
sparc Linux
high Severity medium
: ---
: ---
Assigned To: David Miller
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2000-05-17 09:59 EDT by Paul Kronenwetter
Modified: 2008-05-01 11:37 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2000-06-14 04:03:36 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Paul Kronenwetter 2000-05-17 09:59:13 EDT
System configuration
Ultra 10, 440MHz Ultra-IIi, 512MB RAM, 9GB IDE Disk
Internal HME Ethernet interface
PCI Quad-Fast Ethernet adapter (eth0-3: Quattro HME (PCI/CheerIO)
10/100baseT Ethernet DEC 21153 PCI Bridge)

OS:
Red Hat Linux v6.2 with kernel-2.2.14-12 for Sparc64 installed.

Problem:
Ping reports alternating high-low response times from remote host on
lightly-loaded network.  Remote host sees appropriate request timing and
sends response immediately.  Kernel/network driver doesn't see the response
until another is sent.

Typical Ultra ping output:
$ ping 192.168.0.23
PING 192.168.0.23 (192.168.0.23) from 192.168.0.1 : 56(84) bytes of data.
64 bytes from 192.168.0.23: icmp_seq=0 ttl=255 time=1000.0 ms
64 bytes from 192.168.0.23: icmp_seq=1 ttl=255 time=199.7 ms
64 bytes from 192.168.0.23: icmp_seq=2 ttl=255 time=1000.3 ms
64 bytes from 192.168.0.23: icmp_seq=3 ttl=255 time=103.4 ms
64 bytes from 192.168.0.23: icmp_seq=4 ttl=255 time=1000.3 ms
64 bytes from 192.168.0.23: icmp_seq=5 ttl=255 time=129.5 ms
64 bytes from 192.168.0.23: icmp_seq=6 ttl=255 time=1000.3 ms
64 bytes from 192.168.0.23: icmp_seq=7 ttl=255 time=177.1 ms

--- 192.168.0.23 ping statistics ---
8 packets transmitted, 8 packets received, 0% packet loss
round-trip min/avg/max = 103.4/576.3/1000.3 ms

Snoop of same from 192.168.0.23:
# snoop -tr -d hme1
Using device /dev/hme (promiscuous mode)
  0.00000  192.168.0.1 -> 192.168.0.23 ICMP Echo request
  0.00003 192.168.0.23 -> 192.168.0.1  ICMP Echo reply
  1.00011  192.168.0.1 -> 192.168.0.23 ICMP Echo request
  1.00015 192.168.0.23 -> 192.168.0.1  ICMP Echo reply
  2.00021  192.168.0.1 -> 192.168.0.23 ICMP Echo request
  2.00023 192.168.0.23 -> 192.168.0.1  ICMP Echo reply
  3.00029  192.168.0.1 -> 192.168.0.23 ICMP Echo request
  3.00032 192.168.0.23 -> 192.168.0.1  ICMP Echo reply
  4.00041  192.168.0.1 -> 192.168.0.23 ICMP Echo request
  4.00044 192.168.0.23 -> 192.168.0.1  ICMP Echo reply
  5.00051  192.168.0.1 -> 192.168.0.23 ICMP Echo request
  5.00054 192.168.0.23 -> 192.168.0.1  ICMP Echo reply
  6.00060  192.168.0.1 -> 192.168.0.23 ICMP Echo request
  6.00063 192.168.0.23 -> 192.168.0.1  ICMP Echo reply
  7.00072  192.168.0.1 -> 192.168.0.23 ICMP Echo request
  7.00076 192.168.0.23 -> 192.168.0.1  ICMP Echo reply
  8.00082  192.168.0.1 -> 192.168.0.23 ICMP Echo request
  8.00084 192.168.0.23 -> 192.168.0.1  ICMP Echo reply

When the ping interval is changed to 6 seconds similar behavior is seen:
$ ping -i 6 192.168.0.23
PING 192.168.0.23 (192.168.0.23) from 192.168.0.1 : 56(84) bytes of data.
64 bytes from 192.168.0.23: icmp_seq=0 ttl=255 time=0.4 ms
64 bytes from 192.168.0.23: icmp_seq=1 ttl=255 time=6000.3 ms
64 bytes from 192.168.0.23: icmp_seq=2 ttl=255 time=145.5 ms
64 bytes from 192.168.0.23: icmp_seq=3 ttl=255 time=6000.4 ms
64 bytes from 192.168.0.23: icmp_seq=4 ttl=255 time=180.3 ms
64 bytes from 192.168.0.23: icmp_seq=5 ttl=255 time=6000.3 ms
64 bytes from 192.168.0.23: icmp_seq=6 ttl=255 time=105.3 ms

--- 192.168.0.23 ping statistics ---
7 packets transmitted, 7 packets received, 0% packet loss
round-trip min/avg/max = 0.4/2633.2/6000.4 ms

Snoop of above:
# snoop -tr -d hme1
Using device /dev/hme (promiscuous mode)
  0.00000  192.168.0.1 -> 192.168.0.23 ICMP Echo request
  0.00004 192.168.0.23 -> 192.168.0.1  ICMP Echo reply
  5.99135  192.168.0.1 -> 192.168.0.23 ICMP Echo request
  5.99138 192.168.0.23 -> 192.168.0.1  ICMP Echo reply
 11.99193  192.168.0.1 -> 192.168.0.23 ICMP Echo request
 11.99196 192.168.0.23 -> 192.168.0.1  ICMP Echo reply
 17.99254  192.168.0.1 -> 192.168.0.23 ICMP Echo request
 17.99257 192.168.0.23 -> 192.168.0.1  ICMP Echo reply
 23.99318  192.168.0.1 -> 192.168.0.23 ICMP Echo request
 23.99321 192.168.0.23 -> 192.168.0.1  ICMP Echo reply
 29.99378  192.168.0.1 -> 192.168.0.23 ICMP Echo request
 29.99383 192.168.0.23 -> 192.168.0.1  ICMP Echo reply
 35.99441  192.168.0.1 -> 192.168.0.23 ICMP Echo request
 35.99444 192.168.0.23 -> 192.168.0.1  ICMP Echo reply

Applications other than ping see similar delays with throughput.  If the
ethernet port is on a more heavily used ethernet segment, throughput and
delays are much more appropriate.

This machine is intended to be a firewall between a well-used network and
several leased lines, so these delays will be seen and felt by the remote
users.

Thanks!
-Paul
Comment 1 Paul Kronenwetter 2000-05-17 10:07:59 EDT
I forgot to mention that the on-board HME interface doesn't exhibit these
characteristics on either network.

Also, the delays are seen at each of the four ports on the QFE card.

-Paul
Comment 2 Paul Kronenwetter 2000-06-13 11:36:42 EDT
I could really use some help on this one.  We need this machine/configuration 
for a multi-port firewall.
Comment 3 David Miller 2000-06-14 04:03:36 EDT
I've sent a patch which hopefully fixes this problem to the
bug submitter.

If he reports that the bug is now fixed I will send the patch
to dledford and then close this bug.

Note You need to log in before you can comment on or make changes to this bug.