Re: Is anyone else using 9i RAC on HP-UX ???

Jonathan Lewis apparently said,on my timestamp of 20/02/2005 5:36 AM:

> Under the medium workload on RAW, CPU utilization
> was 80%, at a transaction throughput (rate?) of 23,135.
> With the same workload and configuration, but using
> the Async I/O driver, the transaction throughput was
> 31,961 with a CPU utilization of 79%.
>
> So where was the extra CPU going when the system
> was doing LESS work, and NOT handing off to the async
> processes ?

Re-scheduling the jobs waiting on I/O? Without AIO, the OS re-schedules a proc waiting on I/O. The proc receives control, checks if it can issue its I/O command (no one else waiting), if not it relinquishes CPU back to scheduler. This gets tallied as the proc's own time.
With AIO, the polling/queuing is tallied for as OS time or daemon time, if at all. Not user proc time. Because the process doing the AIO is (usually) a daemon.

<rant>
So maybe that was the diff? It all (I hate this term...) depends on how each implementation accomplishes the IO, be it A or non-A.

I think part of the problem with the imprecision of results between different implementations is that they are just that: different.

In the old days of implicit AIO like all mainframes did, I/O was processed as an OS task. Any proc requesting I/O did so with a SIO instruction, which implicitly caused the proc to go back to the scheduler as well as registering a post-IO return address with the proc's status structure (the PSR, for the mainframe IBM boffins here). The OS would then do whatever was needed and the process would reschedule on the next instruction and proceed execution. The I/O request was acted upon by the hardware and when it was complete, the hardware would interrupt the CPU and send control to what was called an "Interrupt pre-process" routine. This ran at top priority: it just took the I/O interrupt vector and stored it in the I/O queue structure of the OS as well as doing a V operation on the OS's "Interrupt post-process" routine. And control went back to the scheduler. The interrupt post-processing routine would do whatever was needed to put the data into a buffer the user process could get to (usually by just passing pointers), then re-activated the proc's post-IO address as the next execution point for the process, then did a P operation and went back to sleep. The proc would just resume on the post-IO entry point, do whatever it needed with the data, then re-schedule itself to continue normal execution. And that was pretty much it for AIO: it was there, we could rely on it being handled by the OS implicitly, everytime we requested a block IO. In any language, from Assembler to APL.

Then Unix came along and single-threaded ALL IO, in the name of "simplicity". Worse: most P/V operations and proper semaphore concurrency handling were thrown out and replaced by time-shared round-robbin scheduling. The CPUs were getting fast enough to hide the obvious defects of this idea. It didn't take long until they realized it didn't stand a chance of competing with mainframes on IO throughput. But instead of learning from the mainframe experience, the Unix boffins decided to use AIO daemons and polling. Most kept the brute force time-shared scheduling. Still far from perfect. Eventually, they'll all re-invent the wheel and do the right thing.

IIRC, HP did a lot of work with real-time schedulers and proper semaphore controlled multi-tasking and interrupt pre/post processing in the 80s. They are probably the "pioneers" of re-inventing the wheel in the Unix world. Their IO certainly is much different from every other Unix.

> Bottom line: it doesn't look like marketing, so
> I don't think anyone has tried hard to fake
> anything. But the figures look surprisingly
> good for raw, and I'd like to know if there
> was some quirk of the tests that just happened
> to work well with raw.

Like I said: HP handles IO in a quite different way from all other Unix companies. That could be part of the reason. I'd gladly give 1 year of my life to be able to pour through the source code of HPUX. Linux will have to do for the time being. The differences between 2.6 and prior kernels are most surprising: for the first time someone has spent the time to do a proper scheduler for Linux. It shows in the responsiveness. If only they could fix the IO properly, it would be a killer. </rant>

Anyways, enough IO: there's a rock pool waiting for me.

-- 
Cheers
Nuno Souto
in sunny Sydney, Australia
wizofoz2k_at_yahoo.com.au.nospam