3c590 vs. tulip

3c590 vs. tulip

[Dan Mann]

I was just wondering if anybody had an idea which nic card might be a better
choice for me; I have a pci 3c590 and a pci smc that uses the tulip driver.
I don't have the card number for the smc with me handy, however I know both
cards were manufactured in 1995.  Is either card/driver a better choice for
a mildly used file server (I am running 2.4.4 Linus)?


Question 2:

Also, I've got another linux box that is connecting to the server as a
client.  Machines are using samba to share files.  Both machines are running
Hybrid Debian 2.2 + unstable, with 2.4.4 Linus kernel. Server is a P75, 32MB
of ram, 1 8GB ide drive and the above mentioned smc nic with tulip driver.
Client is PII233, 196MB Ram, 1 6GB ide drive and another of the above
mentioned nic cards (smc, tulip).

The server has lots (ok, about 20,000 not counting the os itself) of medium
sized files on it, ranging in size from 60k to 40MB.  When I run gqview
(image viewing program) on the client and point to a local directory that is
mapped to the server using samba, the images (over 4000 in one directory)
are displayed absolutely as fast as I can click my mouse button.  No lag
time whatsoever.  How can this be so fast?  Even with the images on my local
faster machine it is much slower.  Images take at least .5 to 1 second to
load when they are stored locally.  But over the network, with 2.4.4 and
samba 2.2, It's as if the server "knows" what I'm going to ask for before I
actually do.  Is this normal?  I honestly don't think it was this fast when
server was on 2.2 Kernel with samba 2.07.

Maybe it is just me, but it seems much faster.

Dan

Re: 3c590 vs. tulip

[Andi Kleen]

On Fri, May 11, 2001 at 09:27:29AM -0400, Dan Mann wrote:
> I was just wondering if anybody had an idea which nic card might be a better
> choice for me; I have a pci 3c590 and a pci smc that uses the tulip driver.
> I don't have the card number for the smc with me handy, however I know both
> cards were manufactured in 1995.  Is either card/driver a better choice for
> a mildly used file server (I am running 2.4.4 Linus)?

As of 2.4.4 newer 3c90x (I guess you mean that, 3c59x should be mostly
extinct now) are a better choice because they support zero copy TX and 
hardware checksumming while tulip does not.

> faster machine it is much slower.  Images take at least .5 to 1 second to
> load when they are stored locally.  But over the network, with 2.4.4 and
> samba 2.2, It's as if the server "knows" what I'm going to ask for before I
> actually do.  Is this normal?  I honestly don't think it was this fast when
> server was on 2.2 Kernel with samba 2.07.

Sounds like a serious bug. Consider reporting it.

-Andi

Mystery speed: Was Re: 3c590 vs. tulip

[Dan Mann]

> Sounds like a serious bug. Consider reporting it.


I'll do some more concrete testing this weekend.  Don't get me wrong, if
computers can do what I want before even I know it, I'm happy :-)

Dan
----- Original Message -----
From: "Andi Kleen" <ak@suse.de>
To: "Dan Mann" <daniel_b_mann@hotmail.com>
Cc: <linux-kernel@vger.kernel.org>
Sent: Friday, May 11, 2001 9:56 AM
Subject: Re: 3c590 vs. tulip


>
> > faster machine it is much slower.  Images take at least .5 to 1 second
to
> > load when they are stored locally.  But over the network, with 2.4.4 and
> > samba 2.2, It's as if the server "knows" what I'm going to ask for
before I
> > actually do.  Is this normal?  I honestly don't think it was this fast
when
> > server was on 2.2 Kernel with samba 2.07.
>
> Sounds like a serious bug. Consider reporting it.
>
> -Andi

Re: 3c590 vs. tulip

[Pekka Pietikainen]

