MIPS and SPARC
Matt Wieben
processors scale up to each other. I've been looking into both
architectures but I haven't yet decided what I want to switch to. So I'm
just looking for some opinions. Thanks.
Douglas Siebert
Are those your only two choices? If so, why those two? What are you
switching from? Why are you switching from it? What are you switching
(i.e., what are you doing currently that is being "switched"?)
Without more information, we may as well compare MIPS and Sparc based on
the number of letters in their names, because it'll be just as effective
as any technical discussion when you provide ZERO information.
--
Doug Siebert
dsie...@excisethis.khamsin.net
If at first you don't succeed, skydiving is not for you.
Matt Wieben
Intel based platform. The only info I have really found has been on the MIPS
R10000 type, nothing on the Sparc so far. But what I really want is a
processor that does floating point math on small data sets very efficiently.
Precision doesn't concern me as it is already nice enough for me on Intel
hardware (minus Windows), and I can't imagine the Sparc and the MIPS to be
less. So mainly what I would be doing on it is creating, optimizing, and
applying signal processing software. From what I have read, a 64-bit RISC
processor might just be the way to go with the types data of algorithms we
are planning on using, and the Intel Itanium doesn't sound too intriguing to
me right now. From where I am now, I am considering either the SGI O2
system(MIPS) or the Sun Ultra 60 system; both are comparatively priced and I
want one that will do fine mathematical operations very smoothly. I am aware
that any processor will do this, and I don't want this to turn into an 'AMD
vs. Intel' type post you see everywhere. I would like to hear opinions on
which type of architectures you have seen good floating-point performance
on. If you wish me to clarify anything further please let me know...I don't
want to purchase a system like this on a mere flip of the coin even though I
might just have to do that. Thanks.
Rob Young
> Well, I'm mainly switching between those two based on price, coming from an
> Intel based platform.
Not sure why you would switch if you are considering price.
A 128 MByte , 1.5 GHz Dell lists for $2200. A SunBlade 1000
workstation with a 900 MHz UltraSparc III lists for $9995+. And
the Dell considerably outperforms the Sun box on floating point ops:
Sun Microsystems Sun Blade 1000 Model 1900
http://www.specbench.org/osg/cpu2000/results/res2000q3/cpu2000-20000911-00219.asc
SPECfp_base2000 427
SPECfp2000 482
Dell Precision WorkStation 330 (1.50 GHz P4)
http://www.specbench.org/osg/cpu2000/results/res2000q4/cpu2000-20001121-00323.asc
SPECfp_base2000 543
SPECfp2000 552
You may wish to read the detailed descriptions of the
benchmarks themselves to see if there is a similarity to
any of what you are doing:
http://www.specbench.org/osg/cpu2000/CFP2000/
Likewise , before you commit to any box you may wish to
get a loaner and at the very least see how it does against
a 1.5 GHz P4. No use throwing money away, eh?
Rob
Douglas Siebert
>Well, I'm mainly switching between those two based on price, coming from an
>Intel based platform. The only info I have really found has been on the MIPS
>R10000 type, nothing on the Sparc so far. But what I really want is a
>processor that does floating point math on small data sets very efficiently.
>Precision doesn't concern me as it is already nice enough for me on Intel
>hardware (minus Windows), and I can't imagine the Sparc and the MIPS to be
>less. So mainly what I would be doing on it is creating, optimizing, and
>applying signal processing software. From what I have read, a 64-bit RISC
>processor might just be the way to go with the types data of algorithms we
>are planning on using, and the Intel Itanium doesn't sound too intriguing to
>me right now. From where I am now, I am considering either the SGI O2
>system(MIPS) or the Sun Ultra 60 system; both are comparatively priced and I
>want one that will do fine mathematical operations very smoothly. I am aware
>that any processor will do this, and I don't want this to turn into an 'AMD
>vs. Intel' type post you see everywhere. I would like to hear opinions on
>which type of architectures you have seen good floating-point performance
>on. If you wish me to clarify anything further please let me know...I don't
>want to purchase a system like this on a mere flip of the coin even though I
>might just have to do that. Thanks.
For small data sets, you probably care most about cache size and clock
rate. Given that both Intel and AMD CPUs clock _much_ higher than either
MIPS or Sparc, I doubt you'll improve your performance much, if at all.
Yes, those are 64 bit chips, but floating point work doesn't benefit any
from a 64 bit CPU when you are working with small datasets.
If your performance on those x86 CPUs is not good enough, either you are
not optimizing too well, or the cache is too small. If its the latter,
you might want to look at a low end HP PA-RISC system such as a B1000 or
A500. Those systems have 1MB L1 data cache, which is significantly larger
than anything else out there. Plus its FPU can sustain two muladds per
cycle, so if you happen to be doing lots of multiplies and additions on
data > 256K but less than 1MB there's no way anything else can beat it.
Once you get above 1MB then it is a different story, and the story quickly
changes to where Alpha systems are superior (I don't know what their
pricing is, but I assume they have something low end comparable to the O2,
Ultra 60, B1000, etc.)
In short, I wouldn't limit yourself to just MIPS and Sparc, since it is
fairly likely you'd do better with either a PA-RISC or Alpha based system.
But like I said above, depending on the size of your dataset, you may do
best with an x86 system due to the high clock rate, and just need to do a
better job in the code writing department.
Chris Morgan
> Not sure why you would switch if you are considering price.
> A 128 MByte , 1.5 GHz Dell lists for $2200. A SunBlade 1000
> workstation with a 900 MHz UltraSparc III lists for $9995+. And
> the Dell considerably outperforms the Sun box on floating point ops:
This is so misleading. On the one hand it's too fair to Sun since they
don't actually offer to sell 900MHz cpus in their workstations yet. On
the other hand, when they do, I'm fairly certain that that $9995 will
include such goodies as a dual-cpu capable motherboard, an 8MB L2
cache, 512 MB ECC SDRAM, IEEE 1394 controller, smartcard reader and an
18GB 10000 RPM FC/AL hard disk. Of course you have to add in a
monitor, DVD drive and floppy to make the complete package.
At least spec up the Dell to that level, I make that an absolute
minimum of $4300, although it's either a dual-capable PIII machine, or
single P4 at this point, so it's not a good match. Now add in the
discount a typical buyer will get off Sun (typical = large Sun
customer, buying servers, storage, software from them too). It will
probably be a higher discount numerically than Dell.
I would say the real prices are more like $5k vs. $10k. Perhaps that's
an easy win for the Dell for some people, but obviously not the same
gross mismatch Rob implies.
Cheers,
Chris
--
Chris Morgan <cm at mihalis.net> http://www.mihalis.net
Temp sig. - Enquire within
John S. Dyson
"Douglas Siebert" <dsie...@excisethis.khamsin.net> wrote in message news:97985v$3mj$1...@sword.avalon.net...
>
> In short, I wouldn't limit yourself to just MIPS and Sparc, since it is
> fairly likely you'd do better with either a PA-RISC or Alpha based system.
> But like I said above, depending on the size of your dataset, you may do
> best with an x86 system due to the high clock rate, and just need to do a
> better job in the code writing department.
>
in results. This is true even with the AMD chips.
John
Rob Young
> you...@encompasserve.org (Rob Young) writes:
>
>> Not sure why you would switch if you are considering price.
>> A 128 MByte , 1.5 GHz Dell lists for $2200. A SunBlade 1000
>> workstation with a 900 MHz UltraSparc III lists for $9995+. And
>> the Dell considerably outperforms the Sun box on floating point ops:
>
> This is so misleading. On the one hand it's too fair to Sun since they
> don't actually offer to sell 900MHz cpus in their workstations yet. On
> the other hand, when they do, I'm fairly certain that that $9995 will
> include such goodies as a dual-cpu capable motherboard, an 8MB L2
> cache, 512 MB ECC SDRAM, IEEE 1394 controller, smartcard reader and an
> 18GB 10000 RPM FC/AL hard disk. Of course you have to add in a
> monitor, DVD drive and floppy to make the complete package.
>
It isn't misleading. As you note, add a few hundred to the
above for a monitor. Go out to Dell and get 512 MB RDRAM
for $2900 and change:
It includes a 40 GB drive and is guaranteed to smoke that
Sun box *when* it ships (as you note, had no intention of fudding
that up).
> At least spec up the Dell to that level, I make that an absolute
> minimum of $4300, although it's either a dual-capable PIII machine, or
> single P4 at this point, so it's not a good match.
Why isn't it a good match? Because *you* decided he needed
two processors? Your $4300 is WAY too much.
>
> I would say the real prices are more like $5k vs. $10k. Perhaps that's
> an easy win for the Dell for some people, but obviously not the same
> gross mismatch Rob implies.
>
Try again.
Rob
Alt
You know, you has really two choices:
SparcUltra and SGI.
And may be PowerPC.
Oh, you know, I think, you have to choice not such architecture
as culture environment of such systems.
Sounds stupid, may be.
But traditions is a big power...
...also OSes existent software...
I have seen cheap SGI machine which had, I guess,
less number of transistors than my Cyrix MII,
But such Cyrix can not do a quater, or even 10's bit of that
which that SGI was doing.
But both SGI and SPARCs has "severs" and "mathematics" machines,
also you have to choice "inside" architecture.
There is some "cool" :) PowerPCs.
Matt Wieben wrote:
> Well, I'm mainly switching between those two based on price, coming from an
> Intel based platform. The only info I have really found has been on the MIPS
> R10000 type, nothing on the Sparc so far. But what I really want is a
> processor that does floating point math on small data sets very efficiently.
> Precision doesn't concern me as it is already nice enough for me on Intel
> hardware (minus Windows), and I can't imagine the Sparc and the MIPS to be
> less. So mainly what I would be doing on it is creating, optimizing, and
> applying signal processing software. From what I have read, a 64-bit RISC
> processor might just be the way to go with the types data of algorithms we
> are planning on using, and the Intel Itanium doesn't sound too intriguing to
> me right now. From where I am now, I am considering either the SGI O2
> system(MIPS) or the Sun Ultra 60 system; both are comparatively priced and I
> want one that will do fine mathematical operations very smoothly. I am aware
> that any processor will do this, and I don't want this to turn into an 'AMD
> vs. Intel' type post you see everywhere. I would like to hear opinions on
> which type of architectures you have seen good floating-point performance
> on. If you wish me to clarify anything further please let me know...I don't
> want to purchase a system like this on a mere flip of the coin even though I
> might just have to do that. Thanks.
>
> ? Are those your only two choices? If so, why those two? What are you
> ? switching from? Why are you switching from it? What are you switching
> ? (i.e., what are you doing currently that is being "switched"?)
> ?
> ? Without more information, we may as well compare MIPS and Sparc based on
> ? the number of letters in their names, because it'll be just as effective
> ? as any technical discussion when you provide ZERO information.
> ?
> ? --
> ? Doug Siebert
> ? dsie...@excisethis.khamsin.net
> ?
> ? If at first you don't succeed, skydiving is not for you.
Alt
Both sh..t. :)
There's no good processors, at all.
I mean, that all "modern" processor architechtures are obsolite.
Bu the way The man who working in SUN told me two days ago that
certain version of UltraSPARC has not compatibility with early SPARCS.
I mean compatibility of machine (binary) code.
So,
SPARC sales with WorkStations and servers.
When you buy SUN workstation (or server) you pay actually not
for design, and not for manufacturing but for techical support.
Why ?
Because
tech. support staff of SUN >> developers staff of SUN >> manufacturers staff
of SUN
(Note: ">>"- means "much bigger than".)
MIPS is uses in big number of applications.
Actually, I haven't seen no one of them. :)
Alpha - is not bad, aspacially from Sunsung,
but obsolete.
I mean that Sumsung make cheap Alphas.
PowerPC - cheapest architechture.
There Apple Macs with PowerPC.
There was an initiative of IBM to turn PowerPC into the populat platform.
May be IBM and Motorola still make cheap desktopes with PowerPC.
Seams that is all.
--Alt.
r.n. Mehiloe Metroffunow (I'm not russian, I'm Ukrainian !)
Alt
> In article ?9783n8$7rn$1...@usenet.nau.edu?, "Matt Wieben" ?m...@dana.ucc.nau.edu? writes:
> ? Well, I'm mainly switching between those two based on price, coming from an
> ? Intel based platform.
>
> Not sure why you would switch if you are considering price.
> A 128 MByte , 1.5 GHz Dell lists for $2200. A SunBlade 1000
> workstation with a 900 MHz UltraSparc III lists for $9995+. And
> the Dell considerably outperforms the Sun box on floating point ops:
>
> Sun Microsystems Sun Blade 1000 Model 1900
> http://www.specbench.org/osg/cpu2000/results/res2000q3/cpu2000-20000911-00219.asc
>
> SPECfp_base2000 427
> SPECfp2000 482
>
> Dell Precision WorkStation 330 (1.50 GHz P4)
> http://www.specbench.org/osg/cpu2000/results/res2000q4/cpu2000-20001121-00323.asc
>
> SPECfp_base2000 543
> SPECfp2000 552
>
> You may wish to read the detailed descriptions of the
> benchmarks themselves to see if there is a similarity to
> any of what you are doing:
>
> http://www.specbench.org/osg/cpu2000/CFP2000/
>
> Likewise , before you commit to any box you may wish to
> get a loaner and at the very least see how it does against
> a 1.5 GHz P4. No use throwing money away, eh?
>
> Rob
Do you belive it ?
Of cource Int\e/l is COOL supper cool.
And cheap as a sh... , sorry.
All advances of Intel are FAKE !!!
And there is no any test which could absolutely clearly
compare peformance of two different platformes !!!
There is "Digital Signal Processors" which can do ~ ten times
much operation per second with less clock freaquency,
and with less price (coreltive to any processor of Intel).
So what ?
Intel MusDie !!!
--Alt.
Matt Wieben
> not optimizing too well, or the cache is too small. If its the latter,
> you might want to look at a low end HP PA-RISC system such as a B1000 or
> A500. Those systems have 1MB L1 data cache, which is significantly larger
> than anything else out there. Plus its FPU can sustain two muladds per
> cycle, so if you happen to be doing lots of multiplies and additions on
> data > 256K but less than 1MB there's no way anything else can beat it.
> Once you get above 1MB then it is a different story, and the story quickly
> changes to where Alpha systems are superior (I don't know what their
> pricing is, but I assume they have something low end comparable to the O2,
> Ultra 60, B1000, etc.)
Yes, the amount of cache is important to me, which is why I thought about
a P3 Xeon w/1 or 2 megs L2...but 1MB of L1 data cache!--wow!! And at a nice
price, too.
We did have a meeting last night and it seems that it comes down to this:
Me, the Assembler guy, be willing to spend otherwise productive time
learning a new hardware. One alternative brought up was to experiment with
a cluster of 4 P3 800MHz machines. That way we can continue to make better
x86 code and spend only a little time rewriting to work for the cluster.
I'm looking at the PA-RISC though!
> In short, I wouldn't limit yourself to just MIPS and Sparc, since it is
> fairly likely you'd do better with either a PA-RISC or Alpha based system.
> But like I said above, depending on the size of your dataset, you may do
> best with an x86 system due to the high clock rate, and just need to do a
> better job in the code writing department.
We could always do better code writing. No amount of new hardware bells and
whistles can compare to an algorithm that is just pure art.--Those are hard
to come by though.
Patrick Schaaf
>All advances of Intel are FAKE !!!
comp.arch is not about marketing, advocacy, and only a small
bit about personal grunts. Could you please show your
delusions in a different forum?
thanks
Patrick
Chris Morgan
> It isn't misleading. As you note, add a few hundred to the
> above for a monitor. Go out to Dell and get 512 MB RDRAM
> for $2900 and change:
Rob, why don't you compare comparable machines? Since it's not your
beloved Alpha, there's no need to be fair?
That machine has an IDE disk and WindowsME. No 1394. No high
performance disks. No option for another cpu. No option for a modern
operating system (ick). Appears to max out at 1GB. Even so, add in
1394 controller, plus cable, plus the same amount of RAM and I ended
up at $3217.
A better comparison would be something like a Dell Precision 330.
> It includes a 40 GB drive and is guaranteed to smoke that
> Sun box *when* it ships (as you note, had no intention of fudding
> that up).
>
> > At least spec up the Dell to that level, I make that an absolute
> > minimum of $4300, although it's either a dual-capable PIII machine, or
> > single P4 at this point, so it's not a good match.
>
> Why isn't it a good match? Because *you* decided he needed
> two processors? Your $4300 is WAY too much.
Well, let me see, I think is was you that picked a SunBlade 1000 (dual
capable). You know it costs more money to buy a machine that supports
two cpus than one, right? I never included a second cpu in the price,
so stop misrepresenting me.
>
> >
> > I would say the real prices are more like $5k vs. $10k. Perhaps that's
> > an easy win for the Dell for some people, but obviously not the same
> > gross mismatch Rob implies.
> >
>
> Try again.
You're so rude, but so be it. Listen, Rob, do you actually buy high
performance computers, or do you just read about them and tell others
which ones are better? Just wondering.
Stephen Fuld
"Matt Wieben" <m...@dana.ucc.nau.edu> wrote in message
news:979l3u$b4v$1...@usenet.nau.edu...
> We did have a meeting last night and it seems that it comes down to
this:
> Me, the Assembler guy, be willing to spend otherwise productive time
> learning a new hardware. One alternative brought up was to experiment
with
> a cluster of 4 P3 800MHz machines. That way we can continue to make
better
> x86 code and spend only a little time rewriting to work for the cluster.
> I'm looking at the PA-RISC though!
>
>
> > In short, I wouldn't limit yourself to just MIPS and Sparc, since it is
> > fairly likely you'd do better with either a PA-RISC or Alpha based
system.
> > But like I said above, depending on the size of your dataset, you may do
> > best with an x86 system due to the high clock rate, and just need to do
a
> > better job in the code writing department.
>
> We could always do better code writing. No amount of new hardware bells
and
> whistles can compare to an algorithm that is just pure art.--Those are
hard
> to come by though.
I remember earlier you said that precision wasn't much of an issue. Without
knowing what you are doing, I can't tell if this would work, but some
algorithms are amenable to implementation using the SIMD instructions that
are provided for multimedia. You may be able to get 2X or even 4X if you
can arrange your data and algorithms to use these instructions.
--
- Stephen Fuld
Jan Ingvoldstad
<s.f...@worldnet.att.net> said:
> I remember earlier you said that precision wasn't much of an issue. Without
> knowing what you are doing, I can't tell if this would work, but some
> algorithms are amenable to implementation using the SIMD instructions that
> are provided for multimedia. You may be able to get 2X or even 4X if you
> can arrange your data and algorithms to use these instructions.
In that event, it might also be worth investigating whether a Mac G4
would do it, too, if Altivec optimizations would benefit his
program(s).
--
In the beginning was the Bit, and the Bit was Zero. Then Someone
said, Let there be One, and there was One. And Someone blessed them,
and Someone said unto them, Be fruitful, and multiply, and replenish
the Word and subdue it: and have dominion over every thing that is.
Holger Bettag
>
> On Sun, 25 Feb 2001 07:15:52 GMT, "Stephen Fuld"
> <s.f...@worldnet.att.net> said:
>
> > I remember earlier you said that precision wasn't much of an issue.
> > Without knowing what you are doing, I can't tell if this would work,
> > but some algorithms are amenable to implementation using the SIMD
> > instructions that are provided for multimedia. You may be able to get
> > 2X or even 4X if you can arrange your data and algorithms to use these
> > instructions.
>
> In that event, it might also be worth investigating whether a Mac G4
> would do it, too, if Altivec optimizations would benefit his
> program(s).
>
AltiVec would offer four single precision multiply-adds per cycle. The
MPC7400 as used in the G4 Macs 'below 600MHz' can't do much else while
saturating the vector FPU, but the upcoming MPC7450 in the newer G4 Macs
(that are just starting to ship) would have a real chance to come close
to peak throughput with real code. (It is considerably more capable of
out-of-order execution.)
It might also be interesting to know that all G4 Macs have 1MB of external
cache per CPU (half-speed L2 for MPC7400, third-speed L3 for MPC7450) and
that the MERSI bus protocol allows efficient data transfers between caches
of different processors in a system. A dual-processor G4 Mac might very
efficiently handle working sets between 1 and 2 MB if the code is cleverly
threaded. Furthermore, those PPCs manage their cache hierarchy
'exclusive'-style, i.e. the working set can grow larger than a specific cache
without thrashing becoming a big problem _immediately_ (eventually it will,
of course).
The big downside of Macs is probably their operating system. PowerPC Linux
is not yet running on the newest hardware, and MacOS X is not yet ready for
prime time either.
And prices are somewhere between 'standard' x86 boxes and 'proprietary'
unix hardware, though leaning towards PCs.
Holger
Rob Young
Fair enough.
I buy them, larger than desktop. Point is from
the outset of when I got in this... you can wrangle up different
configurations and make the SunBlade less of a burden but the
fact is in floating point calculations it will most likely
be outperformed by a 1.5 GHz Dell. Unless of course SpecFp2000
is somehow broken. I see you got the Dell price
up to $3200 I suppose with enough wrangling we could get it a few
hundred dollars higher. It will still be less than a 1/3 of what
the SunBlade lists for and outperform it. In fact, why not buy two
Dell's, load Linux, and use what is leftover for something else?
After all, he just wants to do computes and I did mention to get
a loaner and benchmark his code, etc.
Rob
Thor Lancelot Simon
Chris Morgan <c...@mihalis.net> wrote:
>you...@encompasserve.org (Rob Young) writes:
>
>> It isn't misleading. As you note, add a few hundred to the
>> above for a monitor. Go out to Dell and get 512 MB RDRAM
>> for $2900 and change:
>
>Rob, why don't you compare comparable machines? Since it's not your
>beloved Alpha, there's no need to be fair?
>
>> http://commerce.us.dell.com/dellstore/config.asp?order_code=S155PO19&customer_id=19&keycode=6V948&view=1
>>
>
>That machine has an IDE disk and WindowsME. No 1394. No high
>performance disks. No option for another cpu. No option for a modern
Who *cares*? This is a number-cruncher, remember?
The fact that Sun forces you to buy a bunch of junk like 1394, a fast
disk subsystem, nice graphics, and a monitor is really neither here nor
there. All that most people whose systems sit there chewing numbers all
day care about is that there's enough CPU and RAM (and enough bandwidth
between the two) and on that score, Sun's been losing pretty badly for a
long time.
--
Thor Lancelot Simon t...@rek.tjls.com
And now he couldn't remember when this passion had flown, leaving him so
foolish and bewildered and astray: can any man?
William Styron
Chris Morgan
> Who *cares*? This is a number-cruncher, remember?
>
> The fact that Sun forces you to buy a bunch of junk like 1394, a fast
> disk subsystem, nice graphics, and a monitor is really neither here nor
> there. All that most people whose systems sit there chewing numbers all
> day care about is that there's enough CPU and RAM (and enough bandwidth
> between the two) and on that score, Sun's been losing pretty badly for a
> long time.
Well if it _only_ had to crunch numbers, it would probably be helpful
to run a stable OS, and it would definitely help to have a nice big L2
cache and a realistic amount of RAM. Even making those changes and
throwing away all the rest of the stuff changes the price more than
Rob likes to admit. His dream machine had 128MB ram.
But since the original poster said "mainly what I would be doing on it
is creating, optimizing, and applying signal processing software" I
took it that software development would be a large issue too. I've
never writtten signal processing software, but I know that IDE disks
blow for my software development purposes.
I don't run signal processing software, but again I find "nice
graphics" essential since I want to look at my results, plus keep some
other stuff in view on my two or three headed machine.
He also mentioned small data sets which makes me think that the raw
performance battle between the two machines mentioned might be
interesting. Would his data fit entirely in the 8MB L2 cache? Maybe.
Cheers,
Chris Morgan
> It isn't misleading. As you note, add a few hundred to the
> above for a monitor. Go out to Dell and get 512 MB RDRAM
> for $2900 and change:
By the way (and sorry to go on about this) Rob listed the SPEC
performance of the Precision 330 workstation but the price of a
different Dell product (a Dell Dimension). A Precision 330 with 512MB
RAM starts at $3564. I call that misleading, forget about the Sun
comparison.
Bernd Paysan
> That machine has an IDE disk and WindowsME. No option for a modern
> operating system (ick).
If they had Linux as option, that would be cheaper than WindowsME.
I was a fan of SCSI disks for a decade. Now, the last time I had to
decide what to buy, I looked at the performance measurements c't makes
twice a year (300 HDs each time). I bought the fastest. The fastest was
a Maxtor IDE drive with 40GB and 7200 RPM. It was fastest because Maxtor
got the next step of high density first into their IDE disks, before IBM
and the others could make their SCSI disks faster. And it's not just
fast, it's also quiet enough to be put under my desk.
--
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://www.jwdt.com/~paysan/
Chris Morgan
> I was a fan of SCSI disks for a decade. Now, the last time I had to
> decide what to buy, I looked at the performance measurements c't makes
> twice a year (300 HDs each time). I bought the fastest. The fastest was
> a Maxtor IDE drive with 40GB and 7200 RPM. It was fastest because Maxtor
> got the next step of high density first into their IDE disks, before IBM
> and the others could make their SCSI disks faster. And it's not just
> fast, it's also quiet enough to be put under my desk.
How well does that scale when you stick a couple in a machine and run
a lot of disk accessing processes simultaneously? (I'm asking
seriously, I wouldn't know the answer, the IDE drives in my Ultra 10
clearly weren't the fastest when new, but they seem to steal a lot of
attention from the cpu).
Cheers,
Mark Horsburgh
>Bernd Paysan <bernd....@gmx.de> writes:
>
>> I was a fan of SCSI disks for a decade. Now, the last time I had to
>> decide what to buy, I looked at the performance measurements c't makes
>> twice a year (300 HDs each time). I bought the fastest. The fastest was
>> a Maxtor IDE drive with 40GB and 7200 RPM. It was fastest because Maxtor
>> got the next step of high density first into their IDE disks, before IBM
>> and the others could make their SCSI disks faster. And it's not just
>> fast, it's also quiet enough to be put under my desk.
>
>How well does that scale when you stick a couple in a machine and run
>a lot of disk accessing processes simultaneously? (I'm asking
>seriously, I wouldn't know the answer, the IDE drives in my Ultra 10
>clearly weren't the fastest when new, but they seem to steal a lot of
>attention from the cpu).
I have a two part answer to that question:
1) It sounds like the IDE drivers on Solaris represent the state of art
in about 1995, when programmed I/O was the norm. On a modern PC
operating system these days (Linux and even Windows ME or Windows 2000),
the CPU usage is reasonably low now that IDE drives can do almost decent
DMA.
2) I do understand that SCSI drive will do better on heavily loaded
machines with long request queues, due to tagged queuing and similar
optimisations.
Of course, for the present discussion that doesn't matter a jot since we
are talking about a development machine. If you are getting much more
than a couple of independent request streams on a development machine I
would be very surprised. Besides, in my experience, compilation with Sun's
Forte compiler is completely CPU bound anyway.
---
Mark Horsburgh
Research is what I'm doing when I don't know what I'm doing.
-- Wernher von Braun
Alexis Cousein
> be outperformed by a 1.5 GHz Dell. Unless of course SpecFp2000
> is somehow broken.
SPECfp2000 is a benchmark. Extrapolating a benchmark is dangerous. To
cite but one example, you'll be hard pressed to address more than 4GB
with a P4 machine, so if you have an application that requires it, you
can't run your application at all, so timings become irrelevant.
It's not that SPECfp2000 is "broken". It's just that it's a benchmark,
and more importantly, a benchmark *SUITE* -- the relative performance of
two processors on the different tests tend to vary with the tests.
In short, citing SPECfp2000 composite benchmark numbers is interesting,
but using it to make absolute judgments on the worth of different
machines is just a pissing contest.
--
Alexis Cousein System Engineer
SGI Belgium and Luxemburg a...@brussels.sgi.com
McCalpin
Alexis Cousein <a...@brussels.sgi.com> wrote:
>Rob Young wrote:
>
>> be outperformed by a 1.5 GHz Dell. Unless of course SpecFp2000
>> is somehow broken.
SPECfp2000 is not a perfect measure of system performance, and Intel-
based systems seem to do unusually well on it, but it is not typically
too far off as a representative single figure of merit.
>SPECfp2000 is a benchmark. Extrapolating a benchmark is dangerous. To
>cite but one example, you'll be hard pressed to address more than 4GB
>with a P4 machine, so if you have an application that requires it, you
>can't run your application at all, so timings become irrelevant.
That would not be extrapolation, that would be a non sequitur.
The SPECfp2000 benchmark suite measures the performance of a
variety of (CPU+memory)-bound codes written in FORTRAN77,
Fortran90, and C. These codes use up to 256 MB RAM.
If I can help out my esteemed former colleague, Mr. Cousein:
The traditional words used to describe this issue are that
"capability" <> "performance"
"Capability" refers to the set of problems that can be addressed
with a machine, while "performance" tells how fast this set of
problems runs. The performance of a machine outside of its
capability set is either zero, or low enough that it does not
make any difference.
So, once you have limited the search to those systems that
are capable of handling your application requirements, then
performance is an important secondary metric. In the workstation
space, the SPEC CPU benchmark suites of the past have typically
been quite useful at giving "ballpark" estimates of the average
performance of a machine across a variety of compute-intensive
workloads. In the context of SPECfp95, my rule of thumb was that
differences in excess of 20% were likely "real", though it typically
takes even larger differences to detect a performance delta between
two machines without the aid of mechanical/electronic timers.
SPECfp2000 has not been around long enough for me to judge whether
my "20% rule" still holds, but it seems like a good starting point.
Consider a user who requires 512 MB RAM, a single 18 GB 10K RPM disk,
CD-ROM (or DVD-ROM), a 21" monitor, and a decent (not exceptional)
graphics adapter. Going to three vendor configurators, I come out
with prices like:
Vendor/System Price CFP2000 Availability
-------------------- ------- ------- ----------
Sun Blade 1000/750 $12.5k 421 constrained
IBM IntelliStation M Pro$ 4.6k 552(est) configurator says "call"
Dell Prec Wkstn 330 $ 4.5k 552 not listed by configurator
-------------------- ------- ------- ----------
Note: IBM does not publish SPECfp2000 performance results on
its IntelliStation line of products. The value quoted above
is an estimate, based on the fact that the IBM product has the
same CPU, memory controller, RDRAM configuration, and software
as the Dell Precision Workstation 330 which does have published
results. The published Intel results on the same base hardware
and software is 558, which is statistically indistinguishable
from 552.
The price difference is quite real --- about $8k extra to go
the Sun route, which is a factor of more than 2.5x.
The performance differences is probably real: 552/421 = 1.31,
or 31% difference. Looking at the individual CFP2000 performance
numbers shows that the Pentium4 performance advantage applies to
ten of the fourteen benchmarks, by as much as 4x in one case and
3x in another case. On the four benchmarks where the Sun is faster
there are two cases where the ratio is about 2:1 in Sun's favor.
I conclude that the performance envelopes of the two machines
are sufficiently different that specific testing of your own
application is a good idea -- in the best case for Sun, the
price/performance is almost at parity with the Pentium4-based
system, while at the other extreme, the Pentium4-based systems
have roughly a 10:1 price/performance advantage.
--
John D. McCalpin, Ph.D. mcca...@austin.ibm.com
Senior Scientist IBM POWER Microprocessor Development
"I am willing to make mistakes as long as
someone else is willing to learn from them."
Jan Vorbrueggen
Kaivalya Dixit's HPCA slides via the SPEC web site have led me to a talk of
yours at a workshop on workload characterization (http://www.cs.virginia.edu/
~mccalpin/wcc_keynote.html). You show nice results comparing SPECfp2000
components to some actual application code. Do the diagrams also exist with
the individual SPECfp2000 components made non-anonymous?
Jan
Peter Boyle
On 25 Feb 2001, Rob Young wrote:
> I buy them, larger than desktop. Point is from
> the outset of when I got in this... you can wrangle up different
> configurations and make the SunBlade less of a burden but the
> fact is in floating point calculations it will most likely
> be outperformed by a 1.5 GHz Dell. Unless of course SpecFp2000
> is somehow broken. I see you got the Dell price
> up to $3200 I suppose with enough wrangling we could get it a few
> hundred dollars higher. It will still be less than a 1/3 of what
> the SunBlade lists for and outperform it. In fact, why not buy two
> Dell's, load Linux, and use what is leftover for something else?
Hi Rob,
I do tend to believe suns underperform, but there's no way a P4 running
gcc/g77 will get anything like the perforance of a p4 running the intel
compilers.
> After all, he just wants to do computes and I did mention to get
> a loaner and benchmark his code, etc.
>
> Rob
Right - that's the smart thing to do.
Peter Boyle pbo...@physics.gla.ac.uk
Thor Lancelot Simon
Peter Boyle <pbo...@holyrood.ed.ac.uk> wrote:
>
>On 25 Feb 2001, Rob Young wrote:
>
>
>> I buy them, larger than desktop. Point is from
>> the outset of when I got in this... you can wrangle up different
>> configurations and make the SunBlade less of a burden but the
>> fact is in floating point calculations it will most likely
>> be outperformed by a 1.5 GHz Dell. Unless of course SpecFp2000
>> is somehow broken. I see you got the Dell price
>> up to $3200 I suppose with enough wrangling we could get it a few
>> hundred dollars higher. It will still be less than a 1/3 of what
>> the SunBlade lists for and outperform it. In fact, why not buy two
>> Dell's, load Linux, and use what is leftover for something else?
>
>Hi Rob,
>
>I do tend to believe suns underperform, but there's no way a P4 running
>gcc/g77 will get anything like the perforance of a p4 running the intel
>compilers.
So what? The Intel compilers are available for Linux (as is the Microway
compiler, which is also quite good).
Thor
Oleg Krivosheev
> Fair enough.
>
> I buy them, larger than desktop. Point is from
> the outset of when I got in this... you can wrangle up different
> configurations and make the SunBlade less of a burden but the
> fact is in floating point calculations it will most likely
> be outperformed by a 1.5 GHz Dell. Unless of course SpecFp2000
> is somehow broken. I see you got the Dell price
> up to $3200 I suppose with enough wrangling we could get it a few
> hundred dollars higher. It will still be less than a 1/3 of what
> the SunBlade lists for and outperform it. In fact, why not buy two
> Dell's, load Linux, and use what is leftover for something else?
Rob,
as much as i like linux, NO WAY you could get the same performance
from gcc as from Intel 5.0 compiler. Expect scores to be at least 20+% lower...
> After all, he just wants to do computes and I did mention to get
> a loaner and benchmark his code, etc.
>
> Rob
OK
Mike Haertel
>SPECfp2000 is not a perfect measure of system performance, and Intel-
>based systems seem to do unusually well on it, but it is not typically
>too far off as a representative single figure of merit.
How times have changed since I first started reading comp.arch
back in the late 80's!
McCalpin
I have not had time to sanitize the "raw" data for public release.
It should not take a lot of time, but I have been swamped at work
for the last six months or so, and just have not been able to get
around to it.... I am sure I will get to it "Real Soon Now".
(probably by summer?)
If I can figure out why my new version of PPC-Linux does not think
that its own sawmill window manager is not Gnome-compliant, then I
will probably be able to get back to work on STREAM and other projects.
Tony Nelson
"Matt Wieben" <m...@dana.ucc.nau.edu> wrote:
> Well, I'm mainly switching between those two based on price, coming from an
> Intel based platform. The only info I have really found has been on the MIPS
> R10000 type, nothing on the Sparc so far. But what I really want is a
> processor that does floating point math on small data sets very efficiently.
> Precision doesn't concern me as it is already nice enough for me on Intel
> hardware (minus Windows), and I can't imagine the Sparc and the MIPS to be
> less. ...
Are you using 80-bit Extended Precision math? You won't find that on
RISC machines like MIPS, Sparc, or PPC.
Are you using the FPU stack or the SSE stuff (which I know nothing about
but should be faster for most uses).
Do your data sets fit in L1 or L2 cache? L1 cache is usually 32KB.
> So mainly what I would be doing on it is creating, optimizing, and
> applying signal processing software. From what I have read, a 64-bit RISC
> processor might just be the way to go with the types data of algorithms we
> are planning on using, ...
Note that most FPUs are already 64 bit internally, and the data path to
the L1 cache is usually pretty wide.
Note that I am a Mac programmer with only limited experience on WIntel.
____________________________________________________________________
TonyN.:' tony...@shore.net
'
Chris Ruemmler
Rob Young <you...@encompasserve.org> wrote:
>In article <9783n8$7rn$1...@usenet.nau.edu>, "Matt Wieben" <m...@dana.ucc.nau.edu> writes:
>> Well, I'm mainly switching between those two based on price, coming from an
>> Intel based platform.
>
> A 128 MByte , 1.5 GHz Dell lists for $2200. A SunBlade 1000
> workstation with a 900 MHz UltraSparc III lists for $9995+. And
> the Dell considerably outperforms the Sun box on floating point ops:
>
>Sun Microsystems Sun Blade 1000 Model 1900
>http://www.specbench.org/osg/cpu2000/results/res2000q3/cpu2000-20000911-00219.asc
>
>
> SPECfp_base2000 427
> SPECfp2000 482
>
at:
http://www.spec.org/osg/cpu2000/topics/avail-sunIII_900.html
describing the issue. Sun is not able to make this processor "generally
available" to customers. This appears to be a benchmark special number.
You should look at the 750Mhz number instead for something that is
more realistic. The 750Mhz number is:
SPECfp_base2000 373
SPECfp2000 421
--Chris
My own views
Chris Morgan
> The price difference is quite real --- about $8k extra to go
> the Sun route, which is a factor of more than 2.5x.
I concede this price factor, at least in this comparison every effort
has been made to control the important variables. This is still not
$2200 vs. $9995 however.
> The performance differences is probably real: 552/421 = 1.31,
> or 31% difference. Looking at the individual CFP2000 performance
> numbers shows that the Pentium4 performance advantage applies to
> ten of the fourteen benchmarks, by as much as 4x in one case and
> 3x in another case. On the four benchmarks where the Sun is faster
> there are two cases where the ratio is about 2:1 in Sun's favor.
> I conclude that the performance envelopes of the two machines
> are sufficiently different that specific testing of your own
> application is a good idea
Totally agree with this too. Now, if only Sun had some fab partner to
match Intel.
Cheers,
Alt
It's not delusions. Just my opinion grounded at comparisons.
First microprocessor of Intel was 8080
(4004 and 4040 was actually only ALU chips)
It had different voltage of kernel and interface circuits.
But I guess that faster troubles of design than the real necessity.
It has quite normal set of 8-bit instruction,
but dumb 16-bit instructions, why ?
Any way it was working in 16-bit address field.
Yes 8-bit processor best of all works with 8-bit instruction,
but ... designers do not has to ignore 16-bit interactions also.
Then was 8086.
With stupid segmented memory.
And with such instruction set where was difficult to guess which
can be the source and/or result of such instruction, plus
some exotic instruction to operate with segmented memory.
In result programmer was most busy with memory layout,
and with data passing, then with algorithm.
For instance concurents serie MC68x0 has entire memory,
and there any instruction was able to use
like source and destination any possible combination.
286.
There was added special some features,
but they was such difficult, that seams only QNX used them all.
And there was more powerful CPU.
Motorola just replaced ALU.
386.
This processor was like 86, 286 and 386 in single corps
but 386 and 86 was absolutely different processors.
There was a way to choice one of them.
Their own instruction sets was looking very close,
but different on a practice.
386 has 32 - ALU, entire memory, and had no artificial trouble
of 86 and 286.
Instruction set of 386 was far from high effective.
Motorola released serie MC680x0,
which was absolutely compatible with MC68x0, but just with
extend to 32 bit registers and 32 bit ALU.
486.
Like 386 but quicker.
Then was Pentium, which was also far from effective.
Pentium MMX.
MMX which was just only fabrication of serie "LC",
from MC680x0LC.
Any MIPS with same clock fr. was quicker,
than any Pentium, with it is has less size of crystal !!!
I saw how Obsolete Silicon with PowerAnimator
did things which still can not do my CyrixMII pr.300.
Same about PowerPC.
So what that new Itaniums/Athlones quick roll friendly tests ?
Such performance explains by enclosing their architecture to
Digital Signal Processors.
There was idea to build personal computers with DSP instead CPU.
Really it should quickly roll video, MP3, make trivial filters.
And so ?
WHERE IS THE ADVANCE OF INTEL ???
Jeffrey Boulier
Chris Morgan <c...@mihalis.net> wrote:
>
>Totally agree with this too. Now, if only Sun had some fab partner to
>match Intel.
>
I've heard that Sun didn't want to go with IBM because it was one of their
major competitors, and Intel is obviously out for the same reason. Fujitsu
is problematic because it makes SPARC clone systems. AMD and Samsung seem
to have pretty strong ties to Compaq. Is Texas Instruments really the pick
of the litter?
I can think of Motorola and Via as manufacturing PC-class
microprocessors, but that's about it. Anyone else?
Hmm... for that matter, does TI make anything "powerful" except for the
UltraSPARC?
And who is making the R12000+ systems for SGI? IBM?
Yours Truly,
Jeffrey Boulier
--
Community Source & Support
------=>Prometheus<=------
Don't ask about the vulture.
Rob Young
> mcca...@gmp246.austin.ibm.com (McCalpin) writes:
>
> Totally agree with this too. Now, if only Sun had some fab partner to
> match Intel.
>
Why not IBM? Seems that is where the rest of the industry
is headed... HP for PA-RISC also.
Rob
Chris Morgan
> I've heard that Sun didn't want to go with IBM because it was one of their
> major competitors, and Intel is obviously out for the same reason. Fujitsu
> is problematic because it makes SPARC clone systems. AMD and Samsung seem
> to have pretty strong ties to Compaq.
I would have thought AMD would be "ok" - all the big PC makers apart
from Dell seem to have gone with them now, it doesn't seem like Compaq
could twist their arm very much. I've got a 750MHz 0.18 micron cpu
made by them more than a year ago, so it seems to my untrained eye
they have the silicon prowess for US-III.
>Is Texas Instruments really the pick of the litter?
I'd be interested to hear what the more knowledgeable commentators
think of that question too.
>
> I can think of Motorola and Via as manufacturing PC-class
> microprocessors, but that's about it. Anyone else?
>
> Hmm... for that matter, does TI make anything "powerful" except for the
> UltraSPARC?
Yes, but they're DSPs.
>
> And who is making the R12000+ systems for SGI? IBM?
The answer will be along in a minute no doubt.
Thor Lancelot Simon
>Patrick Schaaf wrote:
>
>> Alt <a...@card.kyiv.net> writes:
>>
>> >All advances of Intel are FAKE !!!
>>
>> comp.arch is not about marketing, advocacy, and only a small
>> bit about personal grunts. Could you please show your
>> delusions in a different forum?
>>
>> thanks
>
>It's not delusions. Just my opinion grounded at comparisons.
No, it's your whining and flamage disguised as an on-topic article.
This is not alt.wank.chips.mine.is.bigger.than.yours. It's comp.arch.
Keep it on topic -- where the "topic" is computer architecture, not what
CPU or vendor you want to snivel about -- or get lost.
Incidentally, your "masterful" delineation of the history of Intel's x86
architecture skipped the 8008.
Peter Boyle
On 26 Feb 2001, Thor Lancelot Simon wrote:
[Peter Boyle wrote]
> >
> >Hi Rob,
> >
> >I do tend to believe suns underperform, but there's no way a P4 running
> >gcc/g77 will get anything like the perforance of a p4 running the intel
> >compilers.
>
> So what? The Intel compilers are available for Linux (as is the Microway
> compiler, which is also quite good).
>
> Thor
You neglected to mention it is a recent beta test release... but thanks
for the info.
Peter Boyle pbo...@physics.gla.ac.uk
Douglas Siebert
>Be very careful here. This is a vaporware number. See the SPEC website
>at:
>http://www.spec.org/osg/cpu2000/topics/avail-sunIII_900.html
>describing the issue. Sun is not able to make this processor "generally
>available" to customers. This appears to be a benchmark special number.
This is getting pretty tiresome. I wish SPEC was willing to police its
vendor members better. First Intel's withdrawal of the 1.13GHz Pentium
III doesn't result in its removal from the site, now Sun. I guess they
have decided the run "rules" are merely more of a guideline...
I seem to recall reading something about how with SPEC2000 they would be
policing things better, in light of the abuse the old 6 month rule in
SPEC95 had. Surely some of you recall back in 1998 when Digital announced
and produced SPEC results for a 600MHz 21164 with 8MB L3 cache, but it
took well over six months to ship. That wouldn't have been so bad, if
it wasn't for the fact that it was the highest ranked system in both int
and fp for that time, but that a non-Alpha system was #2 behind it by a
mere .1 SPECfp and was actually shipping that whole time as well.
Why not eliminate these abuses by not listing any system that has yet to
ship? (or has been recalled) Do vendors really need "official" SPEC
results in their preannouncements? Can't we wait until the real
announcement of actual orderable and shippable product for the official
results? Sure, some may abuse us slightly with "estimated" SPEC scores,
but at least those don't pollute the database.
If these abuses are ignored, what is to stop any vendor from putting up
numbers for a system they plan to ship within the next 6-9 months? Once
three months are up and they are called to the mat, they can claim they
have experienced some temporary delays, and the nice looking numbers are
left up for all to see, while the disclaimer is well hidden (without even
an * on the results page or a link to the disclaimer on the HTML report
page!)
I guess it is a good thing Itanium numbers suck so much, or we would
have been staring at them for a year now without any real systems
shipping the whole time, and SPEC would have just let them do it.
[My first post on this seems to have been eaten by the NNTP monster, so
if it turns out I'm posting two rants on the same subject, I apologize]
--
Doug Siebert
dsie...@excisethis.khamsin.net
If at first you don't succeed, skydiving is not for you.
Jan Vorbrueggen
>> Do the diagrams also exist with
>> the individual SPECfp2000 components made non-anonymous?
> I have not had time to sanitize the "raw" data for public release.
Colour me confused - you have already mentioned the commercial applications on
the other slides, surely SPEC doesn't object to see the...oh, I see...the raw
data contains both SPEC and commercial, and you want to anonymize the latter
only. Comprende.
Jan
Jan Vorbrueggen
has not been proven. In other cases, e.g. the Compaq ES40-833, the initial
results have been withdrawn and re-issued when the system actually became
available.
I agree this is a thorny issue, but also a difficult one. There will _always_
be quibbling whether the proper balance has been achieved - but will you agree
that SPEC CPU is pretty near to that balance? Given the vagaries of the
business, and the number of results being published, the error rate is quite
low.
Jan
Jan Vorbrueggen
Sun went fabless, there weren't many offers - I don't think IBM or AMD or
Samsung would have been; Digital might have, but probably were considered a
competitor, which TI was and is not. And by now, UltraSPARC's designer are
hooked on TI's process.
Jan
Alexis Cousein
>
> And who is making the R12000+ systems for SGI? IBM?
>
The R12K/R14K etc. chips are fabbed by NEC, IIRC. IBM does fab a number
of other ASICS in the *systems*, though.
--
Alexis Cousein Senior System Engineer
Alt
> In article ?3A9AFDDB...@card.kyiv.net?, Alt ?a...@card.kyiv.net? wrote:
> ?Patrick Schaaf wrote:
> ?
> ?? Alt ?a...@card.kyiv.net? writes:
> ??
> ?? ?All advances of Intel are FAKE !!!
> ??
> ?? comp.arch is not about marketing, advocacy, and only a small
> ?? bit about personal grunts. Could you please show your
> ?? delusions in a different forum?
> ??
> ?? thanks
> ?
> ?It's not delusions. Just my opinion grounded at comparisons.
>
> No, it's your whining and flamage disguised as an on-topic article.
>
> This is not alt.wank.chips.mine.is.bigger.than.yours. It's comp.arch.
> Keep it on topic -- where the "topic" is computer architecture, not what
> CPU or vendor you want to snivel about -- or get lost.
>
> Incidentally, your "masterful" delineation of the history of Intel's x86
> architecture skipped the 8008.
>
That wasn't entire processor.
Yes, I hate Intel, it's true. (under such subject I wrote it first time.)
I always had a trobles with coding Intel processors.
Because their instruction sets was seams to me, illogic.
I was asking my self "Why so stupid ?"
Why I though, thet I am bed programmer, when touble was in creations of Intel.
Well, why do you say that such my posting, is off-topic
(except this one, which is really off-topic) ?
--Alt.
Jan Vorbrueggen
> That just means Compaq decided to be responsible in this case. If they
> had decided to ignore the issue, I'll bet it'd still be in the database
> anyway. How could SPEC justify removing it now that they've left in the
> 1.13GHz Pentium III result for all these months with the actual release
> of non-recalled (at least they hope so, this time!) 1.13GHz systems still
> probably more than three months away even today?
I do see a difference. People _were_ able to order PIII-1130 systems, if only
for a short time, and at least some were delivered, I gather. You could call
it a system with a very short lifetime 8-|. After all, the results for
"historical" systems that are no longer available (except used via e-bay)
are still in the database, and for a very good reason.
The US3-900 system is more doubtful. Have _you_ replied on the SPEC CPU web
page regarding its availability, or otherwise written to, e.g., Jeff Reilly
as the CPU subcommittee chair?
Jan
McCalpin
Douglas Siebert <dsie...@excisethis.khamsin.net> wrote:
>ruem...@cello.hpl.hp.com (Chris Ruemmler) writes:
>
>>Be very careful here. This is a vaporware number. See the SPEC website
>>at:
>
>>http://www.spec.org/osg/cpu2000/topics/avail-sunIII_900.html
>
>>describing the issue. Sun is not able to make this processor "generally
>>available" to customers. This appears to be a benchmark special number.
>
>
>This is getting pretty tiresome. I wish SPEC was willing to police its
>vendor members better.
SPEC *is* its members, and it has very little ability to "police" anyone.
If you want to know if a product is available, the only authoritative
place to get information is from the vendor, not from SPEC. I can't even
count the hours that the SPEC CPU subcommittee has spent arguing over
the definition of "general availability". It is hard enough to define
it for a single vendor platform, then what do you do when some SPEC members
do not sell platforms (e.g., AMD). In the Intel 1.13 PIII case, how do
you define what duration of "stop ship" is required to move a product
from "generally available" to "not generally available"? A week? A month?
The CPU subcommittee was unable to come up with any rules that appeared
to be likely to withstand any of the myriad possible exceptions and
corner cases --- but we spent much of the last six months working on
this specific issue.
Douglas Siebert
>I do see a difference. People _were_ able to order PIII-1130 systems, if only
>for a short time, and at least some were delivered, I gather. You could call
>it a system with a very short lifetime 8-|. After all, the results for
>"historical" systems that are no longer available (except used via e-bay)
>are still in the database, and for a very good reason.
The 1.13GHz Pentium III was recalled. Selling systems and then asking for
them back because they are defective isn't quite the same as selling a
system and then retiring it because it is outdated. For quite a while, that
fake result was Intel's fastest result. I don't have any objection to them
having 400MHz Pentium II results in the database, as you point out, they
are useful for historical comparisons. But those comparisons are invalid
if you look at the state of the industry in July 2000, for example, and now
Intel has this result for a system that didn't really exist.
BTW, upon an email suggestion, I did write to the SPEC comments email
address with my rant. If others feel the same as I do, I hope they will
write as well. If enough people write, they may discuss this at a future
meeting and hopefully decide to change the policy at some point to not
allow any advance submissions. Or at least decide to crack down on non
existant system results in some manner.
Maynard Handley
Yes, and this was extremely informative to those us in comp.arch. You see,
even though we are all professionals who are paid serious money to design
CPUs, we are all actually ignorant of the history of Intel. Thanks, young
student for clearing this all up---it's not as though we actually lived
through it.
Maynard
John Ahlstrom
> Patrick Schaaf wrote:
>
-- snip snip
>
> WHERE IS THE ADVANCE OF INTEL ???
Semiconductor technology.
Circuit design.
Testing
Recognizing the the single most important
characteristic of their architecture was
backward compatibility. Thus allowing themselves
to get about twice as much money per chip as
their competitors in each comparable generation
of size and performance.
--
The belief that there is only one truth and that oneself is in
possession of it seems to me the deepest root of all evil that is in
the world. -- Max Born
Patrick Schaaf
>> Patrick Schaaf wrote:
>>
>-- snip snip
>>
>> WHERE IS THE ADVANCE OF INTEL ???
Please watch your attributions. I mocked the troll. They used some
silly pseudonym.
regards
Patrick
Jan Vorbrueggen
> The 1.13GHz Pentium III was recalled. Selling systems and then asking for
> them back because they are defective isn't quite the same as selling a
> system and then retiring it because it is outdated.
You mean Intel forced you to give back your processor? I don't quite see
that. Surely some of the overclockers cooled theirs enough that it really
worked.
No, this is not a good example. But I think we can close the discussion here
and possibly agree to disagree on this particular case, if not the whole issue.
Jan
Chris Torek
Mark Horsburgh <M.K.Ho...@damtp.cam.ac.uk> writes:
>... It sounds like the IDE drivers on Solaris represent the state of art
>in about 1995, when programmed I/O was the norm. On a modern PC
>operating system these days (Linux and even Windows ME or Windows 2000),
>the CPU usage is reasonably low now that IDE drives can do almost decent
>DMA.
I would be surprised to find that Solaris does not do IDE-DMA. I
recently got IDE-DMA working on the BSD/OS port for the PCI-based
sparcs, and it makes a huge difference -- the untuned raw data
transfer rate on the Ultra10 box I am using for this went up by a
factor of 4.2, to 13 MB/s. (I am limited to WDMA2 mode by the
PCI646U controller, which has broken UltraDMA support.)
>2) I do understand that SCSI drive will do better on heavily loaded
>machines with long request queues, due to tagged queuing and similar
>optimisations.
Generally, yes, although ATA-5 has similar features. (Everything
good in SCSI goes into IDE eventually. :-) )
--
In-Real-Life: Chris Torek, Berkeley Software Design Inc
El Cerrito, CA, USA Domain: to...@bsdi.com +1 510 234 3167
http://claw.bsdi.com/torek/ (not always up) I report spam to abuse@.
Note: PacBell news service is rotten
Piercarlo Grandi
[ ... ]
>> 2) I do understand that SCSI drive will do better on heavily loaded
>> machines with long request queues, due to tagged queuing and similar
>> optimisations.
It will do _immensely_ better... But of course this depends on whether
the host adapter, not just the drive, supports mailboxing and tagged
queueing.
torek> Generally, yes, although ATA-5 has similar features. (Everything
torek> good in SCSI goes into IDE eventually. :-) )
Well, ATAPI is after all basically SCSI command blocks over an ATA
bus...
But I have come to actually have strong hopes for FireWire/i.Link/1394,
as it improves so much on the physical problems of SCSI and ATA so well,
and marketing departments seem to have (fortunately) classified it as a
consumer level bus (because it's used in videocams :->).
Do the 1394 drives and host adapters currently on sale support
mailboxing and tagged queueing? If so, SCSI _and_ ATA could be buried
once and for all.
Terje Mathisen
> But I have come to actually have strong hopes for FireWire/i.Link/1394,
> as it improves so much on the physical problems of SCSI and ATA so well,
Plug & Play is nice...
> and marketing departments seem to have (fortunately) classified it as a
> consumer level bus (because it's used in videocams :->).
>
> Do the 1394 drives and host adapters currently on sale support
> mailboxing and tagged queueing? If so, SCSI _and_ ATA could be buried
> once and for all.
The original 1394 is already too slow, you need second-generation stuff
to support current disk IO rates.
Currently many (most?) 1394 interfaces are limited to running at DV
video bandwidth, which is about 3.6 MB/s, i.e. less than 10% of the 37
MB/s claimed for my IBM DeskStar IDE drives.
I have a very bad feeling about this, we're going to end up with a lot
of variable-rate stuff, with the slowest device limiting your actual
throughput to the original DV rate. :-(
Terje
--
- <Terje.M...@hda.hydro.com>
Using self-discipline, see http://www.eiffel.com/discipline
"almost all programming can be viewed as an exercise in caching"
Malcolm Weir
caused to appear as if it was written:
[ Snip ]
>But I have come to actually have strong hopes for FireWire/i.Link/1394,
>as it improves so much on the physical problems of SCSI and ATA so well,
>and marketing departments seem to have (fortunately) classified it as a
>consumer level bus (because it's used in videocams :->).
I thought the same in 1995...
I was evaluating emerging disk interfaces then, looking at what were the
four prime candidates apart from parallel: FC-AL, SSA, ATA, and 1394. (This
was purely for controller-to-spindle connections, not host-to-controller
ones).
We disliked ATA for a number of reasons -- mainly due to its high pin count
and low-hotpluggability. FC-AL seemed to be overkill, and having to work
with gigahertz signals was perceived as a negative for disk enclosures.
We liked SSA... but support seemed, umm, limited.
1394 had the consumer benefits of ATA, transfer rates that put it ahead of
SSA (although SSA had techniques that masked that in some cases), and the
connection elegance of FC-AL.
But it took 5 years to start seeing vendors do anything 8-(
>Do the 1394 drives and host adapters currently on sale support
>mailboxing and tagged queueing? If so, SCSI _and_ ATA could be buried
>once and for all.
Maybe... but both currently boast higher transfer rates (160MB/s and 100MB/s
vs. 50MB/s) and ATA silicon is pretty pervasive.
Malc.
Rob Young
>
>>Do the 1394 drives and host adapters currently on sale support
>>mailboxing and tagged queueing? If so, SCSI _and_ ATA could be buried
>>once and for all.
>
> Maybe... but both currently boast higher transfer rates (160MB/s and 100MB/s
> vs. 50MB/s) and ATA silicon is pretty pervasive.
>
yeah , bandwidth. UltraSCSI 4 at 320 MB/s and Ultra-5 at 640 MB/s.
Sounds like SCSI might be around for a while.
Rob
Stephen Fuld
"Rob Young" <you...@encompasserve.org> wrote in message
news:Z0wWGY...@eisner.encompasserve.org...
And with Serail ATA comming, which I believe is 150 MB/sec to a single drive
and reduces the pin count (this cost) and cabling problems of "parallel"
ATA, I think it will be around for a while also.
Don't underestimate the power of inertia in interfaces. The last thing the
drive vendors want is yet another interface that they have to support.
--
- Stephen Fuld
Douglas Siebert
>In article <slrn99k64p.fmd...@krull.mkh25.damtp.cam.ac.uk>
>Mark Horsburgh <M.K.Ho...@damtp.cam.ac.uk> writes:
>>2) I do understand that SCSI drive will do better on heavily loaded
>>machines with long request queues, due to tagged queuing and similar
>>optimisations.
>Generally, yes, although ATA-5 has similar features. (Everything
>good in SCSI goes into IDE eventually. :-) )
Does any OS support it? At least according to the comments I've heard
from Linux ATA guru (and T13 working group member) Andre Hedrick, the
ATA specification of tagged command queuing is hopelessly broken. Since
Linux doesn't support it and you BSD guys don't support it, unless Win2K
supports it (I don't know whether it does or not, or whether WinXP will
change this -- anyone know?) then its existance isn't making any real
difference, whereas in SCSI it makes a huge difference on multi-stream
IO. And even if supported, it has to work reliably under high loads
without locking up, corrupting data, etc. on more than a handful of
drive models, or word of mouth will keep people from enabling the feature
in the OS even if available.
ATA definitely has huge advantages in cost, IMHO these days mainly
because drive makers know that people who choose SCSI know why they are
choosing it, so they can charge higher prices and still have people
pay them (the old supply/demand curve from macroeconomics 101)
I don't think its necessarily true that everything good in SCSI will
go into ATA eventually, because ATA isn't targetting the same market.
I don't think ATA product managers expect or even want to move into the
high end storage market SCSI occupies. They know that if ATA became a
complete replacement for SCSI they'd have the same cutthroat price
competition on the high end drives and lose the juicy profits, unless
they somewhat stratified the market by only putting the special features
high end customers want on certain drives. At that point, all they
haven't really accomplished anything since they still have two divergant
product lines to support. The old argument about SCSI controllers being
more expensive might have been valid in 1990, but today I can't imagine
it is more than a few dollars.
--
Douglas Siebert dsie...@excisethis.khamsin.net
I have discovered a remarkable proof which this .sig is too small to contain!
Andrew Reilly
>to...@elf.bsdi.com (Chris Torek) writes:
>
>>In article <slrn99k64p.fmd...@krull.mkh25.damtp.cam.ac.uk>
>>Mark Horsburgh <M.K.Ho...@damtp.cam.ac.uk> writes:
>>>2) I do understand that SCSI drive will do better on heavily loaded
>>>machines with long request queues, due to tagged queuing and similar
>>>optimisations.
>
>>Generally, yes, although ATA-5 has similar features. (Everything
>>good in SCSI goes into IDE eventually. :-) )
>
>
>Does any OS support it? At least according to the comments I've heard
>from Linux ATA guru (and T13 working group member) Andre Hedrick, the
>ATA specification of tagged command queuing is hopelessly broken. Since
>Linux doesn't support it and you BSD guys don't support it, unless Win2K
BSD (well, FreeBSD at least) seems to support tagged queuing in
ATA. The source (/usr/src/sys/dev/ata/ata-disk.c) contains many
references to tagging, and much code to handle it. Ah. Looks
as though it only works on "IBM-DPTA" and "IBM-DTLA" drives, and it
requires a kernel configuration option to enable.
There are obviously _some_ controller hardware problems still
present, too...
#if 0
/*
* wait for data transfer phase
*
* well this should be here acording to specs, but
* promise controllers doesn't like it, they lockup!
* thats probably why tags doesn't work on the promise
* as this is needed there...
*/
--
Andrew
Patrick Schaaf
>I don't think ATA product managers expect or even want to move into the
>high end storage market SCSI occupies. They know that if ATA became a
>complete replacement for SCSI they'd have the same cutthroat price
>competition on the high end drives and lose the juicy profits, unless
>they somewhat stratified the market by only putting the special features
>high end customers want on certain drives.
In these modern times, they could dream of drive firmware enabling
certain performance features only if a monthly renewable licence
key is pushed down to the drive.
:)
Patrick
Bill Broadley
> supports it (I don't know whether it does or not, or whether WinXP will
> change this -- anyone know?) then its existance isn't making any real
> difference, whereas in SCSI it makes a huge difference on multi-stream
> IO.
I'd seen numerous failed attempts to quantify this that failed.
First the adaptec threadmark which seemed designed to show this and
prove scsi's superiority. Netapp's postman or similar seems similarly
capable, maybe it's errors on my parts that lead to similar scsi vs eide
results.
I've yet to see something like this quantified, I have a couple raid
systems around, the most current of which is EIDE. Can anyone post what
they feel would be a good benchmark to show the multi-stream superiority?
Not sure why a disk drive should be able to sort through a list of
commands for which to execute first dramatically better then the
OS can. Of course the drive is more familiar with the geometry, but
generalizations like adjacent blocks are generally faster to access them
remote blocks still holds.
In any case, please post source code, url for a benchmark, or a paper
comparing recent eide setups to recent scsi setups that show this "huge
difference".
--
Bill Broadley
Chris Torek
>>Mark Horsburgh <M.K.Ho...@damtp.cam.ac.uk> writes:
>>>2) I do understand that SCSI drive will do better on heavily loaded
>>>machines with long request queues, due to tagged queuing and similar
>>>optimisations.
>to...@elf.bsdi.com (Chris Torek) writes:
>>Generally, yes, although ATA-5 has similar features. (Everything
>>good in SCSI goes into IDE eventually. :-) )
In article <98m671$lnj$1...@sword.avalon.net>,
Douglas Siebert <dsie...@excisethis.khamsin.net> wrote:
>Does any OS support it?
It is hardly for me to speak for "any system". :-) I do not know
of any that use it by default. I have heard that some have tried
it and have had problems.
>At least according to the comments I've heard
>from Linux ATA guru (and T13 working group member) Andre Hedrick, the
>ATA specification of tagged command queuing is hopelessly broken.
I am not sure whether the *spec* is broken, but I have no doubt
that, since most if not all systems do not use it[%], some drives that
claim to implement it, get it wrong. This is the same situation
that SCSI disks were in back when SCSI tagged queueing first came
out (mid 1990s?). IDE/ATA/ATAPI is perennially some years behind
the curve, although fewer now, it seems, than just three to five
years ago. (As you note below, this leaves room for the huge
price disparities between ATA and SCSI drives.)
-----
[%] Actually, "Windows doesn't use it" suffices for any claimed
hardware feature to be broken in reality. The 800-pound gorilla
gets what it wants, and everyone else can go hang. :-)
-----
>Since Linux doesn't support it and you BSD guys don't support it,
(Us "BSD guys" sometimes cooperate less than might be desirable. :-)
NetBSD uses a different driver architecture than FreeBSD, although
they are converging; BSD/OS uses yet a third one, somewhere off a
line drawn between the two, which I hope will also converge. In
any case I can say for certain that BSD/OS does not use it.)
>unless Win2K supports it (I don't know whether it does or not, or
>whether WinXP will change this -- anyone know?) then its existance
>isn't making any real difference,
Not today, no.
>whereas in SCSI it makes a huge difference on multi-stream IO.
This is somewhat debatable -- it depends greatly on actual access
patterns, raw drive bit rates, and available bus bandwidth on all
the different busses involved. It is of course true that with tags
and disconnect, you get the maximum possible parallelism, hence
the *potential* best-use of shared resources. (This may sometimes
cost increased latency to get increased throughput. For instance,
imagine a SCSI implementation that disconnects, does whichever
transfer is ready into an internal buffer, and only then starts
the reconnect to blast the data across the SCSI bus at 160 MB/s.
Just as it is about to reconnect, though, some other device takes
over the bus, and begins a larger transfer that runs at a mere 40
MB/s. If they were done in the other order, the average latency
would be lower.)
On BSD/OS systems with our drivers, we do in fact see performance
increases in some benchmark(s) when using tags. I have not done
this work myself and cannot say exactly which benchmarks and how
much of an effect they have. (I can add that we have separate
tuning for RAID boxes vs ordinary disks, though.)
>ATA definitely has huge advantages in cost, IMHO these days mainly
>because drive makers know that people who choose SCSI know why they are
>choosing it, so they can charge higher prices and still have people
>pay them (the old supply/demand curve from macroeconomics 101)
Indeed.
>I don't think its necessarily true that everything good in SCSI will
>go into ATA eventually, because ATA isn't targetting the same market.
Oh, I think it will; it is just that by then, SCSI will have
something else better, or something even better will have replaced
SCSI. It is the old "high end moves down to low end" pattern that
repeats year after year.
Douglas Siebert
>I've yet to see something like this quantified, I have a couple raid
>systems around, the most current of which is EIDE. Can anyone post what
>they feel would be a good benchmark to show the multi-stream superiority?
Disclaimer: I haven't ever tried to use this to compare IDE versus SCSI
side by side...
One of my favorite quick n dirty benchmarks for comparing multi stream
I/O, which I use when testing tuning of storage systems like big EMC
frames or whatever is to start up lots of tar processes in parallel.
I've used up to 500 simultaneous tar processes of large directories
of several hundred megabytes each with several hundred thousand files
each (the contents of /usr/man can be replicated a few thousand times
to create this setup, the linux kernel source tree would also be a good
candidate though I haven't ever used it for this)
Since I'm usually working from a database perspective the ideal is to
have the database installed and a nice fat crash and burn database
available so you can delete a few huge tablespaces and then uncommit
all the deletes simultaneously, but usually once you get to the point
of installing the database, you are unfortunately pretty much done
tuning.
Anyway, for testing a single SCSI versus single ATA disk on a single
processor machine, I'd recommend only using a dozen simultaneous
processes. If you find little or no difference between otherwise
equivalent ATA and SCSI disks, I'd 1) be surprised, 2) hope you will
check a known faster disk also to see if you are running into OS
limitations first (although knowing this would also knock any advantages
SCSI may have when using that particular OS) While I'm a big fan of
Linux, I would recommend against its use for this test, because I find
it is pretty poor at the type of multi-threaded I/O I'm talking about
here (I haven't tested 2.4 this way yet, it is supposed to be better)
But BSD or Solaris/x86 is probably a better bet today, to avoid as much
as possible having the OS create limits that make unequal disks appear
equal.
You could in theory use this with equal storage systems to compare how
well two different systems (Sun versus HP, Linux versus NetBSD, whatever)
do. I won't claim to vouch for the usefulness of this information,
however I mention it as an interesting possibility. I have used it with
some pretty good success to quantify the performance differences of EMC
setups configured with RAID-S versus RAID-1 versus RAID-1/striped, when
measured on big iron Sun & HP (E10K, V class, etc.) so I do believe it
produces valid results, at least in the narrow domain in which I've made
use of it.
If you do this test, I'd be interested to hear of the results, along with
of course the models and configurations of the arrays involved, the disks
used in them, testing hardware and OS used, etc. so I can add my own
biases as to how fair I think your testing was to either/both the SCSI or
ATA array :)
Douglas Siebert
>In article <98m671$lnj$1...@sword.avalon.net>,
>Douglas Siebert <dsie...@excisethis.khamsin.net> wrote:
>>I don't think its necessarily true that everything good in SCSI will
>>go into ATA eventually, because ATA isn't targetting the same market.
>Oh, I think it will; it is just that by then, SCSI will have
>something else better, or something even better will have replaced
>SCSI. It is the old "high end moves down to low end" pattern that
>repeats year after year.
Well, my point was that I think the drive makers realize it to their
economic advantage to keep the markets separate, because the profit
margins on SCSI drives are so much higher. True, if they put in all
the features people want in SCSI into high end ATA drives, an ATA
drive with the Seagate X15's performance characteristics would still
command a nice price premium. But the more "average" SCSI drives like
say the whole Barracuda line would not offer anything you couldn't get
with one of the 7200rpm ATA drives, and thus what must be a nice big
profit center for Seagate would disappear.
That's not to say your "trickle down theory" of semiconductor economics
isn't totally valid, but I think there are a small enough number of
drive vendors today that we effectively have an oligopoly in that
market today (getting back to macroeconomics 101 once again :) )
Bill Todd
Bill Broadley <bi...@sphere.math.ucdavis.edu> wrote in message
news:98mgsm$9kn$1...@woodrow.ucdavis.edu...
...
> Not sure why a disk drive should be able to sort through a list of
> commands for which to execute first dramatically better then the
> OS can. Of course the drive is more familiar with the geometry, but
> generalizations like adjacent blocks are generally faster to access them
> remote blocks still holds.
One notable (though it may not qualify as 'dramatic') advantage the drive
has is detailed knowledge of its rotational position, such that it can
choose among multiple requests at similar seek distances based upon which
will be just about to appear under the head when it reaches the target
cylinder (vs. which will have already missed their start sectors and hence
take much of an additional rev to complete).
Another (again, perhaps not 'dramatic') advantage is the ability to overlap
request processing (which I've heard can approach a millisecond for SCSI -
though my impression is that the newer protocols may have finally addressed
this issue) with internal drive activity.
A third, which is peculiar to IDE drives, is that (if I understand the
situation correctly) overlapped requests may avoid missed revs (due to the
common 64 KB request size limitation) on streaming write requests: with
sequential processing, by the time one write request completes the head has
already missed the start of the next, which can reduce the drive's
write-streaming bandwidth by 75%. One can alleviate this problem by
enabling the drive's write-back cache, but at the cost of then never knowing
for sure that *any* write has completed without performing a drive flush:
my impression is that, unlike SCSI, IDE doesn't support a 'force unit
access' per-request override of the write-back cache, and some experiments
Anton Ertl performed a while ago strongly suggested that if a block was
updated frequently enough with the write-back cache enabled it was *never*
written back to disk (a good UPS can reduce the probability of data loss in
such a situation, but even good UPSs have non-negligible failure rates when
external power dies). Reads can avoid a similar problem by enabling the
drive's read cache, which doesn't have the write cache's reliability
down-side.
- bill
Carl Nelson
*snip*
> Not sure why a disk drive should be able to sort through a list of
> commands for which to execute first dramatically better then the
> OS can. Of course the drive is more familiar with the geometry, but
> generalizations like adjacent blocks are generally faster to access
them
> remote blocks still holds.
*snip*
I can think of a couple of reasons to have the drive do the sorting...
First off, the disk may have an on-board cache, which the OS wouldn't
necessarily know about, or if it did know about, wouldn't know about
what's in the cache. By letting the drive reorder the requests it can
reply to a request that it has in memory while doing a seek to satisfy
another (earlier) request. Of course it DOES matter if you really have
cache. I have seen simple buffer memory called cache.
Second off, there may be more than one computer accessing the disk,
with conflicting or complementary requests. The disk controller will
have the information needed to efficiently access the data. The
requesting system won't know if the other system had a request in the
same area that now resides in the disk's cache. The overhead for two (or
more) systems to try to coordinate their accesses would be large and
rather silly if the drive itself can do the reordering. This also means
that the systems would definitely not have the full cache state of the
drive to work with.
Third off, the disk you are talking to may not be a disk, but a raid
or other controller with its own state, cache, and various internal
optimizations. We currently have a DSSI chain which has a controller
that talks DSSI on one side and SCSI on the other. With a 32MB cache
onboard and two systems accessing the same disks (some of which are
striped & shadowed) there is no way that the processors could
efficiently reorder the requests. While this is a rather extreme
example, it IS a situation where the best recourse is to hand off the
reordering to the controller.
This is also a good place to illustrate the importance of protocol
over raw speed. The DSSI (Digital Storage System Interface) interface is
rather poky compared to raw SCSI speed, but it does support several of
the optimizations (tagging, disconnect and such) that are needed to
adequately support anything other than a single-user system. I have seen
the same system run "raw" SCSI and SCSI with a front-end DSSI
controller. There was quite a difference. The DSSI controller, with its
internal cache and protocol optimizations was able to "hide" most of the
shortcomings of SCSI, and considerably boost performance. It doesn't
come as much of a surprise to me that VMS runs badly on IDE drives,
given the protocol limitations. Of course, the operating system has to
be able to take advantage of the optimizations that the protocol offers,
otherwise its pretty much moot.
No, I don't have any quantifications of this other than simple
observation. But simple observation has lead me to point to one line of
assembly language code in an application comprised of thousands of lines
of *ack* Cobol code and say "Change this parameter and your system will
fly instead of wheeze", and be right. I only wish that I could have had
a tenth of what we didn't spent on an upgrade... Negotiate first, THEN
be a wisenheimer. *sigh*
Finally, ask yourself. Do you REALLY want a computer which might cost
tens (or hundreds) of thousands of dollars to be spending its time
sorting disk requests when the same job could be better done by a <$200
disk controller while it is idly waiting for a seek to complete? If its
a home computer, or something sitting on a desk at work for word
processing or a little surfing/e-mail then it really doesn't matter
much, so IDE is a good choice, as it is inexpensive and it works. But in
a situation where you have four systems clustered, running multiple
multi-threaded applications, batch queues, online users, and serving
other systems to boot, you need, and can justify paying for, those
optimizations.
--
Carl Nelson carl....@mcmail.maricopa.edu
Paul Black
> The original 1394 is already too slow, you need second-generation stuff
> to support current disk IO rates.
We haven't yet managed to get hold of an IDE disk for which this is true
(some of the figures claimed don't stand up to testing).
> Currently many (most?) 1394 interfaces are limited to running at DV
> video bandwidth, which is about 3.6 MB/s, i.e. less than 10% of the 37
> MB/s claimed for my IBM DeskStar IDE drives.
I'm not quite sure what you mean by "1394 interfaces", the PC card or
the 1394-IDE bridge chip? Our OXFW911 1394-IDE bridge chip does a
sustained 37MB/s with the IBM drive (a disk that does "exactly what it
says on the tin").
Paul
Terje Mathisen
>
> Terje Mathisen <terje.m...@hda.hydro.com> wrote:
> > The original 1394 is already too slow, you need second-generation stuff
> > to support current disk IO rates.
>
> We haven't yet managed to get hold of an IDE disk for which this is true
> (some of the figures claimed don't stand up to testing).
OK, that's good news!
> > Currently many (most?) 1394 interfaces are limited to running at DV
> > video bandwidth, which is about 3.6 MB/s, i.e. less than 10% of the 37
> > MB/s claimed for my IBM DeskStar IDE drives.
>
> I'm not quite sure what you mean by "1394 interfaces", the PC card or
I'm talking about the Pinnacle/miro/Pyro sub-$100 cards, from what I've
read in news:rec.video.desktop these interfaces seem to run at Mini-DV
data rates even when connected to a FireWire disk.
If this is wrong, then that's good news. :-)
> the 1394-IDE bridge chip? Our OXFW911 1394-IDE bridge chip does a
> sustained 37MB/s with the IBM drive (a disk that does "exactly what it
> says on the tin").
Right, I have one of these at work, and two more on the way to my home
machines. Nice disk. :-)
Piercarlo Grandi
>>> <bi...@sphere.math.ucdavis.edu> said:
[ ... tagged queueing is wonderful ... ]
bill> [ ... ] I've yet to see something like this quantified, I have a
bill> couple raid systems around, the most current of which is EIDE.
A few years ago I built a cheapo video-on-demand server for a small
language laboratory, to show foreign language MPEG'ed films...
The server specs were really impressive :-): 16MB RAM, Pentium I
@100MHz, two 4GB Fujitsu SCSI disks, two NCR 8xx cards or Adaptec 274x
(FAST SCSI), two DEC Tulip based 100MHz cards.
It could serve easily 20 workstations or more, concurrently, with a
different MPEG 1 stream each, for a total aggregate data rate of roughly
4MB/s, with CPU being perhaps 15% busy.
I tried some ATA disks too, and they could easily do the same transfer
rate on a single transfer (usign Linux 'hdparm').
But with multiple streams coming off the disk, the ATA disk aggregate
transfer rate went _down_; it was perhaps 4-5MB/s with one stream, and
would go down to something lik 300KB/s with 10-15. The aggregate
transfer rate of the SCSI disk instead didn't drop drastically.
In both cases the disk rattled quite impressively (I was sure to start
the different streams on different MPEG files and at different time
offsets in them).
Now, if I switched off tagged queueing in the Linux SCSI HA driver, it
was much the same as if I was using the ATA disks.
bill> Can anyone post what they feel would be a good benchmark to show
bill> the multi-stream superiority? [ ... ]
You can easily create a multistreaming test on any Linux machine. Run a
script like the following one on some quiescent machine, first one with
an ATA HA (make sure DMA has been enabled on the test disk) and then one
with a SCSI HA (make sure the driver has been compiled with tagged
queueing enabled by default, or enable it explicitly)...
------------------------------------------------------------------------
: ${DISK="$1"} ${DISK:='/dev/hda'}
: ${STREAMS="$2"} ${STREAMS:='8'}
: ${INTERVAL="$3"} ${INTERVAL:='5'}
: ${COUNT="$4"} ${COUNT:='200000'}
: ${BLOCK="$5"} ${BLOCK:='1024'}
case "$STREAMS" in
2) STREAMS='1 2';;
4) STREAMS='1 2 3 4';;
8) STREAMS='1 2 3 4 5 6 7 8';;
16) STREAMS='1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16';;
*) STREAMS='1';;
esac
PID=''
for N in $STREAMS
do
dd bs=1024 skip="${N}00000" count="$COUNT" \
of=/dev/null if="$DISK" &
PID="$PID $!"
trap "kill $PID; exit 1" 1 2 3 13 15
echo "$N:$PID"
sleep "$INTERVAL"
done
wait
------------------------------------------------------------------------
This script exceeds the load of a video-on-demand server. While being a
bit rough and ready, please note that for example it does stagger
carefully the starting point of the streams to ensure they are spaced on
the disks and they all don't just read the same blocks.
First run it with 1 stream, then with some number you like (8 is well
enough to see the effect), while running 'vmstat' in another window
while this is running, and watch the 'bi' column, in particular watch as
it goes as the number of processes goes up.
I have just tried it on two random PCs, one with a somewhat old SCSI
setup and one with a fairly new ATA setup. The sequential transfer rates
measure by 'hdparm' are 18MB/s for the ATA disk/HA and 12MB/s for the
SCSI disk/HA combo.
On the ATA combo, with 1 stream I get roughly 13000 blocks in/s; with 4
streams I get 600, and with 8 I get around 400; CPU busy about 10% (1
stream) to 1% (8 streams) on a 600MHz PIII.
On the SCSI combo, with 1 stream I get roughly 12000 blocks in/s; with 4
streams I get 6000, and with 8 or 16 I still get 6000; CPU busy about 10%
on a 400MHz PII.
The difference, which is due entirely to the host adapter supporting
tagged queueing, is pretty dramatic.
It is slightly different from what I remembered: ATA did not fall off
so catastrophically, and SCSI did not fall to half the single stream.
But admittedly these two random PCs are not very well set up, but at
the time I had made sure that both ther ATA and the SCSI drive and HA
were carefully chosen for best performance. I suspect for example that
the default max queue length on the SCSI HA being 8 might be
inappropriate.
bill> Not sure why a disk drive should be able to sort through a list of
bill> commands for which to execute first dramatically better then the
bill> OS can. [ ... ]
This has puzzled me too for quite a while. I have suspected some
possibilities like:
* For a SCSI HA without tagged queueing, elevator sorting and _at the
OS driver level_ the driver needs to have a queue of requests, but
this never happens as requests are fired off immediately to the drive
and get queued there and the drive just executes them in the order in
which it received them.
* For an ATA HA, elevator sorting may be furstrated by high latencies on
command issue, and the lack of queueing at the drive (uh?).
But these are really wild guesses; I have just decided that I can live
pretty well with ATA drives on my home PC, and just go with SCSI if I
need multi streaming on a server, so lazily I haven't investigated why,
even if I had started at one point looking at and instrumenting the
Linux ATA driver to figure out things.
George N. White III
> dsie...@excisethis.khamsin.net (Douglas Siebert) writes:
>
> >I don't think ATA product managers expect or even want to move into the
> >high end storage market SCSI occupies. They know that if ATA became a
> >complete replacement for SCSI they'd have the same cutthroat price
> >competition on the high end drives and lose the juicy profits, unless
> >they somewhat stratified the market by only putting the special features
> >high end customers want on certain drives.
SCSI drives typically have longer (e.g., 5yr) warranties than ATA. While
some of this is more robust design, I've always wondered if the same
features that make SCSI faster than ATA in heavy use also reduce wear and
tear on the mechanical bits. When an expensive SCSI drive fails within
the 5yr warranty you expect to get an exact replacement to slot into your
striped array, etc. When an ATA drive fails within the 3yr warranty
you may get a current (probably higher capacity and performance) model as
a replacement.
> In these modern times, they could dream of drive firmware enabling
> certain performance features only if a monthly renewable licence
> key is pushed down to the drive.
Or that have built-in log-structured file systems with off-site copies of
the metadata so when you accidentally delete a file you can enter a
credit card number to recover your data.
--
George N. White III <gn...@acm.org> Bedford Institute of Oceanography
Maxim S. Shatskih
> read in news:rec.video.desktop these interfaces seem to run at Mini-DV
> data rates even when connected to a FireWire disk.
OHCI 1394 cards from Texas Instruments supported 400Mbps (50MB/s) as early
as in 1999.
The cheap miro card uses 100Mbps - enough for DV, not enough for a disk.
Max
Niels Jørgen Kruse
<terje.m...@hda.hydro.com> skrev:
> Piercarlo Grandi wrote:
>> But I have come to actually have strong hopes for FireWire/i.Link/1394,
>> as it improves so much on the physical problems of SCSI and ATA so well,
>
> Plug & Play is nice...
>
>> and marketing departments seem to have (fortunately) classified it as a
>> consumer level bus (because it's used in videocams :->).
>>
>> Do the 1394 drives and host adapters currently on sale support
>> mailboxing and tagged queueing? If so, SCSI _and_ ATA could be buried
>> once and for all.
There are no native 1394 drives (yet). However Maxtor and Western Digital
make external 1394 drives using ata-1394 bridges. Volumes were good enough
to get a mension in some sort of earnings report from Maxtor IIRC.
> The original 1394 is already too slow, you need second-generation stuff
> to support current disk IO rates.
You need better ata-1394 bridges to just max out 400 Mbit.
> Currently many (most?) 1394 interfaces are limited to running at DV
> video bandwidth, which is about 3.6 MB/s, i.e. less than 10% of the 37
> MB/s claimed for my IBM DeskStar IDE drives.
These numbers are way to pessimistic. On this link
<http://www.macup.com/archiv/3671.html> you will find a review (in german)
of external drives using the first ata-1394 bridge to support Ultra-DMA (or
so they say).
Two drives were tested, a 30 GB 7200 RPM drive (3.5") and a 20 GB 4800 RPM
drive (2.5"). The latter was powered by the host through the FireWire cable,
while the former required a wall plug. The drives were tested with Benchtest
from HDT 4.0 and the results were
read write
3.5" 22,6 MB/s 12,5 MB/s
2.5" 11,8 MB/s 14,3 MB/s
> I have a very bad feeling about this, we're going to end up with a lot
> of variable-rate stuff, with the slowest device limiting your actual
> throughput to the original DV rate. :-(
Are you getting 1394 and SCSI mixed up? 1394 didn't achieve much volume
before 400 Mbit was the norm.
--
Mvh./Regards, Niels Jørgen Kruse, Vanløse, Denmark
Thomas Womack
> Terje Mathisen <terje.m...@hda.hydro.com> wrote:
> > The original 1394 is already too slow, you need second-generation stuff
> > to support current disk IO rates.
>
> We haven't yet managed to get hold of an IDE disk for which this is true
> (some of the figures claimed don't stand up to testing).
Does this mean "no current drive sustains 50-minus-transfer-overheads MB/s",
which seems entirely believable though probably only for one more
head-technology generation [36MB/s at 7200RPM => 2.5Mbits around the edge of
the disc, say 3.0 once you account for ECC; platters are, umm, 90mm or so
[are all manufacturers' platters the same size? I suppose it's dictated by
form factor], so that's ten or eleven bits per micron: how much lower can
that get?], or something more complicated? [Current 1394 is 400Mb/s, isn't
it?]
The IDE-disc reviews I see all say something a little over 35MB/s on the
fastest zone of the disc, tailing down to 25MB/s for the slowest ... discs
are constant angular velocity, presumably, so the fastest zone will be the
outside? This looks as if 50MB/s is enough for sustained transfers even if
people get 10krpm spindles into IDE drives, which I'm slightly surprised IBM
hasn't done yet.
[do the burst figures have any meaning at all? Surely, with a sensible OS on
a P4, repeated reads of a 2-megabyte block will be satisfied from RDRAM at
2GB/second or so]
Of course, fast IDE discs and clever IDE controllers are cheap enough now
that it's almost reasonable to do 2- or even 4-way RAID0, with 3ware cards
for instance, and that's blown well past 400Mb/s and is running into the
limits of the PCI bus. Though I can't think of a consumer-level app enabled
by 100MByte-per-second disc: HDTV TiVo, maybe, if you could compress fast
enough and if anyone actually bothered broadcasting in HDTV.
> I'm not quite sure what you mean by "1394 interfaces", the PC card or
> the 1394-IDE bridge chip? Our OXFW911 1394-IDE bridge chip does a
> sustained 37MB/s with the IBM drive (a disk that does "exactly what it
> says on the tin").
Where would I get a 400Mb/s 1394 interface card (presumably 32-bit PCI), and
how much would I expect to pay for it?
Tom
Douglas Siebert
>SCSI drives typically have longer (e.g., 5yr) warranties than ATA. While
>some of this is more robust design, I've always wondered if the same
>features that make SCSI faster than ATA in heavy use also reduce wear and
>tear on the mechanical bits. When an expensive SCSI drive fails within
Or the fact that they charge so much more means it is easier to justify
(and customers would think they deserve) a longer warranty, even if the
mechanics on two given ATA versus SCSI models were totally identical.
Niels Jørgen Kruse
<ma...@storagecraft.com> skrev:
Terje:
>> Where would I get a 400Mb/s 1394 interface card (presumably 32-bit PCI),
> and
>> how much would I expect to pay for it?
Maxtor sell their 400Mb/s 1394 interface card for 50$. Information can be
found on <http://www.maxtordirect.com/searchresults.asp?search_id=4>.
Terje Mathisen
>
> I artiklen <3AAE6F97...@hda.hydro.com> , Terje Mathisen
> <terje.m...@hda.hydro.com> skrev:
> > video bandwidth, which is about 3.6 MB/s, i.e. less than 10% of the 37
> > MB/s claimed for my IBM DeskStar IDE drives.
>
> These numbers are way to pessimistic. On this link
> <http://www.macup.com/archiv/3671.html> you will find a review (in german)
> of external drives using the first ata-1394 bridge to support Ultra-DMA (or
> so they say).
>
> Two drives were tested, a 30 GB 7200 RPM drive (3.5") and a 20 GB 4800 RPM
> drive (2.5"). The latter was powered by the host through the FireWire cable,
> while the former required a wall plug. The drives were tested with Benchtest
> from HDT 4.0 and the results were
>
> read write
> 3.5" 22,6 MB/s 12,5 MB/s
> 2.5" 11,8 MB/s 14,3 MB/s
Thanks!
Those numbers are very helpful, it means that external FireWire disks
can be a very useful way to move data from one system to another.
One idea would be to use them for an 'air gap' type setup, to replicate
data between an internal system and a server in a DMZ.
Maxim S. Shatskih
and
> how much would I expect to pay for it?
The OHCI card with the Texas Instruments chipset (TSB12LV23 link layer
chip - sorry for not remembering the PHY layer chip designation) is IIRC
400Mbps capable.
Visit the TI's site to be 100% sure of this.
The vendor of the card itself is not so important (it can be Miro or such) -
just buy the card with TSB12LV23 chip or later one. It will be the TI OHCI
card.
The card price is around USD 100-150 (Miro's package with the card + the
expensive cable + the DV software is about 220).
It has the best driver support for MS OSes starting with Win98 (MS's native
OHCI1394.SYS driver) and the Linux support since early 2000, if not earlier.
OHCI compatible 1394 cards are the industry standard.
Max
Paul Black
>
> "Paul Black" <paul....@oxsemi.com> wrote
> > We haven't yet managed to get hold of an IDE disk for which this is true
> > (some of the figures claimed don't stand up to testing).
>
> Does this mean "no current drive sustains 50-minus-transfer-overheads MB/s",
It seems to be the case - we have one disk where the manufacturer
claimed 54MB/s but we could only manage 26 :-(
Paul
Piercarlo Grandi
>>> <terje.m...@hda.hydro.com> said:
terje.mathisen> [ ... ] Those numbers are very helpful, it means that
terje.mathisen> external FireWire disks can be a very useful way to move
terje.mathisen> data from one system to another. [ ... ]
Ah yes, but not just for that... BTW, in the USA there are some mail
order places that sell external Firewire-to-ATA enclosures for not very
much, and I have seen reviews that these work rather well indeed. I have
just done a little web search and I got for example:
http://WWW.McPowerUSA.com/fd3.htm
http://WWW.Quadmation.com/firewire/
http://WWW.DStor.com/products_firewire_ds5241fw.shtml
http://WWW.ApDrives.com/1394-slim-Firewire-hard-drive-enclosure.html
http://WWW.Centos.com.TW/CI-8050BF4.htm
http://WWW.MoreTech.com.TW/p-html/usb/ieee1394/html/0330/0330-052.htm
Niels Jørgen Kruse
(Piercarlo Grandi) skrev:
Granite Digital make an enclosure based on the Oxford Semiconductor bridge
mensioned earlier in the thread. A glowing review can be found on
<http://www.barefeats.com/fire14.htm>. A few comments to the review:
1) There is a picture of the enclosure in the review and it is singularly
ugly. Sensitive types should avoid clicking the link.
2) The site is a bit sensational and doesn't have an impeccable reputation.
3) The unit on the bar charts should no doubt have been MB/s.
4) There is a remarkable difference in write speed between the 133Mhz bus G4
and the earlier 100Mhz bus G4. The main difference between these is a new
northbridge chip that revamps the PCI bus architecture (adding write
combining) and integrates the 1394 (link layer) controller. The earlier G4
system seems to have a write ceiling on the PCI bus around 27 MB/s (while
the PCI bus is 64 bits, the 1394 controller(s) only use 32 bits). This
ceiling is gone with the integrated 1394 controller. It would be nice to
have seen if the improved PCI bus would have helped a PCI-card 1394
controller too.
Michael Meissner
> On 13 Mar 2001, Patrick Schaaf wrote:
>
> > dsie...@excisethis.khamsin.net (Douglas Siebert) writes:
> >
> > >I don't think ATA product managers expect or even want to move into the
> > >high end storage market SCSI occupies. They know that if ATA became a
> > >complete replacement for SCSI they'd have the same cutthroat price
> > >competition on the high end drives and lose the juicy profits, unless
> > >they somewhat stratified the market by only putting the special features
> > >high end customers want on certain drives.
>
> SCSI drives typically have longer (e.g., 5yr) warranties than ATA. While
> some of this is more robust design, I've always wondered if the same
> features that make SCSI faster than ATA in heavy use also reduce wear and
> tear on the mechanical bits. When an expensive SCSI drive fails within
> the 5yr warranty you expect to get an exact replacement to slot into your
> striped array, etc. When an ATA drive fails within the 3yr warranty
> you may get a current (probably higher capacity and performance) model as
> a replacement.
In the two times I've had to send back SCSI disks for warranty repairs, I've
gotten the latest model back, rather than the exact same model disk (IBM sent
back an 18gig disk when I sent in a 9gig disk, and Seagate sent back a Hawk-II
2gig drive when I sent in a Hawk-I 2gig drive a few years ago). Maybe its
different if you have SCA connectors instead of 50/68 pin.
--
Michael Meissner, Red Hat, Inc. (GCC group)
PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA
Work: meis...@redhat.com phone: +1 978-486-9304
Non-work: meis...@spectacle-pond.org fax: +1 978-692-4482