fanj@remb6489.wpd.sgi.com (Fan Jiao) (05/25/90)
I posted a msg asking for help on the issues of MFM and RLL. And I got several very helpful responses and pointers. And I'd like to share with you. I have Micropolis M1335 and M1323. The parameters are: 1024 Cyl X 8 Heads X 17 Sectors/1024 Cyl X 4 Heads X 17 Sectors. I got a new WD1006V-SR2 to re-format Micropolis' 71Meg(1335) and 34Meg(1323). I got 107 Meg from the 1335, while 43 Meg, 1323(I could not find any closer match to 1024X4; instead I used 820X4). I ran SI on C:, and the index is 3.6, compared with 2.7 in MFM 3:1 case. I also did CORETEST. The transfer rate now is 672 KB/sec, while it was 162 before. -- Fan Jiao(Chiao) x 1615 | M/S 9U-510
davidsen@sixhub.UUCP (Wm E. Davidsen Jr) (05/26/90)
In article <60997@sgi.sgi.com> fanj@remb6489.wpd.sgi.com (Fan Jiao) writes: | I got a new WD1006V-SR2 to re-format Micropolis' 71Meg(1335) and 34Meg(1323). | I got 107 Meg from the 1335, while 43 Meg, 1323(I could not find any closer | match to 1024X4; instead I used 820X4). But you can have a perfect match... set the drive type to one and fill in the blanks. -- bill davidsen - davidsen@sixhub.uucp (uunet!crdgw1!sixhub!davidsen) sysop *IX BBS and Public Access UNIX moderator of comp.binaries.ibm.pc and 80386 mailing list "Stupidity, like virtue, is its own reward" -me
phil@pepsi.amd.com (Phil Ngai) (05/26/90)
In article <60997@sgi.sgi.com> fanj@remb6489.wpd.sgi.com (Fan Jiao) writes: |I got a new WD1006V-SR2 to re-format Micropolis' 71Meg(1335) and 34Meg(1323). |I got 107 Meg from the 1335, while 43 Meg, 1323(I could not find any closer |match to 1024X4; instead I used 820X4). You can customize the geometry, it's an entry on the menu you get when you run cc00:5. |I ran SI on C:, and the index is 3.6, compared with 2.7 in MFM 3:1 case. |I also did CORETEST. The transfer rate now is 672 KB/sec, while it was |162 before. Did you set 1:1 interleave? You should get about 798 Kb/s. -- Phil Ngai, phil@amd.com {uunet,decwrl,ucbvax}!amdcad!phil The Green Movement has Red Roots.
del@fnx.UUCP (Dag Erik Lindberg) (05/29/90)
In article <60997@sgi.sgi.com> fanj@remb6489.wpd.sgi.com (Fan Jiao) writes:
=
=I posted a msg asking for help on the issues of MFM and RLL. And I got several
=very helpful responses and pointers. And I'd like to share with you.
=
=I have Micropolis M1335 and M1323. The parameters are:
=1024 Cyl X 8 Heads X 17 Sectors/1024 Cyl X 4 Heads X 17 Sectors.
=
=Fan Jiao(Chiao)
=x 1615 | M/S 9U-510
What I want to know is, what is this junk (and all the 'helpful' replies)
doing in comp.sys.ibm.pc.programmer?
--
del AKA Erik Lindberg
uunet!pilchuck!fnx!delshwake@raysnec.UUCP (Ray Shwake) (05/29/90)
In article <60997@sgi.sgi.com> fanj@remb6489.wpd.sgi.com (Fan Jiao) writes: >I ran SI on C:, and the index is 3.6, compared with 2.7 in MFM 3:1 case. >I also did CORETEST. The transfer rate now is 672 KB/sec, while it was >162 before. With the exception of the seek time figures, I don't lend much credence to CORETEST results. The throughput analysis appears to use large block data streams (usually 32K or 64K) whereas most applications and operating systems use .5K - 2K transfers. The presence of software disk cache will also skew results so much they become meaningless. With version 2.8 they at least recognize the use of cache, but results are still worthless. Norton's SI doesn't appear to be anything special where disk measurements are concerned. One interesting benchmarker I've come across comes from Western Digital and Columbia Data. It's called TESTDISK. One of the nice things about it is that it measures throughput for a RANGE of block sizes. I'm currently waiting for SEABENCH from Seagate. Don't know if Segate or Imprimis (now absorbed by Seagate) developed it.
wargopl@image.soe.clarkson.edu (Peter L. Wargo) (05/30/90)
From article <37@raysnec.UUCP>, by shwake@raysnec.UUCP (Ray Shwake): > In article <60997@sgi.sgi.com> fanj@remb6489.wpd.sgi.com (Fan Jiao) writes: >>I ran SI on C:, and the index is 3.6, compared with 2.7 in MFM 3:1 case. >>I also did CORETEST. The transfer rate now is 672 KB/sec, while it was >>162 before. > > With the exception of the seek time figures, I don't lend much credence > to CORETEST results. The throughput analysis appears to use large block > data streams (usually 32K or 64K) whereas most applications and operating > systems use .5K - 2K transfers. The presence of software disk cache will > also skew results so much they become meaningless. With version 2.8 they > at least recognize the use of cache, but results are still worthless. Coretest will allow you to change the block size... you can go from 1k to 64k in 1k inc. (In my version) type "coretest ?" Pete -- Peter L. Wargo - wargopl@sun.soe.clarkson.edu, amoung others... "I don't believe it - I just spent 4 years at an expensive university- and I end up as a top-40 DJ..."