From: greve AT rs1 DOT thch DOT uni-bonn DOT de (Thomas Greve)
Subject: HD Errors?
To: djgpp AT sun DOT soe DOT clarkson DOT edu
Date: Mon, 11 May 92 13:06:37 NFT
Status: O

Hello folx,

i have to revoke. (My special apologies to DJ.)

Some days ago i said, go32 with some HD intensive 32bit executable would
crash with some obscure DOS read error. 1.05 did. 1.06 doesn't any more.

A simple program initializing a 10MB array and reading it out afterwards
crashed go32 1.05 safely. (The error msg popped up some *minutes* after
disk activity ended. HD timeouts are long... Ah yes. DOS tried to read
several times until it gave up.)

I've tried an Erathostenes sieve of 10MB yesterday. After two and a half
hours of heavy paging, i stopped the experiment as passed.

Someone talked about wait states and reliability:
- if you have too little *memory* wait states, you will run into parity
  errors. (DJ: Does go32 fetch the NMI??) But you should run into
  problems when running real-mode-apps, too.
- if you have too little *IO* waits (or too high a bus clock), problems
  are different. With my Conner CP 3204, i had similar problems as the
  one described abv, but this happened with chkdsk as well as with go32.
  After i reduced bus clock to 11MHz, coretest told me a slightly lower
  transfer rate (still > 1MB/s, so what?), but the disk worked reliably
  then.  Especially it passed the 2.5 hour paging test :-) :-)
  (This disk had problems in a 20MHz '386 i have never solved. It was a
  function of bus clock, io waits and disk usage, but there was no
  configuration that made them vanish :-( As it works now, it probably
  was due to hardware. We all *love* ISA, don't we? ;-)
- Stacks: i've set them 0,0. DOS stacks are brain damaged anyway. And
  any program i know (including go32) has enough stack space to manage
  hardware IRQs. BTW: that's all what they are for. Nothing to do with
  multitasking.)
- Hyperdisk: it works. At least 4.21 on my machine ;-) But it makes disk
  access tighter and some AT bus drives seem to have problems with this.
- lost IRQs: the faster a machine is, the *less* IRQs should be lost!
  But my machine has a feature of 'background refresh' which causes my
  streamer (disk io intensive!) to produce parity errors. Maybe, there
  is too little refresh when running disk intensive programs? (This is
  wild guessing, though.) 

Ah, yes. My Hardware: 486 AT 33, ETEQ, 8MB, CP3204, ET4K, Qemm 5.11, 
Hyperdisk 4.21.

				- Thomas

   greve AT rs1 DOT thch DOT uni-bonn DOT de
   unt145 AT dbnrhrz1