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