• Content Count

  • Joined

  • Last visited

Community Reputation

0 Neutral

About Tiberius

  • Rank

Contact Methods

  • AIM
  • ICQ
  1. Tiberius

    Tcq, Raid, Scsi, And Sata

    i hate to triple reply but i just noticed the comment about software RAID up top-- you are exactly right! the RAIDcore is actually a highly optimized software implementation, and you can tell- it doesn't require obscenely deep queues to break even on performance, and in certain benchmarks that traditionally rub very poorly with hardware-accelerated RAID controllers, the RAIDcore delivers performance shockingly superior to not only comparable SATA controllers, but high end SCSI implementations. if you are going to dismiss RAID out of hand, at least catch the right culprit: processing overhead. an optimal implementation of RAID would yield performance benefits in any disk-limited application, but realistically processing overhead and serialization of requests limits the realization of this theoretical advantage.
  2. Tiberius

    Tcq, Raid, Scsi, And Sata

    apparently you can't edit i meant to say "display random access time benefits in RAID0", not throughput
  3. Tiberius

    Tcq, Raid, Scsi, And Sata

    few things 1. the controllers in this review all kind of suck-- try including the escalade 9xxx or RAIDcore controllers, as suggested. 2. the benchmarks all represent a productivity user on crack scenario-- real power users move happy fellowtons of data around, and I didn't see a single large file transfer benchmark, something that is either going to represent a *very* deep queue environment (gather of fragmented sectors in P2P downloads) or a linear read/write (something an optimized RAID-0 implemention should slaughter). 3. real world benchmarks. these synthetic drivemark scores are all fine in practice, but they don't represent real-world patterns at all, and IO/sec is a pretty vague figure- real file systems aren't perfectly sector aligned, and the clock you're staring at waiting for UT2K4 to load isn't demarcated in I/Os. while i agree that random access time is not going to improve a lot through the use of RAID-0 in the average single user environment, any respectable implementation of RAID-0 will yield much higher average real-world throughput, and there are in fact single user tasks that display random throughput benefits in RAID0. (small file throughput in reiserFS comes to mind- single 30GB disk took ~9 minutes to prune undesired content from an archived web site, 3x 9gb (5 year old scsi disks with absolutely miserable STR) array took ~2 minutes, array-to-array versus disk-to-disk times for tar extraction and file copy are orders of magnitude greater as well) biased data against RAID doesn't do anyone any more good than biased data for it, and dismissing dissenting opinions *certainly* doesn't do any good.
  4. Tiberius

    Partitioning For Speed?

    also p2p software is horrible for fragmenting your drives a seperate p2p scratch space partition is advisable (and move it from that partition to your data partition when the transfer finishes or whatever) partitions are fun
  5. Tiberius

    Partitioning For Speed?

    actually you want a small windows partition (you don't need to seperate swap off of it though) if you just use a big partition many system files will end up having their sectors spread over a very wide range of cylinders as they're replaced or appended to or rewritten and as a result the average latency of accessing certain windows system files will be (much) greater using a ~4gb partition for \Windows and seperate partition for Program Files is ideal using 4gb of 160gb for windows means when booting or whatnot the maximum access latency will be the interface and processing latency plus rotational latency plus 4/160ths of the seek latency... it works out to like ~4ms vs ~12ms. definite improvement. use the windows partition for swap but make sure you remove it defrag and then set it for a fixed size otherwise it'll resize itself and frag your stinker as well. if you use photoshop or rip dvds it generally helps to create an additional partition roughly the size of the scratch space you need to avoid the scratch files/dvd image being fragmented by and/or fragmenting your data partition (and if its a scratch file limiting the range of cylinders by using a partition will improve performance via random seek latency) end barely coherent rant