I agree, it's too bad they didn't test the Turion MT. These benchmarks conclude that (1) the Turion ML-44 "only" offer performances similar to the Pentium M 760, and that (2) the Turion system consume as a whole a third more power than the Pentium system at full load (but, good news, a bit less at idle).
From my point of view, in order to improve (1) and (2), I would:
Design a next-gen Turion processor with a dual-channel memory controller, in order to be on par with the Pentium M and because most benchmarks where the Turion is behind seem to be due to the single-channel memory bus (picColor, Linpack, WorldBench Office XP, WorldBench WinZip, etc).
Use a Turion MT instead of a Turion ML, and optimize the AMD motherboard components to consume less power, because the difference in power consumption is so huge (AMD system: 99 W, Intel system: 75 W) that the CPU alone cannot explain it (Turion ML TDP: 35 W, Pentium M TDP: 27 W).
But isn't the above obvious ? Why neither the article conclusion, nor slashdot readers have pointed this out ?
there may in fact be larger ice deposits on the far side of the moon anyway.
No, because the dark side of the moon is exposed to as much light as the non-dark side of the moon.
At the Full Moon, the dark side doesn't see the Sun.
At the New Moon, the dark side does see the Sun.
What is the scientific end game of sending people to Mars?
What was the scientific end game of Columbus's voyage to the Americas ?
I use virtualization a lot, both at work and for for personal needs. I have
got about 20 disk images, and my work typically requires me to run 2 or 3
virtual machines concurrently. Three or 4 years ago, I was using VMWare
because it was basically the only product that worked well at the time.
However I have switched to Qemu since then, because IMHO it is
technically superior. Here is why:
Qemu copy-on-write disk image formats allows me to have as many different
disk images of the same OS while using MUCH LESS disk space than VMWare.
For example at work, I have N images of Windows XP, each configured with a
different set of applications, parameters, etc, and all of them can be run
concurrently. For me the lack of this feature in VMWare is clearly a
showstopper, if I had to use VMWare I would have to create litteraly N
different images, and it would use N times the disk space of Qemu (!). I
cannot understand why VMWare STILL doesn't offer you such a feature after
so many years.
Qemu copy-on-write disk image formats also allows me to create a new disk
image instantly (less than 1 sec). The closest existing VMWare feature
("snapshot") is slow and not as convenient.
Qemu offers the option of being run on a machine without an X server. This
is useful because my servers running Qemu don't need to be bloated with X,
they are also more secure (no exported X display, etc). It is also much
faster to run, create and manage virtual machines using Qemu's command line
tools than using VMWare's GUI. And graphical guest OSes are usually
accessed over VNC-like protocols so the lack of X doesn't matter.
Qemu, like VMWare, uses a kernel module to implement different techniques
to speed up virtualization. However Qemu kernel module is smaller (less
potential security vulns) and more stable (in my experience).
Qemu offers you the possibility of NOT using this kernel module. It can be
very useful when you need to fire it up on a random machine: you don't have
the obtain its kernel headers and you don't need to compile a kernel
module.
Qemu offers a CLI tool to create, convert, commit (copy-on-write) disk
images; the main Qemu binary is also a CLI tool; and the monitor device can
also be redirected to standard input/output. The obvious
advantage of this is that the whole Qemu suite is scriptable and flexible. I have
written quite a few scripts to ease my life, you can control basically
everything: start, shutdown, reboot, eject CD drives, save screenshots,
pause/continue emulation, etc. I know that VMWare has recently introduced
a Perl API, but I don't know if it is as complete as what you can do with
Qemu.
Qemu is open-source, relies on standard kernel components and is generally
better engineered. For example it uses the existing tun/tap driver and lets
the users use iptables, to create virtual network interfaces and do
NAT/bridging, etc. While VMWare re-implements THEIR virtual interfaces,
THEIR nat code and THEIR bridging code, unnecessarily adding potential bugs
and complexity to the whole system. VMWare has to do this because they
have to support other technically inferior host OSes (Windows has no
tun/tap driver, its firewall is not as powerful as iptables, etc).
The only feature I would like to see implemented in Qemu is the one allowing you to make real USB devices available to guest OSes.
But anyway VMWare has so many disadvantages (see above) that for me it's a clear no-go.
I think people praising VMWare are maybe too close-minded and don't realize its disadvantages because they have no experience with other virtualization softwares...
There is also this common misconception that, on the global desktop & server PC market, Apple is extremely small compared to Dell. People think that Apple sells 1% or less of the total number of PCs sold by Dell. But this is wrong, Apple has got 1/7th (14%) of Dell market share. Given this perspective, Apple suddenly appears much bigger...
To answer you question: of course no, I am not just looking at the cost of parts. I know that vendors HAVE to provide all the usual services such as maintenance, remote monitoring, parts replacement, support, help, fine-tuning, installation, etc.
Thanks for your input, guys. I am pretty confident in my approach, and I am going to seriously think about it:)
I'll eat my dog if this [Google Ubuntu-based distribution] is released to the world as a "consumer" distribution, designed to take Windows marketshare.
Thanks to Slashdot, your post is archived.
I predict this will happen.
History will prove me right.
No I don't work for NetApp. Could you be more specific about what would interest you ? You would buy 1000 TB for $2m USD. What about 500 TB for $1.2m USD ? 250 TB for $700k USD ? Would you like such a product to appear as a single file server on your network ? Or, say 10 or 100 independent fileservers ? What about the protocol NFS, FTP, TFTP, CIFS, other ? Do you have any power requirements (the whole thing must be
Yes, my $2 million USD price would include redundant disks, servers, power supplies, enclosures, disk controllers, network gear, maintenance contract with on-site technician to replace failing parts, etc. Everything would be pretty much redundant. The only thing is, the initial investment necessary to start my business (and validate my ideas) would be high: $3 million USD (first product + initial development cost + safety margin). And of course I am pretty sure that if my idea pulls off, EMC would immediately try to kill my business by slashing their prices because I know they know their prices already include large margins...
This is an idea that I have considered. But in my case, I am
very nomadic: I move about once every 12 months. So if I hosted my own server, I would have at least 3 to 4 weeks of downtime every 12 months (time to move and subscribe to a new DSL plan), plus a change of IP address. Add to this the frequent power outages in my area (California), and IMHO this is just too much hassle. Compare this to a managed colo for 1U with a 10 Mbps (if not 100 Mbps) symmetric connection for about $100 a month or less, and I think for me the colo makes more sense... But of course I would be happy to change my mind if someone can share a good experience while hosting his own server and moving frequently...
Damn I really need to create my own business in the storage market.
I am not exactly sure about what EMC provides in this $4 million package
(servers, 24x7 contract, maintenance, hard disk replament, etc) but
I KNOW how to create a 1 PB storage device for less than half the price ($2 million instead of $4 million). And I am pretty sure about my numbers...
I am sick of the current state of the storage market. Vendors are either designing unnecessarily expensive solutions, or are having HUGE margins...
I have thought about it a lot. I work from many different locations (at work, at home, at random places on my laptop using a wireless Internet provider, etc) on a multitude of projects, and basically my need is to have a permanent access to a secure Unix server offering flexible services on my DNS domain, in order to:
Use it as a mail server, get myself a permanent email address (independent of my current employer and/or the current trendy free email account provider), forward most of my current email addresses to this central location, archive some of the emails without having to worry about the available storage space, archive the most important mailing lists I am subscribed to, and be able to conveniently access all of this at anytime using a local Mutt instance via SSH (or a remote IMAP/SSL client). Nothing is as fast as a textual mail interface to manage a huge amount of emails.
Use it as a web server, because I need to have a permanent HTTP address for some of my stuff (articles/papers I publish, etc). When I say "permanent", I expect to use the same domain and URL in 30 years.
Use it as a handy Unix shell available at anytime, from which I have direct access to the Internet: no fscking fw, no high-latency DSL connection, convenient end-point for my private VPNs, etc.
Store and edit the data that I use very frequently: current open source projects I am working on, etc.
That's why I plan to buy a 1U server with at least 2 disks in order to do RAID 1, and I will have it collocated in a datacenter offering affordable prices. I plan to use an encrypted partition (think/home) to store my data, this partition will have to be mounted manually (to enter the required passphrase). This way if someone power off the server and try to steal my data, the encrypted partition will be useless for him.
Ideally I would have preferred NON-managed colocation (i.e. I would responsible for the physical installation of my hardware in the rack, and I would have access to it 24/7), but since it's too expensive I have chosen to go for managed colocation (i.e. I send my server to the colo company and they install it, but I would not have free physical access to my server).
My suggestion to the OP is that if he wants to achieve a high I/O rate at the lowest possible price, then the solution if of course to use a Google-like solution: use commodity hardware.
For example buy a lot of ATA/SATA harddisks (in order to spread the load over them), use them inside ATA-over-Ethernet enclosures (www.coraid.com, Linux driver available in any 2.6 vanilla kernel), and connect them with multiple Gigabit Ethernet links to the storage server. And the best part in all of this: ATA/SATA is so cheap, that you will be able to buy 3 or 4 times more disks than a Fiber Channel solution, allowing you to get more storage space, and a substancially better "I/O rate per dollar" ratio.
Of course ATA/SATA disks are less reliable than FC disks, but this shouldn't matter, because even with expensive high-end solutions, you have to plan for disk failures. With a Fiber Channel solution, you might have to replace a disk every 12 months in your RAID arrays. With an ATA/SATA solution, it might happen every 2 months. But in both cases you don't care: the RAID layer will protect you.
The Cell's general purpose "controller" CPU is an incredibly stripped down PPC core that has incredibly low performance compared to any standard general purpose CPU.
Maybe you should tell that to IBM, so that they don't waste time & money researching the possibility of building "incredibly low performance" Cell-based Blade servers.
I can clearly see the typical usage that could be made of such servers. Your VPN server spends 90% of it's CPU time doing crypto-related operations ? Replace it with a Cell-based server using a Cell-optimized crypto library. You have a server farm doing video encoding ? Replace it with Cell-based servers using Cell-optimized video encoding routines.
Regarding Cell-based workstations, I can't predict whether this market will ever develop or not because it all depends on the software that will be ported to it. Open source apps have a net advantage of course, since they simply need to be recompiled for the Cell. IBM has already ported Linux to the Cell too. And as a Linux/BSD guru, I would not hesitate to buy a Cell-based workstation just to play with it. Because I know I don't need a 3.4 GHz Pentium 4 to browse the web, send emails, read PDFs, write some code, play a few MP3s, etc. I was an early adopter of AMD64, I bought my dual-Opteron box, and have contributed various assembly-optimized code to various open source projects. I expect to do the same with the Cell.
I'm an operations guy, and BAD IMPLEMENTATION = DON'T USE.
I totally agree with you. I am also someone who had to go with RAID 1 instead of RAID 5 a few times because of some external constraints I did not have control on ("client: this server must use windows with this hardware RAID card", no Linux, no MD).
The OP was stating more "RAID 5 is the cat's pajama's, always use RAID 5".
I was the OP and more precisely what I meant is that RAID 5 should be the first option considered by a system designer (because of its good usable/total disk space ratio and good sequential read/write speed). But then of course, if small random writes are common and performance really matters, or if using a bad hardware implementation is a constraint of the project, then a system designer should consider other RAID strategies.
People tend to discard the RAID 5 option too early. Here is a typical scenario I have seen too many times: they test RAID 5 with their favorite hw card but see it is slow. So they try to invent false arguments explaining this (like "writing a byte require N-1 reads + 2 writes", while in reality 2 reads are sufficient), whithout understanding the real reasons of this slowness (bad hw implementations). Then their incorrect reasoning leads to those misconceptions that I hate so much ("I tried RAID 5 with my hw card, it was slow, by consequent any other RAID 5 implementation shall be slow"). No wonder why some of them are then surprised by the performances of Linux's RAID 5 MD driver...
Here is another thing most people don't know: large sequential writes on a RAID 5 array do not require previous reading of parity data.
the entire "stripe" would have to be in cache for both parity and data.
It happens more often than you think (because of read ahead and because of the small size of stripes).
I find the caching algorithms are far better at allowing RAID 1 to match RAID 5 read performance than letting RAID 5 match RAID 1's write performance. But perhaps thats because I'm wasting my time with real world performance metrics than theoretical models.
Let me repeat it again: the vast majority of poor performances observed with RAID 5 is due to BAD HARDWARE IMPLEMENTATIONS, it's not due to the design of RAID 5 itself. That's why I hate hearing people saying "RAID 5 is slow" when actually the culprit is their hardware RAID 5 card. And even when using Linux's MD drivers, in some particular workloads RAID 5 may be slower than usual because it is very sensitive to the I/O scheduling algorithm and to the way the scatter/gather mechanism acts. And guess what ? Here again people think "RAID 5 is slow" when actually the culprit is a side-effect of the I/O scheduling algorithm and or scatter/gather mechanisms (in other words the kernel is not tuned correctly). You really have to trust me on this. I have profiled so many RAID performance issues (and fixed so many) that I know for a fact that RAID 5 in itself, RAID 5 as a design, RAID 5 as a way to use block devices, does not deserve the current disrespect so many people show towards it.
You seem to belong to the 5% of engineers that actually understand RAID, good:-) However I disagree with you on 2 points:
Assuming good implementations of RAID 1+0 and RAID 5, reads from RAID 1+0 arrays are NOT faster than reads from RAID 5 arrays. This is because in order to interleave reads from mirrored disks, the heads have to constantly seek to the next block of data to read, read it, then seek again, read, etc. So you can NEVER reach the combined output of N x individual_disk_read_speed, but more something like N x f x individual_disk_read_speed where f is a factor in the range [0..1] and depends primarily on the chunk size and the disk seek time (e.g. f=0.8 or f=0.9). Whereas in RAID 5 arrays the parity data is always read (in order to be verified), so the heads don't have to seek when doing sequential reads => you end up with EXACTLY (N-1) x individual_disk_read_speed. Of course when N increases, RAID 5 read speeds increase more than RAID 1+0 read speeds, because the later is always limited by this f factor.
You said "RAID 5 write speed is poor". I disagree here too, because for the same reasons than explained above, RAID 5 write speeds can theoretically be AS FAST AS RAID 1+0 write speeds. Most disapointing RAID 5 write speeds experienced in the real world are due to poor implementations, or inadequate I/O scheduling, or hardware cache bottlenecks. For example NONE of the hardware RAID 5 cards I have seen in my whole life offer decent RAID 5 write speeds, even the most expensive ones from Adaptec, LSI, etc. AFAIK Linux software RAID 5 implementation seems to be the only one offering decent RAID 5 write speeds. One of my big project is to rewrite FreeBSD's RAID 5 code, so that we have at least two competitors in the area:-)
Slashdot Mirror
-
Design flawed OS
-
Sell flawed OS
-
Profit !!!
Any ressemblance to any situation, person, event, past, present and future is completely fortuitous.I agree, it's too bad they didn't test the Turion MT. These benchmarks conclude that (1) the Turion ML-44 "only" offer performances similar to the Pentium M 760, and that (2) the Turion system consume as a whole a third more power than the Pentium system at full load (but, good news, a bit less at idle). From my point of view, in order to improve (1) and (2), I would:
But isn't the above obvious ? Why neither the article conclusion, nor slashdot readers have pointed this out ?
Easy, if your mom has small boobs, then she is not an actress.
No, because the dark side of the moon is exposed to as much light as the non-dark side of the moon.
At the Full Moon, the dark side doesn't see the Sun.
At the New Moon, the dark side does see the Sun.
What was the scientific end game of Columbus's voyage to the Americas ?
I use virtualization a lot, both at work and for for personal needs. I have got about 20 disk images, and my work typically requires me to run 2 or 3 virtual machines concurrently. Three or 4 years ago, I was using VMWare because it was basically the only product that worked well at the time. However I have switched to Qemu since then, because IMHO it is technically superior. Here is why:
The only feature I would like to see implemented in Qemu is the one allowing you to make real USB devices available to guest OSes. But anyway VMWare has so many disadvantages (see above) that for me it's a clear no-go. I think people praising VMWare are maybe too close-minded and don't realize its disadvantages because they have no experience with other virtualization softwares...
There is also this common misconception that, on the global desktop & server PC market, Apple is extremely small compared to Dell. People think that Apple sells 1% or less of the total number of PCs sold by Dell. But this is wrong, Apple has got 1/7th (14%) of Dell market share. Given this perspective, Apple suddenly appears much bigger...
$ sed 's/Iraq/Iran/g' *.c
$ make install
war.c: In function `analyze_country':
war.c:42: warning: variable `Iran' might possess nuclear weapons
Yes. And I am dead serious: mostly open source apps + in-house software for the missing parts (I know exactly which ones are missing).
To answer you question: of course no, I am not just looking at the cost of parts. I know that vendors HAVE to provide all the usual services such as maintenance, remote monitoring, parts replacement, support, help, fine-tuning, installation, etc.
Thanks for your input, guys. I am pretty confident in my approach, and I am going to seriously think about it :)
Thanks to Slashdot, your post is archived.
I predict this will happen.
History will prove me right.
See you soon,
(rest of the post)
...the whole thing must be < 50 kW) ? That's it, no more questions.
No I don't work for NetApp. Could you be more specific about what would interest you ? You would buy 1000 TB for $2m USD. What about 500 TB for $1.2m USD ? 250 TB for $700k USD ? Would you like such a product to appear as a single file server on your network ? Or, say 10 or 100 independent fileservers ? What about the protocol NFS, FTP, TFTP, CIFS, other ? Do you have any power requirements (the whole thing must be
Yes, my $2 million USD price would include redundant disks, servers, power supplies, enclosures, disk controllers, network gear, maintenance contract with on-site technician to replace failing parts, etc. Everything would be pretty much redundant. The only thing is, the initial investment necessary to start my business (and validate my ideas) would be high: $3 million USD (first product + initial development cost + safety margin). And of course I am pretty sure that if my idea pulls off, EMC would immediately try to kill my business by slashing their prices because I know they know their prices already include large margins...
This is an idea that I have considered. But in my case, I am very nomadic: I move about once every 12 months. So if I hosted my own server, I would have at least 3 to 4 weeks of downtime every 12 months (time to move and subscribe to a new DSL plan), plus a change of IP address. Add to this the frequent power outages in my area (California), and IMHO this is just too much hassle. Compare this to a managed colo for 1U with a 10 Mbps (if not 100 Mbps) symmetric connection for about $100 a month or less, and I think for me the colo makes more sense... But of course I would be happy to change my mind if someone can share a good experience while hosting his own server and moving frequently...
Damn I really need to create my own business in the storage market. I am not exactly sure about what EMC provides in this $4 million package (servers, 24x7 contract, maintenance, hard disk replament, etc) but I KNOW how to create a 1 PB storage device for less than half the price ($2 million instead of $4 million). And I am pretty sure about my numbers...
I am sick of the current state of the storage market. Vendors are either designing unnecessarily expensive solutions, or are having HUGE margins...
I have thought about it a lot. I work from many different locations (at work, at home, at random places on my laptop using a wireless Internet provider, etc) on a multitude of projects, and basically my need is to have a permanent access to a secure Unix server offering flexible services on my DNS domain, in order to:
That's why I plan to buy a 1U server with at least 2 disks in order to do RAID 1, and I will have it collocated in a datacenter offering affordable prices. I plan to use an encrypted partition (think /home) to store my data, this partition will have to be mounted manually (to enter the required passphrase). This way if someone power off the server and try to steal my data, the encrypted partition will be useless for him.
Ideally I would have preferred NON-managed colocation (i.e. I would responsible for the physical installation of my hardware in the rack, and I would have access to it 24/7), but since it's too expensive I have chosen to go for managed colocation (i.e. I send my server to the colo company and they install it, but I would not have free physical access to my server).
You should read /. more often, Vista will have a new soundtrack from Robert Fripp !!
My suggestion to the OP is that if he wants to achieve a high I/O rate at the lowest possible price, then the solution if of course to use a Google-like solution: use commodity hardware.
For example buy a lot of ATA/SATA harddisks (in order to spread the load over them), use them inside ATA-over-Ethernet enclosures (www.coraid.com, Linux driver available in any 2.6 vanilla kernel), and connect them with multiple Gigabit Ethernet links to the storage server. And the best part in all of this: ATA/SATA is so cheap, that you will be able to buy 3 or 4 times more disks than a Fiber Channel solution, allowing you to get more storage space, and a substancially better "I/O rate per dollar" ratio.
Of course ATA/SATA disks are less reliable than FC disks, but this shouldn't matter, because even with expensive high-end solutions, you have to plan for disk failures. With a Fiber Channel solution, you might have to replace a disk every 12 months in your RAID arrays. With an ATA/SATA solution, it might happen every 2 months. But in both cases you don't care: the RAID layer will protect you.
Yes it will. Cryptography is an area where Cell designers especially expect the processor to perform well. See this.
Well we can't really say anything until IBM actually announces those Cell-based server. So, wait and see.
Yes, it will.
Maybe you should tell that to IBM, so that they don't waste time & money researching the possibility of building "incredibly low performance" Cell-based Blade servers.
I can clearly see the typical usage that could be made of such servers. Your VPN server spends 90% of it's CPU time doing crypto-related operations ? Replace it with a Cell-based server using a Cell-optimized crypto library. You have a server farm doing video encoding ? Replace it with Cell-based servers using Cell-optimized video encoding routines.
Regarding Cell-based workstations, I can't predict whether this market will ever develop or not because it all depends on the software that will be ported to it. Open source apps have a net advantage of course, since they simply need to be recompiled for the Cell. IBM has already ported Linux to the Cell too. And as a Linux/BSD guru, I would not hesitate to buy a Cell-based workstation just to play with it. Because I know I don't need a 3.4 GHz Pentium 4 to browse the web, send emails, read PDFs, write some code, play a few MP3s, etc. I was an early adopter of AMD64, I bought my dual-Opteron box, and have contributed various assembly-optimized code to various open source projects. I expect to do the same with the Cell.
Does that mean you shoplifted the 'y' ?
I totally agree with you. I am also someone who had to go with RAID 1 instead of RAID 5 a few times because of some external constraints I did not have control on ("client: this server must use windows with this hardware RAID card", no Linux, no MD).
I was the OP and more precisely what I meant is that RAID 5 should be the first option considered by a system designer (because of its good usable/total disk space ratio and good sequential read/write speed). But then of course, if small random writes are common and performance really matters, or if using a bad hardware implementation is a constraint of the project, then a system designer should consider other RAID strategies.
People tend to discard the RAID 5 option too early. Here is a typical scenario I have seen too many times: they test RAID 5 with their favorite hw card but see it is slow. So they try to invent false arguments explaining this (like "writing a byte require N-1 reads + 2 writes", while in reality 2 reads are sufficient), whithout understanding the real reasons of this slowness (bad hw implementations). Then their incorrect reasoning leads to those misconceptions that I hate so much ("I tried RAID 5 with my hw card, it was slow, by consequent any other RAID 5 implementation shall be slow"). No wonder why some of them are then surprised by the performances of Linux's RAID 5 MD driver...
Here is another thing most people don't know: large sequential writes on a RAID 5 array do not require previous reading of parity data.
I say Santa Claus does exist...
It happens more often than you think (because of read ahead and because of the small size of stripes).
Let me repeat it again: the vast majority of poor performances observed with RAID 5 is due to BAD HARDWARE IMPLEMENTATIONS, it's not due to the design of RAID 5 itself. That's why I hate hearing people saying "RAID 5 is slow" when actually the culprit is their hardware RAID 5 card. And even when using Linux's MD drivers, in some particular workloads RAID 5 may be slower than usual because it is very sensitive to the I/O scheduling algorithm and to the way the scatter/gather mechanism acts. And guess what ? Here again people think "RAID 5 is slow" when actually the culprit is a side-effect of the I/O scheduling algorithm and or scatter/gather mechanisms (in other words the kernel is not tuned correctly). You really have to trust me on this. I have profiled so many RAID performance issues (and fixed so many) that I know for a fact that RAID 5 in itself, RAID 5 as a design, RAID 5 as a way to use block devices, does not deserve the current disrespect so many people show towards it.
You seem to belong to the 5% of engineers that actually understand RAID, good :-) However I disagree with you on 2 points: