|
Let me give you some background, James. I've been writing a lot RPG code this past year - building a Web development framework. And researching whether a Web framework is a suitable alternative to 5250. To help me optimize my RPG code, I'll sometimes write an equivalent in Foxpro or Delphi and compare the difference. It has puzzled me that my $1,600 Laptop consistently out performs my $16,000 AS/400 - sometimes by a factor of 10. It further confused me after I learned that the AS/400 had a 200 Mhz processor - which I consider fast. I wondered whether something was constraining the AS/400 processor. I have now learned that IBM has some means of governing the CPU so that I can only get at about 20% of it's capacity. PC manufacturers don't do that. The puzzle is solved. Your explanation of the I/O support provided to 5250 applications may lead someone to conclude that the AS/400 is not built to handle Web applications. Perhaps, that's partly right. I believe OS/400 is ideal for the Web. But a constrained CPU is not. Web applications require lots of CPU because they involve the handling of lengthy streams. Apparently IBM is beginning to realize that - the capacity of their new servers is a step in the right direction. Nathan. > Date: Thu, 03 May 2001 14:14:15 -0700 > From: "James W. Kilgore" <eMail@James-W-Kilgore.com> > Subject: Re: How are CPU Speed and Overall CPW Related? > > Nathan, > > As everyone has been trying to tell you, you are comparing apples to > oranges by this measure. > > It does bring up the point that no single machine is best suited to > solve all problems. > > It wouldn't take much to bring your 100mhz PC to it's knees with some > other task running at the same time. The AS/400 is not intended to be a > single function machine, so it is not optimized for those types of > functions. And, yes, it will measure poorly when tested for something > it was not designed for. As any machine would test poorly for something > it was not designed for. > > I'm not sure what you are trying to get at, but you must face that > reality that the AS/400 is -not- the best machine at all things, But, it > is the best machine when a single machine has to do all things all at > once. > > Although I liked the motorcycle vs bus example, I'll give you a > different one that actually relates to computers and the AS/400 in > particular. This has to do with the response degradation curve. That > is, under other systems, there is a direct, linear curve that > corresponds with the number of users and their response time. The more > users, the slower the response time. > > IBM created an I/O subsystem that flattened that curve. A single user > was faster on the other system when compared to the AS/400, but 20+ > users were slower. (The same was true in token ring vs ethernet) Now > why would IBM do this? Well, from what I've read, IBM spends a whole > bunch of money on researching things like psychological factors in user > satisfaction. What they found was that any given user was happier (more > satisfied) with a system that provided a consistent response time than a > system that went from fast, to slow, then back to fast again throughout > the work day. So if you get .5 sec response time as a single user, you > will still get .5 sec response time with 20 or 100 or 10,000 users. > (provided that you have the right model for the workload) > > I guess the point that I'm getting to is that the AS/400 never was, and > never will be, optimized for a single user. It is designed to be a > multi user, multi tasking, consistent response time, back room, boring > fixture. > > "Nathan M. Andelin" wrote: +--- | This is the Midrange System Mailing List! | To submit a new message, send your mail to MIDRANGE-L@midrange.com. | To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com. | To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com. | Questions should be directed to the list owner/operator: david@midrange.com +---
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.