Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!uunet!dino!uxc.cso.uiuc.edu!uxc.cso.uiuc.edu!ux1.cso.uiuc.edu!uxe.cso.uiuc.edu!mcdonald
From: mcdonald@uxe.cso.uiuc.edu
Newsgroups: comp.arch
Subject: Re: PC vs. mainframe I/O (Re: SCSI on s
Message-ID: <46500077@uxe.cso.uiuc.edu>
Date: 17 Sep 89 23:01:24 GMT
References: <21962@cup.portal.com>
Lines: 34
Nf-ID: #R:cup.portal.com:21962:uxe.cso.uiuc.edu:46500077:000:1326
Nf-From: uxe.cso.uiuc.edu!mcdonald    Sep 16 19:14:00 1989



>Many 386 PCs give values of about only 200KB/sec which is not
>a "SCREAM" unless you compare to the PC XT or something (which
>is what manufacturers do to mislead you.)  This is with SCSI too!!! 


>Perhaps you could try this file copy on your machine and see
>what you get? I have heard of a few machines other than SUN that
>can do 750KB/sec. Use MSDOS to do this so there is no program
>overhead. If you only have one disk, you can copy to the NULL
>device(in which case don't divide B by 2).

I tried it on my Dell 310 with 150 meg disk.

Reading a 3 megabyte file (copying to a 8192*7 byte buffer) 
and doing nothing to the results resulted in 570 kByte/second.

Copying the file from one disk to a different part of the same disk
gave 440 kByte/second (after the divide by two).

This is not stupendous, but then again is by no means 200kByte/second.

This was using pure DOS calls, contiguous files, written
using interrupt calls in C (not the C library). However, the
actual copy made fearsome chuggings of the disk head, 
probably due to the necessity to update the FAT. It was not 
as bad as the vendor-supplied disk test program, though.

Oh yes, I am using a 160 kbyte disk cache (Microsoft Smartdrive).
Obviously, this cache cannot contain the whole 3 meg file! 
(What it does is buffer tracks).

Doug McDonald