Image Map Image Map
Page 4 of 4 FirstFirst 1234
Results 31 to 39 of 39

Thread: XT-IDE vs. SCSI on IBM XT/286

  1. #31
    Join Date
    May 2011
    Location
    Outer Mongolia
    Posts
    1,796

    Default

    Quote Originally Posted by maxtherabbit View Post
    The SCSI disk still slaughtered the CF card in sustained transfer rate, changing file size had no impact on that (actually it boosted the SCSI numbers a fuzz)
    I'm not surprised that particular SCSI disk can roast a CF card alive when it comes to sustained linear transfer rate; the native sustained transfer rate of that drive is on the order of ten times faster than your 286 benchmarks indicate so if its prefetch algorithm is any good at all it's probably spending most of its time twiddling its thumbs and reading out stuff it's already fetched into cache even with the larger file size. Meanwhile the CF has a teeny little brain-dead flash controller that can't even read and chew gum at the same time and on writes is limited by the block-erase-oriented nature of the flash media it's controlling. No read prefetch, no cache, it's actually having to deal with the substantially-slower-than-RAM Flash chips for every block in real time. For this sort of test the Atlas is swatting a fly with a sledgehammer.

    Now if you were baking off against an actual SSD with similar caching mechanisms instead of a humble CF card... honestly, it would hardly matter. Hitting a fly with either a sledgehammer or a 200 pound anvil is overkill, the difference is just a matter of degree.
    My Retro-computing YouTube Channel (updates... eventually?): Paleozoic PCs

  2. #32

    Default

    Quote Originally Posted by Eudimorphodon View Post
    I'm not surprised that particular SCSI disk can roast a CF card alive when it comes to sustained linear transfer rate; the native sustained transfer rate of that drive is on the order of ten times faster than your 286 benchmarks indicate so if its prefetch algorithm is any good at all it's probably spending most of its time twiddling its thumbs and reading out stuff it's already fetched into cache even with the larger file size. Meanwhile the CF has a teeny little brain-dead flash controller that can't even read and chew gum at the same time and on writes is limited by the block-erase-oriented nature of the flash media it's controlling. No read prefetch, no cache, it's actually having to deal with the substantially-slower-than-RAM Flash chips for every block in real time. For this sort of test the Atlas is swatting a fly with a sledgehammer.

    Now if you were baking off against an actual SSD with similar caching mechanisms instead of a humble CF card... honestly, it would hardly matter. Hitting a fly with either a sledgehammer or a 200 pound anvil is overkill, the difference is just a matter of degree.
    Atlas' native sustained transfer rate was actually rated at 41 MB/sec, so a little closer to 15x

    Even the 1993 7200RPM Barracuda was able to edge out the CF card in sustained transfer on the 286 BTW

  3. #33
    Join Date
    Aug 2006
    Location
    Chicagoland, Illinois, USA
    Posts
    6,236
    Blog Entries
    1

    Default

    Quote Originally Posted by maxtherabbit View Post
    Eudimorphodon was correct, it was the cache skewing the results. I re-ran the test on the Atlas 10KII with file size set to 16MB: the 8K random, 70% read was averaging around 67 IOPS and sector random read was averaging around 80 IOPS. Still a damn good showing but the CF card was indeed a bit faster at 70/100 when I originally tested it with a 4MB file size. I didn't bother to rerun the CF test with a larger file since it shouldn't make a meaningful difference in theory.
    Thank you for re-running the tests and confirming our theories.

    For a 4.77 MHz system, IOPs are much more important than, say, a 386 with 4MB RAM. Smaller programs on slower systems benefit more from IOPs than transfer rate. Once you hit 386/4MB territory, programs are larger, data files are larger, caches are larger, and now transfer rate becomes more important. So it's a matter of picking the right tool for the job.
    Offering a bounty for:
    - A working Sanyo MBC-775, Olivetti M24, or Logabax 1600
    - Music Construction Set, IBM Music Feature edition (has red sticker on front stating IBM Music Feature)

  4. #34

    Default

    Quote Originally Posted by Trixter View Post
    Thank you for re-running the tests and confirming our theories.

    For a 4.77 MHz system, IOPs are much more important than, say, a 386 with 4MB RAM. Smaller programs on slower systems benefit more from IOPs than transfer rate. Once you hit 386/4MB territory, programs are larger, data files are larger, caches are larger, and now transfer rate becomes more important. So it's a matter of picking the right tool for the job.
    Yeah. I can see the CF card being a solid choice for a 5150/5160. Of course, the cache on the mechanical drives does confer real-world benefit as well so we can't count it out as a feature - it's just somewhat more limited in the scope of its benefit than a 4MB synthetic benchmark would reveal.

    The 286 system in my tests is 12MHz (0-wait) with 4MB RAM and OP's system is a 5162 so I guess we're in a middle ground where either solution would have it's merits.

  5. #35
    Join Date
    May 2011
    Location
    Outer Mongolia
    Posts
    1,796

    Default

    Quote Originally Posted by maxtherabbit View Post
    Yeah. I can see the CF card being a solid choice for a 5150/5160. Of course, the cache on the mechanical drives does confer real-world benefit as well so we can't count it out as a feature - it's just somewhat more limited in the scope of its benefit than a 4MB synthetic benchmark would reveal.
    Of course, another way to look at it is a CF card is pretty much *the* bottom of the barrel baseline for slow performance in the world of "SSDs" (other than bit-banged SPI on an SD card?), yet it still manages superior random access times compared to a nuclear weapons-grade Ultra 160 SCSI drive. Just imagine what a more capable SSD could do.

    (Although, as I noted earlier, I do wonder if you're going to have some issues getting optimal transfer rates out of IDE on a 286. My experience, which admittedly isn't that extensive, is you can run into all sorts of annoying difficulties with getting faster drives to behave properly in systems that predate UDMA/33 as a minimum baseline. This particularly applies to PATA/SATA adapters, which you'd almost certainly need to put in a real large-caliber SSD... unless you do SATA->SCSI, which is doable but the adapters get ridiculous. There were a precious few parallel Ultra320 SSDs made but they're rare as hen's teeth and looking at eBay... yeah, I don't think anyone's spending that for a 286.)

    Of course, realistically, it would just come down to how completely can you max out the benchmark, there's going to be zero practical benefit. For straight DOS "retrocomputing" I can't offhandedly think of a realistic use case that's going to benefit that much from data transfer rates faster than a CF card. (We're talking about about maybe one second's difference either way in how long it takes to read in a level from a DOOM .WAD?) Once you start talking about running Windows (or OS/2, or whatever) that might be constantly swapping RAM and overlays actively in and out in the background then transfer (and write) speeds would definitely be more of a factor to consider.

    And of course there's always the factor of if you simply think it's fun to cobble together a massive fire-breathing retro-SCSI monster of a storage system instead of settling for a puny and boring alternative. That's a perfectly legit reason to go that direction as well.
    My Retro-computing YouTube Channel (updates... eventually?): Paleozoic PCs

  6. #36

    Default

    Quote Originally Posted by maxtherabbit View Post
    I just like spinning rust, what can I say
    A kindred spirit.
    Once upon a time, the internet sucked because it came through the phone. Now the phone sucks because it comes through the internet.

  7. #37
    Join Date
    Dec 2007
    Location
    Texas Hill Country
    Posts
    134

    Default

    Without reading the whole thread, I dealt with SCSI on my 5170 all night. Ended up using the stock MFM controller (for the floppy portion) and an Adaptec AHA-1542CF (with floppy disabled). Talk about a PITA finding a working configuration. I tried an 8 bit Storage Dimensions controller, as well as the WD7000, a controller by DPT, and another by a no-name company.
    IBM Computers: 5150 (16-64K, 64-256K), 5160, 5161, 5162, 5170 (regular and Tempest), Option 370 16 bit, PC Convertible
    PS/2 Machines: 30, 40SX, 50Z, 55SX, 60, 70, 77 (Lacuna & Bermuda), 80, 85, 90 XP, 95, "E"
    Vintage ThinkPads: 300, 360C/CE, 510CS, 560/E, 600E/X, 701C/CS, 700, 720C, 730TE (tablet), 750C/P (color and tablet models), 755C/CE/CD/CDV/CX, 760ED, 765L, 770
    Vintage UNIX workstations: 2/120, 3/75, 3/60, SS 2/5/20, U2 Ent, HP 715/100, several RS/6000s

  8. #38

    Default

    Quote Originally Posted by pkhoury View Post
    Without reading the whole thread, I dealt with SCSI on my 5170 all night. Ended up using the stock MFM controller (for the floppy portion) and an Adaptec AHA-1542CF (with floppy disabled). Talk about a PITA finding a working configuration. I tried an 8 bit Storage Dimensions controller, as well as the WD7000, a controller by DPT, and another by a no-name company.
    Finding a working drive/controller combo is something that I've struggled with as well.
    Once upon a time, the internet sucked because it came through the phone. Now the phone sucks because it comes through the internet.

  9. #39

    Default

    I have no SCSI drives left, They all died and got binned a long time ago, In my IBM 5170 and 5162 i swapped out the IBM Bios for the AMI bios and use the XUB and a 16-bit IDE/Floppy controller with no problems.

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •