GNIC II results & bug reports.
Claude Lefrancois
lefranco@postit.cae.ca
Thu Oct 29 11:20:35 1998
Hello !!!
I am testing two GNIC II cards. The first one is installed in a Dell
Workstation 410 (dual Pentium II 400 MHz/512 KB cache, 256 MB RAM and
AIC-7890 U2W SCSI controller). This machine is running 2.0.35 SMP. The
second computer is a Dell PowerEdge 6300/400 (Quad Pentium II Xeon 400
MHz/1MB cache, 256 MB RAM and AHA-2940 UW SCSI controller). This
machine is running 2.1.126-pre2-ac2 SMP.
INSTALLATION:
-------------
The module compiles and install just fine on 2.0.35 SMP:
Found Hamachi GNIC-II at PCI address 0x00000000 fcfff004, IRQ 9.
hamachi.c:v0.07 8/17/98 Written by Donald Becker
http://www.tidalwave.net/~becker/hamachi.html
eth2: Hamachi GNIC-II type 10911 at 0x10853000, 00:e0:b1:04:14:44, IRQ 9.
eth2: 32-bit 33 Mhz PCI bus (60), Virtual Jumpers 30, LPA 48e0.
On 2.1.126, when I compile the module, I get a warning concerning the
PCI interface, but the old PCI interface is still available for
2.1.xxx then the driver should work without problem. Here is the
output:
In file included from hamachi.c:79:
usr/include/linux/bios32.h:11: warning: #warning This driver
uses the old PCI interface, please fix it (see Documentation/pci.txt)
When I install the module, I get:
Found Hamachi GNIC-II at PCI address 0xf7804004, IRQ 11.
hamachi.c:v0.07 8/17/98 Written by Donald Becker
http://www.tidalwave.net/~becker/hamachi.html
eth2: Hamachi GNIC-II type 10911 at 0xd084e000, 00:e0:b1:04:14:46, IRQ 11.
eth2: 32-bit 33 Mhz PCI bus (60), Virtual Jumpers 30, LPA 0000.
PCI latency timer (CFLT) is unreasonably low at 32. Setting to 64 clocks.
The PCI latency timer is something bad or not ? This machine has 3 PCI
64 bit slots. The driver doesn't want to load in these slots. When I
try to use the GNIC-II in a 64 bit slot, I get:
hamachi.o: init_module: Device or resource busy
The card is installed in a standard 32 bit PCI slot.
Then, I configure the two GNIC-II boards with no problem to use a
dedicated fiber optic cable connection
TEST 1:
-------
I run ttcp to see the available throuput:
Client is 2.1.126 SMP: ttcp -t -s -n 16384 -f M hamachi2
ttcp-t: buflen=8192, nbuf=16384, align=16384/0, port=5001 tcp -> hamachi1
ttcp-t: socket
ttcp-t: connect
ttcp-t: 134217728 bytes in 4.36 real seconds = 29.35 MB/sec +++
ttcp-t: 16384 I/O calls, msec/call = 0.27, calls/sec = 3757.08
ttcp-t: 0.0user 1.3sys 0:04real 32% 0i+0d 0maxrss 0+2pf 0+0csw
Server is 2.0.35 SMP: ttcp -r -s -f M
ttcp-r: buflen=8192, nbuf=2048, align=16384/0, port=5001 tcp
ttcp-r: socket
ttcp-r: accept from 192.168.22.1
ttcp-r: 134217728 bytes in 4.37 real seconds = 29.32 MB/sec +++
ttcp-r: 23705 I/O calls, msec/call = 0.19, calls/sec = 5430.34
ttcp-r: 0.0user 0.8sys 0:04real 19% 0i+0d 0maxrss 0+2pf 0+0csw
The results are just great. But on 2.1.126 SMP, I get the following
kernel message:
Socket destroy delayed (r=0 w=160)
That doesn't seem good to me ... Any ideas ?
TEST 2:
-------
I run an ftp one way direction from 2.0.35 SMP computer to 2.1.126
SMP computer with a 120 MB binary file and I get the following
results:
ftp> get test2
local: test2 remote: test2
200 PORT command successful.
150 Opening BINARY mode data connection for test2 (120518880 bytes).
226 Transfer complete.
120518880 bytes received in 4.47 secs (2.6e+04 Kbytes/sec)
This sounds very very good. I also get the following kernel messages:
(I get a lot of NMI messages followed by a socket destroy delayed)
Uhhuh. NMI received for unknown reason 31.
Dazed and confused, but trying to continue
Do you have a strange power saving mode enabled?
Uhhuh. NMI received for unknown reason 21.
Dazed and confused, but trying to continue
Do you have a strange power saving mode enabled?
Socket destroy delayed (r=0 w=160)
Can the NMI problem be due to the 64 bit PCI slot ? Do Linux support
the 64 bit PCI slot on ix86 platforms ?
TEST 3:
-------
I run multiple ftps two way directions and I get the following results:
2.0.35 SMP:
ftp> local: test remote: test2
200 PORT command successful.
150 Opening BINARY mode data connection for test2 (120518880 bytes).
226 Transfer complete.
120518880 bytes received in 16.6 secs (7.1e+03 Kbytes/sec)
ftp> local: test remote: test2
200 PORT command successful.
150 Opening BINARY mode data connection for test2 (120518880 bytes).
226 Transfer complete.
120518880 bytes received in 16 secs (7.4e+03 Kbytes/sec)
ftp> local: test remote: test2
200 PORT command successful.
150 Opening BINARY mode data connection for test2 (120518880 bytes).
226 Transfer complete.
120518880 bytes received in 12 secs (9.8e+03 Kbytes/sec)
ftp> local: test remote: test2
200 PORT command successful.
150 Opening BINARY mode data connection for test2 (120518880 bytes).
226 Transfer complete.
120518880 bytes received in 15.3 secs (7.7e+03 Kbytes/sec)
2.1.126 SMP:
ftp> local: test remote: test2
200 PORT command successful.
150 Opening BINARY mode data connection for test2 (120518880 bytes).
226 Transfer complete.
120518880 bytes received in 10.4 secs (1.1e+04 Kbytes/sec)
ftp> local: test remote: test2
200 PORT command successful.
150 Opening BINARY mode data connection for test2 (120518880 bytes).
226 Transfer complete.
120518880 bytes received in 11 secs (1.1e+04 Kbytes/sec)
ftp> local: test remote: test2
200 PORT command successful.
150 Opening BINARY mode data connection for test2 (120518880 bytes).
226 Transfer complete.
120518880 bytes received in 9.33 secs (1.3e+04 Kbytes/sec)
ftp> local: test remote: test2
200 PORT command successful.
150 Opening BINARY mode data connection for test2 (120518880 bytes).
226 Transfer complete.
120518880 bytes received in 11.5 secs (1e+04 Kbytes/sec)
These results are very good too !!!
TEST 4:
-------
Our software runs just fine. But, when we run our software + ftp (I
put the boards under heavy load, I get:
eth2: Hamachi transmit timed out, status 00003803, resetting...
Rx ring 0ade9020: 0000d000 0000d000 0000d000 0000d000 0000d000 0000d000 0000d000 0000d000 0000d000 0000d000 0000d000 0000d000 0000d000 0000d000 0000d000 0000d000 0000d000 0000d000 0000d000 0000d000 0000d000 0000d000 0000d000 0000d000 0000d000 0000d000 0000d000 0000d000 0000d000 0000d000 0000d000 0000f000
Tx ring 0ade9120: 4000 4000 4000 4000 4000 4000 4000 4000 4000 4000 4000 4000 4000 4000 4000 6000
on both sides and the 2.1.126 SMP computer completly dies... It looks
like the same problem than David Skingsley <david.skingsley@bt-sys.bt.co.uk>
reported earlier in the mailing list.
Please, can you give us some feedback about this problem ? Or how to
investigate it and fix it ?
Thanks a lot for your good work and help !!!
Claude Lefrancois
Software Engineer
--
___________________________________ ______________________
| | |
| Claude Lefrancois | CCCC AAAA EEEEE |
| CAE Electronique Ltee | C C A A E |
| 8585 Cote-de-Liesse | C A A E |
| Saint-Laurent, Quebec, Canada | C AAAAAA EEEE |
| H4T 1G6 | C A A E |
| mail: lefranco@cae.ca | C C A A E |
| tel: (514) 341-2000 x3194 | CCCC A A EEEEE |
|___________________________________|______________________|
| To unsubscribe, send mail to Majordomo@cesdis.gsfc.nasa.gov, and within the
| body of the mail, include only the text:
| unsubscribe this-list-name youraddress@wherever.org
| You will be unsubscribed as speedily as possible.