evan@telly.on.ca (Evan Leibovitch) (09/27/89)
Telly's recent disk problems supposedly provided a long-term benefit, by
enabling me to install a Maxtor 140 Meg drive. I'm told the seek and
transfer rates for this beast are supposed to be pretty good. The
AT-bus controller is an OMTI, same as for the previous drive. The system
is a 386 clone.
The disk was low-level formattted with a 1:2 interleave. Why, I don't
know. Anyway, since installing this thing the disk speed has been OK,
but INCOMING uucp throughput on the Trailblazer has been severely
reduced. Outgoing speed has not been affected, nor has traffic at 2400
baud.
Here's what happens. The transfer starts, at full-tilt PEP speed, for a
few seconds. Then I hear the disk head move and the modem transfer
stops dead. A second or two passes, then it starts again - until another
disk seek in a few seconds, another pause, etc...
If I didn't know better I'd swear it was dropping characters on input.
I know that telly's modem, on COM1:, would be radically sped up if put
on an intelligent card. That's the next piece of hardware coming. But is
it possible that a badly-done interleave could have this kind of effect?
What *is* the optimal interleave for a decent-speed ST506 drive?
Please mail suggestions. Thanks.
--
Evan Leibovitch, Sound Software, Brampton, Ontario - evan@telly.on.ca
She was looking for a vacation, and he was the last resort.root@nebulus.UUCP (Dennis S. Breckenridge) (09/28/89)
ST-506 interleave is recomended to be 3:1 unless you are running a Western Digital 1006-WA? or similar 1:1 controller. Most Diagnostic software with these controllers are accurate to a point. To test the controller out format it then run the PC Tech Journal Benchmarks If the disk test results are good at 2:1 leave it, otherwise format it for 3:1 or 1:1. Re-test it. Your interrupt problem is obvious. Com1 runs at a typical spl(6) level and that is high. Disk runs at a lower level but also uses DMA which means the cpu is put to sleep. Are you getting the idea. Modem is in xfer mode ... need a block of data ... disk is on wrong block or not cached ... put new disk request up... uucp times out ... disk request complete ... uucp still times out ... disk block is transfered ... interrupt is generated modem generates interrupt ... disk interrupt is suspended due to the high priority of serial port. interupt is serviced and modem now has data and everything is happy again. ignore typos and grammar... it is 2am
woods@eci386.uucp (Greg A. Woods) (09/29/89)
In article <1989Sep27.022039.14752@telly.on.ca> evan@telly.on.ca (Evan Leibovitch) writes: > Telly's recent disk problems supposedly provided a long-term benefit, by > enabling me to install a Maxtor 140 Meg drive. I'm told the seek and > transfer rates for this beast are supposed to be pretty good. The > AT-bus controller is an OMTI, same as for the previous drive. The system > is a 386 clone. Does the OMTI need/have a special driver? Perhaps their driver has a problem with interrupts and priority levels. Does the disk head move (i.e. you hear a click)? Or do you hear it re-calibrate (a whistle)? The driver for my 3B2 misses a beat on some of the faster drives under heavy load, and while it re-calibrates the drive, you're stuck in very high priority driver code. The 3B2 was never specified to run the bigger drives, but at the same time, there is supposed to be a fix available for this problem. > I know that telly's modem, on COM1:, would be radically sped up if put > on an intelligent card. That's the next piece of hardware coming. But is > it possible that a badly-done interleave could have this kind of effect? The most likely problem is you're driving the serial port too fast. It just can't keep up to that speed, and when the disk get's an interrupt, the serial driver loses. What you might try is to queue up a big file TO telly, and then put uucico in debug mode (-x9) and watch the packets come in, taking special note of those times when the disk is active. Look for timeouts and re-transmissions. > What *is* the optimal interleave for a decent-speed ST506 drive? I depends upon your CPU and controller. If 1:1 works, use it, otherwise you might be stuck re-formatting and testing several times to find the optimum value. There is also the mkfs gap factor. This is like a filesystem level interleave, and can be used to optimize the driver's performance. BTW, I wouldn't call the Maxtor 1140 (it's actually 114 Mb) a screamer! The one I have is faster than the CDC Wren 30 Mb drive though. :-) -- Greg A. Woods woods@{eci386,gate,robohack,ontmoh,tmsoft,gpu.utcs.UToronto.CA,utorgpu.BITNET} +1-416-443-1734 [h] +1-416-595-5425 [w] Toronto, Ontario CANADA
jmm@eci386.uucp (John Macdonald) (10/05/89)
In article <1989Sep28.182627.25730@eci386.uucp> woods@eci386.UUCP (Greg A. Woods) writes: >BTW, I wouldn't call the Maxtor 1140 (it's actually 114 Mb) a screamer! ^^^^^^^^^^^^^^^^^^^^ Well, Greg, if you're going to be picky, so can I. As is fairly common in the industry, Maxtor specifies the pre-formatted capacity. The after-formatting capacity depends upon the controller and the formatting software (in particular, it's method for handling bad areas on the disk). On the late Spectrix systems, Maxtor 1140 disks formatted out to having 122 Mb available for Unix file systems etc., not counting the 1.8 Mb allocated for alternating tracks containing bad blocks. I agree that it's neither a screamer nor a plodder. (As an additional consideration, it has been around long enough that there is *no* concern about Maxtor still being on the learning curve for this drive :-). -- "Software and cathedrals are much the same - | John Macdonald first we build them, then we pray" (Sam Redwine) | jmm@eci386
brian@ncrcan.Toronto.NCR.COM (10/06/89)
John Macdonald says: > ... As is fairly common > in the industry, Maxtor specifies the pre-formatted capacity. The > after-formatting capacity depends upon the controller and the formatting > software (in particular, it's method for handling bad areas on the disk). > On the late Spectrix systems, Maxtor 1140 disks formatted out to having > 122 Mb available for Unix file systems etc., not counting the 1.8 Mb > allocated for alternating tracks containing bad blocks. Just to add my own experiences to this.... I have Maxtor 1140 disks formatted to approx. 305MB (really 319,610,880 bytes). This is done on PC's with Perstor Controllers (31 Sectors/track) and using the 1140 disks as if they were 2190's (ie, 1224 cylinders instead of the 918 as published by Maxtor). I have yet to come across a Maxtor 1140 on which this couldn't be done. Brian.
clewis@ecicrl.UUCP (Chris Lewis) (10/08/89)
In article <891006074552.5152@tmsoft.uucp> brian@ncrcan.Toronto.NCR.COM writes: >I have Maxtor 1140 disks formatted to approx. 305MB (really 319,610,880 bytes). >This is done on PC's with Perstor Controllers (31 Sectors/track) and using >the 1140 disks as if they were 2190's (ie, 1224 cylinders instead of the >918 as published by Maxtor). I have yet to come across a Maxtor 1140 on >which this couldn't be done. Woooffff! Could you tell us a little more about the Perstor? I know about MFM -> RLL conversions, where the controller uses a different data encoding to improve the data storage per track by 50%. Most MFM (ST506) drives are capable of handling this reliably. But the Perstor must be doing somewhat more than that - eg: lying about the geometry and multiplying the storage per track by something close to 3! Is it doing compression or something? What's the performance like? 1:1 capable? Are they AT bus and AT compatible? (eg: command interface compatible with standard AT controllers like WD1007 ESDI controllers are) This might be a cheap way to upgrade capacity for people with existing drives. However, unless it can get an additional factor of two in there, (for some reason large ST506's (like the XT1140) list for more than 380 Mb ESDI drives including controller!), new systems are better off going ESDI. For cost *and* performance. -- Chris Lewis, Elegant Communications Inc. UUCP: {uunet!mnetor, utcsri!utzoo, uunet!attcan!lsuc, yunexus}!ecicrl!clewis Moderator of the Ferret Mailing List (ferret-request@eci386) Phone: (416)-294-9253
mason@tmsoft.uucp (Dave Mason) (10/09/89)
In article <695@ecicrl.UUCP> clewis@ecicrl.UUCP (Chris Lewis) writes: >In article <891006074552.5152@tmsoft.uucp> brian@ncrcan.Toronto.NCR.COM writes: > >>I have Maxtor 1140 disks formatted to approx. 305MB (really 319,610,880 bytes). >>This is done on PC's with Perstor Controllers (31 Sectors/track) and using >>the 1140 disks as if they were 2190's (ie, 1224 cylinders instead of the >>918 as published by Maxtor). I have yet to come across a Maxtor 1140 on >>which this couldn't be done. Note that Brian's also suggesting that there are more tracks really on the disk. I have an 1140 with RLL controller with 175MB. If he's right about the other cylinders this would go to 233MB (244,392,960 bytes), still not 305, but that's still a hell of a cheap way to get an extra 116MB!! (I have 2 of them) I have a non-AT bus, so presumably couldn't use the Perstor (unless there's a SCSI version). >But the Perstor must be doing somewhat more than that - eg: lying >about the geometry and multiplying the storage per track by something >close to 3! Is it doing compression or something? What's the performance >like? 1:1 capable? I'd also like to know what it's doing. Anybody around who knows any FACTS on the Perstor? GUESS time: Facts: 1) a block on disk has some header & trailer bytes around it for recognising the block, error checking, electronics switching time and rounding up to an even multiple of blocks/track. From the sample formats in my Docs, this looks to be a minimum of about 56 bytes. 2) 10416 bytes on MFM disk track (according to my Adaptec Documentation) 3) *1.5 that makes 15624 bytes on RLL disk track 4) 512*31 (re Brian's note above) = 15872 DATA bytes on a Perstor track Speculation: This is close enough that one possibility that comes to mind is that it (squeezes the bits VERY slightly (<2%) &) keeps a full track buffer. It then would read and write the track as a single 15872 byte sector, and break it up in the buffer. This would have some noticeable performance effects: 1) average access times would be slightly larger (average rotational delay would be 1.5 * rotation time rather than .5 - adding 16.67ms/access) (making the total average access on the 1140 go from 36.33 ms (?28 ms seek? + 8.33 ms rotational latency) to 53 ms) 2) 1:1 interleave would be free. 3) Once you accessed one block on a track, getting the rest would be free. Over all this should give somewhat worse performance on a (SysV) Unix file system (though I'd be willing to suffer this for the extra 24% disk space). A BSD new file system might be able to make good use of the track buffer. ../Dave
clewis@eci386.uucp (Chris Lewis) (10/11/89)
In article <1989Oct8.192745.20807@tmsoft.uucp> mason@tmsoft.UUCP (Dave Mason) writes: |In article <695@ecicrl.UUCP> clewis@ecicrl.UUCP (Chris Lewis) writes: |>In article <891006074552.5152@tmsoft.uucp> brian@ncrcan.Toronto.NCR.COM writes: |> |>>I have Maxtor 1140 disks formatted to approx. 305MB (really 319,610,880 bytes). |>>This is done on PC's with Perstor Controllers (31 Sectors/track) and using |>>the 1140 disks as if they were 2190's (ie, 1224 cylinders instead of the |>>918 as published by Maxtor). I have yet to come across a Maxtor 1140 on |>>which this couldn't be done. | |Note that Brian's also suggesting that there are more tracks really on |the disk. I don't think so. This is why: - ST506 normally allows 1024 cylinders. If the XT1140 was >988, Maxtor certainly would have at least said 1024. - A controller is *not* able to change head step distances (as they were, say, with Apple II floppies), because to the controller, an ST506 disk has a discrete number of head positions that you issue "step head out" and "step head in" and "recalibrate head" commands to. Eg: you can't 1/2 step the head. (Apple II's used this for software copy protect... but some floppy drives couldn't do it at all.... grumble) What I think that the Perstor is really doing is getting the number of sectors per track > 31, running into a DOS limitation, and then spoofing the geometry so that the number sectors per track remains legal, but the number of cylinders is upped instead. This is analogous to the way the WD1007 handles ESDI disks with 34 sectors/track... You're right though, *part* of the way this is done could be that the Perstor formats each track as one *long* physical block, thus you have relatively little header/trailer lossage. > 1) average access times would be slightly larger (average >rotational delay would be 1.5 * rotation time rather than .5 - adding >16.67ms/access) (making the total average access on the 1140 go from >36.33 ms (?28 ms seek? + 8.33 ms rotational latency) to 53 ms) The XT1140 is 28 Ms. Yes, average "single" block latency would go up, especially if the buffer parcelling occured in the driver (major buffering problems), but overall system performance is a much more complicated thing to predict. We (well, in a previous incarnation, my colleagues (including to a certain extent John Macdonald - I did the Spectrix DPT driver...)) implemented driver-based track buffering on the Spectrix 68020 Xenix systems, and discovered a pretty substantial performance improvement *on average*. Provided that the controller (or driver) manages to keep a *couple* (or more) full tracks of data around as a next level of buffer cache, UNIX's tendency to read disk blocks sequentially (even in archaic file system layouts like Xenix III) will get you a big win. John Macdonald may remember some of the performance statistics from the XL. As a canonical *best* case, just imagine a dd of a blocked disk, *one* rotation per track read. Which is on the order of 6 times faster than systems that don't have or can't fully utilize 1:1 interleave. Canonical *worst* case is the 53 Ms. average that you calculated. On the other hand, the DPT left the track buffering Spectrix driver in the dust.... Woof! -- He's a consultant: | Chris Lewis, Elegant Communications Inc. Lend him your watch | UUCP {uunet!attcan,utzoo}!lsuc!eci386!clewis and he'll tell you the time. | Moderator of the Ferret mailing list. Don Munroe, Cosmic Commander|
jmm@eci386.uucp (John Macdonald) (10/13/89)
In article <1989Oct10.221219.3571@eci386.uucp> clewis@eci386.UUCP (Chris Lewis) writes: | |We (well, in a previous incarnation, my colleagues (including to a certain |extent John Macdonald - I did the Spectrix DPT driver...)) implemented |driver-based track buffering on the Spectrix 68020 Xenix systems, and |discovered a pretty substantial performance improvement |*on average*. Provided that the controller (or driver) manages to |keep a *couple* (or more) full tracks of data around as a next level |of buffer cache, UNIX's tendency to read disk blocks sequentially |(even in archaic file system layouts like Xenix III) will get you a big win. | |John Macdonald may remember some of the performance statistics from |the XL. I'm afraid I don't remember any specific figures. It was not (necessarily) using physical tracks. We used "logical" tracks - a block of "k" sequential sectors aligned on a "k"-sector boundary. If "k" happened to be the same number as there were physical sectors per track, then it was buffering physical tracks. Even if a system was being used for just one purpose, it still was very valuable to have more than a few track buffers, and when many users were on then many buffers were needed. It generally turned out more valuable to allocate "extra" memory to track buffers instead of to Unix buffer cache. It also turned out to be even more valuable than usual to frequently do an fsck to reorder the free list - keeping the free list sorted means that files will have larger portions of their data in contiguous sectors (or close to it). As I recall, we used about 1 Meg for track buffers and about 1/2 Meg for buffer cache. |As a canonical *best* case, just imagine a dd of a blocked disk, *one* |rotation per track read. Which is on the order of 6 times faster than |systems that don't have or can't fully utilize 1:1 interleave. Note that even with Unix's internal read-ahead you still can't usually use 1:1 interleave (often far less) - by the time the controller finshes reading a sector, transfers it to the system's memory, interrupts the processor, and informs it that the transfer is complete, and then the device driver tells Unix that the transfer is complete, Unix notices that this is a sequential file and so a read-ahead of the next sector is in order, issues the read request to the device driver, the device driver prepares the control blocks, tells the controller to use them, the controller gets the control blocks and interprets them to find that it is being asked for the next sector (whew); well after all that has happened, the disk has certainly revolved the few bytes between the end of the one sector and the start of the next (and probably it has rotated past a number of complete sectors too). With the track buffering, one request is sent to the controller for the group of sectors, so it is only delays internal to the controller that could cause it to be able to handle 1:1 interleave (this is not uncommon, mind you). Where track buffering loses is when you *don't* ever use any of the other sectors in the logical track. Then you have had a somewhat slower time for the original track and no subsequent gain on the (non-existent) later ones. The time penalty for the first sector is the rotational time to read the extra sectors in the logical track. Some sample time calculations, using a Maxtor 1140 with logical track size of 9K (half a physical track): random one-sector (512 bytes) read (i.e. first read in a new place): seek: 20 ms. rotate: 8 1/3 ms. (avg half rotation) read: 1/2 ms. (one sector = 1/35 of a track) total: 29 ms. subsequent one-sector read (i.e. previous read was in same physical track): seek: 0 rotate: 8 1/3 ms. (avg half rotation) read: 1/2 ms. total: 9 ms. random track buffer (9K bytes) read (i.e. first read in a new place): seek: 20 ms. rotate: 8 1/3 ms. read: 9 ms. (18 sectors = 18/35 track total: 37 ms. Thus, the track buffering read adds about 33% to the first read to an area, but then the next 17 reads in the same area are free, instead of 1/3 price. If two sectors are used, then track buffering breaks even, and if more are used then it wins. Note that the cheap subsequent read (non-track buffering) only occurs if no other disk activity occurs in between - whereas the track buffering subsequent reads are essentially free unless so many different areas are accessed that the buffer cannot be retained. |Canonical *worst* case is the 53 Ms. average that you calculated. | |On the other hand, the DPT left the track buffering Spectrix driver |in the dust.... Woof! Mind you, we never got around to implementing track buffering in the DPT device driver - it might have provided some additional advantage. -- "Software and cathedrals are much the same - | John Macdonald first we build them, then we pray" (Sam Redwine) | jmm@eci386
brian@ncrcan.Toronto.NCR.COM (10/13/89)
> |>>This is done on PC's with Perstor Controllers (31 Sectors/track) and using > |>>the 1140 disks as if they were 2190's (ie, 1224 cylinders instead of the > |>>918 as published by Maxtor). I have yet to come across a Maxtor 1140 on > |>>which this couldn't be done. > | > |Note that Brian's also suggesting that there are more tracks really on > |the disk. > > I don't think so. This is why: Yes there is more tracks on the drive. You can also use the 1140 as a 1224 cyl, 17 sect/track unit, if you wish. > > - ST506 normally allows 1024 cylinders. If the XT1140 was >988, > Maxtor certainly would have at least said 1024. I didn't think there was a limit imposed on the cylinder count by the ST506 interface. Heads, yes, since there is only 4 head select lines, limiting you to 16 heads. (Note that most fast (ie voice-coil actuated head assembly) ST506 drives allow 15 heads, as the 16th head is used internally by the drive logic to read the servo tracks on the reserved servo platter. Stepper motor drives can have a full complement of 16 heads). The actual cylinder positioning is done with the STEP and DIRECTION signals, using the TRACK00 signal for synchronization. Therefore, you can STEP the heads in as far as the drive will allow it. In the case of the Maxtor 1140, which is voice coil actuated, there is enough servo tracks on the servo platter to allow 1224 cylinders. There may be more, I've never tried and the Perstor doesn't support any more. And why push my luck any further anyways :-) > - A controller is *not* able to change head step distances (as they > were, say, with Apple II floppies), because to the controller, > an ST506 disk has a discrete number of head positions that > you issue "step head out" and "step head in" and "recalibrate head" > commands to. Eg: you can't 1/2 step the head. (Apple II's used > this for software copy protect... but some floppy drives couldn't > do it at all.... grumble) Agreed. > > What I think that the Perstor is really doing is getting the number of > sectors per track > 31, running into a DOS limitation, and then spoofing the > geometry so that the number sectors per track remains legal, but the > number of cylinders is upped instead. This is analogous to the way > the WD1007 handles ESDI disks with 34 sectors/track... Most modern AT BIOSES are able to handle large number of sectors/track. The DOS limitation lies in the fact that it uses a 10 bit number to represent the track number internally in it's logical block calculations, thus limitting DOS's usable number of cylinders to 1024. When using the Perstor and Maxtor at 1024 cyls with 31 spt, there is no problem at all, and no drive mapping going on. In fact, I don't even think that the Perstor has the BIOS software or hardware required to map the drive to 17 spt, which is the way the WD and DTC controllers do it. To gain access to the additional 200 cylinders, a software driver is loaded at boot time. I suspect that this driver is doing some sector mapping, but again note that the drive runs fine at 1024 cylinders, 31 spt, no additional drivers required. Norton, PCTOOLS, PCKWIK disk cache, all report 1024 cylinders, 31 spt! > > You're right though, *part* of the way this is done could be that the > Perstor formats each track as one *long* physical block, thus you > have relatively little header/trailer lossage. Actually, the Perstor uses a technique developed by them called ARRL, Advanced RLL, which is similar to 2,7 RLL developed by IBM. It uses a different grouping scheme when writing the flux transitions onto the surface of the disk. The grouping chosen is very specific, in that it will yield a data rate of 9 megabits/sec (31 spt) or 10 megabits/sec (34 spt), yet the actual code rate to the drive will be only be 5 megabits/sec, which gives a FTPI (flux transitions per inch) rate the same as that seen with standard MFM at 5 megabits/sec. In this way, it is working within the limits of the ST506 interface and the drives built to that standard. In other words, it does not place any additional demands on the drive than normal ST506 MFM would. This is unlike standard RLL, which operates at a code rate of 7.5 Mb/s, or 7.5 million FTPI. (which is why RLL requires plated media drives. ARLL does not!) -- +-------------------+-----------------------------------------------------+ | Brian Onn | UUCP: ..!uunet!attcan!ncrcan!brian | | NCR Canada Ltd. | INTERNET: Brian.Onn@Toronto.NCR.COM | +-------------------+-----------------------------------------------------+
woods@eci386 (Greg A. Woods) (10/13/89)
[ On Wed Oct 4 16:29 (Re: "Re: Is it the interleave?"), John Macdonald wrote: ] > > In article <1989Sep28.182627.25730@eci386.uucp> > woods@eci386.UUCP (Greg A. Woods) writes: > >BTW, I wouldn't call the Maxtor 1140 (it's actually 114 Mb) a screamer! > ^^^^^^^^^^^^^^^^^^^^ Hmm.... Now I'm making mistakes by omission. That's 114 Mb formatted to Maxtor's specs. (and 140 Mb un-formatted, to Maxtor's specs.). I get a bit more with the 3B2, 'cause its controller likes 18 sectors per track, so perhaps 122 Mb as well (I can't remember just now). As for reliability of the Maxtor, I've heard (third hand) that they are near the top of the list for needing repair work. That may also mean they outnumber the rest in the field too. I know the disk I'm using has had a bad time, but I've seen others work just as hard, or maybe more so, and are still ticking (:-) along. -- Greg A. Woods woods@{eci386,gate,robohack,ontmoh,tmsoft,gpu.utcs.UToronto.CA,utorgpu.BITNET} +1-416-443-1734 [h] +1-416-595-5425 [w] Toronto, Ontario CANADA
clewis@ecicrl.UUCP (10/14/89)
couple things, some related to this thread, some earlier... In article <1989Oct12.202334.23282@eci386.uucp> jmm@eci386.UUCP (John Macdonald) writes: >In article <1989Oct10.221219.3571@eci386.uucp> clewis@eci386.UUCP (Chris Lewis) writes: >|As a canonical *best* case, just imagine a dd of a blocked disk, *one* >|rotation per track read. Which is on the order of 6 times faster than >|systems that don't have or can't fully utilize 1:1 interleave. > >Note that even with Unix's internal read-ahead you still can't usually >use 1:1 interleave (often far less) This point should be re-emphasized: 1:1 interleave generally does not gain you *anything*, because the kernel/drivers are not likely to be able to reissue an I/O before you're *past* the next sector. Unless: a) Your drivers are really smart and coalesce read-aheads into multiple sector I/O's. Of which track buffering is a sort of a special case. I did something similar with the the DPT when I had the thing work on 1K physical sectors and 512 byte logical ones. (1K sector support in Xenix is a little wierd, and similar to SRV2 if I understand things correctly....) b) your application is wierd and reads sequentially with big buffers. Some of my benchmarks seemed to indicate that UNIX disk activity can be fairly effectively modeled as random reads of 4-8 blocks, and that with standard read-ahead you need a fairly substantial effective interleave (phyical + mkfs) to avoid missing too many rotations. Thanks, Brian for the explanation of how the Perstor works. So much for guessing. -- Chris Lewis, Elegant Communications Inc. UUCP: {uunet!mnetor, utcsri!utzoo, uunet!attcan!lsuc, yunexus}!ecicrl!clewis Moderator of the Ferret Mailing List (ferret-request@eci386) Phone: (416)-294-9253