cliffhanger@cup.portal.com (Cliff C Heyer) (10/02/89)
Colin Writes... >In their defense, they're handicapped by the MS-DOS file system, which is >pretty piss-poor. Hugh LaMaster Writes.. >But it is unfair to use today's controllers >to criticize systems shipped 1-2 years ago. Cliff Responds... I agree; these are good points. But my question was & is, was an honest effort made to build these systems 1-2 years as "state of the art"? And I have no way today to establish this before I buy. No manufacturer I have seen publishes meaningful information. The only PC I/O benchmarks published from which one can deduce I/O rate in KB/sec is BYTE. The sales people quote things like 15MHz ESDI, but then when you test their machine you get 300KB/sec. I don't think this happens by accident. I've been made to believe that I'm buying "the best" but when I do testing, or read UNIX REVIEW, BYTE or other benchmarks, I find I am not. >"I am buying the system from company Y. Even >though the CPU is only 10 MIPS instead of 20, it can stream data from 4 >controllers simultaneously at 2.5MB/sec. each, with negligible CPU overhead." BRAVO!!!!!!!! Greg Pavlov Writes... > We support a good-sized database application on one of these systems, in > spite of the limited "600KB/sec" transfer rate: that measure is not very mean- > ingful and inaccurate in any case. OK, I don't mean to say that 600KB/sec not useful. But look at it this way: You are paying a consultant $70/hour to write a special high performance hash index for a 250MB custom database. At 600KB/sec, lets say it takes him 10 seconds to perform a certain test, but a 1.3MB/sec it takes him 4 seconds. I've saved 6 seconds or $.114 . In weeks and months of testing in a R&D environment over many programmers, and it adds up. AND if I discover that I can buy different hardware for the SAME price that gives me the 1.3MB/sec, then I can save the money without spending any. BUT what if the sales guy tells me "we use 15MHz ESDI" and after I buy I find I only get 300KB/sec. Then I find out the truth from tech support - that "it just won't go any faster." Will I be happy? I don't know about other people, but to me each second wasted waiting for a computer is a second of my life gone forever. If a little shopping can save me this time, why not? Matt Kennel Writes... >This brings up a point: in what processing regimes does total >sustained disk transfer rate be the performance-limiting factor? This sounds like what one reads in the trade papers. When you are editing a book that has 10MB text and images on a machine with 16MB DRAM. I would rather have the file read into memory in 8 seconds than 50 seconds. I don't know about you, but I have better things to do with 42 seconds than wait. If you don't mind waiting, that is your choice. Each you time wait it adds up. In a week, you may find you waited 8 hours. >For a mini/single-user workstation configuration I'd think that the >average access time rather than sustained throughput would be most >important as most I/O transfers would be relatively small. >So, given equal access times, how much of a difference in >interactive workloads does a jump from say 500 KB/s (low end micro >but for the Rest Of Us, how much does it really matter? If your software does thousands of small accesses, the access time begins to overshadow the disk transfer time so much that the access time is the limiting factor. But that is not usually what happens. Usually you are starting a word processing program which may be 100KB. I would like to see it start instantly, rather than wait 2 seconds. Then when I edit my 450KB file, I would rather see it read into memory in .4 second rather than 3 seconds. I would like to do backup in .4 seconds rather than 3 seconds. I would rather be doing some productive work for those 3 seconds rather than wasting it waiting for the computer. And each of those 3 seconds adds up over the months and years to a surprising amount. Don_A_Corbitt Writes... >Buffer RLL KB/s RAMDrive KB/s >512 196 1245 >1024 336 2203 >2048 381 3206 >4096 387 5266 >8192 489 6526 >16384 567 7367 >32767 611 7856 >PS - in 1984 I wrote the firmware for a 3.5" floppy drive with performance >in mind - 1:1 interleave, track skewing, etc for the portable Tandy Model 100. >It ran faster than any desktop PC I could find to benchmark it against. And I >haven't noticed anyone making the effort to do the same since. So nobody cares >about Disk IO? Guess you are one of the few! The above shows how "unused" the AT bus really is. Most AT bus users don't know how a fast bus would speed up their work. All the manufacturers talk about is MIPS. A 1 MIPS DECsystem-20 supports 40 users. Why do we need 8 MIPS PCs? Let's try a 1 MIPS 80286 or 68000 chip with 1MB/sec DMA disk I/O and see how well that works. I think we'd find that disk I/O is more important the manufacturers are leading us to believe. Cliffhanger@cup.portal.com