Path: grendel.demon.co.uk!jes
From: jes AT grendel DOT demon DOT co DOT uk@grendel.demon.co.uk (Jim Segrave)
Subject: Re: slow floppy performance
Reply-To: jes AT grendel DOT demon DOT co DOT uk
To: djgpp AT sun DOT soe DOT clarkson DOT edu
Date: Wed, 25 Nov 92 21:58:10  GMT
Organization: None
Lines: 37

In article <9211241822 DOT AA16187 AT tristan DOT TN DOT CORNELL DOT EDU> you write:
> So I measured the floppy perfomance again (using K&R's version of cp,
> if you care, copying from floppy to a ram drive) and found out that
> my cp was still half the speed of dos's copy. since cp uses read and
> write (not fread and fwrite) I went directly to the source for 
> read (read.s) and found out two interesting things:
> 
> Q3) the magic number 4096 appears in there. why? I know 4096 is several
> 	sectors and is therefore a good number to use for a buffer size,
> 	but why is it hard coded in read.s?

Probably because that's the virtual memory paging size? Remeber go32 has
to copy disc data from a buffer in real (below 1M) ram to buffers which
are in virtual memory and may have any physical address. Hard with
MFM/IDE controllers which do programmed I/O, really hard with SCSI
controllers which use DMA.


> Q4) read boils down to an int 21 call. My understanding of int 21 calls
> 	is that they are robust and reliable (across different versions
> 	of DOS and different devices.) by they are slow. So is there
> 	a way we can speed this up?

Any attempt to go below Int 21 will break DOS file systems, networks,
etc. Not recommended at all. I don't think any DOS programs, including
copy try to get below the Int 21 level. If they do, they shouldn't.
Consider a Novell network which, I believe, traps Int 21 calls and
redirects them, including the file access (read and write) calls. 
> phew! Excuse spelling/grammer errors, etc.
> Please let me know if any of the inferences I made were incorrect.
> 
> 
> 							-Mohammad
> 
--
Jim Segrave (Segrave Software Services)     jes AT grendel DOT demon DOT co DOT uk