On Fri, May 11, 2001 at 03:56:41PM +0200, Andi Kleen wrote:
> On Fri, May 11, 2001 at 09:27:29AM -0400, Dan Mann wrote:
> > I was just wondering if anybody had an idea which nic card might be a better
> > choice for me; I have a pci 3c590 and a pci smc that uses the tulip driver.
> > I don't have the card number for the smc with me handy, however I know both
> > cards were manufactured in 1995.  Is either card/driver a better choice for
> > a mildly used file server (I am running 2.4.4 Linus)?
> 
> As of 2.4.4 newer 3c90x (I guess you mean that, 3c59x should be mostly
> extinct now) are a better choice because they support zero copy TX and 
> hardware checksumming while tulip does not.
>From what I remember, 3c590 was a horribly buggy card that sometimes
broke even in workstation use (possibly fixed by driver updates more
recently). 3c905B and later are fine, I'm not sure if the original
905 had any bad issues. The original ones definately won't do zero-copy.

The tulips from that era work pretty reliably. Some of the older ones
just won't do autonegotiation (I've seen this with an old 
SMC with both 10/100baseTX and 9-pin "for use with token ring cabling"
connectors). Forcing the link speed works just fine, though.

-- 
Pekka Pietikainen

Re: 3c590 vs. tulip

[Simon Kirby]

On Fri, May 11, 2001 at 09:27:29AM -0400, Dan Mann wrote:

> The server has lots (ok, about 20,000 not counting the os itself) of medium
> sized files on it, ranging in size from 60k to 40MB.  When I run gqview
> (image viewing program) on the client and point to a local directory that is
> mapped to the server using samba, the images (over 4000 in one directory)
> are displayed absolutely as fast as I can click my mouse button.  No lag
> time whatsoever.  How can this be so fast?  Even with the images on my local
> faster machine it is much slower.  Images take at least .5 to 1 second to
> load when they are stored locally.  But over the network, with 2.4.4 and
> samba 2.2, It's as if the server "knows" what I'm going to ask for before I
> actually do.  Is this normal?  I honestly don't think it was this fast when
> server was on 2.2 Kernel with samba 2.07.

Note that the newer gqviews preload the "next" image (next based on your
previous clicking direction).  If you are clicking sequentially and give
it enough time between images, it will immediately display the next image
when you click on it.

I don't see how even if it were any sort of caching bug or something that
gqview would be able to load them that much faster -- it still has to
decode them at one point or another.

Simon-

[  Stormix Technologies Inc.  ][  NetNation Communications Inc. ]
[       sim@stormix.com       ][       sim@netnation.com        ]
[ Opinions expressed are not necessarily those of my employers. ]

Re: 3c590 vs. tulip

[root]

Andi Kleen (ak@suse.de) wrote
>
>On Fri, May 11, 2001 at 09:27:29AM -0400, Dan Mann wrote: 
>> I was just wondering if anybody had an idea which nic card might be a better 
>> choice for me; I have a pci 3c590 and a pci smc that uses the tulip driver. 
>> I don't have the card number for the smc with me handy, however I know both 
>> cards were manufactured in 1995. Is either card/driver a better choice for 
>> a mildly used file server (I am running 2.4.4 Linus)? 
>
>As of 2.4.4 newer 3c90x (I guess you mean that, 3c59x should be mostly 
>extinct now) are a better choice because they support zero copy TX and 
>hardware checksumming while tulip does not. 

On http://www.scyld.com/expert/100mbps.html
Venerable Don Becker wrote:

> 
> DEC "Tulip" 21140/21142/21143 
>     Bus master, with same clean and fast packet interface of the 10Mbs
>     21040, but a with different serial subsubsystem. It's used on the SMC
>     PCI EtherPower and most other 100Mbs cards.
>     A limitation of the current chips is that packets may only be received
>     into long-aligned buffers, which results in the IP header being
>     misaligned. For some word-oriented architectures, such as Digital's
>     own Alpha, this results in pointless copying. Programming info: The
>     datasheet is readily available online or from DEC.
>     Driver: I've written a Linux device driver that works with most
>     Tulip-based adapter. 
>     Multicast support: The DEC Tulip chip has the best design of the
>     commodity chips. Its reception filter has several modes. In addition to
>     the common hardware multicast hash filter mode (with 512 entries,
>     rather than the common 64 entries), it has a mode where it can
>     accept any of 16 specific addresses, either multicast or physical. 
>     Large packet support: The tulip chips can be configured to extend
>     the normal Tx jabber clock from 1.6-2.0 msec. (2048 to 2560
>     transmitted octets) to 26-33 msec. Similarly, the "Rx watchdog"
>     timer can be disabled so that any length packet may be received.
>     (Untested.)
> 3Com Vortex 
>     Uses primarily a programmed-I/O interface similar to the 3c509, but
>     has a limited bus master capability. The chip is used only on the
>     3c595 board.
>     Programming info: The programming manual is readily available
>     from 3Com. 
>     Driver: I've written a Linux device driver for the 3c590 and 3c595. 
>     Large packet support: The Vortex chips can be explicitly
>     configured to support 4.5K (FDDI-sized) packets. 
>     Multicast support: The 3Com Vortex chips, like the rest of the
>     EtherLink III series, have no hardware multicast filter. Multicast
>     reception is enabled by a "receive all multicast packets" bit.
> 3Com Boomerang 
>     An update to the 3Com Vortex, this chip primarily uses a full
>     descriptor-based bus-master interface, similar to the AMD, Tulip
>     and Speedo3 chips. The programmed-I/O interface of the Vortex is
>     currently retained, but is scheduled to be deleted in future chip
>     revisions. This chip is used only on the 3Com EtherLink III XL
>     boards, the 3c900 series.
>     Programming info: The programming manual will soon be available
>     from 3Com. 
>     Driver: I've enhanced the Linux Vortex device driver to use this
>     chip in PIO mode. A new driver supporting the full-bus-master
>     mode is in progress. 
>     Large packet support: Like the Vortex chip, the Boomerang can be
>     explicitly configured to support 4.5K (FDDI-sized) packets. 
>     Multicast support: This chip, like the rest of the EtherLink III
>     series, have no hardware multicast filter. Multicast reception is
>     enabled by a "receive all multicast packets" bit.
> Intel Speedo-3 i82557/i82558 
>     The chip has an interface similar to the other Intel network chips,
>     with a direct PCI interface and the "SCB" implemented as registers
>     visible in I/O and memory space. The chip is used on the Intel
>     EtherExpress/Pro100B and 100+ boards, several OEM boards, and a
>     custom board from Allied Telesyn.
>     The i82558 chip integrates a i82555 transceiver, adds flow control,
>     has improved firmware, and adds power
>     management/wake-up-packet control. Programming info:
>     Technical details are very difficult to obtain, and usually requires
>     signing a NDA with Intel. 
>     Driver: I've written a Linux device driver for the i82557 that
>     demonstrates one way to use the Speedo-3. 
>     Large packet support: Unknown. 
>     Multicast support: The Intel EtherExpress PCI Pro 100B has a
>     hardware multicast filter, but it illustrates characteristic Intel
>     quirkiness and difficulty of use. A set-multicast-list command is
>     queued on the Tx packet queue. The chip processes the list of
>     multicast addresses to accept, and fills in an internal hash table.
>     During the (presumably short) period that the set-multicast-list
>     command is being processed, no packets are received(!). 

Basically, it appears that Don Becker praised the Tulip chipset the most.  
How much important is "zero copy TX and hardware checksumming"?

Best regards,

Hugh

ghsong at kjist dot ac dot kr

Re: 3c590 vs. tulip

[Andi Kleen]

On Mon, May 14, 2001 at 05:09:52PM +0900, root wrote:
> Basically, it appears that Don Becker praised the Tulip chipset the most.  
> How much important is "zero copy TX and hardware checksumming"?

Zero copy TX is not that important yet except if you use samba or Tux or
proftpd or anything else that uses sendfile, but RX hardware checksumming 
is important as it saves a lot of CPU during receiving big packets. 
2.4 can in some circumstances do the checksumming during a copy (see 
netstat -s TCPHPHitsToUser), but hardware checksum is still preferable.
2.2 benefits from it more. 

The document seems to be rather outdated BTW, even boomerang is an 
old 3com chipset. Please not that the 4byte receive restriction on Tulip
also hurts i386. 

-Andi