From: viking@iastate.edu (Dan Sorenson)
Subject: Re: server crash
Organization: Iowa State University, Ames IA
Date: Tue, 26 Jan 1993 05:51:56 GMT

In <C1F0AJ.2p7@wm.estec.esa.nl> Dave Stafford writes:

> domet@ucbeh.san.uc.edu writes:
>>Ethernet vs. Token Ring
>>
>>I used to be decided on it. BUT I found out through our Marketing research
>> that there is going to be many many more records in our database than we 
>>first imagined. A Network designer (a friend, not a sales person) told me 
>>that with a database of the magnitude that this one is, that Ethernt tends 
>>to slow down a little and that it may be wise to consider a ring topology
>> since it usually stays at a constant rate of transmission.

	I generally process a few hundred megabytes of database files
(FoxPro/LAN 2.0 on a 3.11 net, 10baseT ethernet with AT&T adaptors to
go to thinwire or thickwire as necessary) on a daily basis.  Figure eight
machines doing record-by-record transactions (though appending and deleting
records actually affect the whole database) and four others doing work using
the entire file (average a field, for example).  The bottleneck is in the
machine, not ethernet.  Figure a 486/33 as necessary to make a 10Mbits/sec
ethernet connection the slow part.  Strangely enough, a 2.15c server was
quite speedy when I had a 486/50 on my desk and a 386/25 as the server.
When it was reversed and we upgraded to Netware 3.11, the 386/25 was
unable to work the 486/50 server.  Even a DOS Xcopy, usually guarenteed to
bring the 2.15 server to its knees, only added a few percentage points of
utilization to the 486/50 server.  Ethernet wasn't the bottleneck in either
situation, but rather the speed of the machines in question.  Check MIT or
Iowa State -- their Ethernet backbone is supporting hundreds of DECstations
running Xwindows with file servers located all over campus, attached via an
Ethernet backbone.  It's working.  (BTW: it's called Project Athena at MIT,
and Project Vincent at ISU.  Your situation may be different, but I think
this shows that Ethernet isn't generally a slow medium.)

>>QUESTION 1: Is this something to consider with a database having up to 
>>            10,000 records (available to be) accessed daily and
>>            up to 50,000 total?

	No.  At the risk of sounding snobbish, I exceed that number of
records in a couple hundred database files within a month.  While the
database package you're using is certainly a great factor, ethernet
has not shown itself to be worked overly hard in any common transaction
that would be done in my case.

>>QUESTION 2: I need to know the major differences between the two.
>>            PHYSICAL and LOGICAL differences.

>As to question 2, well briefly ethernet is a BUS network, ie. all points
>connect to all other points off the same cable. Packets are fired off
>by stations, and seen by all others simultaneously (well nearly). You
>check the address, and if it's not for you, drop the packet.

>Token ring depends on the stations being connected in a logical ring 
>(although wiring can be either ring or star) and packets are passed
>to each station in turn and examined. If it's not for you, pass the 
>packet on to the next station.

	I've wondered about this: on my ethernet LAN, if a machine
goes down for some reason I can simply unplug it and start tearing
it apart.  No other machine is affected.  Is that the case with
Token Ring?  If not, this might be a worthwhile thing to consider,
especially if you'll have several clones or the like to support and
limited time to fix them.  It's rather nice to be able to unplug a
machine over the lunch hour, swap in a new card or two, and place it
back on-line without affecting the other jobs that are going on.

	Just my $0.02 -- I'm not any sort of guru, just the guy who
got stuck with keeping things running.

< Dan Sorenson, DoD #1066 z1dan@exnet.iastate.edu viking@iastate.edu >
<  ISU only censors what I read, not what I say.  Don't blame them.  >
<     USENET: Post to exotic, distant machines.  Meet exciting,      >
<                 unusual people.  And flame them.                   >