On Sat, Nov 28, 2015 at 7:19 PM, Jerome H. Fine <jhfinedp3k at compsys.to> wrote: A similar thing was implemented on the old DEC Rainbow 100 (though I'm sure others). To give the software a chance to do some minor things while processing, it physically laid out the 10 sectors as 0 2 3 4 6 8 1 3 5 7 9 so that when reading sequentially, you had half a disk rotation to get your act together to read the next sector. This turned out to be only a small performance win, and was a pita for interoperability, so was done only in the earliest versions. Since these were RX50 disks, I suspected its origins were in the PDP-11s and VAXen that the drives were also attached to. Warner

There were a few systems (such as CP/M) that optimized (or attempted to) interleave depending on use. So, "boot" tracks were 1:1, "directory" may have been 2:1 and user data 3:1. Schemes varied widely. One or two even interleaved side-to-side in addition to "skewing track-to-track. Obviously written by a programmer tasked with the job of "Let's see how fast we can get data on or off this thing". --Chuck

On Mon, 30 Nov 2015, dwight wrote: Oversimplified remedial tutorial: Ideally, the system reads a sector, does what it has to do with the content, and goes back for the next one, and can read every sector of the track in a single revolution. But, if the system can't finish with a sector in time for the next sector, then it's going to have to wait a full revolution of the disk, which would be the worst condition. With 10 sectors per track, we are looking at a simple file read taking 10 times as long. Well, OK, the system could take hours to process the data from the sector, so there is no maximum possible slowness. Maybe Microsoft knows what the maximum slowest is. Most "modern" systems can keep up with simple numeric sequence, although some software can slow things down enough to bring the problem back. If it is just barely too slow to get the next sector in sequence, then a simple rearrangement of the sectors on the disk could solve it. Something as simple as arranging the sectors such as 1,6,2,7,3,8,4,9,5 The rest of the software doesn't even need to know about it. It still asks for sector 1, then asks for sector 2, etc. If that's still not enough, it can go something such as 1,4,7,2,5,8,3,6,9 1,3,5,7,9,2,4,6,8 etc. Obviously, simply loading the content of a file into memory can be done quicker than if some software is trying to process the incoming data. Some of us have been crazy enough to use disks with different sector sequences for data files of different programs (WORDSTAR V WEIRD V WORDPERVERT V SUPERCALC, etc.) In addition, depending on how long the drive takes to move to the next track, you might need more time before reading the first sector of the next track. So, in some cases, it may be more efficient to have the first sector of the next track not be the first physical sector on that track. The sectors of that track could be in the same pattern, but simply starting at a different point in the cycle. A computer system that rearranges sectors on the track can normally manage OK with a disk formatted on a different system with a different physical sequence. If you are writing a program to FORMAT disks for a machine, the sector sequence will not necessarily matter, although it could result in slower access. When looking at an unfamiliar disk format, if the sectors are not in sequential order, then it usually means that the OS uses them in numeric order, but that the arrangement is out of numeric order for efficiency. Sector sequence can also be done in software. With the physical sectors still arranged sequentially and consecutively, the OS could decide that the first "logical" sector(s) are in sector 1, and the next logical sector(s) are in sector 3, etc. ("deblocking") If the sectors of an unknown disk are in numeric order, it could mean that 1) the system was efficient enough to handle consecutive sectors 2) the designer didn't care about that level of efficiency 3) the OS is not using the sectors in numeric order. In that case, it calls for examining the content of sectors, looking for information flow. If you encounter the first part of a word of text at the end of one sector ("half a worm in the apple"), and the rest of the word at the beginning of another sector, that helps determine the sector sequence. If you aren't lucky enough to have text files in a language that you can follow, look for source files (such as DUMP.ASM), and machine language of processors that you can follow. Tracks where some sectors have been over-written with other content can make it more confusing to determine the sequence. It is USUALLY the same on every track, but there are rare exceptions. And different disk formats from the same manufacturer may be different. Physical format may be different on boot or system tracks than on the rest of the disk. Other than sector numbers the physical format is usually the same on both sides of a DS disk. When you encounter one that is not, it is likely to be a DS disk that has been reformatted to use on a SS machine, such as re-using a PC disk for an Osborne. -- Grumpy Ol' Fred cisin at xenosoft.com

