Image Map Image Map
Page 3 of 4 FirstFirst 1234 LastLast
Results 21 to 30 of 39

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

  1. #21
    Join Date
    Oct 2014
    Location
    near frankfurt/m, germany
    Posts
    981

    Default

    If you are locky the the file is in the cache, But only after reading it once. CF is full capacity cache. No need to reads the file twice to get full speed at the 2nd time.

  2. #22
    Join Date
    Oct 2014
    Location
    near frankfurt/m, germany
    Posts
    981

    Default

    Quote Originally Posted by Stone View Post
    Ya', nothing really compares to nitpicking over factors with fundamentally meaningless values.

    Already fixed. Bit still fast enough to fill the dos memory of 640 kb in less than 2 seconds.

  3. #23

    Default

    Quote Originally Posted by Eudimorphodon View Post
    The Quantum Atlas has an 8MB cache buffer with a sophisticated prefetch algorithm. According to this page:

    https://www.lo-tech.co.uk/wiki/DOS_Disk_Tester

    That test, unless otherwise instructed, uses a 4MB test file. It's very possible the entire file fits into the cache. In which case, sure, it's going to be faster, it's running from actual RAM.
    That's an interesting point, I'll try to circle back around to the test with a >8MB file and see if the results change substantively

  4. #24
    Join Date
    May 2011
    Location
    Outer Mongolia
    Posts
    1,783

    Default

    My assumption would be that if you tested an IDE drive that also had a massive onboard cache the results would be similar, although we get into the sticky area of software support for faster transfer modes; getting a SCSI card to work at full speed might well be easier than trying to get IDE flying at full blast in a 286, or just playing nice with a huge modern IDE drive period. (I don't know if the SCSI card in play here is using DMA or otherwise behaving in a more sophisticated manner than PIO Mode 0, which *theoretically* can push 3.3MB/sec but may well be CPU limited.)

    In any case, again, I can't imagine benchmark-breaking results like this ever realistically translating into performance you'd notice on a 286 class machine and, as noted, if what's happening with this particular benchmark is the drive's cache is getting populated when the test initializes and you're just exercising that then a flash drive, even a relatively slow one, probably *will* be more responsive in real life. (At least until your cache gets loaded up.) We're in this odd area where we're comparing a horse wearing a jetpack to a Honda Civic. Which one is faster? Well, the horse, technically, at least under certain conditions, but it's kind of an overengineered solution if you just want to fetch groceries.
    My Retro-computing YouTube Channel (updates... eventually?): Paleozoic PCs

  5. #25

    Default

    Quote Originally Posted by Eudimorphodon View Post
    My assumption would be that if you tested an IDE drive that also had a massive onboard cache the results would be similar, although we get into the sticky area of software support for faster transfer modes; getting a SCSI card to work at full speed might well be easier than trying to get IDE flying at full blast in a 286, or just playing nice with a huge modern IDE drive period. (I don't know if the SCSI card in play here is using DMA or otherwise behaving in a more sophisticated manner than PIO Mode 0, which *theoretically* can push 3.3MB/sec but may well be CPU limited.)

    In any case, again, I can't imagine benchmark-breaking results like this ever realistically translating into performance you'd notice on a 286 class machine and, as noted, if what's happening with this particular benchmark is the drive's cache is getting populated when the test initializes and you're just exercising that then a flash drive, even a relatively slow one, probably *will* be more responsive in real life. (At least until your cache gets loaded up.) We're in this odd area where we're comparing a horse wearing a jetpack to a Honda Civic. Which one is faster? Well, the horse, technically, at least under certain conditions, but it's kind of an overengineered solution if you just want to fetch groceries.
    As far as how they "feel" honestly I think they feel the same.

    My whole argument is, put simply: "if you want to maximize storage performance on a slow CPU, there are other options than flash memory"

    I just like spinning rust, what can I say

  6. #26
    Join Date
    Aug 2006
    Location
    Chicagoland, Illinois, USA
    Posts
    6,222
    Blog Entries
    1

    Default

    Quote Originally Posted by maxtherabbit View Post
    My whole argument is, put simply: "if you want to maximize storage performance on a slow CPU, there are other options than flash memory"
    I'd amend this to "If your workload is not random-access-heavy, there are other options than flash memory".
    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)

  7. #27

    Default

    Quote Originally Posted by Trixter View Post
    I'd amend this to "If your workload is not random-access-heavy, there are other options than flash memory".
    I'm still not convinced that the 10K SCSI drive with busmastering HBA can't defeat the flash memory even in random access, but I will re-run the test as advised.

  8. #28
    Join Date
    Aug 2006
    Location
    Chicagoland, Illinois, USA
    Posts
    6,222
    Blog Entries
    1

    Default

    It's pretty easy to win a random IOPs contents when the entire dataset is in cache.

    Also, any XTIDE card in the comparison should have the correct BIOS flashed on it. It isn't fair to compare to an XTIDE card where the XUB is configured to 8-bit PIO when 16-bit REP INSW is available on the host platform.
    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)

  9. #29
    Join Date
    Jan 2007
    Location
    Pacific Northwest, USA
    Posts
    33,122
    Blog Entries
    18

    Default

    Quote Originally Posted by Trixter View Post
    I'd amend this to "If your workload is not random-access-heavy, there are other options than flash memory".
    Yeah, a good fast tape drive will work...

  10. #30

    Default

    Quote Originally Posted by Trixter View Post
    It's pretty easy to win a random IOPs contents when the entire dataset is in cache.

    Also, any XTIDE card in the comparison should have the correct BIOS flashed on it. It isn't fair to compare to an XTIDE card where the XUB is configured to 8-bit PIO when 16-bit REP INSW is available on the host platform.

    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.

    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)

    CF card numbers were based on the correct XUB with 16-bit PIO and 286 instruction set.

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
  •