Mail Archives: djgpp/1992/11/25/18:57:16
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
- Raw text -