Return to BSD News archive
Xref: sserve comp.os.os2.programmer:13304 comp.os.linux:52896 comp.os.mach:3164 comp.os.minix:22548 comp.periphs:4104 comp.unix.bsd:12405 comp.unix.pc-clone.32bit:4040 comp.os.386bsd.development:1047
Newsgroups: comp.os.os2.programmer,comp.os.linux,comp.os.mach,comp.os.minix,comp.periphs,comp.unix.bsd,comp.unix.pc-clone.32bit,comp.os.386bsd.development
Path: sserve!newshost.anu.edu.au!munnari.oz.au!news.Hawaii.Edu!ames!agate!howland.reston.ans.net!wupost!csus.edu!netcom.com!jmonroy
From: jmonroy@netcom.com (Jesus Monroy Jr)
Subject: More annoyance on the DMA problem
Message-ID: <jmonroyCBoq14.Kz0@netcom.com>
Keywords: DMA i8237 8254
Organization: NETCOM On-line Communication Services (408 241-9760 guest)
Date: Fri, 13 Aug 1993 06:29:27 GMT
Lines: 136
More annoyance on the problem with the DMA/RAM refresh
------------------------------------------------------
Some facts from:
"IBM Personal Computer Troubleshooting and & Repair
for the IBM PC, PC/XT, and PC AT"
by Robert C. Benner
p.51 Refresh begins when the OUT1 signal from the
8254, programmable interval timer (U34),
sends a DMA request signal (DRQ0) to the
DMA controller (U35).
p.106 DMA RAM refresh occurs on timer channel 1
66,287 time per second causing a Refresh
signal every 15 microseconds.
p.111 Each DMA request line is an individual asynchronous
channel input used by the peripheral circuitry to
obtain DMA service.
p.121 Refresh is accomplished by performing a memory-access
cycle at each of the row addresses within a bank of
RAM every two to four milliseconds.
(1000 microseconds in a millisecond.)
The new FDC driver is reading a 1.44 meg diskette in
about 1 minute 30 seconds. There are 2880 sectors on
a diskette of this size. 2880 divided by 90 seconds
is 302 sectors per second. 66,287 divided by 302
is approx. 219.5 refreshs per sector transfer.
The lower harmonics for 66,287 are
index refreshes in time period (fraction of sec.)
1. 33,143 +-1 .5
2. 16,571 +-1 .25
3. 8,281 +-1 .125
4. 4,140 +-1 .0625
5. 2,070 +-1 .03125
6. 1,035 .015625
7. 517 +-1 .0078125
8. 258 +-1 .00390625
9. 129 .001953125
10. 64 +-1 [good reason to stop occured]
A sector transfer occurs every .195361 +-.0000001
I reported 5 to 10 failures in a transfer.
This equates to 1 DMA failure for every 288 sectors for
10 as the total, and 1 in 576 for 5 failures total.
At index 9 you will see .001953125, which is
very close to 1/100 of the time between sector transfers.
So 1 in 12,900 +- 10% RAM refresh can collide with a
FDC transfer. The worst failures I've seen to date occur
1 in 300 sectors. The numbers say that I should get 1 in
100 failures approx. from a collision on DMA requests.
Is this in line with the facts?
Note I did not consider code execution time, sector
to sector dead time, head seeking latency, or any of the
other time variables.
The major variables are:
1) RAM refresh cycle time
2) Context switch time
2) FDC sector transfer time
3) FDC code execution time
4) FDC track seek time
5) FDC sector start time
(time before actual sector starts)
6) any device with a harmonic of .1935
If this is really a problem can it be solved?
Yes, I think so but, the "isa_dmaxxx()" calls will
need a failure mode. BTW, this is an improvement to the
RTC (Real-Time Control).
What will need to happen is the 8254 (PIT) needs to
be inspected for the time remaining to the DRQ (DMA ReQuest).
This can be done via the "Counter Latch" command.
An available duty cycle of 90% seems to be appropriate, but
a smaller duty cycle will need to investigated if this is
not enough time to avoid the collision.
Calculations for a better time might be had from
Bruce Evans in Australia, since he is using arm scheduling
for the FDC driver on Linux. Arm scheduling, by him, seems to
be a description of an optimization technique using
schewing(sp?) or interleaving. He should know approx. how
much time each sector transfer takes and how long from the end
of a read till the start of the next read.
CONCLUSION: The available duty cycle from the DMA should be
about 3 times the amount of time for each sector
transfer _and_ the counter time remaining should be
no less the time needed for a complete sector read.
NOTE: The read-a-track may have to have a disable option
for 386bsd.
Last thing if this does not work, I have not Idea One
on what to do next and will drop this investigation.
What follows can in just before posting this.
=====================================================================
Date: Thu, 12 Aug 1993 08:48:24 -0600 (MDT)
From: Roger Ivie <IVIE@CC.USU.EDU>
Subject: Re: More on the DMA timing problem
You probably already know this, but:
There used to be a bug in some of AMD's DMA controllers. I don't remember what
the bug was (I knew what it was about 3 years ago). Fastback used to check
for the bug when you installed it; I don't know whether it still does.
Roger Ivie
ivie@cc.usu.edu
___________________________________________________________________________
Jesus Monroy Jr jmonroy@netcom.com
/386BSD/device-drivers /fd /qic /clock /documentation
___________________________________________________________________________