Slashdot Mirror
Adaptec Supporting Ultra160 On IA-64 Linux
GeorgieBoy writes: "Adaptec has announced support for Ultra160 SCSI adapters under Intel 64-bit Linux. Looks like IA-64 Linux will be pretty well supported upon Itanium's arrival." There already are SCSI adapters for the (also 64-bit) Alpha under Linux, but this move sounds like a smart one for Adaptec to tie their name to both Linux and IA-64. Other companies planning pre-emptive hardware support? Step right up, please.
Unfortunatly, most systems running linux are not for high-performance environments...
Please define "high-performance." Standing alone, this comment may appear at first glance to be flamebait.
"Wouldn't the time be better spent bring a real _server_ OS up to IA-64 spec?"
To what end? So that high-end hardware becomes useable only by "high-end" (READ: rediculously expensive) OS users? Umm...or would the time perhaps be better spent bringing high-performance features to Linux? As a sysadmin who has worked with both Linux and some of those other "real _server_ OS"'s you speak of, I'd much rather see Linux brought up to the level of Solaris and some of the other enterprise-level, high-performance OS's out there.
I'd just rather deal with Linux on a daily basis. I've learned it's a much more pleasant experience than wrangling with some of the commercial UNIX offerings.
I'm glad to see more development of this nature. Congrats to Adaptec for taking this first, small step in the right direction. Next step: Open-source drivers, open hardware and development specs.
Back then, it was the desktop, and there was no competition.
Right now, this is for servers, M$ is trying to make W2K the be-all, and there's some fierce competition. This will be a real black eye for M$ marketing. It will put paid to a lt of their boasting as to being ready for the enterprise server market. It will be DELICIOUS!
--
Infuriate left and right
I wonder if gcc is up to the task for compiling programs for IA64.
Compaq is saying that its compilers is generating code whichs runs 2 times faster than code generated by gcc.
For the Alpha, a chip for which code generation is much more easier than the IA64 (VLIW compilers are complicated beasts!).
So Linux will run first on the IA64, yes, but will it have good performances ? I'm not sure at all.
Does anyone have more informations ?
Ya, but dont forget about the problems with the i820 and i840 chip sets. Also lets not forget the poor access time of the Rambus. I guess it comes down to BX boards and chips being the only thing to get if you REALLY want stability.
Linux O Muerte!
Well, this comes to ~50-55 MBs xfer rate from the drive media to the cache on the drive... of course you can burst from the 2MB cache at up to bus speed (more or less), and if you are on a slower bus (plain old UW, etc) you could do a non-cached burst... that being said, if all you are doing is serving static files, then - yeah, the bottleneck isn't the drive most of the time, but if the drive has to do a lok of seeks, and collect db records from many areas of the disk (assuming you don't use an array or other method of speed-up) then your drive won't be bursting at full rate, since it will disconnect until the data is ready. This can then be the bottleneck, regardless of bus speed... seek times kill. Then you actually have to manipulate the data before you send it out, but that's usally an order of magnitude or three less than the disk access...
drive seek: 10^-3
CPU cycle: 10^-9 (so even 100 cycles is still *way* faster than a disk access
"It's tough to be bilingual when you get hit in the head."
Another good question: How many months until ATA 200? The IBM 75G Deskstar article talks about ATA 100 support. Yeah, SCSI has it's place, yeah it has low CPU over head, etc, but is adaptec not getting a little worried? Can you imagine the situation if ATA transfer rates exceed SCSI? SCSI drives are targeted for server market, which makes their prices "unnaturally" high (inelastic demand) but at some point might not it become cheaper to build, say, a HD subsystem blackbox of ATA drives with it's own CPU, microkernel feeding a host through gigabit ethernet or something? If the software tools were in place, you might get a full ATA host with the disk subsystems priced at half the cost of SCSI flavor.
Take home prophecy: Linux (i.e. geeks) kill the SCSI oligarchy.
Go Geeks Go
Unfortunatly, most systems running linux are not for high-performance environments. Wouldn't the time be better spent bring a real _server_ OS up to IA-64 spec?
Desperation is a stinky cologne
It seems to me that this is just a tacit admission by a major hardware manufacturer that Linux is well ahead of Doze, Solaris and any other OSes that are being developed for IA64. Based on Microsoft's previous record, we might see a 64 bit IA64 windows sometime in 2002, and Solaris is for the time being on hold, after a rather childish slagging match between Intel and Sun with each one claiming that the other was not pulling their weight by doing a fair share of the porting effort. As a result, when Itanium arrives, there will be only one viable choice - Linux. So if you are a hardware manufacturer that would like to be able to take advantage of the new architecture - then you can wait 2 years for MS, or you can just bite the bullet (jump on the bandwagon?) now. It's a question of simple, obvious business sense.
ø`ø,,ø`ø,,ø`ø,,ø`ø,,ø`ø,,ø`ø,ø`ø
Adaptec has high bandwidth Hard drive controllers to sell on the x86 market. They believe iNTEL's claim that this will be Itanium in just a few short months. Therefore they must make this available for Itanium and support it as much as possible.
Since there is only one complete OS that's correctly capable of doing real work on Itanium today; they really have no choice. See this story for details about Turbo Linux on Itanium. This isn't just a kernel or a compiler but a full, functional Linux distribution. The closest thing anyone has to a Linux distribution ( in terms of included Apps ) is Microsoft's "Back Office suite".
--= Isn't it surprising how badly I spell ?
This is nothing new. Remember it was many YEARS after the release of the 386 MS came out with a version of Windows that used any 32bit features. For those who don't remember it was Windows 3.1 and the features were performance tweaks for virtual memory. It would still run on a 286 if you knew how to detune the setup.
All the apps for the platform were 16 bit however. It wasn't until yet more years that they actually released a 32 bit OS. It was Windows NT and though it had some 16 Bit stuff in there it qualified as a 32 bit OS even in early release.
MS will sell a 32 bit OS or even that hybrid 16/32 bit Win98 or WinME on Itanium and the market will lap it up. Perhaps not as quickly or in the volumes that Linux will enjoy but enough to be noticed.
As for Monterey. I have herd a lot of posturing from the people producing it and some talk from people who promise to ship it on boxes but I have yet to here customers who say "We want to use Monterey on Itanium to run our business". Why would they ? It's a compliantly unknown quantity. In the Jargon file it qualifies as Vaporware. I.e. Nobody has seen even an Alpha build.
--= Isn't it surprising how badly I spell ?
Even with a pair of Quantum Atlas V drives (27 MB/sec write rate), I doubt that any real performance gains will be measured running at 160 MB/sec burst rate over 80 MB/sec (U2W).
Now, when you've got a RAID 0 stripe 4 drives deep, that might show some potential for improvement.
So this one is definitely for the server room.
Those new IBM drives with up to a 16 MB cache - if you have 16 MB cache on each drive, plus 64 MB cache on the RAID controller, then the 80 MB/sec is potentially rate-limiting.
So - how many months until Ultra 4 320/m SCSI?
Paul
.
They should think about becoming more like Advansys who actually provide kernel tuning advice.
Or perhaps Symbios who have programming guides and real datasheets for much of their stuff.
free login required
Basically Adaptec should spend some of it's time thinking about the customer now, not the the customer in a year that they are trying to create.
--
dronf!