hes@ecsvax.UUCP (Henry Schaffer) (11/23/85)
<>I was intrigued by this topic, and asked a colleague for his comments. He is John Stephenson at TUCC who is an expert on large IBM systems using the OS/MVS operating system. >I think that if anyone can invent a rule of thumb for memory size as >discussed by >Shein in net.arch that it will apply only to a certain operating system >and type of work. With mvs the rule is simply that if the wait light >in not out and the i/o system is running hard, especially paging hard, >then memory is the number one candidate for addition. Of course, since >the paging system is simulating memory, faster paging is a possible >alternative but there is an additional, largely unknown, cpu cost to >paging. Here relative costs enter the picture and since they change >all the time one's thumb is likely to get sore. Note that IBM mainframes have a "wait light" which goes on when the cpu can't do anything because e.g., it is waiting for the completion of I/O. --henry schaffer
josh@polaris.UUCP (Josh Knight) (11/25/85)
In article <794@ecsvax.UUCP> hes@ecsvax.UUCP (Henry Schaffer) writes: > > Note that IBM mainframes have a "wait light" which goes on when the >cpu can't do anything because e.g., it is waiting for the completion of >I/O. IBM 370's have a "wait state" that the operating system can use to wait for interrupts rather than a "busy wait loop" if it wants to. On the other hand a "busy wait loop" with interrupts enabled will work just as well on a 370 as any other architecture. Older machines do indeed have a light or meter that purports to measure the fraction of time that the machine is in wait state. With a 2 MIPS system (I'm thinking of a 370/168 here) and incandescent lights, however, exactly what it means is open to question. Newer machines have a "system activity display" (I think that's what it's called) that displays the fraction of time spent in wait state, among other things. Any opinions (expressed or implied) or errors are mine and not my employers. -- Josh Knight, IBM T.J. Watson Research josh at YKTVMH on BITNET, josh.yktvmh@ibm-sj on CSnet, ...!philabs!polaris!josh
cmt@myrias.UUCP (Chris Thomson) (11/30/85)
Josh Knight writes: > IBM 370's have a "wait state" that the operating system can use to wait for > interrupts rather than a "busy wait loop" if it wants to. On the other hand > a "busy wait loop" with interrupts enabled will work just as well on a 370 > as any other architecture. Yes, it is true that you can busy wait on a 370, but it's a dumb idea. Not only does it slow down your i/o channels, but it makes it impossible to give interrupts to the less busy cpu in a dyadic configuration.
mat@amdahl.UUCP (Mike Taylor) (12/08/85)
> In article <794@ecsvax.UUCP> hes@ecsvax.UUCP (Henry Schaffer) writes: > > > > Note that IBM mainframes have a "wait light" which goes on when the > >cpu can't do anything because e.g., it is waiting for the completion of > >I/O. > > IBM 370's have a "wait state" that the operating system can use to wait for > interrupts rather than a "busy wait loop" if it wants to. On the other hand > a "busy wait loop" with interrupts enabled will work just as well on a 370 as > any other architecture. Older machines do indeed have a light or meter that > purports to measure the fraction of time that the machine is in wait state. > With a 2 MIPS system (I'm thinking of a 370/168 here) and incandescent lights, > however, exactly what it means is open to question. Newer machines have a > "system activity display" (I think that's what it's called) that displays > the fraction of time spent in wait state, among other things. > The wait light and the use of a "wait state" were the architectural solution to the need for usage-sensitive pricing. IBM has for many years offered rental plans which provided a number of hours of use per month for a fixed monthly charge, plus an hourly charge for any hours used over the fixed amount (176). The system usage is measured by a meter. The meter runs when any device in the system is active. I/O devices provide a "metering out" signal. The CPU provides "not wait state." The meter status is indicated by a control panel light labelled "system." There is a time lag built in of 0.5 second, so that metering goes inactive after the last device in the system becomes inactive and no device becomes active for 0.5 sec. For this purpose, incandescent lights are perfectly adequate. The control program uses the wait state as a cooperation with IBM's billing algorithm, not for tuning or measurement purposes. -- Mike Taylor ...!{ihnp4,hplabs,amd,sun}!amdahl!mat [ This may not reflect my opinion, let alone anyone else's. ]
mat@amdahl.UUCP (Mike Taylor) (12/11/85)
> Yes, it is true that you can busy wait on a 370, but it's a dumb idea. Not > only does it slow down your i/o channels, but it makes it impossible to > give interrupts to the less busy cpu in a dyadic configuration. You don't want to give interrupts to the less busy CPU, you want to give interrupts to the one that is more likely to have the interrupt supervisor code in its cache. Interrupt windowing in MVS therefore concentrates interrupts on one (arbitrarily chosen) CPU, for example. BTW, a busy loop doesn't interfere with the I/O channels on any high end systems, because there is no mainstore activity once the loop is in the cache. -- Mike Taylor ...!{ihnp4,hplabs,amd,sun}!amdahl!mat [ This may not reflect my opinion, let alone anyone else's. ]