Re: Animosity from the press
On Sun, 2002-05-26 at 20:31, Phil Payne wrote: > No - you're a power user - the sort of person who would have gone out to buy a 387. >Although > there seem to be lots of power users about, that's because they inhabit similar >places. A few > thousand or a few tens of thousands at most - compared with tems of millions of >processors > shipped. There were more copies of quake sold than that. By your definition they are all power users. > > throughput. They won't be until those features like the FPU become > > economical using either hardware or software to drop into mainstream > > cheap processor silicon. > > The trend is the other way. Major manufacturers are looking at simply >overconfiguring by a > large percentage and then disabling broken bits in software. Such machines will >never be > repaired. IBM's proposed 'Icecube' design almost precludes repair. Thats the same trend. Note I very carefully said _or_ software. The whole self routing chip stuff is almost twenty years old so its about time someone got it to work on useful components. > I don't see that as an issue. IBM has established comparative benchmarks between >its own > products - if you have one, you can relate it to other similar products. LSPR is >the best > example, though even there things like buffer pool redefinitiuons tend to blur the >numbers. > But who should verify and who arbitrate over the inevitable arguments? Vendor provided comparisons between its own products. Comparisons by Ford between Ford cards don't tell you anything about whether its a Porsche or Bicycle equivalent. And *no* credible mainstream computing journalist will trust a vendor provided benchmark. They've seen enough such material, most of which appears to be compost. Until the mainframe folks and the IBM marketing folks involved with it can understand the mainstream viewpoint, and its cynicism of vendor provided data I don't see the coverage of S/390 improving one iota.
Re: Animosity from the press
We actually disclosed all the internal results on the testing to date with zSeries. It is available on our Website in response to the recent articles off linuxworld.com. It is a tremendous effort I can tell you to do Benchmarking with large mail (millions of users) environments, all the so called products/parts, IMAP/POP, MTA, LDAP, Filesystems, Storage, Blasting tools, reporting tools, on and on. I can say that thanks to the SuSE and IBM engineers we have come a long way with Linux results on zSeries. We have made every effort to not be "on the bench with a tone signal" using real profiles, how many users, checking this or that, size of message, time during the day to check/send you name it. Thanks again to Hans Reiser, Chris Mason, Bernd, Hubert Mantel, Andrea Arcangeli, and the 1/2 dozen members of the IBM Engineering team for the work. Regards, Jon On 5/26/02 2:54 PM, "Phil Payne" <[EMAIL PROTECTED]> wrote: >> Vendor provided comparisons between its own products. Comparisons by >> Ford between Ford cards don't tell you anything about whether its a >> Porsche or Bicycle equivalent. And *no* credible mainstream computing >> journalist will trust a vendor provided benchmark. They've seen enough >> such material, most of which appears to be compost. > > Benchmarketing, as it's known. I think most results could be verified - but > they wouldn't be > much more use. It's always fun to dig into the _exact_ configuration used for > the 'headline' > benchmarks - it's usually one that a real user wouldn't dream of installing in > a thousand > years. Exotic front end preprocessors, various bits of error recovery and/or > transaction > logging turned > off - that kind of thing. > > -- > Phil Payne > http://www.isham-research.com > +44 7785 302 803 > +49 173 6242039 >
Re: Animosity from the press
> Vendor provided comparisons between its own products. Comparisons by > Ford between Ford cards don't tell you anything about whether its a > Porsche or Bicycle equivalent. And *no* credible mainstream computing > journalist will trust a vendor provided benchmark. They've seen enough > such material, most of which appears to be compost. Benchmarketing, as it's known. I think most results could be verified - but they wouldn't be much more use. It's always fun to dig into the _exact_ configuration used for the 'headline' benchmarks - it's usually one that a real user wouldn't dream of installing in a thousand years. Exotic front end preprocessors, various bits of error recovery and/or transaction logging turned off - that kind of thing. -- Phil Payne http://www.isham-research.com +44 7785 302 803 +49 173 6242039
Re: Animosity from the press
> On Sun, 2002-05-26 at 10:52, Phil Payne wrote: > > > Your I/O bus is typically PCI however so you are limited to about > > > 100Mbytes/second I/O throughput in the real world. > > > > I would regard 100Mb/sec as a peak (instantaneous) transfer rate. Throughp > ut will be only a > > fraction of that. On some tests only a small fraction. > > That really depends on the system. On an Athlon with 64bit PCI I can do > 150Mbyte/second peak I/O , 120Mbyte/second sustained. Thats with about > $10,000 of loaner hard disks. The sustained disk read/write speed for a > single UDMA hard disk is about a magnitude lower. Well, ... [root@numbat root]# hdparm -t /dev/hda /dev/hda: Timing buffered disk reads: 64 MB in 1.86 seconds = 34.41 MB/sec [root@numbat root]# hdparm -t /dev/hda /dev/hda: Timing buffered disk reads: 64 MB in 1.85 seconds = 34.59 MB/sec [root@numbat root]# hdparm -t /dev/hda /dev/hda: Timing buffered disk reads: 64 MB in 1.84 seconds = 34.78 MB/sec [root@numbat root]# I wouldn't want anyone to think Alan means 15 Mbytes/sec. I can do better than that on a P II/233. Bonnie does produce a similar figure. -- Cheers John Summerfield Microsoft's most solid OS: http://www.geocities.com/rcwoolley/ Note: mail delivered to me is deemed to be intended for me, for my disposition. == If you don't like being told you're wrong, be right!
Re: Animosity from the press
> Lets take a real world benchmark. On < $2000 of PC I can recompile the > entire Linux kernel in 3 minutes, and the entirity of XFree86 in 30. I > can saturate multiple 100Mbit links with web traffic. I can encode video > in real time to mpeg and burn it to VideoCD as I go. I can render > 1024x768 3D scenes with texture and lighting at 80frames/second. > > All of those happen to be useful to me. I think you misunderstand some > of the nature of the commodity processors. No - you're a power user - the sort of person who would have gone out to buy a 387. Although there seem to be lots of power users about, that's because they inhabit similar places. A few thousand or a few tens of thousands at most - compared with tems of millions of processors shipped. > >> Performance measurement should be left to those who know what they're doing. The >first step > > is to define terms of measurement, and these must be related to real world and >real user > > issues, so that the results are relevant to their audience. > > Understand that the majority audience isn't interested in bit errors per > year, component failures per year, floor space per 100Mbyte/sec > throughput. They won't be until those features like the FPU become > economical using either hardware or software to drop into mainstream > cheap processor silicon. The trend is the other way. Major manufacturers are looking at simply overconfiguring by a large percentage and then disabling broken bits in software. Such machines will never be repaired. IBM's proposed 'Icecube' design almost precludes repair. > Why is that relevant - because the computing mainstream press > understands the computing mainstream. They care about desktop > performance properties (latency over throughput, price/performance, > etc). Getting them to think in other terms is hard, especially when any > attempt to get public IBM comparisons that are third party verified is > hitting a wall of silence. I don't see that as an issue. IBM has established comparative benchmarks between its own products - if you have one, you can relate it to other similar products. LSPR is the best example, though even there things like buffer pool redefinitiuons tend to blur the numbers. But who should verify and who arbitrate over the inevitable arguments? -- Phil Payne http://www.isham-research.com +44 7785 302 803 +49 173 6242039
Re: Animosity from the press
On Sun, 2002-05-26 at 10:52, Phil Payne wrote: > > Your I/O bus is typically PCI however so you are limited to about > > 100Mbytes/second I/O throughput in the real world. > > I would regard 100Mb/sec as a peak (instantaneous) transfer rate. Throughput will >be only a > fraction of that. On some tests only a small fraction. That really depends on the system. On an Athlon with 64bit PCI I can do 150Mbyte/second peak I/O , 120Mbyte/second sustained. Thats with about $10,000 of loaner hard disks. The sustained disk read/write speed for a single UDMA hard disk is about a magnitude lower. > The functionality and the performance are indeed there, but they are of no benefit >to 99.999% > of the chip's purchasers. Making an issue out of it as a 'superiority' of that >platform > distracts purchasers from price/benefit issues that are much more relveant to their > environments, and does the industry as a whole a disservice. Lets take a real world benchmark. On < $2000 of PC I can recompile the entire Linux kernel in 3 minutes, and the entirity of XFree86 in 30. I can saturate multiple 100Mbit links with web traffic. I can encode video in real time to mpeg and burn it to VideoCD as I go. I can render 1024x768 3D scenes with texture and lighting at 80frames/second. All of those happen to be useful to me. I think you misunderstand some of the nature of the commodity processors. >> Performance measurement should be left to those who know what they're doing. The >first step > is to define terms of measurement, and these must be related to real world and real >user > issues, so that the results are relevant to their audience. Understand that the majority audience isn't interested in bit errors per year, component failures per year, floor space per 100Mbyte/sec throughput. They won't be until those features like the FPU become economical using either hardware or software to drop into mainstream cheap processor silicon. Why is that relevant - because the computing mainstream press understands the computing mainstream. They care about desktop performance properties (latency over throughput, price/performance, etc). Getting them to think in other terms is hard, especially when any attempt to get public IBM comparisons that are third party verified is hitting a wall of silence. Alan
Re: Animosity from the press
> Other way around. Modern processors are in instructions per clock. On > raw CPU power it doesn't just beat the mainframe - it steamrollers them. > Your I/O bus is typically PCI however so you are limited to about > 100Mbytes/second I/O throughput in the real world. I would regard 100Mb/sec as a peak (instantaneous) transfer rate. Throughput will be only a fraction of that. On some tests only a small fraction. I looked at PC benchmarking quite seriously a few years back. It's very difficult because the design assumptions for a single-user system are so very different from those for a multi-user system. One case in point was OS2, which makes heavy use of background threads for housekeeping purposes. Windows 95 does something similar for cache management. Drive either with a synthetic workload and they're taken out of their design envelopes - both will run into critical resource shortages even in well-configured systems and show 'knee of the curve' phenomena. At one point Ziff Davis was actually running word processing 'benchmarks' using driving systems to simulate 40,000 keystrokes a minute - obviously a real world test. The issue is partly that the Intel processor is overpowered for the majority of purposes. Remember the 386/387 combination? From a logical point of view it made sense - only those who needed serious number-crunching power would buy the 80387 Co-processor. But it's actually cheaper to integrate the function on a standard chip - Intel saves dieing for a second chip, the motherboard manufacturers save the cost of an extra socket, and the users save having to find, purchaes and install a high-value static senstive component. The functionality and the performance are indeed there, but they are of no benefit to 99.999% of the chip's purchasers. Making an issue out of it as a 'superiority' of that platform distracts purchasers from price/benefit issues that are much more relveant to their environments, and does the industry as a whole a disservice. Performance measurement should be left to those who know what they're doing. The first step is to define terms of measurement, and these must be related to real world and real user issues, so that the results are relevant to their audience. -- Phil Payne http://www.isham-research.com +44 7785 302 803 +49 173 6242039
Re: Animosity from the press
On Fri, May 24, 2002 at 02:42:32PM -0700, Lionel Dyck wrote: > Seems that the linuxworld author of the mainframe articles is none too > happy with those on this listserv. > http://www.linuxworld.com/site-stories/2002/0522.mainframelinux.sidebar2.html I haven't been reading this guy's articles...and after reading the sidebar, it's clear I haven't missed anything. He simply Doesn't Get It. "Linux excels at the kinds of tasks that don't fir the mainframer's idea of data processing. I argue Linux mainframe performance must be evaluated in the context set by other uses of Linux, not other uses of zOS[sic]. Mainframe advocates excuse the poor performance of Linux in their environment by denigrating the kind of interactive computing Linux does best." He clearly misses the point: it's a server, dammit, not a single-user desktop. It's not *going* to do well on computation benchmarks. That's not what it was designed for, or optimized for. He should be looking at things like Apache and Samba and PostgreSQL, not KDE and SETI@Home. I think it's revealing as hell that Moshe Bar got comparable performance out of Linux/390 on a 2-way 1 GHz PIII under Hercules - which, I'm guessing, will turn about 10 MIPS with a reasonable I/O load - to what he did out of a PII-450. I daresay that the PII is turning more than 10 MIPS (any guesses? How many clocks per instruction does a PII use, under average workloads?), and that's even though the Linux/390 was having to put up with software emulation of I/O! I suggest we not waste time on someone who 1) appears to have a real axe to grind and 2) is so determined to resist any clue offered to him.
Re: LVM & Shark
Mark Post: > Sergey Korzhevsky: >> I heard some rumor about "Don't use LVM with Shark/ESS because it use >> RAID5". >> Is this true? > > No, I don't believe this is true. LVM should work just fine with that > hardware. Using an ESS system is confusing because the ESS box is making believe there are actual physical drives hidden somewhere within it's cabinet. It does for a disk farm what VM does for the CPU. The actual resources within a Shark may implement a "set of volumes" using RAID5- but that will be hidden (except for the slow writes, which the box will just cache anyway) from the actual mainframe (or whatnot) attached to it. You will probably want to avoid having the LVM in Linux from implementing it's own RAID5 array, though. -- John R. Campbell Speaker to Machines [EMAIL PROTECTED] - As a SysAdmin, yes, I CAN read your e-mail, but I DON'T get that bored! Disclaimer: All opinions expressed above are those of John R. Campbell alone and are seriously unlikely to reflect the opinions of his employer(s) or lackeys thereof. Anyone who says differently is itching for a fight!
Re: Animosity from the press
At 15:40 25-05-02, Alan Cox wrote: >Other way around. Modern processors are in instructions per clock. Same for mainframe CPU as far as I know, which is one of the reasons why we don't use the MIPS to rate the speed of a processor. Like what is my MIPS rate when we have zero-cycle instructions? ;-) Rob
Re: Animosity from the press
> Seems that the linuxworld author of the mainframe articles is none too > happy with those on this listserv. > > http://www.linuxworld.com/site-stories/2002/0522.mainframelinux.sidebar2.html > > All I can say is I am disappointed that the editors would publish his rant > and as I assume he is still subscribed to this listserv I'm sure he will > see this. The referenced article (see above url) is highly unprofessional > and shows someone who can not accept critism or correction. In this > business we all need to know how to say "I don't know" and "you taught me > something" as things change too fast to have our feet in concrete. For the record, my comments are quoted accurately and the author did ask for and receive permission to publish. I never thought he'd be that dumb. Synthetic loops have indeed been discredited for at least as long as I said - I can cite many and various examples of highly misleading results derived from them, as can my erstwhile colleagues at HDS, Comparex, Amdahl and so on. I actually considered trying to explain the significance of performance features in large multi-user systems, such as the preservation of previously translated virtual-real address pairs when the segment table origin register is changed - but thought the better of it. How do you see a feature like that in a synthetic loop? The man's a fool. His incompetence is now stored in retrieval systems all over the globe and will come back to revisit him whenever he tries to pronounce in the future. His next article might be about triple-bypass heart surgery using a Swiss Army knife. I look forward to it. -- Phil Payne http://www.isham-research.com +44 7785 302 803 +49 173 6242039
Re: TurboLinux install IPL tape issues
At 20:33 23-05-02, Hank Calzaretta wrote: >I'm using Turbo; this is the JCL I use to create the IPL tape. Are you sure >you are writing the 1st file of an NL tape? It is not necessary to make a NL tape when that takes a lot of authorisation in your shop. You can IPL a SL tape too, but you should have the operators do the IPL 5 times. Rob
