larry@focsys.UUCP (Larry Williamson) (10/24/88)
We have an application in which we write large amounts of data to
an AT disk without benefit of any file system structure or
overhead. The disk is used only as a very large raw buffer.
To date, we have been using DOS interrupts 25 and 26 to write and
read the disk. We transfer 64K byte blocks with each dos call.
This is no longer fast enough for us. We must now transfer more
data in less time, (of course :-).
We are using an adaptec RLL controller with a miniscribe drive. Core
test tells us this combination runs at over 600Kbytes/sec, yet our
tests show only 350K/s. Why this major difference? It is obvious
that coretest is doing something different than we are.
Any suggestions?
We are prepared to write more code to circumvent dos if necessary.
Since the disk write and read functions that we need are extremely
simple, we don't have to provide much functionality.
Thanks,
larry
--
Larry Williamson -- Focus Automation Systems -- Waterloo, Ontario
watmath!focsys!larry (519) 746-4918Devin_E_Ben-Hur@cup.portal.com (10/26/88)
Larry Williamson asks about improving throughput using int 25&26 disk IO calls with 64k buffers. The AT DMA chip can only handle requests that do not span a 64k hardware memory boundary (that is, the high 4 bits for DMA must remain constant). If your 64k buffer passed to int 25/26 does span a 64k boundary, the BIOS function will deblock your request into two DMA controller requests, thus reducing your thruput. Allocate your disk buffer such that its address is of the form S000:0000 for some hex digit S. Devin_Ben-Hur@cup.portal.com (port-hole-flames > /nev/dull) ...!ucbvax!sun!cup.portal.com!devin_e_ben-hur
Devin_E_Ben-Hur@cup.portal.com (10/26/88)
In addition to making sure your buffer does not span a 64k absolute memory boundary, you should make your read and write request size an integral multiple of your track size. For the RLL drive you mentioned, I believe the track size is 27 sectors (13.5k) so try reading & writing 54K at a time instead of 64K at a time to avoid additional deblocking from partial track read/writes. Devin_Ben-Hur@cup.portal.com (port-hole-flames > /nev/dull) ...!ucbvax!sun!cup.portal.com!devin_e_ben-hur
bill@hpcvlx.HP.COM (Bill Frolik) (10/26/88)
The simplest thing to do is replace your Int 25h and Int 26h calls with calls to BIOS Int 13h functions 2 and 3, which is basically what DOS does with your 25h/26h requests after adding a layer of buffering and converting your absolute sector request into an equivalent cylinder, head, and sector number. So you don't have to look it up in your tech ref manual, the following four Int 13h functions are probably all you need. Remember that the first hard disk in your system is drive number 80h, and that sector numbers start at 1, not 0. Also, be sure to check error status after each function; as long as AH keeps coming back zero, you're okay. RESET DISK Resets the controller and recalibrate to track 0. Specify: AH = 0 DL = Drive unit number Returns: AH = Error status GET PARAMETERS Get information about the drive specified in DL. Specify: AH = 8 DL = Drive unit number Returns: AH = Error status CH = Max cylinder number CL = Sectors per track DH = Max head number ES:DI = Pointer to disk parameter table (I don't have the table in front of me, but I think it contains somewhere the number of bytes per sector in addition to all this other information. Normal DOS disk sectors are 512 bytes long, but sometimes folks use larger values on hard disks to "break" the 32M limit.) READ SECTOR(S) Read one or more sectors from the disk. Specify: AH = 2 AL = Number of sectors to read CH = Cylinder number (0-n) CL = Sector number (1-n) DH = Head number (0-n) DL = Drive unit number ES:BX = Address of data buffer Returns: AH = Error status AL = Number of sectors actually read WRITE SECTOR(S) Write one or more sectors to the disk. Specify: AH = 3 AL = Number of sectors to write CH = Cylinder number (0-n) CL = Sector number (1-n) DH = Head number (0-n) DL = Drive unit number ES:BX = Address of data buffer Returns: AH = Error status AL = Number of sectors actually written Error codes: 00 - No error 01 - Bad command or drive number 02 - Address mark not found 03 - Write protect violation 04 - Sector not found 05 - Reset failed 06 - Disk change error (floppies only) 08 - DMA overrun on last operation 09 - DMA overrun 0C - Track/sector combination not supported 10 - Bad CRC on floppy read 20 - Controller failure 40 - Seek failure 80 - Timeout ----------------------------------- Bill Frolik / hp-pcd!bill Hewlett-Packard / Corvallis, Oregon
jim@belltec.UUCP (Mr. Jim's Own Logon) (10/28/88)
In article <10480@cup.portal.com>, Devin_E_Ben-Hur@cup.portal.com writes: > Larry Williamson asks about improving throughput using int 25&26 disk > IO calls with 64k buffers. > > The AT DMA chip can only handle requests that do not span a 64k hardware > memory boundary (that is, the high 4 bits for DMA must remain constant). But almost all hard disk controllers are string I/O based, and are not based on the DMA controller at all. I say almost all because someone, somewhere must have one that does (probably made before everyone found out how slow they were). By the way, I hate how the usage of 'DMA' now seems to automatically refer to the usage of a DMA controller. Only in the PC realm of the world is multimaster support so weak that using the DMA chip is easier than implimenting a true DMA from an alternate bus master. -Jim Wall Bell Technologies, Inc.
tom@vrdxhq.UUCP (Tom Welsh) (10/29/88)
Also, bear in mind, that on 286-ATs, hard disk IO is NOT done through DMA. Check the schematics/info on DMA -- only one DMA channel is connected, and it's to the floppy. .
ray@micomvax.UUCP (Ray Dunn) (11/02/88)
In article <10480@cup.portal.com> Devin_E_Ben-Hur@cup.portal.com writes: >Larry Williamson asks about improving throughput using int 25&26 disk >IO calls with 64k buffers. > >The AT DMA chip can only handle requests that do not span a 64k hardware >memory boundary (that is, the high 4 bits for DMA must remain constant). This is completely true, unfortunately it is also completely irrelevant - the hard disk does *not* use the DMA!! Speed optimization should be done by using BIOS INT 13 to do your I/O, to get as close to the hardware as you can without actually "sucking the ferkin". You should also match your requests with the physical layout of the data on the disk, the number of sectors per track, and optimize the interleave by trial and error. This is of course a pain in the neck and dreadfully unportable. If things have got to this sorry state, it is almost certain that you need to examine very carefully your whole approach to your application requirements. Good Luck. PS - checking the obvious - what is the state of your VERIFY flag? -- Ray Dunn. | UUCP: ..!philabs!micomvax!ray Philips Electronics Ltd. | TEL : (514) 744-8200 Ext: 2347 600 Dr Frederik Philips Blvd | FAX : (514) 744-6455 St Laurent. Quebec. H4M 2S9 | TLX : 05-824090