*BSD News Article 19808


Return to BSD News archive

From: uhclem@nemesis.UUCP
Date: 20 Aug 93 20:55 CDT
Newsgroups: comp.os.386bsd.development
Subject: Re: More annoyance on the DMA problem
Message-ID: <-21004671@nemesis>
Path: sserve!newshost.anu.edu.au!munnari.oz.au!news.Hawaii.Edu!ames!agate!howland.reston.ans.net!sol.ctr.columbia.edu!news.kei.com!news.oc.com!utacfd.uta.edu!trsvax!trsvax!nemesis!uhclem
Nf-ID: #R:netcom.com:0:nemesis:-21004671:000:4015
Nf-From: nemesis.UUCP!uhclem    Aug 20 20:55:00 1993
References: <0@netcom.com>
Lines: 78


<Gee, I thought I would never let myself get roped into this discussion>

[0]	I always thought that 3.5 drives rotate at 250rpm= 5 rev/s.

300 RPM for 3.5" drives   300 / 60 = 5 RPS
(although perhaps there are 50 seconds in a minute in PAL-I countries. :-)

[0]There are 18 sectors/track. ie 90 sectors/sec .  therefore the transfer
[0]rate is 512*90 = 50KBytes/s (aprox.). Negligable as far as DMA
[0]latency goes.  I

Look at these from the point of view of the bit transfer rate of the
drive, ie, 500Kbit/sec (engineers K, not computer K).  It it takes 1/5th
of a second for one revolution (300 RPM media) and the transfer rate is
fixed at 500Kbit/sec, then the maximum possible bits per track on the
media is 
	500,000 * .2 = 100,000(bits/track) / 8(bits/byte) = 12,500 bytes.
In reality, you have to subtract gaps I, II, III, IV, ID fields and
other goodies, but you will find that 18 x 512 byte sectors gives
you 9,216 usable bytes per track, which is less than the mamimum
of 12,500 bytes (this is good).

For 360 RPM (6 RPS) media with a 500Kbit/sec transfer rate, you get:
	500,000 * .16667 = 83,333 / 8 = 10,417 bytes
Again, subtract out the gaps and ID fields and you find that
15 * 512 byte sectors gives you 7,680 usable bytes per track, which is
less than 10,417, also good. 

NOTE ALSO that 16 * 512 byte sectors WILL LEGALLY FIT onto 360 RPM media
with valid sizes on all gaps and ID fields.  (16 * 512 = 8,192 < 12,500)
The old Tandy 16/6000 XENIX systems did this for years.  For some reason,
the IBM AT "high capacity" floppies elected to not follow IBMs own
sector-count/gapping recommendations. 
(80trks x 16sec/trk x 2trks/cyl x 512 byt/sec = 1,310,720 / 1024 = 1.28M/disk)
(80trks x 15sec/trk x 2trks/cyl x 512 byt/sec = 1,228,800 / 1024 = 1.20M/disk)

Now, at a transfer rate of 500,000 bits/sec, it means that when the
drive is really reading or writing a sector, the controller will request
a single byte transfer NOMINALLY every 16usec.  Because of the design
of the UPc765 controller, it must receive each byte within 15.7usec
of the request.  Once a character is received (assume write sector) and
the previous one has been clocked to/from the drive head,  the next byte
is shifted into the serial converter and a request is immediately
made for yet-another byte, allowing up to 15.7usec for bytes 2-n to
arrive.

Because the 765 has only a single byte buffer, it means that DMA channels
5, 6, 7, 1 and 0 are forbidden from having any device that runs the DMA in
a multi-byte transfer (continuous) mode, or that the channel can be held
by WAIT for > 15.5usec, or else the FDC will have an under/overrun.
The standard BIOS drivers simply retry the sector if this event occurs.
Yes, the sector contents on the write on the disk is lost until the retry
is performed, then the lost data is overwritten with the complete sector.

Yes, you can dork with the channel priorities, but this tends to break
other things.  And don't try adjusting late write.  It makes a lot of
different systems crash instantly.

Note that 300 RPM (250 Kbit/sec) 360/720K media on PCs is actually run at
360 RPM (single speed drive == cheaper) and a transfer rate of 300Kbit/sec
is used to make the head-to-media rate come out right, but it also means
the transfer timing demands are higher than they would be if the media
was really running at 300 RPM with a 250 Kbit/sec transfer rate.

Remember that the 8237-5 used in the original AT (and lots of clones)
can't run faster than 5MHz, so the AT and lots of other machines ran
the DMA at half the system clock (original AT was 6MHz, DMA was 3MHz.)
It is important to keep this in mind when computing how many transfers
you can actually get through an AT-architecture computer.


Frank Durda IV <uhclem@nemesis.lonestar.org>|"The Knights who say "LETNi"
...utacfd!nemesis!uhclem (nearest internet) | demand...  A SEGMENT REGISTER!!!"
...letni!rwsys!nemesis!uhclem	            |"A what?"
...decvax!microsoft!trsvax!nemesis!uhclem   |"LETNi! LETNi! LETNi!"  - 1983