Also, I doubt you have an application that can either produce or consume data at 180MB/sec or faster, so this is all just a benchmark war I assume.
Amazing leap. I didn't hear him say anything about his usage other than to use the word "server" in a sentence. I would say the opposite, that disk i/o is the main bottle neck for most services these days and so, lacking specific details, if you had to assume anything, it's safer to assume that his application IS disk i/o bound than not. Every one of my servers, being multi-user real time database driven application servers performing unholy numbers of small random access transactions to many files at once, can always use all the disk bandwidth that can possibly be provided. 24 10krpm sas spindles on a brand new adaptec 5000 series hardware raid, configured for raid10 (5 is too slow for unavoidable reasons that no hardware can get around) is still not too much bandwidth. It's great. It's sinificantly faster than the 8 7200rpm sata2 spindles on adaptec 3000 series cards most of my other servers have, which themselves are already "good enough" up to a certain number of users on average. But there really is no point at which more is pointless. Even with that 24 drive screamer, many common actions take time, and the more disk bandwdth and the more spindles to paralellize operations, the faster those actions go. (reports that touch lost of files, rsync and other backups, df/du/find etc utils that need to scan through everything and in doing so end up blowing away the various caches in the os and in the hadware) Larger cache on the drives, larger cache on the card, faster channels to the drives, it all helps even though the platters can really only deliver about 60-70 mbit and even though the pci-e interface can't actually deliver the full 24x3gbit theoretical bandwidth to the cpu or ram. Lots of ops get coalesced within the raid card and the raid card can use lots of bandwidth itself just between the disks and the card just maintaining the raid. He didn't say all that about his application, but he didn't say otherwise either. He may not even know whether the increased speed will help his application very much. He may be in the process of finding out by testing, which is not only perfectly valid but the rightest thing in the world. It's just about never right to presume to tell anyone else that they don't need what they are asking for unless they provide a truly ridiculous amount of detail and background and context about their situation, such that you could actually evaluate the whole system and decree things like "N seconds per transaction is more than good enough, because this and this other factor limits things anyways, and so more won't make a difference..." -- Brian K. White brian@aljex.com http://www.myspace.com/KEYofR +++++[>+++[>+++++>+++++++<<-]<-]>>+.>.+++++.+++++++.-.[>+<---]>++. filePro BBx Linux SCO FreeBSD #callahans Satriani Filk! -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org