[Top] [All Lists]

Re: 3081+3730 worth it?

To: riscy@pyramid.com
Subject: Re: 3081+3730 worth it?
From: Drew Eckhardt <drew@ophelia.cs.Colorado.EDU>
Date: Thu, 15 Jul 1993 18:27:27 -0600
In-reply-to: Your message of "Thu, 15 Jul 1993 18:56:56 CDT." <9307152257.AA01120@gossip.pyramid.com>
Reply-to: riscy@pyramid.com
Sender: owner-riscy@pyramid.com
    How hard would it to replace a subset of the functionality of the 3730???
    Seems like the 3730 is expensive and does more then we need and limited in 
    other areas (simms).  How about moving floppy+IDE+2 serial ports+parallel+g
    to ISA for $25 or with 16550's for $45.  

Serial ports without the FIFO buffers are worthless under *nix due to 
the dropped characters, so you're talking $45 on the ISA bus.  The 
FDC37c665 chip that does this (4M FDC, IDE, 2 16550's + parallel + 
game) was originally quoted at $23, a more recent number is $21.45 
canadian or $17.80 US.  That allows a lot of room for connectors
and the RS232 drivers until we're on a par with the ISA bus. 

    How about if we delete video?(GASP I think that a lot of us don't 

I want the fastest interactive system I can get for a reasonable
price.  So, I'm better off with a 486-66 and local bus video 
than I am with a MIPS4400 and ISA S3 board.  I'm sure that a lot
of other people share these goals.
    I'd think that for X11 stuff an s3-928 ($250) on ISA (5 MB/sec) would be 
    faster and take less cpu then the dumb frame buffer ($100+) solution curren
    being considered.  
    State of the art x-terminals work on 1.25 MB/sec couldn 't 
    an accelerated video card do well on ISA at 4 times the speed?  

I disagree.

Unless you can put the entire Xserver on the ISA graphics board,
it's not a fair comparison.  With the S3 board, you're still
moving fonts across the ISA bus everytime you bitblt a character
since the S3 board doesn't have enough memory to cache them, with
your cheap S3 board it's using DRAM so the blitter hardware, etc.
must share bandwidth with the video serializers at 45-90M/sec
(we don't have this problem with VRAM), the X terminal has a lot 
more intelligence (ie, 40Mhz R3000) and breathing room (8M of 
memory + VRAM vs. 1M total) to accelerate things.

The S3 board may relieve some of the burden of the CPU, but on a
single user workstation, I'm interested in total interactive 
performance, so I don't care if my GCC build in the background
slows down.
    Of course i f 
    you couldn't afford an S3-928 ($250) you could get a lesser card. 

Motherboard solution, using VRAM (assuming we get VRAM control signals 
off of the MOM chip, 3700, etc) 

2 Mac-compatible 512K VRAM SIMMS  $30/ea
1 TI tlc34076 RAMDAC              $32/ea
1 NSC LM1882 Video sync generator  $8/ea

Total : $100.  Much better than $250 for an S3 board. Not much worse than
        a Tseng ET4000 (max transfer rate 6M/sec) and cheaper than a 
        local bus board of any sort.
    72 pin simms while more expensive would need 4 times less sockets, 

If you shop arround 36 bit wide SIMMs are about the same price as 9 bit
wide SIMMs, ie ~$25 a megabyte.
    and 4 ti mes less simms to interleave.  2 8MB simms that allow interleaved 
    access are mu ch more attractive then 8 1MB sims, 8 4MB sims, or 
    4 non-interleaved 4MB x 9's
    I think once board space and simm sockets are taken into account the price 
    increase would be marginal.

Agreed.  I think that the 72 pin SIMMs are probably the route to go because
of realestate and the flexibility it gives us in interleaved memory 
configurations. Some people are arguing for 9 bit wide SIMMs because you 
have to replace less when a failure occurs - but I've never seen a memory
failure where a good chip went bad, on the 50 Unix workstations I administer
(some over 5 years old), on our VAX11/785, my PC, etc.

(On PC's, I've seen instances where new chips at a given speed don't 
work at the motherboard manufacturers' recommended number of wait 
states for that speed, but I attribute this to the marginal tollerances 
allowed for in PC design where it works if it all breaks the right way,
and haven't seen any problems using chips a speed faster (ie, 70ns 
instead of 80) than that recommended) 
    Considering that the memory efficient linux+80486 easily needs 16 Mb to run
    X11 while compiling without swapping, 64 MB or greater max would be nice.

Without paging *PERIOD*.  In 8M of memory, startup code will get paged 
out. With the addition of the fully unified buffercache in .99.10, with 
8M of memory and a kernel configured for my system my load average stays over 
1 during builds under X and the drive blips once every few seconds so I'm 
not thrashing.

Double that should be comfortable on a RISC.

    The combination of a fast cpu (40 Mhz mips) with the larger risc code 
    size plus linux+x11 (low locality) seems like the 24k 3081 cache would 
    be a bottle neck for the system, I think that 256k or more of cache could 
    make a big difference.

1.  That's separate I/D caches, so locality is maintained better.

2.  We have interleaved memory, which minimizes the cost of a cache miss.

3.  Our goal is "reasonable performance at a reasonable price", where
        reasonable performance in a workstation generally implies interactive
        performance.  This means what the system feels like to the user, 
        ie video, disk, etc.  So, I'd rather have onboard video than a second
        level cache.

    Someone posted a R4000 at 50 Mhz with 16k cache was up to twice as slow as
    a 33 Mhz mips 3000 with 64 k cache.

Caching : as you add more cache, you have diminishing returns.  Some one 
needs to look at the cache hit/miss rates and decide (for our purposes)
where more cache does more harm (price) than good (performance).


<Prev in Thread] Current Thread [Next in Thread>