----- Original Message ----- From: "Paul Koning" <paulkoning at comcast.net> Sent: Monday, November 30, 2015 3:55 PM Your writeup was aimed at floppy disks, but interleave may also appear on hard drives. I don't remember it in reasonably modern systems, but it shows up on CDC 6000 systems. ----- Reply ----- Definitely an issue with IBM PC/XTs and clones; I recall testing every new combination of HD and controller for most efficient interleave before I delivered to the client. m

Nothing wrong with what you wrote that I can see; excellent tutorial IMO. m ----- Original Message ----- From: "Fred Cisin" <cisin at xenosoft.com> To: "General Discussion: On-Topic and Off-Topic Posts" <cctalk at classiccmp.org> Sent: Monday, November 30, 2015 4:45 PM Subject: Re: Sector Interleave

On Mon, Nov 30, 2015 at 3:13 PM, Chuck Guzis <cclist at sydex.com> wrote: One of the drum computers had the address of the next instruction as an operand of the instruction; the programmer would scatter the instructions according to the execution time of the instructions; IIRC "assembler" referred to the process of converting the sequential source to the scattered arrangement. -- Charles

On Mon, Nov 30, 2015 at 1:45 PM, Fred Cisin <cisin at xenosoft.com> wrote: Probably outside the domain of the question: The DPS8-M had configurable core memory bank interleave (even/odd addresses); I would hazard a guess that this improved bandwidth on double word read/writes. -- Charles

On Nov 30, 2015, at 6:35 PM, Paul Koning <paulkoning at comcast.net> wrote: The TU58 was a block addressable using a cassette tape drive famously(?) called DECtape II. File placement on the two different linear tracks was a necessary art, especially if you were booting RT11 regularly. This helped it to stream or not rewind in sensitive places. The 1:2 interleave was ?built-in? to the block formatting (see EK-0TU58-UG-001_TU58_DECtape_II_Users_Guide_Oct78.pdf). I used a late model device, pulling data from clinical diagnostic computers without too many challenges. However, compared to reliability of DECtape*, DECtape iI was not in the same class IMHO. Jerry *Yes - I skipped over DECtape. I?ve leave that one to the many experts on the list.

Sure it does. The DOS format, which was adopted by RSTS, has 4 way interleaving. If you write a 500 block file, it writes every 4th block forward, then fills in one set of gaps reverse, then forward and backward again, resulting in finally all blocks used. This is a software function, of course, and actually implemented in the file system, but it's certainly interleaving. It doesn't apply to contiguous files (supported in DOS but not RSTS), which is why RSTS V4A sysgen with output to DECtape took so long -- writing a contiguous CIL file, in block order, madly seeking back & forth. The reason for the interleaving on DECtape is the start/stop time. To run non-interleaved at high speed you have to leave the tape running (no "stop" commands) and you have to issue the next command quickly. RT-11 could do that; DOS could not. paul

