consp21@bingsung.cc.binghamton.edu (Ken Hoover) (10/24/89)
In article <13091@boulder.Colorado.EDU>, johnsobm@boulder.Colorado.EDU has a lot of questions, and I'll answer the ones I can... > 2. What is interleaving? > Interleaving, with respect to hard disks, is the technique of alternat- ing sector numbers around the track on the disk itself to obtain the fastest data-transfer rate. Interleave is expressed in a ratio (1:1, 2:1, 3:1, etc) to express how far apart the sectors are on the disk in terms of how many sectors are between sector n and sector n+1. For example, the physical placement of the sectors on a drive with 1:1 interleave is: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 (at 17 sectors/track) but is 0 9 1 10 2 11 3 12 4 13 5 14 6 15 7 16 8 on a drive with 2:1 interleave. (have I got that right?) The idea is the same as the interleaves get higher. The controlling factor that a slower controller will not have enough time to get the data from a sector into the memory of your computer before the next sector to be read has rotated out from under the head of the drive, and will have to wait until the sector that needs to be read next comes around again. Interleaving that is too "tight" will mean that it takes one (or more!) rotations of the platter to read in multiple sectors. A correctly set interleave will allow a disk to read an entire track in as few revolutions of the platter as possible. i.e. being able to read an entire track in just three rotations of the platter if the interleave is 3:1. A controller with 1:1 interleave will be able to read a track into the memory of your machine as fast as the drive can spin the disk under the read/write head. (Most drives run at about 3600rpm) There are several packages (most notably SpinRite) that will analyze your disk and correct the interleaving to create the highest throughput through your controller. [...] > > 2. In a similar vein, what do the fans of the various C implementations > say is the major advantage/raison d'etre/necessity of using C over, say, > Turbo Pascal, or TP & assembler? > Well, the reason I most often hear for using C over Pascal (in any implementation) is that C produces "tighter" code (i.e. you can do more with less typing). However, this advantage is offset by a (considerable) decrease in readability. Personally, I think that "C" stands for "Cryptic"; but that's my opinion. C is now the language of choice for system programmers, and is (unfortunately) a must of you wish to understand the UN*X operating system to any degree at any level below the prompt. As you have probably guessed, I am not a fan of C as a programming language - but I know of literally dozens of people who swear by it. Whether you like it or not boils down to personal preference, I guess. > Thanks for any input (or is that gauche?) > > johnsobm@spot.colorado.EDU > (I am an even parity voter) I hope I helped. (Bracing myself for another wave...) ------------------------------------------------------------------------------ Ken Hoover [ consp21@bingsuns.pod.binghamton.edu | consp21@bingvaxa.BITNET ] Resident computer jock and Mac hacker, SUNY-Binghamton Bio dept. Senior undergraduate consultant, SUNY-Binghamton Computer Center ------------------------------------------------------------------------------ Disclaimer : just becasuse I program Macs doesn't mean I can't program my XT either... :-)
neese@adaptex.UUCP (10/24/89)
>1. Briefly, what do the following abbreviations mean: > > RLL > MFM > ESDI > SCSI RLL and MFM refer to data encoding schemes. That is how the data is actually written to the disk. ESDI and SCSI refer to interface specifications. ESDI and SCSI use RLL for most encoding schemes. There is also a variant of the RLL encoding scheme that is used with SCSI only. It is called ZBR. This encoding scheme actually creates zones on the drive that have different numbers of sectors in each zone. This is done to get the most capacity possible out of a drive. For instance, the outer zones (or tracks) of a drive can hold more data than the inner zones (tracks). SO the HD builders put as many as 93 sectors on the out zones (tracks) and as few as 32 sectors on the inner zones (tracks). You can do this with SCSI as SCSI presents a logical interface to the user, all other interfaces, in the AT world, use a physical interface. Roy Neese Adaptec Central Field Applications Engineer UUCP @ {texbell,attctc}!cpe!adaptex!neese merch!adaptex!neese
madd@world.std.com (jim frost) (10/25/89)
In article <13091@boulder.Colorado.EDU> johnsobm@spot.Colorado.EDU writes: |1. Briefly, what do the following abbreviations mean: | RLL Run-length-limited. | MFM Modified Frequency Modulation, I believe. This is supposed to be a better encoding method than pure FM. | SCSI Small Computer System Interface. |1. What do UN*X loyalists hold as the greatest strength/virtue of that |OS? There are two reasons why I like UNIX. First, it has a substantial set of small utilities which can be combined in many ways to accomplish just about any job without programming. I appreciate this approach and miss it terribly on other operating systems. Second, it defines a standard (or nearly standard) software interface which remains consistent across a wide range of hardware platforms, allowing program written on (say) a PC-class machine to run on (say) a Cray or parallel-architecture machine. The fact that it is an interface and not an implementation is why UNIX is so "portable". Even if it is impractical to port a current implementation of UNIX to your hardware, you can retool the implementation for your hardware and so long as the interface remains the same, it will work fine. This is an important consideration when porting to such things as parallel architectures where conventional OS designs don't work. Interface-versus-implementation also means that you can change the entire design of the filesystem without breaking a single program. Unfortunately it also means that your interface must remain fairly simple or you will have a hard time supporting a wide range of hardware. The trade-off works well enough for me. |Or, more simply, what chiefly distinguishes UN*X (Xenix, Ultrix, |Minix, etc) from DOS, other than, say, sheer size/power? What is the |fundamental difference in philosophy that allows UN*X to handle much |larger systems/applications? The first difference between UNIX and DOS is that DOS provides mainly a set of disk-i/o calls, with little or no support for anything else. This design led many programmers (myself included) to go straight to the hardware to get the job done correctly or with good response time. If DOS had been a "real" operating system, it would have provided standardized software interfaces (which *worked*) for such things as serial communications devices (eg modems) and reasonable terminal i/o handling (ie it would be efficient to use DOS to write to the screen). The lack of this support has a lot to do with the difficulty in creating a multitasking DOS, amongst other problems. UNIX, on the other hand, provides support for a wide range of i/o devices (although some would say poor support in many cases) and attempts to use them efficiently. Given the wide range of hardware platforms that UNIX runs on, it is to the programmer's advantage to avoid hardware dependencies. Additionally UNIX provides multitasking and several forms of interprocess communication, most notably the pipe. Most common implementations of UNIX also allow shared memory and networked host communication. Most versions of UNIX have virtual memory -- either swapping or paging based or both -- to allow more main memory to be used by applications than you actually have, faking it by using secondary storage. The UNIX filesystem, especially implementations on research-based or high-end commercial UNIX's, is fairly robust and responsive. Newer implementations are very robust and are unlikely to become heavily fragmented. All UNIX filesystems support file protection mechanisms. Lastly, UNIX is a multiuser system, with all the extra complexities which that implies. |2. In a similar vein, what do the fans of the various C implementations |say is the major advantage/raison d'etre/necessity of using C over, say, |Turbo Pascal, or TP & assembler? C is particularly well suited for systems work, much more so than Pascal, and far more portable than assembler. It is easy to make a fairly good C compiler. C has a good mixture of low-level programming capabilities with the ease of use of a high-level language. Few other languages provide this. While many people say that C is "cryptic", good programmers can produce very readable code with little difficulty, and the standard library set is no more cryptic than many other languages I have used, although it is often much more terse (which in part leads to its "crypticness"). |I would really appreciate any advice: good reference books on C and |UN*X and the various shells, arguements designed to steer me in the |direction of the ONE and TRUE path to programming wisdom (ie, should |I emphasize C/UN*X to the practical exclusion of all else? Is it yet |a C/UN*X world out there? There are a good many C books out there, although someone will have to point you towards those (and good shell-programming books) since I learned from the original K&R and K&P books. As for emphasizing UNIX above all else, I believe it would be most practical for you to learn UNIX programming well, but don't dwell on it exclusively (read "The Idea of a University" by Newman for good explanations of why). The world is not completely UNIX and never will be, although experts seem to expect a tremendous growth in the UNIX market over the next several years (considering its growth in the last several years, this is not surprising). This tends to indicate that you'll be able to find a job. |Is C/UN*X simply THE superior programming tool |of the 90's?) Perhaps, perhaps not. I've found it to be the best development environment of any I have ever used for large-scale projects, probably because the utilities were designed with such things in mind. Properly used it is a very effective programming environment. There may be better, but there are no better environments which are so widely available. jim frost software tool & die madd@std.com