If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. |
|
|
Thread Tools | Display Modes |
#101
|
|||
|
|||
Poor raid 1 performance?
Change odd and even sectors in odd and even strip(e)s and your story starts
to make some sense. Unfortunately strip(e)s are a hindrance in RAID1, e.g. if a file is in 3 strips it is read in 3 chunks when it could have been read faster in 2 (1+ strip by one drive, 1+ strip by the other). "Antoine Leca" wrote in message In , Bob Willard va escriu Antoine Leca wrote: But while considering only 256 sectors, you did not answer. Will an actual drive deliver the same throughput when you ask it to read 256 continuous sectors, as when you ask it to read all even-numbered sectors from 100,000 to 100,510 (count is 256 too)? I don't know of any HDs that support a command to read every other sector. Neither do I. But I believe (could be wrong) there is the possibility to send "some" commands to be "queued" (not sure that is the correct term), that is, without waiting for the precedent to be completed. With that feature, one can send various otherwise independent commands in a row, for example, 256 commands to read one sector each (the even-numbered ones). As a result, you are asking the drive to read all even-numbered sectors from 100,000 to 100,510. Even if a hypothetical HD could be told to read every other sector, it would read from the platter at half-speed, since it takes just as much time to skip a sector as to read it. That is what I thought too, and it seems we all agree at this point. It seemed to me that a sequencial read (issued by the OS as various I/O commands) from a RAID-1 array will be seen by one drive inside the array just this way, as a successiveness queue of commands to read the even-numbered sectors. (And please do not tell me it is silly to cut into such small units as sectors, and that it would be much more efficient to use bigger "block": it was my point initially behind the word "stripe", admittedly misused here; but it appeared it was misunderstood so I needed to simplify the scheme. Vocabulary is a big problem for beginners.) Now, if the OS is not stupid/silly, it will group the read commands into a _unique_ one, for 512 sectors here (and the RAID controller can do it also, just in case); and then the controller will only issue one command to the drive, for half the sectors (one drive will provide sectors 100,000 to 100,255; and the second 100,256 to 100,511). *Maybe* this was the point that Folkert was trying to make "initially" freenews.net), when he said I was too much focused ("fascinated") on hardware and I were missing the overall picture, "IO-commands". Could very well have been so, as seen when I re-read the thread (for example, what Folkert said to Gerhard Fiedler in reenews.net: I understand it is almost exactly what I wrote just above.) {Not true if the read is satisfied from the HD's cache, of course. In that case, the answer would be "implementation-dependent".} Of course. Which is why I tried to avoid this effect by referring to the vagueness of "long" reads, thinking it will be clear. Antoine |
#102
|
|||
|
|||
Poor raid 1 performance?
"Antoine Leca" wrote in message
In reenews.net, Folkert Rienstra va escriu The second drive also transfers in bursts. The second drive bursts in between the first drive's bursts. I do not see why there would be a need for such temporal dichotomy, assuming of course that both drives are not together on the same physical link. IDE is a 2 device bus interface. For my enlightment, how common are RAID controllers using (paired) IDE devices? Very. There are more expensive ones that have restricted themselfs to using only 1 device per channel and they come with single device cables only. Instead of 2 channels they come with 4 or even 8. I learned reading http://www.storagereview.com/guide20...lMultiple.html, but it seems a bit old (2000?), particularly when it comes to disk interfaces. In a nutshell that says: ATA can't multitask so lets rant about SCSI. Not very useful. Where can I find present-day informations? Nothing much changed except maybe Overlapped and Queued feature set which should bring ATA upto speed with SCSI but that never caught on. IDE (I prefer to speak of IDE here, because ATA actually can) cannot start simultanious reads from 2 devices on the same channel or start a read and write simultaniously unless the write goes before the read. What this boils down to is that you can't in some circumstances average your access times (no parallel seeks) and can't use the full bandwidth of the channel (empty bursts) so that your accesses appear simultanious (parallel), instead they are serial (one access after the other) and you get only half the thruput per drive. This isn't so much of a problem for long sequential reads (to start with: no seeks) and no real need to start commands simultaniously(*) because when one drive reads the other caches ahead and buffers, the whole transfer is at 100% interface speed from buffer when the command that requests that data comes. So it looses half by being serial but gains 100% by being able to use the full bandwidth for itself. (*) Only the first commands are in serial, every next one is virtually parallel as long as the read commands are sequencial. For example, I imagine both are connected using SATA to different channels. Yes, I made a comment about that later, but as usual you snipped that again. About "single channel" vs. "separate channel", right? Yes, and how they appear on the PCI bus. I am sorry, I did not (then) match the terminology, now I did better (read the above article, for once.) OTOH, if you are considering SCSI-linked drives, I could see your point. No difference if you use dual channel SCSI. I was assuming this would allow two transfers to occur simultaneously, wouldn't it? And this question is about IDE or SCSI or both? Or dual channel SCSI only? Thanks for your explanations, and your patience. As you can read in the other post, I perhaps finally understood your point. Perhaps. Antoine |
#103
|
|||
|
|||
Poor raid 1 performance?
In reenews.net,
Folkert Rienstra va escriu Where can I find present-day informations? Nothing much changed except [...] Thanks for your feedback (I snipped for the post, but I am actually digesting it, seems much worth reading). Antoine |
Thread Tools | |
Display Modes | |
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Poll (please): Time-shifting Performance | Bryan Hoover | Ati Videocards | 1 | December 15th 04 11:56 PM |
Question about performance | The Berzerker | Ati Videocards | 1 | September 27th 04 09:25 PM |
G400 & G-series RR performance question. | Kevin Lawton | Matrox Videocards | 6 | May 20th 04 09:51 PM |
Maximum System Bus Speed | David Maynard | Overclocking | 41 | April 14th 04 10:47 PM |
Geforce 4 2D/desktop performance in WinXP | zmike6 | Nvidia Videocards | 2 | August 29th 03 07:41 AM |