Well this comparison is not really interesting (and I was looking for real-world performance studies, not bench results): it shows a maximum read burst speed of only 135 MB/s for the Hitachi disk (SATA 3.0 Gbps) and 127 MB/s for the Raptor one (SATA 1.5 Gbps), while I have seen other websites' benchmarks reaching more than 200 MB/s during burst transfers in the past. So there is definitely something that went wrong in the hardware or software setup. And I can't say what because the author provide so few technical details...
Regarding your question, it depends:
If you are using a port multiplier supporting 3.0 Gbps SATA links, then the "host-side" link will be running at 3.0 Gbps and the "disk-side" one at 1.5 Gbps.
If you are using a port multiplier supporting 1.5 Gbps SATA links or if you don't use any, then all of your links will be running at 1.5 Gbps.
But I guess this is what you expected, didn't you ?
We all agree that the 300 MB/s figure is only relevant in the case of burst transfers, between the host and the disk's cache (some benchmarks show that some disks are
able to go above 200 MB/s).
But if I were you, I wouldn't be so quick into saying that a 300 MB/s SATA link is
useless (well you don't say it but you seem to think it). I have myself recently built multiple storage servers with 4+ SATA or SCSI disks,
and in my experience those kind of minor details can sometime have an big unexpected impact
in some very particular utilization cases.
Now I am not saying that everybody absolutely need 300 MB/s SATA links, but I am just saying that
without a comparison of 150 vs. 300 MB/s SATA links in real-world scenarios
nobody can say that 300 MB/s is useless, and AFAIK not a single well-known hardware
website has ever done such a comparison.
Of course there are some other obvious advantages into using 300 MB/s SATA links. For example
if you connect 2 or 3 disks on a single SATA port using a port multiplier, a 150 MB/s
SATA link will be quickly saturated while a 300 MB/s SATA link won't. Indeed recent SATA
disks (e.g. the Seagate 7200.8 family) can reach 68 MB/s of sustained transfer rate, multiply this by 2 and you get 136 MB/s, which is 90% of 150 MB/s, that means that if the overhead of the SATA protocol is higher than 10%, then a 150 MB/s SATA link will not let you use the full potential sustained transfer rate of 2 disks.
We have often read about Google's datacenters on/. but AFAIK we have never seen any picture of their datacenters. So if somebody has something to say/show about this (even insiders:P), please reply to this post.
The speed of light is just too low for Google's AJAX applications to take over the world.
No, you are wrong. Even if Google had only 2 datacenters on the surface of the Earth located at 2 antipodal points, a path from any location to one of the datacenters would always be shorter than 10010 km (mean Earth's circumference divided by 4) and it would take 33 ms for the light to cover this distance. So the RTT would be 66 ms, which is sufficient for Ajax applications.
Though the speed of light contributes a little to the latency between hosts on the Internet, it is primarily caused by the number of hops (routers) between them. So if latency is your problem, you create multiple datacenters mostly to reduce the number of hops, not to reduce the distance that signals have to cover.
If we round the CPU's power consumption up to account for all the support machinery, and figure 100W per CPU.
What about if they use dual-core low-power Opterons (the HE models), which use an amount of power comparable to single-core models ? And hop! suddenly you end up with a 50W per logical CPU.
Anyway only future will tell us if Cringely's figures are right or not.
To all those people thinking that HT multiplies CPU performance by 2,
here is a very simple experiment that will prove you wrong. Define
those functions in your shell (BSD, Linux, Cygwin, whatever):
Then, on an HT enabled box, benchmark the function running a single CPU
intensive process:
$ time p1 [...] real 0m5.165s
It took 5.2 seconds. Now do it with the function running two CPU
intensive processes:
$ time p2 [...] real 0m10.390s
It takes twice the time (10.4 secs).
If HT really offered twice the perfs, it would have taken the same
amount of time (5.2 secs) because HT would have run the 2 processes on
the 2 "independent" CPUs, but as you can see this is not the case.
The explanation of this is that the
execution units are shared between the 2 logical CPUs.
Whereas on this dual opteron 244 box I happen to have in front of me,
both benchmarks give the same numbers: p1 = 4.4 secs and p2 = 4.5 secs,
because on a true SMP (or dual-core) box, the 2 CPUs are obviously
independent and don't share their execution units. As it is correctly
pointed out by other people, HT is a way to reduce the impact of pipeline
stalls and execution units under-utilisation, it is not a way
to magically "multiplies" raw CPU performance by 2.
Well after much digging I found a thread on how HT could cause issues with the software. I disabled it in the bios, do not really need it for anything. And ran the Tuner 48 hours solid without a lockup.
This does not prove that Hyper Threading is the one to blame. On the contrary, this kind of problem sounds typically like there are deadlock bugs in ATI's softawre that are only triggered by HT. A deadlock situation occurs when multiple threads need to acquire a common set of software locks (spinlocks, mutexes, etc), but each of them is waiting for other threads to release some locks that have already been acquired. Deadlocks are usually easier to trigger when running multiple logical CPUs (HT, or SMP, or dual-core, etc) because the threads actually run concurrently on the CPUs, increasing the chances of having them acquiring the locks at the same time. Of course since deadlock issues are actually a subclass of race condition issues, all of this is extremely time sensitive and the problem may disappear/reappear when changing the hardware or software even just a little bit. This may explain why laffer1 (who replied to your post) don't experience your issue with its different config (not the same software versions, and SMP instead of HT).
I am not a big Intel fan, but in this particular case it looks like Intel's HT is not the one to blame. Instead you should redirect your anger toward ATI:)
I am sick of people who see a small statement and then assume a bunch of crap beyond what was really said.
Ok, maybe I should have been that aggressive. But you have to admit that Taimoor's post is ambiguous. That's why I wanted to warn everyone that MD5 is also used to do much more than merely hashing passwords...
Given the restrictions present in most login systems, this method WILL work.
I am sick of seeing all those uninformed posts made by people thinking that MD5 is only used in "login systems" to "hash passwords". I am sure you didn't know that, for example, MD5 is also used to digitally sign the X.509 v3 certificates used by some HTTPS websites. So I am forced to repeat what the grand parent said, for the n-th time:
No, in most cases, cascading hash functions like this DOES NOT WORK. The minority of cases where such an inferior method may work is irrelevant. A better solution is to develop a new secure hashing algorithm.
This doesn't work.
Because the MD5 attack is basically what we call a "free-start collision". In other words, whatever is your "secretstring", it will not prevent attackers from finding collisions. See the researchers' paper for more info http://eprint.iacr.org/2004/199.pdf.
these dialog boxes need to have the polish and unified feel that they do on XP or OS X.
Sure Linux apps need improvement, but so do Windows apps.
It seems that most people praising Windows (the OS and its apps) fail to see its defects.
The fact that everybody is so used to those bugs, incomprehensible error messages,
and erratic behaviours may explain why they passively accept this state of affairs.
Sure there are some good things here and there, in this proprietary OS, but
I really do hope that Linux don't try to imitate Windows.
Linux should seek its own perfection model, because Windows is far from being perfect.
[...Skype's encryption is closed source...]
Ooh.. closed source is evil! By this logic, Info-Tech should recommend
banning Windows (to the delight, I'm sure, of many/.ers)
What Info-Tech means by "closed source" is in fact "proprietary algorithm". The usual stance amongst cryptography researchers is that proprietary algorithms must be avoided at any price because they have not been cryptanalyzed as much as standard algorithms, so they have higher chances of being flawed. It would be much better if Skype replaced its algo by AES for example.
Err I was supposed to be "funny", who modded me "insightful" ?
Usually when I try to be funny, I am modded "flamebait" because nobody get my joke, or not modded at all because nobody not even care about reading me. But this is the 1st time ever that I am modded "insightful".
Damn ! Why is it so hard to be funny on slashdot ? Am I that bad ?:)
As an eminent member of the NKKSU (North Korean Kraeizy Scientist Union), I see absolutely no problem with such practices. I myself regularly force my own lab slav^H^H^H^Hworkers to do such things. Those bastards are so lazy anyway that this is the only way to justify their outrageously high wages. No later than yesterday one of them even asked me a raise to $3.75 per hour. What the H-E-L-L was he thinking ? I can tell you that I added him immediately to the list of subjects that are going to be used in this experiment with the RNA-deconstructor human immunodeficiency virus. This time this is an improved version which works (I think).
-- Dr. Madh
Slashdot Mirror
Well this comparison is not really interesting (and I was looking for real-world performance studies, not bench results): it shows a maximum read burst speed of only 135 MB/s for the Hitachi disk (SATA 3.0 Gbps) and 127 MB/s for the Raptor one (SATA 1.5 Gbps), while I have seen other websites' benchmarks reaching more than 200 MB/s during burst transfers in the past. So there is definitely something that went wrong in the hardware or software setup. And I can't say what because the author provide so few technical details... Regarding your question, it depends:
But I guess this is what you expected, didn't you ?
Ok, I am calling 911.
We all agree that the 300 MB/s figure is only relevant in the case of burst transfers, between the host and the disk's cache (some benchmarks show that some disks are able to go above 200 MB/s). But if I were you, I wouldn't be so quick into saying that a 300 MB/s SATA link is useless (well you don't say it but you seem to think it). I have myself recently built multiple storage servers with 4+ SATA or SCSI disks, and in my experience those kind of minor details can sometime have an big unexpected impact in some very particular utilization cases. Now I am not saying that everybody absolutely need 300 MB/s SATA links, but I am just saying that without a comparison of 150 vs. 300 MB/s SATA links in real-world scenarios nobody can say that 300 MB/s is useless, and AFAIK not a single well-known hardware website has ever done such a comparison.
Of course there are some other obvious advantages into using 300 MB/s SATA links. For example if you connect 2 or 3 disks on a single SATA port using a port multiplier, a 150 MB/s SATA link will be quickly saturated while a 300 MB/s SATA link won't. Indeed recent SATA disks (e.g. the Seagate 7200.8 family) can reach 68 MB/s of sustained transfer rate, multiply this by 2 and you get 136 MB/s, which is 90% of 150 MB/s, that means that if the overhead of the SATA protocol is higher than 10%, then a 150 MB/s SATA link will not let you use the full potential sustained transfer rate of 2 disks.
We have often read about Google's datacenters on /. but AFAIK we have never seen any picture of their datacenters. So if somebody has something to say/show about this (even insiders :P), please reply to this post.
The speed of light is just too low for Google's AJAX applications to take over the world.
No, you are wrong. Even if Google had only 2 datacenters on the surface of the Earth located at 2 antipodal points, a path from any location to one of the datacenters would always be shorter than 10010 km (mean Earth's circumference divided by 4) and it would take 33 ms for the light to cover this distance. So the RTT would be 66 ms, which is sufficient for Ajax applications.
Though the speed of light contributes a little to the latency between hosts on the Internet, it is primarily caused by the number of hops (routers) between them. So if latency is your problem, you create multiple datacenters mostly to reduce the number of hops, not to reduce the distance that signals have to cover.
If we round the CPU's power consumption up to account for all the support machinery, and figure 100W per CPU.
What about if they use dual-core low-power Opterons (the HE models), which use an amount of power comparable to single-core models ? And hop! suddenly you end up with a 50W per logical CPU.
Anyway only future will tell us if Cringely's figures are right or not.
To all those people thinking that HT multiplies CPU performance by 2, here is a very simple experiment that will prove you wrong. Define those functions in your shell (BSD, Linux, Cygwin, whatever):
Then, on an HT enabled box, benchmark the function running a single CPU intensive process:
It took 5.2 seconds. Now do it with the function running two CPU intensive processes:
It takes twice the time (10.4 secs). If HT really offered twice the perfs, it would have taken the same amount of time (5.2 secs) because HT would have run the 2 processes on the 2 "independent" CPUs, but as you can see this is not the case. The explanation of this is that the execution units are shared between the 2 logical CPUs. Whereas on this dual opteron 244 box I happen to have in front of me, both benchmarks give the same numbers: p1 = 4.4 secs and p2 = 4.5 secs, because on a true SMP (or dual-core) box, the 2 CPUs are obviously independent and don't share their execution units. As it is correctly pointed out by other people, HT is a way to reduce the impact of pipeline stalls and execution units under-utilisation, it is not a way to magically "multiplies" raw CPU performance by 2.
Well after much digging I found a thread on how HT could cause issues with the software. I disabled it in the bios, do not really need it for anything. And ran the Tuner 48 hours solid without a lockup.
This does not prove that Hyper Threading is the one to blame. On the contrary, this kind of problem sounds typically like there are deadlock bugs in ATI's softawre that are only triggered by HT. A deadlock situation occurs when multiple threads need to acquire a common set of software locks (spinlocks, mutexes, etc), but each of them is waiting for other threads to release some locks that have already been acquired. Deadlocks are usually easier to trigger when running multiple logical CPUs (HT, or SMP, or dual-core, etc) because the threads actually run concurrently on the CPUs, increasing the chances of having them acquiring the locks at the same time. Of course since deadlock issues are actually a subclass of race condition issues, all of this is extremely time sensitive and the problem may disappear/reappear when changing the hardware or software even just a little bit. This may explain why laffer1 (who replied to your post) don't experience your issue with its different config (not the same software versions, and SMP instead of HT).
I am not a big Intel fan, but in this particular case it looks like Intel's HT is not the one to blame. Instead you should redirect your anger toward ATI :)
I am sick of people who see a small statement and then assume a bunch of crap beyond what was really said.
Ok, maybe I should have been that aggressive. But you have to admit that Taimoor's post is ambiguous. That's why I wanted to warn everyone that MD5 is also used to do much more than merely hashing passwords...
Given the restrictions present in most login systems, this method WILL work.
I am sick of seeing all those uninformed posts made by people thinking that MD5 is only used in "login systems" to "hash passwords". I am sure you didn't know that, for example, MD5 is also used to digitally sign the X.509 v3 certificates used by some HTTPS websites. So I am forced to repeat what the grand parent said, for the n-th time: No, in most cases, cascading hash functions like this DOES NOT WORK. The minority of cases where such an inferior method may work is irrelevant. A better solution is to develop a new secure hashing algorithm.
What about this?
hash = MD5(secretstring.input)
This doesn't work. Because the MD5 attack is basically what we call a "free-start collision". In other words, whatever is your "secretstring", it will not prevent attackers from finding collisions. See the researchers' paper for more info http://eprint.iacr.org/2004/199.pdf.
these dialog boxes need to have the polish and unified feel that they do on XP or OS X.
Sure Linux apps need improvement, but so do Windows apps. It seems that most people praising Windows (the OS and its apps) fail to see its defects. The fact that everybody is so used to those bugs, incomprehensible error messages, and erratic behaviours may explain why they passively accept this state of affairs.
Sure there are some good things here and there, in this proprietary OS, but I really do hope that Linux don't try to imitate Windows. Linux should seek its own perfection model, because Windows is far from being perfect.
Ooh.. closed source is evil! By this logic, Info-Tech should recommend
banning Windows (to the delight, I'm sure, of many
What Info-Tech means by "closed source" is in fact "proprietary algorithm". The usual stance amongst cryptography researchers is that proprietary algorithms must be avoided at any price because they have not been cryptanalyzed as much as standard algorithms, so they have higher chances of being flawed. It would be much better if Skype replaced its algo by AES for example.
Err I was supposed to be "funny", who modded me "insightful" ?
:)
Usually when I try to be funny, I am modded "flamebait" because nobody get my joke, or not modded at all because nobody not even care about reading me. But this is the 1st time ever that I am modded "insightful".
Damn ! Why is it so hard to be funny on slashdot ? Am I that bad ?
As an eminent member of the NKKSU (North Korean Kraeizy Scientist Union), I see absolutely no problem with such practices. I myself regularly force my own lab slav^H^H^H^Hworkers to do such things. Those bastards are so lazy anyway that this is the only way to justify their outrageously high wages. No later than yesterday one of them even asked me a raise to $3.75 per hour. What the H-E-L-L was he thinking ? I can tell you that I added him immediately to the list of subjects that are going to be used in this experiment with the RNA-deconstructor human immunodeficiency virus. This time this is an improved version which works (I think). -- Dr. Madh
Hot girls have this feature built-in.
You want to _prevent_ Africa from getting access to IT ressources ? I am sorry but this is completely stupid.
Education is more important than food.
Hum, those archeologist must have never explored my kitchen.
This is called a cameo because he would not be listed in the credits.