Well Windows XP and 2003 are both pretty greedy with hardware, if you want to do anything with them besides watch screensavers.
At my last job my desktop machine was a dual P3 with 1GB of RAM, dating back to 2000. I was quite happy using that machine, and my workload is *far* from light (dozens of putty windows, several Firefox windows with a dozen tabs each, multiple VMWare machines, etc).
I can't count the number of clients I have that torture themselves daily with 4 year old Dells because they don't want to spend money upgrading.
Worst case is they need a RAM upgrade to 512MB of 1GB. Unless by "torturing" you mean actually trying to run performance-intesive software (in which case, it's hardly the OS's fault).
Last year's machine may be okay, 2 year old hardware can be fine, but don't kid yourself that a P3-733 with a slow, old 20G hard drive will cut the mustard.
It certainly will if it has enough RAM.
Once it gets infected with spyware, which is inevitable, it'll be so useless you might as well use it to prop open a door.
It's far from inevitable. Basic security practices result in a malware-free Windows PC.
I wasn't trying to imply that you had made that suggestion. Just to be clear, this whole discussion has been about latencies, not transfer rates.
The problem is you don't appear to be using the term "latency" in a meaningful or consistent fashion.
With RAID-1 it doesn't matter that the requests are balanced. a two-way mirror gives a 2x improvement in average latency. Make it a 3-way mirror, and you'll have a 3x improvement.
False.
With RAID-0, the balance of requests does matter. Assume two disks, one containing even block numbers, the other containing odds. If the requests are pathological, i.e. all odds, the improvement will be 0. But if *any* of the requests are even, then there's an improvement.
In transfer rate, yes. In latency, no. In overall performance, maybe.
Wikipedia backs up what I have said. Please read what it says.
That doesn't make it correct. Indeed, whoever wrote that Wikipedia article has the same problems with terminology and assumptions you do.
I'll make one last attempt to explain why RAID will not improve latency, and will generally make it worse. If you can't see the physics and maths that make it so, there's not going to be much I can do to change your mind.
Consider the scenario where you have a three-disk RAID0, with a 64kb chunk size. A request for 140kb is made, and conveniently enough, is contained in chunks on all three disks. So they are able to operate in parallel and provide maximum benefit.
Disk 0 seeks to the appropriate place and takes the average seek time of 8ms.
Simultaneously, Disk 1 seeks to the appropriate place, however, since the necessary block is further away from the head, its seek time is 11ms.
Disk 2 is lucky, and the necessary data is quite close to the read head. It's seek time is only 4ms.
The disk return the the chunks, which are appropriately assembled by the RAID layer and passed back up to the OS (since the requests are so small, the transfer times in this example are negligible - this is the sort of disk operation where a RAID array's performance suffers).
The latency for this operation was 11ms (plus a tiny amount for transfer). The time taken by the slowest seek. Why ? Because the operation could not complete until both chunks of the stripe had been retrieved, even though two of the three disks involved only took 4ms and 8ms.
Now, if we take a more ideal view and say that all three disks only take the average seek time (8ms) to return their chunks. The latency for the operation is *still* 8ms, because it cannot complete until all three disks have returned their chunks. It will most certainly *not* be <3ms, which is the result you would claim was possible (8/3).
The RAID array can never have have a latency lower than that of the component devices. Obviously, since that value can only ever even match the component devices in ideal conditions (perfectly parallelised operations), it will be higher on average than the component devices' average. This is why the average latency of a RAID array will be higher than the average latency of a single drive, even if that drive is identical to the RAID component drives.
(This is the same logic that dictates a RAID1 cannot have write performance better than an individual disk.)
Also, this example is talking about a RAID0, which is about as best-case as you can get in terms of overall RAID performance. Other RAID levels that offer no advantage - or even a penalty - for writes (particularly random writes) like RAID1 and RAID5, only swing the latency advantage further towards the individual disk case.
Here is another way to think about it. By your reasoning, a RAID1 made up of eight disks with an 8ms latency would have an average latency of 1ms. Do you seriously believe if you benchmark an eight-disk RAID1 you'll get an average seek time of 1ms ?
And defending/protecting against them should be a primary function of the OS.
Which Windows does.
And they do actually defend in a lot of ways, preventing modifications to the registry, stopping spyware installing itself and stopping viruses getting executing on your machine by scanning files as they are opened/run.
They only need to do this when the user (or a software bug) has circumvented or otherwise nullified the protection offered by the OS. I consider that to be cleaning up after the fact, rather than stopping it before it happens.
(The G4 still kicks the crap out of 'em at comparable speeds, but since the fastest mobile G4 Mac you can get is 1.67 Ghz, it's a moot point).
No it doesn't. The Pentium M is as fast - if not faster - than the G4 at the same clock speed, and has more than triple the memory bandwidth on the 533Mhz FSB models.
G4s are *spanked* by Pentium M's, even at the same clockspeed, except for those very carefully chosen benchmarks Apple likes to use. The G4 hasn't been a competitive performer for *years*.
Interesting comment--considering that they are teaching Intelligent Design alongside Evolutionary Theory. Your comment seems to indicate that, by teaching ONLY Evolution, that's how we develop Independent Thinking? Tell one side of a story? Somehow, that seems more like indoctrination to me.
The problem is not the teaching of Creationism. The problem is the teaching of Creationism in a science classroom. Creationism is not science. It is Religion or, at a big stretch, Philosophy.
Should the religious zealots ever manage to come up with something scientific, I've no doubt it will be taught in a science classroom. But Creationism ain't it.
Surely defending against spyware and security breaches should be a primary function of the OS, rather than an application that is built to run on the operating system.
Anti-virus/spyware software doesn't really "defend" against the attacks, they clean them up after they've happened.
Spyware basically is malware takes advantage of a poorly architected Windows environment, n'est-ce pas?
How is an environment that runs what the user tells it to run "poorly architected" ?
You *are* aware that most malware gets in via users clicking "OK" in the wrong places, executing malicious email attachments, and installing software that includes the stuff, right ? Most of it - assuming the software is up to date - doesn't get in through software bugs or flaws.
Your "poor architecture" environment implies that it would be *impossible* to run Windows and not fall victim to malware. This is blatant FUD and couldn't be further from the truth.
Actually no its not. IE and Windows Media were textbook cases. They entered a new unrelated market and bundled the software for free to do it.
How can you say that when IE was available as a standalone download (and gained most of its market share) *years* before it was integrated into Windows, and media player was included with Windows for *years* before there even was a "media player market".
That's Apple's game because Apple doesn't have the same OEM pressure that Microsoft does.
The only reasons newer versions of OS X get faster is because the old versions were so damn slow. They didn't have anywhere to go but up.
This doesn't really apply to Windows, which has always been quite usable on both current and 3 - 5 year old hardware. OS X, even on brand spanking new G4-based Macs, is slow. Back when it was first released, even on the cutting edge Macs of the day, OS X ran like a dog. This has never happened to Windows.
Microsoft have an excellent track record of supporting older hardware and making sure Windows is usable on it. In general, anything <=5 years old will run the current version of Windows usably, perhaps requiring a small RAM upgrade. This "Microsoft forces upgrade every year" FUD that gets rolled out on Slashdot every other day is pure, unaldulterated bullshit. Games are about the only thing the typical consumer will ever find "forcing" them into "yearly upgrades".
What does that mean? Is that some sort of tax maneuver?
Yes. The employer purchases the machine on the employee's behalf, and then subtracts the amount from the employee's before-tax salary, spread over a number of salary cycles (ie: paychecks) specified by the employee (up to a certain amount, I think it's 3 - this is why the opportunity is generally only relevant to those on relatively high salaries). Additionally, since the purchse is being made by a business, they don't pay GST (sales tax) and the GST refund goes to the employee.
Basically, it makes the entire cost of the laptop a tax deduction, and the employee immediately receives a 10% GST "refund". The downside is the employer must be prepared to do it, the employee's paycheck will probably be substantially less while the payments are deducted from it and it's only applicable to laptops.
Employees are allowed to do this once a year (technically, a "Fringe Benefits Tax" year, which is slightly different to a "Taxation" year). The "rort", of course, is employees who do this every year and then immediately on-sell the laptop on ebay (or similar). If you buy, say, a $4000 laptop and resell it for $3500, you'll make about $1000 out of it (from memory, it's been a while since I did it, and I was on a different tax bracket back then).
I did not show the best case nor did I treat it as the general case. I used one of the simplest cases to illustrate my point.
Huh ? Perfectly balanced, parallelisable IO (as per your RAID1 and "checkout" examples) is about as "best case" as you can get when talking about RAID IO.
And you *are* treating it as a general case by saying such IO will be the rule, rather than the exception.
You're almost there.
Well, I'm starting to understand what you're trying to argue. That doesn't make it right with regards to what I'm saying, however.
No, it's a latency issue. It has nothing to do with throughput, by which I assume you mean transfer rate. Consider the case where each read is for a single byte, or in my analogy, each shopper has a single item. Throughput doesn't matter, it's latency.
Look, your shopping analogy *does not work* in the general case because it is based on the assumption that each checkout (ie: disk) can operate independently of, and simultaneously with, all the others. You need an ideal scenario for this to be true, and these are rare. Typically an IO to a RAID will have to touch multiple disks, and will also not access the disks in an equitable fashion. Repeating carefully selected best case scenarios won't change the general case.
There are only two cases where a RAID array can even have latency equivalent to a single drive, and that is when a) the IO only touches a single component in the array, or b) the array components are all perfectly synced and the IO operations to the individual drives are processed and complete perfectly parallel - and when you're talking about a single drive with a lower latency than any of the array components, neither of them are possible.
You're correct in saying that the more knowledge the RAID controller ( whether it be hardware or software ) has about the data, the more it can optimize performance, but it's only in the patholgical cases where there will be no improvement.
An operation that touches multiple drives in a RAID array *cannot* have better latency than a single drive operation. No amount of controller of software intelligence can change physics and maths. It may have higher throughput, but whether or not that makes the overall operation complete quicker depends on the request size. A single drive with a 4ms latency but only 75MB/s transfer rate will complete a 300kb IO quicker than a typical 4 disk RAID0 with 170MB/s of throughput and a 10ms latency, even if we assume a perfect best case scenario for the RAID array.
You're also right to say that quicker disks are a win. But even the fastest disk in the world can be easily swamped by a large number of requests.
I never suggested a single drive will always offer better overall performance than a RAID array. Merely that it will have better latency.
more spindles == faster service
This is not always true, and no amount of repetition on your part will change that.
There are two distinct parts of any disk IO operation. How quickly the device can be ready to transfer the data (the latency) and how quickly the data comes off the device (the throughput). Even in an absolutely ideal situation, a RAID array *cannot* have better latency than an individual disk (assuming the disk is of equal or better performance than the RAID components). It might be equal, but it can't be any faster (and will usually be slower). OTOH, an array will have higher throughput. So, if your IO operations are throughput-bound (generally, large and sequential) the RAID will be faster. However, if they're latency bound (generally, small and random) the individual disk (or RAID of fewer, lower latency disks) will be faster. Only when the throughput advantage starts to overwhelm the latency advantage, will overall performance increase (which is what I think you mean when you say latency).
These two principles follow through into RAID arrays themselves. The more spindles you add, the worse lat
All of them? You started off by saying that I gave "the one" example of RAID reducing the overall latency of multiple reads.
I pointed out that you picked the one aspect where latency *might* be improved. There's typically a lot more to disk access than perfectly parallelisable disk reads.
I'm talking about *average* performance in the *general* case. On *average*, in *general*, RAID will increase latency. There are certainly examples of specific situations where this is not true, but that doesn't change the *general* case. Particularly when those examples only actually manifest in ideal conditions.
Well, it's not the only one. RAID-0 will give the same result unless the data is pathological somehow, e.g. it clashes with some other interleaving scheme.
Which is quite likely. There aren't many scenarios where it's possible to specifically tune the stripe size to the file size, nor control the physical placement on disk of logical files.
For RAID0 to give the same result, you would need 2 simultaneous reads <=$STRIPE_SIZE, where the data was on different disks. Again, not likely to be a common case.
I understand what you're saying about the independence of checkout lanes, but it's the same as having a fairly uniform distribution of read requests (across the range of blocks in the volume).
No, I don't think you do. The reasons the checkout lanes are "independent", is because the progress of any arbitrary customer through any arbitrary checkout lane is completely self contained. No matter how fast or slow one lane may be progressing, they have no affect on the "processing speed" of any other lane. This does *not* apply with most RAID arrays as typically a logical array transaction will have to touch multiple physical drives. That is, your overall access time to the array, per operation, is dependent on the slowest drive's (involved in the transaction) individual seek time, because the transaction as a whole cannot complete until the slowest drive has. Hopefully you can see that this cannot be better than any individual drive's seek time and, on average, will be worse.
More spindles == faster service.
This is not necessarily true. Again, if the IO patterns are such that seek times dominate throughput, then more spindles will probably not help and, indeed, might even make the situation worse.
The general equation is: transaction_time = (request_size/throughput) * device latency. If throughput can easily dominate (typically, a larger request_size), more drives will help. If it can't, they won't.
RAID really shines with non-small, sequential reads and writes - because these maximise its primary benefit of throughput - this is where your statement above holds. However, when you get into lots of small, random disk requests, the latency of individual drives becomes more the limiting factor, as the transactions aren't big enough to really benefit from the increased throughput. For example, on a usenet server or squid server, you will probably get better performance out of disk subsystem using x low latency drives (be they accessed individually or as a RAID array), than you will from one using 2x drives that have higher latencies, even thought the second scenario would probably have more than twice the throughput in a sustained read.
I suspect that the reason so many people think that RAID doesn't reduce latency is that they're using braindead controllers. I've seen plenty of them that are too stupid to even load balance across mirrors, the simplest case.
The problem is you are taking your hypothetical, best-case scenario and treating it as the general case. This is not a good thing to do. Most of the time your x-disk RAID array isn't going to be able to process x simultaneous disk operations or, indeed, anything even approaching that level of efficiency.
No controller can change the laws of physics. If your disk operation has to touch X disks i
The analogy works well. You just seem to be overlooking the obvious. Take mirrored RAID as an example. Assume the system needs to read 100 separate chunks of data. With a single disk, it must wait for 100 seeks (100 people in a single checkout lane), With two disks (lanes), the reads (checkouts) happen in parallel, so the system only waits for 50 seeks.
This is an absolute ideal scenario, and the only one (concerning a RAID1, at least) in which your claim is correct. I hope I don't have to tell you how unrealistic that is to be drawing general conclusions from.
Your analogy doesn't work very well because, as I said, all the "checkouts" can operate independently, and a bottleneck on one does not affect the others. This is not at all like accesses to a RAID array, except in absolutely ideal situations (the kinds you read about in magazine reviews and sales brochures).
That's why it IS a myth that RAID doesn't improve latency.
On average, in general, it doesn't. It does in some cases - in particular where the files are large and accesses contiguous (such that the throughput "overwhelms" the seek time). However, most environments will benefit far more from a smaller number of lower latency drives, than a larger number of higher latency drives, assuming performance is the primary criteria.
It won't improve the best case, but it will improve the average.
No, it won't. It might improve the best case, but not the average, not in general. Indeed, the "best case" (nicely symmetrical, contiguous, parallelisable disk reads) are about all it will improve. In a RAID1 (to use your example) every operation except a disk read can only ever be - even in absolutely ideal, perfect conditions - as fast as a single drive. In actual usage they will be worse.
It's sysadmin 101 that you add spindles when the transaction load gets high.
That's a pretty dramatic oversimplification. It's not difficult at all to come up with scenarios where replacing drives with ones that have lower latency will produce better results than just adding more spindles to an array will.
Added to that, there's a substantial difference between just "adding spindles" and "adding spindles to existing arrays" which is being glossed over.
Whether you spread the load at the filesystem level or at the block level doesn't matter, as long as it allows two disks to work at the same time.
This will not necessarily guarantee an improvement in performance.
In general, the more spindles you add to a RAID array, the worse the latency gets and the better the throughput gets (in particular, with "cheap IDE RAID" style arrays that are obviously being referred to, that usually don't have synchronised spindles). If the access patterns are such that the increase in throughput overwhelms the increase in latency, then overall performance will improve (and, of course, vice versa). However, in my experience that's not a common case - particularly in heavily loaded multitasking server environments. You're better of getting lower latency disks, or adding more separate disks and/or arrays, rather than adding more disks to an existing array.
Of course, the different levels of RAID each have different performance dynamics as well, so it's hard to talk specifically about whatever examples you might be thinking of - but the rule of thumb that RAID doesn't really help with latency applies to all of them, just in relatively different amounts.
From what you've said thus far, I suspect you're using experience with workstation or desktop setups with RAID1 or RAID0 arrays to base your opinions on. This isn't unreasonable in and of itself, but these sort of scenarios will really show a disproportionate impression of performance improvement from higher throughput, compared to heavily loaded and multitasking server scenarios, because the disk activity is far more likely to be linear and contiguous, and because the performance is only averaged across a single user. You can't really draw conclusions about server performance based on workstation usage.
It's not an absolute, either, I'll grant you - but it is an excellent rule of thumb.
The only case in which RAID does not improve latency is that of a single tasking system.
This is not correct. RAID *might* improve your latency if its purpose is very specific, the setup can be carefully tuned for the access patterns and the physical placement of data on the disks is predictable, but in general it won't.
The latency that's important for a multitasking system is the time an application has to wait for its data, not the time it takes the disk to process a single request.
I'm confused. How isn't the time a disk takes to process requests directly related to how quickly the data can get to the application, in the general case ?
Having more drives simply means there's a better chance that some requests can be handled in parallel.
Certainly, but the chances of it happening are very low. A higher RPM drive will give immediate, predictable and consistent improvements in access times. A RAID array *might*, some of the time, if you're lucky and the planets are correctly aligned - but on average it will actually make latency worse.
Your claim is akin to saying that people won't have to wait longer at the supermarket checkout when only one lane is open.
Your analogy sucks. Not only is the scenario of people being served at checkouts talking about completely independent operations, but that independence also allows for performance hotspots (ie: longer queues in a particular aisle) to be avoided. Accesses to a RAID array exhibit neither of these characteristics.
That's generally what cache is for- on the drive, on the controller, and in the system itself. Even databases are optimized with the "expense" of disk access kept in mind in the optimizer's strategy.
This does not change the fact that if you need low latency, RAID won't help you much, if at all, and is more likely to make the situation worse.
So to cut through the jargon crap- in other words, someone finally remembered that RAID means Redundant Array of Inexpensive Disks, and that in most cases, when you've got 5 or more drives in an array, you don't need them to be 15,000 RPM?
RAID improves throughput, but not latency. If you need low latency, you need high-RPM drives and no amount of RAID will help you.
So security breaches are mostly the result of... ? Social engineering?
Users. This encompasses user error, user ignorance, social engineering, malicious sabotage, poorly configured machines (admins are "users", too) - anything where the user must play an active part to the breach (so, just about every email "virus", all those bits of spyware that get installed when the user clicks "OK", etc).
*Very* few security breaches happen because of coding problems (buffer overflows, backdoors, bugs, etc).
No my comparison is valid if form factor is a considered criteria.
Not really. The only major plus the Mini has going for it is its form factor - in pretty much every other way, hardware-wise, it (comparitively) sucks and is expensive.
You can't do a valid comparison by ignoring features and form factor is definitely a feature.
I never suggested otherwise. I was merely pointing out that form factor would have to be of major importance for the Mini to be considered competitive. If it isn't - if you can handle having a bigger case - then it doesn't stack up particularly well to PC competition. You can buy a PC *and an LCD* for only marginally more than a Mini on its own.
The problem with comparisons like yours are that they are trying to pick a random type of computer, which Apple does not sell an equivalent version of, and compare it to some computer Apple does sell a version of.
And the problem with the typical Mac user comparison is that they pick a Mac, then try to match up the PC to it very specifically (usually to the point of adding in the retail cost of certain pieces of bundled software).
I am not trying to pick a random type of computer. I am pointing out that for only a little bit more than a Mini, you get a fully functional PC that is substantially superior in most ways.
Apple offers a limited selection of computer types, but that is a separate issue. There are mac mini like x86 computers.
Well, if you're going to be as pedantic as you apparently are, there aren't "Mini like" PCs, because you can't get PCs that slow these days.
They are all much more expensive, not half to one tenth the price, as the earlier post claimed.
I did not - and do not - agree with the 2x-10x comparison. However, most Macs carry a price premium, given their features (there are exceptions). Often they have a specific feature - like form factor - to "justify" that price premium. However, if you take that specific feature out of the equation, because it isn't relevant to you, then the price premium rapidly becomes excessive.
The Mini is not a particularly good Mac. It's a G4, and thus lacks the memory and bus bandwidth OS X requires to run well. It's further crippled by a slow hard disk and an outdated video chipset. It was obseleted by Tiger (and CoreImage) within months of its release. I won't be surprised at all if Low End Mac deem it a Road Apple a few years down the track. Really, the only thing going for it is the form factor - so if that's important to you (for whatever reason) then the price is probably reasonably. If it isn't (like, say, for me) it's a bloody ripoff. A G5 iMac is a far better value proposition (but, again, for me is a waste of money because I already have screen, keyboard, etc. Oh, for a headless iMac...)
Try doing a comparison with the ibook, and see if you can find a consumer grade laptop with the same feature set, for less. Is it significantly less, as the previous poster claimed?
The iBook is actually a reasonably good deal - which is why I own one (although they're not as good as they used to be). However, like all G4 Macs, OS X performance sucks. It's value lies primarily in its size but, again, other than that it's nothing outstanding (ie: if you're just after a smallish laptop, rather than a really small laptop - so anything up to about a 14" is ok - then the iBook doesn't stand out). For example, a 12" Dell Inspiron 700 is about $400 cheaper, is maginally larger (but lighter) and will be substantially faster. Stepping up a bit in size, an Inspiron 600M can be had for only $750, whereas a 14" iBook is $2000.
hat's the thing that's pissing me off! Comments like that!:) It's not the wrong illustration if you are looking at things from the viewpoint of manufacturer->customer. It boils down to the same difference - loss of income.
"Loss of income" ? How can you lose something you never have ?
Copyright infringement != theft - conceptually, legally, morally or ethically - despite the tens of millions of dollars the copyright cartels have spent on propaganda stating the contrary. They are *fundamentally* different things.
An example: if I walk into an Apple seller and shoplift a copy of Tiger, then a loss has been suffered. This loss is real, tangible and affects the bottom line of that particular Apple seller. However, if I download a copy of Tiger off the 'net - *especially if I never actually use it* - then no loss has been suffered. Some (particularly lawyers) might argue that *potential revenue hasn't been earned*, but this is fundamentally a completely different thing from a loss (and conceptually, shaky ground at best)
Honestly, while IP laws are more complex than real property laws, the morality of the thing never has been. The only thing that makes it grey is that so many people choose to ignore the rules that it's become mainstream.
No, the laws are "ignored" because they're unintuitive and, increasingly, draconian and unjust (the latter is a more recent development, but the former is pretty universal). "Intellectual property" and physical property are nothing alike, yet there are a bunch of laws that exist to try and make out that they're comparable.
Slashdot Mirror
At my last job my desktop machine was a dual P3 with 1GB of RAM, dating back to 2000. I was quite happy using that machine, and my workload is *far* from light (dozens of putty windows, several Firefox windows with a dozen tabs each, multiple VMWare machines, etc).
I can't count the number of clients I have that torture themselves daily with 4 year old Dells because they don't want to spend money upgrading.
Worst case is they need a RAM upgrade to 512MB of 1GB. Unless by "torturing" you mean actually trying to run performance-intesive software (in which case, it's hardly the OS's fault).
Last year's machine may be okay, 2 year old hardware can be fine, but don't kid yourself that a P3-733 with a slow, old 20G hard drive will cut the mustard.
It certainly will if it has enough RAM.
Once it gets infected with spyware, which is inevitable, it'll be so useless you might as well use it to prop open a door.
It's far from inevitable. Basic security practices result in a malware-free Windows PC.
The problem is you don't appear to be using the term "latency" in a meaningful or consistent fashion.
With RAID-1 it doesn't matter that the requests are balanced. a two-way mirror gives a 2x improvement in average latency. Make it a 3-way mirror, and you'll have a 3x improvement.
False.
With RAID-0, the balance of requests does matter. Assume two disks, one containing even block numbers, the other containing odds. If the requests are pathological, i.e. all odds, the improvement will be 0. But if *any* of the requests are even, then there's an improvement.
In transfer rate, yes. In latency, no. In overall performance, maybe.
Wikipedia backs up what I have said. Please read what it says.
That doesn't make it correct. Indeed, whoever wrote that Wikipedia article has the same problems with terminology and assumptions you do.
I'll make one last attempt to explain why RAID will not improve latency, and will generally make it worse. If you can't see the physics and maths that make it so, there's not going to be much I can do to change your mind.
Consider the scenario where you have a three-disk RAID0, with a 64kb chunk size. A request for 140kb is made, and conveniently enough, is contained in chunks on all three disks. So they are able to operate in parallel and provide maximum benefit.
Disk 0 seeks to the appropriate place and takes the average seek time of 8ms.
Simultaneously, Disk 1 seeks to the appropriate place, however, since the necessary block is further away from the head, its seek time is 11ms.
Disk 2 is lucky, and the necessary data is quite close to the read head. It's seek time is only 4ms.
The disk return the the chunks, which are appropriately assembled by the RAID layer and passed back up to the OS (since the requests are so small, the transfer times in this example are negligible - this is the sort of disk operation where a RAID array's performance suffers).
The latency for this operation was 11ms (plus a tiny amount for transfer). The time taken by the slowest seek. Why ? Because the operation could not complete until both chunks of the stripe had been retrieved, even though two of the three disks involved only took 4ms and 8ms.
Now, if we take a more ideal view and say that all three disks only take the average seek time (8ms) to return their chunks. The latency for the operation is *still* 8ms, because it cannot complete until all three disks have returned their chunks. It will most certainly *not* be <3ms, which is the result you would claim was possible (8/3).
The RAID array can never have have a latency lower than that of the component devices. Obviously, since that value can only ever even match the component devices in ideal conditions (perfectly parallelised operations), it will be higher on average than the component devices' average. This is why the average latency of a RAID array will be higher than the average latency of a single drive, even if that drive is identical to the RAID component drives.
(This is the same logic that dictates a RAID1 cannot have write performance better than an individual disk.)
Also, this example is talking about a RAID0, which is about as best-case as you can get in terms of overall RAID performance. Other RAID levels that offer no advantage - or even a penalty - for writes (particularly random writes) like RAID1 and RAID5, only swing the latency advantage further towards the individual disk case.
Here is another way to think about it. By your reasoning, a RAID1 made up of eight disks with an 8ms latency would have an average latency of 1ms. Do you seriously believe if you benchmark an eight-disk RAID1 you'll get an average seek time of 1ms ?
Which Windows does.
And they do actually defend in a lot of ways, preventing modifications to the registry, stopping spyware installing itself and stopping viruses getting executing on your machine by scanning files as they are opened/run.
They only need to do this when the user (or a software bug) has circumvented or otherwise nullified the protection offered by the OS. I consider that to be cleaning up after the fact, rather than stopping it before it happens.
It's even more impressive when you consider a P3 is basically just a tooled up Pentium Pro, which debuted back in 1995.
No it doesn't. The Pentium M is as fast - if not faster - than the G4 at the same clock speed, and has more than triple the memory bandwidth on the 533Mhz FSB models.
G4s are *spanked* by Pentium M's, even at the same clockspeed, except for those very carefully chosen benchmarks Apple likes to use. The G4 hasn't been a competitive performer for *years*.
The problem is not the teaching of Creationism. The problem is the teaching of Creationism in a science classroom. Creationism is not science. It is Religion or, at a big stretch, Philosophy.
Should the religious zealots ever manage to come up with something scientific, I've no doubt it will be taught in a science classroom. But Creationism ain't it.
Let me guess, you're one of these dimwits who think "integrating IE directly into the OS" means it's part of the kernel ?
Then why would you try to install the patch in the first place ? Heck, why would you even be running Windows ?
When you come with a way of detecting whether or not the user really did mean to type 'rm -rf /*', you'll have a point.
Windows, like any other mainstream OS, is a secure as the end user makes it.
the whole Home vs. Professional thing is already a scam to get more money from those who are worried they need the "better version".
Yeah. A scam. Because it's not like pretty much every other vendor in the world uses the same sort of product differentiation.
Anti-virus/spyware software doesn't really "defend" against the attacks, they clean them up after they've happened.
How is an environment that runs what the user tells it to run "poorly architected" ?
You *are* aware that most malware gets in via users clicking "OK" in the wrong places, executing malicious email attachments, and installing software that includes the stuff, right ? Most of it - assuming the software is up to date - doesn't get in through software bugs or flaws.
Your "poor architecture" environment implies that it would be *impossible* to run Windows and not fall victim to malware. This is blatant FUD and couldn't be further from the truth.
If someone actually madea functional equivalent, they might consider it.
How can you say that when IE was available as a standalone download (and gained most of its market share) *years* before it was integrated into Windows, and media player was included with Windows for *years* before there even was a "media player market".
The only reasons newer versions of OS X get faster is because the old versions were so damn slow. They didn't have anywhere to go but up.
This doesn't really apply to Windows, which has always been quite usable on both current and 3 - 5 year old hardware. OS X, even on brand spanking new G4-based Macs, is slow. Back when it was first released, even on the cutting edge Macs of the day, OS X ran like a dog. This has never happened to Windows.
Microsoft have an excellent track record of supporting older hardware and making sure Windows is usable on it. In general, anything <=5 years old will run the current version of Windows usably, perhaps requiring a small RAM upgrade. This "Microsoft forces upgrade every year" FUD that gets rolled out on Slashdot every other day is pure, unaldulterated bullshit. Games are about the only thing the typical consumer will ever find "forcing" them into "yearly upgrades".
Yes. The employer purchases the machine on the employee's behalf, and then subtracts the amount from the employee's before-tax salary, spread over a number of salary cycles (ie: paychecks) specified by the employee (up to a certain amount, I think it's 3 - this is why the opportunity is generally only relevant to those on relatively high salaries). Additionally, since the purchse is being made by a business, they don't pay GST (sales tax) and the GST refund goes to the employee.
Basically, it makes the entire cost of the laptop a tax deduction, and the employee immediately receives a 10% GST "refund". The downside is the employer must be prepared to do it, the employee's paycheck will probably be substantially less while the payments are deducted from it and it's only applicable to laptops.
Employees are allowed to do this once a year (technically, a "Fringe Benefits Tax" year, which is slightly different to a "Taxation" year). The "rort", of course, is employees who do this every year and then immediately on-sell the laptop on ebay (or similar). If you buy, say, a $4000 laptop and resell it for $3500, you'll make about $1000 out of it (from memory, it's been a while since I did it, and I was on a different tax bracket back then).
Huh ? Perfectly balanced, parallelisable IO (as per your RAID1 and "checkout" examples) is about as "best case" as you can get when talking about RAID IO.
And you *are* treating it as a general case by saying such IO will be the rule, rather than the exception.
You're almost there.
Well, I'm starting to understand what you're trying to argue. That doesn't make it right with regards to what I'm saying, however.
No, it's a latency issue. It has nothing to do with throughput, by which I assume you mean transfer rate. Consider the case where each read is for a single byte, or in my analogy, each shopper has a single item. Throughput doesn't matter, it's latency.
Look, your shopping analogy *does not work* in the general case because it is based on the assumption that each checkout (ie: disk) can operate independently of, and simultaneously with, all the others. You need an ideal scenario for this to be true, and these are rare. Typically an IO to a RAID will have to touch multiple disks, and will also not access the disks in an equitable fashion. Repeating carefully selected best case scenarios won't change the general case.
There are only two cases where a RAID array can even have latency equivalent to a single drive, and that is when a) the IO only touches a single component in the array, or b) the array components are all perfectly synced and the IO operations to the individual drives are processed and complete perfectly parallel - and when you're talking about a single drive with a lower latency than any of the array components, neither of them are possible.
You're correct in saying that the more knowledge the RAID controller ( whether it be hardware or software ) has about the data, the more it can optimize performance, but it's only in the patholgical cases where there will be no improvement.
An operation that touches multiple drives in a RAID array *cannot* have better latency than a single drive operation. No amount of controller of software intelligence can change physics and maths. It may have higher throughput, but whether or not that makes the overall operation complete quicker depends on the request size. A single drive with a 4ms latency but only 75MB/s transfer rate will complete a 300kb IO quicker than a typical 4 disk RAID0 with 170MB/s of throughput and a 10ms latency, even if we assume a perfect best case scenario for the RAID array.
You're also right to say that quicker disks are a win. But even the fastest disk in the world can be easily swamped by a large number of requests.
I never suggested a single drive will always offer better overall performance than a RAID array. Merely that it will have better latency.
more spindles == faster service
This is not always true, and no amount of repetition on your part will change that.
There are two distinct parts of any disk IO operation. How quickly the device can be ready to transfer the data (the latency) and how quickly the data comes off the device (the throughput). Even in an absolutely ideal situation, a RAID array *cannot* have better latency than an individual disk (assuming the disk is of equal or better performance than the RAID components). It might be equal, but it can't be any faster (and will usually be slower). OTOH, an array will have higher throughput. So, if your IO operations are throughput-bound (generally, large and sequential) the RAID will be faster. However, if they're latency bound (generally, small and random) the individual disk (or RAID of fewer, lower latency disks) will be faster. Only when the throughput advantage starts to overwhelm the latency advantage, will overall performance increase (which is what I think you mean when you say latency).
These two principles follow through into RAID arrays themselves. The more spindles you add, the worse lat
All of them? You started off by saying that I gave "the one" example of RAID reducing the overall latency of multiple reads.
I pointed out that you picked the one aspect where latency *might* be improved. There's typically a lot more to disk access than perfectly parallelisable disk reads.
I'm talking about *average* performance in the *general* case. On *average*, in *general*, RAID will increase latency. There are certainly examples of specific situations where this is not true, but that doesn't change the *general* case. Particularly when those examples only actually manifest in ideal conditions.
Well, it's not the only one. RAID-0 will give the same result unless the data is pathological somehow, e.g. it clashes with some other interleaving scheme.
Which is quite likely. There aren't many scenarios where it's possible to specifically tune the stripe size to the file size, nor control the physical placement on disk of logical files.
For RAID0 to give the same result, you would need 2 simultaneous reads <=$STRIPE_SIZE, where the data was on different disks. Again, not likely to be a common case.
I understand what you're saying about the independence of checkout lanes, but it's the same as having a fairly uniform distribution of read requests (across the range of blocks in the volume).
No, I don't think you do. The reasons the checkout lanes are "independent", is because the progress of any arbitrary customer through any arbitrary checkout lane is completely self contained. No matter how fast or slow one lane may be progressing, they have no affect on the "processing speed" of any other lane. This does *not* apply with most RAID arrays as typically a logical array transaction will have to touch multiple physical drives. That is, your overall access time to the array, per operation, is dependent on the slowest drive's (involved in the transaction) individual seek time, because the transaction as a whole cannot complete until the slowest drive has. Hopefully you can see that this cannot be better than any individual drive's seek time and, on average, will be worse.
More spindles == faster service.
This is not necessarily true. Again, if the IO patterns are such that seek times dominate throughput, then more spindles will probably not help and, indeed, might even make the situation worse.
The general equation is: transaction_time = (request_size/throughput) * device latency. If throughput can easily dominate (typically, a larger request_size), more drives will help. If it can't, they won't.
RAID really shines with non-small, sequential reads and writes - because these maximise its primary benefit of throughput - this is where your statement above holds. However, when you get into lots of small, random disk requests, the latency of individual drives becomes more the limiting factor, as the transactions aren't big enough to really benefit from the increased throughput. For example, on a usenet server or squid server, you will probably get better performance out of disk subsystem using x low latency drives (be they accessed individually or as a RAID array), than you will from one using 2x drives that have higher latencies, even thought the second scenario would probably have more than twice the throughput in a sustained read.
I suspect that the reason so many people think that RAID doesn't reduce latency is that they're using braindead controllers. I've seen plenty of them that are too stupid to even load balance across mirrors, the simplest case.
The problem is you are taking your hypothetical, best-case scenario and treating it as the general case. This is not a good thing to do. Most of the time your x-disk RAID array isn't going to be able to process x simultaneous disk operations or, indeed, anything even approaching that level of efficiency.
No controller can change the laws of physics. If your disk operation has to touch X disks i
This is an absolute ideal scenario, and the only one (concerning a RAID1, at least) in which your claim is correct. I hope I don't have to tell you how unrealistic that is to be drawing general conclusions from.
Your analogy doesn't work very well because, as I said, all the "checkouts" can operate independently, and a bottleneck on one does not affect the others. This is not at all like accesses to a RAID array, except in absolutely ideal situations (the kinds you read about in magazine reviews and sales brochures).
That's why it IS a myth that RAID doesn't improve latency.
On average, in general, it doesn't. It does in some cases - in particular where the files are large and accesses contiguous (such that the throughput "overwhelms" the seek time). However, most environments will benefit far more from a smaller number of lower latency drives, than a larger number of higher latency drives, assuming performance is the primary criteria.
It won't improve the best case, but it will improve the average.
No, it won't. It might improve the best case, but not the average, not in general. Indeed, the "best case" (nicely symmetrical, contiguous, parallelisable disk reads) are about all it will improve. In a RAID1 (to use your example) every operation except a disk read can only ever be - even in absolutely ideal, perfect conditions - as fast as a single drive. In actual usage they will be worse.
It's sysadmin 101 that you add spindles when the transaction load gets high.
That's a pretty dramatic oversimplification. It's not difficult at all to come up with scenarios where replacing drives with ones that have lower latency will produce better results than just adding more spindles to an array will.
Added to that, there's a substantial difference between just "adding spindles" and "adding spindles to existing arrays" which is being glossed over.
Whether you spread the load at the filesystem level or at the block level doesn't matter, as long as it allows two disks to work at the same time.
This will not necessarily guarantee an improvement in performance.
In general, the more spindles you add to a RAID array, the worse the latency gets and the better the throughput gets (in particular, with "cheap IDE RAID" style arrays that are obviously being referred to, that usually don't have synchronised spindles). If the access patterns are such that the increase in throughput overwhelms the increase in latency, then overall performance will improve (and, of course, vice versa). However, in my experience that's not a common case - particularly in heavily loaded multitasking server environments. You're better of getting lower latency disks, or adding more separate disks and/or arrays, rather than adding more disks to an existing array.
Of course, the different levels of RAID each have different performance dynamics as well, so it's hard to talk specifically about whatever examples you might be thinking of - but the rule of thumb that RAID doesn't really help with latency applies to all of them, just in relatively different amounts.
From what you've said thus far, I suspect you're using experience with workstation or desktop setups with RAID1 or RAID0 arrays to base your opinions on. This isn't unreasonable in and of itself, but these sort of scenarios will really show a disproportionate impression of performance improvement from higher throughput, compared to heavily loaded and multitasking server scenarios, because the disk activity is far more likely to be linear and contiguous, and because the performance is only averaged across a single user. You can't really draw conclusions about server performance based on workstation usage.
It's not a myth.
It's not an absolute, either, I'll grant you - but it is an excellent rule of thumb.
The only case in which RAID does not improve latency is that of a single tasking system.
This is not correct. RAID *might* improve your latency if its purpose is very specific, the setup can be carefully tuned for the access patterns and the physical placement of data on the disks is predictable, but in general it won't.
The latency that's important for a multitasking system is the time an application has to wait for its data, not the time it takes the disk to process a single request.
I'm confused. How isn't the time a disk takes to process requests directly related to how quickly the data can get to the application, in the general case ?
Having more drives simply means there's a better chance that some requests can be handled in parallel.
Certainly, but the chances of it happening are very low. A higher RPM drive will give immediate, predictable and consistent improvements in access times. A RAID array *might*, some of the time, if you're lucky and the planets are correctly aligned - but on average it will actually make latency worse.
Your claim is akin to saying that people won't have to wait longer at the supermarket checkout when only one lane is open.
Your analogy sucks. Not only is the scenario of people being served at checkouts talking about completely independent operations, but that independence also allows for performance hotspots (ie: longer queues in a particular aisle) to be avoided. Accesses to a RAID array exhibit neither of these characteristics.
This does not change the fact that if you need low latency, RAID won't help you much, if at all, and is more likely to make the situation worse.
RAID improves throughput, but not latency. If you need low latency, you need high-RPM drives and no amount of RAID will help you.
Users. This encompasses user error, user ignorance, social engineering, malicious sabotage, poorly configured machines (admins are "users", too) - anything where the user must play an active part to the breach (so, just about every email "virus", all those bits of spyware that get installed when the user clicks "OK", etc).
*Very* few security breaches happen because of coding problems (buffer overflows, backdoors, bugs, etc).
Not really. The only major plus the Mini has going for it is its form factor - in pretty much every other way, hardware-wise, it (comparitively) sucks and is expensive.
You can't do a valid comparison by ignoring features and form factor is definitely a feature.
I never suggested otherwise. I was merely pointing out that form factor would have to be of major importance for the Mini to be considered competitive. If it isn't - if you can handle having a bigger case - then it doesn't stack up particularly well to PC competition. You can buy a PC *and an LCD* for only marginally more than a Mini on its own.
The problem with comparisons like yours are that they are trying to pick a random type of computer, which Apple does not sell an equivalent version of, and compare it to some computer Apple does sell a version of.
And the problem with the typical Mac user comparison is that they pick a Mac, then try to match up the PC to it very specifically (usually to the point of adding in the retail cost of certain pieces of bundled software).
I am not trying to pick a random type of computer. I am pointing out that for only a little bit more than a Mini, you get a fully functional PC that is substantially superior in most ways.
Apple offers a limited selection of computer types, but that is a separate issue. There are mac mini like x86 computers.
Well, if you're going to be as pedantic as you apparently are, there aren't "Mini like" PCs, because you can't get PCs that slow these days.
They are all much more expensive, not half to one tenth the price, as the earlier post claimed.
I did not - and do not - agree with the 2x-10x comparison. However, most Macs carry a price premium, given their features (there are exceptions). Often they have a specific feature - like form factor - to "justify" that price premium. However, if you take that specific feature out of the equation, because it isn't relevant to you, then the price premium rapidly becomes excessive.
The Mini is not a particularly good Mac. It's a G4, and thus lacks the memory and bus bandwidth OS X requires to run well. It's further crippled by a slow hard disk and an outdated video chipset. It was obseleted by Tiger (and CoreImage) within months of its release. I won't be surprised at all if Low End Mac deem it a Road Apple a few years down the track. Really, the only thing going for it is the form factor - so if that's important to you (for whatever reason) then the price is probably reasonably. If it isn't (like, say, for me) it's a bloody ripoff. A G5 iMac is a far better value proposition (but, again, for me is a waste of money because I already have screen, keyboard, etc. Oh, for a headless iMac...)
Try doing a comparison with the ibook, and see if you can find a consumer grade laptop with the same feature set, for less. Is it significantly less, as the previous poster claimed?
The iBook is actually a reasonably good deal - which is why I own one (although they're not as good as they used to be). However, like all G4 Macs, OS X performance sucks. It's value lies primarily in its size but, again, other than that it's nothing outstanding (ie: if you're just after a smallish laptop, rather than a really small laptop - so anything up to about a 14" is ok - then the iBook doesn't stand out). For example, a 12" Dell Inspiron 700 is about $400 cheaper, is maginally larger (but lighter) and will be substantially faster. Stepping up a bit in size, an Inspiron 600M can be had for only $750, whereas a 14" iBook is $2000.
"Loss of income" ? How can you lose something you never have ?
Copyright infringement != theft - conceptually, legally, morally or ethically - despite the tens of millions of dollars the copyright cartels have spent on propaganda stating the contrary. They are *fundamentally* different things.
An example: if I walk into an Apple seller and shoplift a copy of Tiger, then a loss has been suffered. This loss is real, tangible and affects the bottom line of that particular Apple seller. However, if I download a copy of Tiger off the 'net - *especially if I never actually use it* - then no loss has been suffered. Some (particularly lawyers) might argue that *potential revenue hasn't been earned*, but this is fundamentally a completely different thing from a loss (and conceptually, shaky ground at best)
Honestly, while IP laws are more complex than real property laws, the morality of the thing never has been. The only thing that makes it grey is that so many people choose to ignore the rules that it's become mainstream.
No, the laws are "ignored" because they're unintuitive and, increasingly, draconian and unjust (the latter is a more recent development, but the former is pretty universal). "Intellectual property" and physical property are nothing alike, yet there are a bunch of laws that exist to try and make out that they're comparable.