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
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?
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
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
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
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).