patf@.HP.COM (pat fung) (06/27/90)
From pnl@hpfinote.HP.COM Sun Jun 24 15:26:40 1990 , Peter Lim writes: >Not according to what I know. RLL increases bits/track by doing 2 things. >(1): Re-arrange the flux changes so that there is less flux change for > the same number of bits stored (which is what you just stated > above). >(2): Pack successive bits more than 50% closer than in MFM. The 2,7 > encoding scheme requires that more bits to be stored for the same > amount of data than MFM. At the same time, RLL store 50% more > data than MFM => more than 50%. :-). However, because the > 2,7 encoding scheme reduces the flux change per bit, it worked > out to be about 14 % more ----> Don't ask me how I arrive at ^^^^ ---> 140% > this number. It is from some second hand source. This is how you get 140% more capacity using RLL 2,7 encoding. RLL 2,7 uses 7 bits to encode 5 data bits with no less than two consecutive bits of the same type. The worst case of flux change is every two bits compared with MFM, the worst case is a flux change every bit when alternating 1's and 0's are encountered. So in the space of 7 bit of MFM recording, you get 14 bits of RLL recording using the same flux density. But the 14 bits of RLL data is only representing 10 bits of actual data. The increase in capacity is: 10/7 = 1.42 or 142% By playing with the inter-sector gap, 26 sectors can be squeezed into a track compare with 17 sectors with MFM. The capacity boost is more like 25/17=1.52 or 152%. Since the flux density is the same as MFM recording, there is no reason why any disk drive cannot be use with RLL controllers. I have used ST225, ST251 with no problem. No need to pay more for RLL rated drives, they are the same drives! There is an argument that the bit shift is more critical with RLL data seperators. With the advance in data separator design this is no longer a problem and this is why the early effort of ARLL designs will not work with oxide coated drives. The ARLL increase the capacity by incresing the flux density by 25%. I do not know the Perstor controller writes 33 or 34 sectors on one track. This is almost 190% to 200% increase in capacity. Will it work with any hard disk drives? Like to see anyone with the Perstor controller post their experiences. Pat Fung patf@hpranger.HP.COM
patf@.HP.COM (pat fung) (06/27/90)
From pnl@hpfinote.HP.COM Sun Jun 24 15:26:40 1990 , Peter Lim writes: >Not according to what I know. RLL increases bits/track by doing 2 things. >(1): Re-arrange the flux changes so that there is less flux change for > the same number of bits stored (which is what you just stated > above). >(2): Pack successive bits more than 50% closer than in MFM. The 2,7 > encoding scheme requires that more bits to be stored for the same > amount of data than MFM. At the same time, RLL store 50% more > data than MFM => more than 50%. :-). However, because the > 2,7 encoding scheme reduces the flux change per bit, it worked > out to be about 14 % more ----> Don't ask me how I arrive at ^^^^ ---> 140% > this number. It is from some second hand source. This is how you get 140% more capacity using RLL 2,7 encoding. RLL 2,7 uses 7 bits to encode 5 data bits with no less than two consecutive bits of the same type. The worst case of flux change is every two bits compared with MFM, the worst case is a flux change every bit when alternating 1's and 0's are encountered. So in the space of 7 bit of MFM recording, you get 14 bits of RLL recording using the same flux density. But the 14 bits of RLL data is only representing 10 bits of actual data. The increase in capacity is: 10/7 = 1.42 or 142% By playing with the inter-sector gap, 26 sectors can be squeezed into a track compare with 17 sectors with MFM. The capacity boost is more like 25/17=1.52 or 152%. Since the flux density is the same as MFM recording, there is no reason why any disk drive cannot be use with RLL controllers. I have used ST225, ST251 with no problem. No need to pay more for RLL rated drives, they are the same drives! There is an argument that the bit shift is more critical with RLL data seperators. With the advance in data separator design this is no longer a problem and this is why the early effort of ARLL designs will not work with oxide coated drives. The ARLL increase the capacity by incresing the flux density by 25%. I do not know the Perstor controller writes 33 or 34 sectors on one track. This is almost 190% to 200% increase in capacity. Will it work with any hard disk drives? Like to see anyone with the Perstor controller post their experiences. Pat Fung patf@hpranger.HP.COM P.S. I just found that I miss used the word 'flux density'. I really mean 'flux change density' in number of flux reversal per inch. I do not use bit density because it means different for MFM and RLL encoding.
pnl@hpfinote.HP.COM (Peter Lim) (06/29/90)
From patf@.HP.COM (pat fung) / 4:04 pm Jun 26, 1990 /, Pat Fung writes: > This is how you get 140% more capacity using RLL 2,7 encoding. RLL 2,7 uses > 7 bits to encode 5 data bits with no less than two consecutive bits of the > same type. The worst case of flux change is every two bits compared with MFM, > the worst case is a flux change every bit when alternating 1's and 0's are > encountered. So in the space of 7 bit of MFM recording, you get 14 bits of > RLL recording using the same flux density. But the 14 bits of RLL data > is only > representing 10 bits of actual data. The increase in capacity is: > > 10/7 = 1.42 or 142% > > By playing with the inter-sector gap, 26 sectors can be squeezed into a > track compare with 17 sectors with MFM. The capacity boost is more like > 25/17=1.52 or 152%. > This is the most convincing argument I heard on this topic. So, this means that the info I read about from this Brady book is bullshit :-). ... and I stand corrected. I also need to apologize to the net for posting unverified info. I did claim that Perstor has 1:1 controller; but I checked this out to be not true. The absolute truth is that: Perstor produces 8-bit and 16-bit controllers; and at least one of the two comes with a miserable 2K-byte on board buffer. This means that if you have a very fast computer, it is theoretically possible to run Perstor's controller at 1:1 interleave. But the catch is ---- so far, such computer doesn't exist. Cheers. Regards, ## Life is fast enough as it is ........ Peter Lim. ## .... DON'T PUSH IT !! >>>-------, ########################################### : E-mail: plim@hpsgwg.HP.COM Snail-mail: Hewlett Packard Singapore, : Tel: (065)-279-2289 (ICDS, ICS) | Telnet: 520-2289 1150 Depot Road, __\@/__ ... also at: pnl@hpfipnl.HP.COM Singapore 0410. SPLAT !
jose@hpsad.HP.COM (Jose Gomez-Rubio (SEED Student)) (07/03/90)
I found more info on the Perstor Controller in books written by Aubrey Pilgram published by TAB Books. They mentioned the controller writes out a 5.5 megabits/sec but reads at 9 megabits/sec. Seems like no wonder they are compatiable with a bunch of hard disks. P.S. The books are: Build your own XT and save a bundle Build your own AT and save a bundle Build your own 80386 and save a bundle Copyright dates are 1987-88.