True. Interleaving, as described in this thread, is typically a software function; the software uses the blocks in an order different from the "ascending by 1" natural ordering. I suppose it's possible to do something like interleaving where consecutive sector addresses are not physically adjacent on the media. Come to think of it, that's exactly what the MSCP RX50 controllers do, since MSCP implements the mapping from LBA to physical addresses in the controller, not the host. But in older systems where the controllers handle physical addresses and the mapping from LBA is in the driver, interleave is handled there (or above). The CDC 844 controller (which handles drives that look like the RP04 or RP06) had a command to set 1:1 or 2:1 interleave. The reason is that it would allow reading or writing several sectors without an intervening "seek" command. Depending on the selected mode, the current sector address would advance by 1 or by 2 at the end of the operation (and, in the case of 2:1, wrap at track end the first time around). That's the only case I have seen of interleave support in pre-MSCP controllers. On the subject of DECtape, and "keeping good track of things" -- DOS format DECtape has 510 bytes per tape block, the other two bytes are used as the link word. It's a bit like MSDOS FAT format (or CDC 6000 series, which did it 20 years earlier), but with the links in the blocks rather than in a separate region. The directory points to the first block, and you get the next block address when you read the first. Yes, that means no random access supported; in DOS, if you needed random access you were required to use a contiguous file, in which all 512 bytes per block are payload. The interleaving is simply a side effect of the block allocation algorithm: when looking for the next block to allocate, it would start looking at current + 4 or current - 4 (depending on the direction for this block). So starting from an empty tape you'd get a regular layout, but if there were already some allocated blocks you might get larger skips, and on a very nearly full tape possibly a smaller skip. A very odd interleave shows up in the THE operating system for the Electrologica EL-X8 by Dijkstra, in its addressing for the paging drum. That device is word addressable (think of an RF11, but somewhat larger: 512k 27-bit words). The start word address of sector n is given by (n * 1025) mod 512k. I assume that's done for the usual reasons interleaving is used, but while the formula is nicely spelled out in the literature, no explanation is given for why it was used. paul

On 12/01/2015 09:25 AM, Charles Anthony wrote: A particularly cute one was employed with early versions of Harvard Graphics for the PC. A protection key was encoded in the gap between sectors. Since the PC 765 controller writes individual sectors (i.e. looks for a IDAM, then a DAM, then turns on Write Gate), it was very difficult (but not impossible) to replicate this stuff, as using a regular write command would cause the data separator to lose sync in the write splice area. On the other hand, it was pretty simple for a WD-17/27 type FDC to duplicate this. --Chuck

On 2015-12-01 18:09, Paul Koning wrote: Yes, the "hardware" interleave is what I was assuming everyone here was talking about. Otherwise there is no point/need to format to get the interleaving... With disks, this is perfectly doable, as the block number is in the block header, and the drive/controller scans headers until the current block passes by. There is no real reason to actually place the disk blocks in consecutive physical order on the disk. Any order will work. That's what soft sectors gets you. And in addition to the interleaving someone also mentioned that you can stagger blocks between tracks, so that you have time for a track switch and then hit the next sector in optimal time, if you really work at it. Johnny

When I attempted to evaluate how well a backup to tape would work, I always included the verify portion to make sure that the tape had been written correctly in addition to making sure that the tape could also be read. For the PDP-11/83 under RT-11, there were essentially two choices: TK50 and TK70. Aside from the advantage that the TK70 had over the TK50 with respect to the capacity - (if I remember correctly) about 256 MB vs 32 MB, the other problem was that it was found to be impossible to steam the TK50 during a BUP verify operation. So in addition to the TK70 being much faster in the first place relative to the TK50, the verify operation was just not feasible. Somehow, the PDP-11/83 could read both the tape and the disk drive, then compare the two current buffers while the alternate buffers were being read, using, I presume, DMA requests to the two controllers to transfer the data to the next pair of buffers. Of course, RT-11 had special EMT requests to initiate the read requests and then go away and do something else. Obviously, I could have copied the BUP backup to a scratch disk and verified the scratch disk against the original disk and saved a great deal of time if the TK50 had been the only option. Jerome Fine

On Nov 29, 2015, at 12:13 PM, Warner Losh <imp at bsdimp.com> wrote: ?.but, at least you had a functionally redundant sector 3! :-)

On Sun, Nov 29, 2015 at 1:19 PM, Fred Cisin <cisin at xenosoft.com> wrote: 8" on one side, 5.25" on the other. -- Charles

On 2015-12-01 16:49, John Robertson wrote: And all of these commands are only relevant if you are in the US. Much of the rest of the world signed the Berne convention long before that. Johnny