Mylex SCSI controller

[Cliff C Heyer]

bill davidsen writes...
>A) typical ESDI drives (looking a a recent spec sheet) turn 3600 rpm,
>have 32 sectors of 512 bytes. 32*512*60/1024 = 960kb max from ESDI, no
>allowance for latency, step time, etc.

Exactly. So I'm p***ed off that this is quoted in (MSDOS)sales literature, but
when you actually try a simple 10MB contig. disk to disk copy on an EMPTY 
300MB disk under DOS you end up getting 200-300KB/sec on "most"
machines.

>B) I measured the ballpark i/o of several machines by doing a dd of the
>raw device to /dev/null. Crude, but it shows about 600kb for my ESDI
>system
dido.

> From this set of reasonably useful numbers I would suggest that you
>could look for a less demanding solution in any of the following areas:
>is your application really transfer rate bound? 

When I'm copying a 120MB file and I have to wait 10 minutes instead of
2 minutes, I'm I/O bound for 8 minutes. And when you consider that I
was quoted 1.2MB/sec for ESDI and am only getting 200KB/sec I think
reason to be angry! (why should it be up to me to tune the machine
to get the "quoted" speed?)

>Do the figures you
>quoted for other machines reflect actual performance, benchmark
>performance, or hardware limits? 

Evidently it's not actual performance OR benchmark performance,
must be hardware "chip specification" (MSDOS)

>Are you asking for something which isn't being marketed?

Your figures show it IS sold because you have it...

>The only thing you implied with which I disagree is the implication
>that people will grow out of 386 type systems in the i/o end. 

People start with a 50MB database & 1 user, and in two years 
it becomes 500MB and 10 users, in three years 900MB, etc. 
If this is not growing out of a 386 system, what is?

>Cliff Heyer said previously...
>>The VAX ranges from 600KB/sec to 1.3MB/sec tops sustained I/O *per job*. Many
>>PCs I tested got in the range of 200KB/sec (ST-506 ...). Then I found to my
>>surprise that SCSI & ESDI disks on many machines was still 200-300KB/sec!  
>>This was confirmed by checking BYTE benchmarks that list 1MB throughput times.
>>SUN was the only machine in BYTE that showed a respectable 800KB/sec time.
Karl Denninger responded...
>Huh?  1.3MB/second per job, eh?
>With what interface?  And to how many jobs?  We install, service, upgrade
>and work on VAX systems all the time, and I've >never< seen one which can
>sustain 1.3MB/sec (bytes now, not bits) across more than one or two jobs!
>The typical 3xxx (or MVII) series machine with 
>ESDI or SCSI interfaces and a couple of drives?  No way!

I'm talking about one job only, such as a VAXstation 3xxx (KS650 CPU) with
a Dilog DQ246 (SMD-E)& CDC EMD 9720-750. Also get the same results
with the new SCSI Q-bus adaptor CQD-220/M & Imprimis Sabre. (all >80blk
contig. transfers single user) OK, we don't use this all the time, but if I can
spend the same amount of money for hardware that does this, why not?

Cliff wrote...
>>It has become evident to me that in spite of 15MHz ESDI chips, sync SCSI, etc.
>>certain machines still go as slow as their ST-506 counterparts. Also, unlike
>>the old mainframe days when computer were rated in actual disk I/O in KB/sec, 
>>todays micros are sold with NO ratings, except the "chip throughput" ratings
>>which are meaningless because they do not show what the actual throughput
>>is.
Karl responded...
>I don't know where you're coming from, or where you get your hardware, but
>there is no way that I can agree with this.
Cliff responds...
Have you ever benchmarked (MSDOS)386 CPUs and compared ESDI/SCSI with ST-506?
If you had, there is no way you could say this. My guess is that less than 10%
of the DOS hardware out there will give you 900KB/sec, and the rest (mail order
houses, etc.) runs the same speed as ST-506 even though the sales literature
says otherwise. I intend to study this (my degree is in hardware engineering
even though I ended up in software) to find out what they are doing.

>Every one of our RLL-based machines can do in the area of 700KB/sec raw I/O.
>Every one of our ESDI-based machines can do in the area of 900KB/sec.  What
>is lost in the OS is another story, but that's something we don't have
>control over!
>No, you can't do this with cheap and slow hardware.  You certainly CAN with
>fast and a little more expensive components.

Well I was talking about MSDOS, I know UNIX has much more overhead. I wouldn't
expect to get 900KB/sec with UNIX. Perhaps the PC-compatible makers are using
their own drivers(or something else) that ends up being slower than other machines,
or some other lower cost stuff.

>Why not buy from someone who does bother to check these things, and can tell
>you exactly what you're getting?

Good point. I guess my beef is the false advertising. Good article about this recently
in Sept. 89 MIPS P. 99 col. 1, where they compare to the 60's hifi days. The "real"
specs are all hidden and nobody knows what they are getting until after they buy
and open the cover, look at the chip numbers (if they haven't been defaced) and look
them up. 

kEITHe writes...
>Anyway, using CORE27 to test an Everex STEP/25, a WD 7000ASC and a
>CDC WREN IV (? 300 Mbytes) I got 1.04 Mbytes/sec.  That was some
>time ago, however, and I've abandon that configuration.
>
>Using CORE27 on the Intel 301, Adaptec 1542A and CDC combination I
>get 1.4+ Megabytes per second reported.  This is with no caching 
program loaded.

Cliff Responds...
OK here's someone who knows what I am talking about! BUT the INTEL 301
is big bucks right? I seem to remember that intel boards are much more
expensive (=faster DRAM etc). (comments please!)


Well back to Mylex DC376. 13MB/sec.........I have a feeling that this is with
the 4MB cache loaded and streaming out contig... How about the "raw" rate
from disk assuming what you want is not in the cache? Also, I assume this
controller is "smart" in that while it's transferring the 4th MB, it's loading
the first 3 MB with the next read it thinks you'll want so when it's at the
end of the 4th MB it will seamlessly start at the 5th.

Also, what is the AT-32? Is this their own design or is it a logical extension
of the AT bus?