EtherExpressPro & linux-2.2.14

DuWayne drh at niptron.com
Thu Jan 25 07:40:43 PST 2001


As we use it in a non-bonded way I was unaware of the issues
you stated. I would love to see a fixed standard driver. From
what Ive seen. Its an intermittent and hardware dependent
problem. Ive seen cards flake out, just to fix itself on the next
reboot. And some cards never show these symptoms at all.
So Im guessing it has something to do with a timing or race
condition in the eepro100 driver. I also remember seeing something
on it in a post somewhere. But I forgot what or where that was.

Steffen Persvold wrote:

> The only thing that isn't too good with the Intel driver from their
> website is that it's not good at channel bonding (which might interrest
> you beowulfers) !
>
> I've performed benchmarks with Netpipe and it shows that the e100 driver
> may perform as well as the eepro100 driver in single mode, but if I
> 'bond' two of them together the eepro100 is by far better. The results I
> get a peak performance of only 55 Mbit/sec (!?!) with the e100 driver,
> while the eepro100 reach 179 Mbit/sec. The tests were run with two
> identical Serverworks 370DER motherboards using the two onboard network
> controllers. The nodes was connected to a Intel 460T switch. The kernel
> I was using was a patched up 2.2.16 kernel (the bonding driver from
> 2.2.18)
>
> Some of the output from NPtcp:
> eepro100:
>    # ./NPtcp -t -h 192.168.1.4 -l 131072 -u 4194307 -P
>    Latency: 0.000068
>    Now starting main loop
>      0:    131069 bytes    7 times -->  172.14 Mbps in 0.005809 sec
>      1:    131072 bytes   21 times -->  172.20 Mbps in 0.005807 sec
>      2:    131075 bytes   21 times -->  172.18 Mbps in 0.005808 sec
>      3:    196605 bytes   21 times -->  174.33 Mbps in 0.008604 sec
>      4:    196608 bytes   19 times -->  174.32 Mbps in 0.008605 sec
>      5:    196611 bytes   19 times -->  174.31 Mbps in 0.008606 sec
>      6:    262141 bytes   19 times -->  175.33 Mbps in 0.011407 sec
>      7:    262144 bytes   16 times -->  175.36 Mbps in 0.011405 sec
>      8:    262147 bytes   16 times -->  175.36 Mbps in 0.011406 sec
>      9:    327677 bytes   10 times -->  176.42 Mbps in 0.014171 sec
>     10:    327680 bytes   10 times -->  176.43 Mbps in 0.014170 sec
>     11:    327683 bytes   10 times -->  176.42 Mbps in 0.014171 sec
>     12:    458749 bytes   10 times -->  177.17 Mbps in 0.019755 sec
>     13:    458752 bytes    9 times -->  177.18 Mbps in 0.019754 sec
>     14:    458755 bytes    9 times -->  177.18 Mbps in 0.019755 sec
>     15:    589821 bytes    7 times -->  177.74 Mbps in 0.025318 sec
>     16:    589824 bytes    7 times -->  177.74 Mbps in 0.025318 sec
>     17:    589827 bytes    7 times -->  177.70 Mbps in 0.025323 sec
> .............
>
> e100:
>    # ./NPtcp -t -h 192.168.1.4 -l 131072 -u 4194307 -P -o e100_bond.txt
>    Latency: 0.000072
>    Now starting main loop
>      0:    131069 bytes    7 times -->   54.29 Mbps in 0.018421 sec
>      1:    131072 bytes    7 times -->   52.13 Mbps in 0.019184 sec
>      2:    131075 bytes    7 times -->   52.51 Mbps in 0.019046 sec
>      3:    196605 bytes    7 times -->   52.31 Mbps in 0.028677 sec
>      4:    196608 bytes    7 times -->   51.44 Mbps in 0.029160 sec
>      5:    196611 bytes    7 times -->   51.97 Mbps in 0.028864 sec
>      6:    262141 bytes    7 times -->   51.48 Mbps in 0.038849 sec
>      7:    262144 bytes    7 times -->   52.08 Mbps in 0.038402 sec
>      8:    262147 bytes    7 times -->   52.21 Mbps in 0.038309 sec
>      9:    327677 bytes    7 times -->   51.01 Mbps in 0.049014 sec
>     10:    327680 bytes    7 times -->   51.62 Mbps in 0.048434 sec
>     11:    327683 bytes    7 times -->   51.19 Mbps in 0.048837 sec
>     12:    458749 bytes    7 times -->   51.36 Mbps in 0.068148 sec
>     13:    458752 bytes    7 times -->   51.26 Mbps in 0.068283 sec
>     14:    458755 bytes    7 times -->   51.21 Mbps in 0.068343 sec
>     15:    589821 bytes    7 times -->   51.18 Mbps in 0.087923 sec
>     16:    589824 bytes    7 times -->   50.52 Mbps in 0.089071 sec
>     17:    589827 bytes    7 times -->   50.78 Mbps in 0.088620 sec
>
> The performance problems with the e100 driver seems to be related to the
> receiver; if I use NetPipe in streaming mode (not ping-pong) and use the
> e100 driver on the sender and the eepro100 on the receiver performance
> is almost back to what it should be.
>
> Conclusion : I think the more permanent solution for everyone using
> these adapters must be to see if we can by any chance improve the
> stability of the eepro100.
>
> Best regards,
> --
>  Steffen Persvold                        Systems Engineer
>  Email  : mailto:sp at scali.com            Scali AS (http://www.scali.com)
>  Norway : Tlf  : (+47) 2262 8950         Olaf Helsets vei 6
>           Fax  : (+47) 2262 8951         N-0621 Oslo, Norway
>
>  USA    : Tlf  : (+1) 713 706 0544 (43)  Scali
>                                          10500 Richmond Avenue, Suite
> 190
>                                          Houston, Texas 77042, USA
>
> DuWayne wrote:
> >
> > We had the same problems with the eepro100 diver. We ended up switching to
> > Intels driver. Its available from their web site. Cured all the issues we were
> > having
> > with the eepro100 driver.
> >
> > Rob Nelson wrote:
> >
> > > >2.2.15 had a much-revised eepro100 driver.
> > > >
> > > >I am hopeful that using, say, 2.2.18 will cure your problem.
> > >
> > > FWIW, and I don't really have anything but anecdotal evidence to support
> > > this, as the web page at sco.com seems to have disappeared, but replacing
> > > eepro100's seems to be the only fix. Take a look at the 2.2.x changelogs.
> > > eepro100 drivers have had fatal bugs found in the chipsets multiple times,
> > > just in 2.2.x. Our NT, SCO, linux, and even Novell servers almost always
> > > have a new eepro driver in whatever upgrade they get. We've finally switched
> > > to 3com's in servers due to frustration with Intel at building a quality
> > > chipset.
> > >
> > > Sco used to have a good page detailing the problem. Basically, something on
> > > the PCI card that controlled input and output overflowed its onboard 8k ram
> > > chip or whatever sort of memory it had, which then killed its internal
> > > stack. Power-cycling was the only way to flush it. The bug has been squashed
> > > multiple times, only to rear its head in some new form later. If you keep
> > > going with eepro's, good luck. I heartily recommend 3c905-b's or -c's.
> > >
> > > Rob Nelson
> > > ronelson at vt.edu
> > >
> > > _______________________________________________
> > > Beowulf mailing list
> > > Beowulf at beowulf.org
> > > http://www.beowulf.org/mailman/listinfo/beowulf
> >
> > _______________________________________________
> > Beowulf mailing list
> > Beowulf at beowulf.org
> > http://www.beowulf.org/mailman/listinfo/beowulf
>
> _______________________________________________
> Beowulf mailing list
> Beowulf at beowulf.org
> http://www.beowulf.org/mailman/listinfo/beowulf





More information about the Beowulf mailing list