Winders

Member
  • Content Count

    2
  • Joined

  • Last visited

Community Reputation

0 Neutral

About Winders

  • Rank
    Member
  1. What if the problem is in the queue handling of the drive? Linuxers seem to have seen that phenomenon and the kernel allows them to reduce queue. One found that his problem disappeared at max queue of 4. Is there a way to have the controller only allow a queue depth of 16, instead of 32? I have tried setting HLM\SYSTEM\CurrentControlSet\Services\iaStor\Parameters\Device\NumberOfRequests to various settings like 0x1, 0x4, 0x8, 0x10, 0x18. But I'm not sure the iaStor.sys even uses the setting. If somebody could find a way to test that, perhaps we would know. If not, perhaps a way to hack the driver to a max queue depth less than 32?
  2. What about the possibility that the SD15 Seagate 7200.11 750GB was a mistake? What if HD makers intentionally keep their SATA NCQ algorithm a little crappy, so that people will still buy the SAS/SCSI? Maybe they accidentally had the wrong performance profile in SD15, and 'corrected' it in SD1A. It would make sense that they detune the performance based on what Windows does, but they can't completely screw it up without being obvious in benchmarks or non-compliant. When you use other OSes, or put a smart controller in between, the 'problem' vanishes because you no longer have a Windows access pattern. This would explain why it seems that some PATA drives performed better than NCQ. Before NCQ, IDE had no way to challenge SCSI's exclusive ability to issue multiple commands. When SATA NCQ appeared, something had to be done to make sure it didn't threaten those profits. It would explain a lot of these strange outcomes, and why nobody particularly seems to care. Also, check this list of devices out: Possibly the same problem or related? https://ata.wiki.kernel.org/index.php/Known_issues#Affected_devices_2