Mail Archives: djgpp/1992/05/11/08:08:07
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
- Raw text -