[EMAIL PROTECTED] (Nathan Myers) writes:
> Certainly there are machines and kernels that count time more precisely
> (isn't PG ported to QNX?). We do users of such kernels no favors by
> pretending they only count clock ticks. Furthermore, a 1ms clock
> tick is pretty common, e.g. on Alpha box
On Sat, Feb 17, 2001 at 12:26:31PM -0500, Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > A comment on microsecond delays using select(). Most Unix kernels run
> > at 100hz, meaning that they have a programmable timer that interrupts
> > the CPU every 10 milliseconds.
>
> Right -
> So *if* some I/O just completed, the call *might* do what we need,
> which is yield the CPU. Otherwise we're just wasting cycles, and
> will continue to waste them until we do a select with a nonzero
> delay. I propose we cut out the spinning and just do a nonzero delay
> immediately.
Well, a
Bruce Momjian <[EMAIL PROTECTED]> writes:
>> Having read the select(2) man page more closely, I now realize that
>> it is *defined* not to yield the processor when the requested delay
>> is zero: it just checks the file ready status and returns immediately.
> Actually, a kernel call is something.
> I have been thinking some more about the s_lock() delay loop in
> connection with this. We currently have
>
> /*
> * Each time we busy spin we select the next element of this array as the
> * number of microseconds to wait. This accomplishes pseudo random back-off.
> * Values are not critic
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > A comment on microsecond delays using select(). Most Unix kernels run
> > at 100hz, meaning that they have a programmable timer that interrupts
> > the CPU every 10 milliseconds.
>
> Right --- this probably also explains my observation that some ke
Bruce Momjian <[EMAIL PROTECTED]> writes:
> A comment on microsecond delays using select(). Most Unix kernels run
> at 100hz, meaning that they have a programmable timer that interrupts
> the CPU every 10 milliseconds.
Right --- this probably also explains my observation that some kernels
seem t
Bruce Momjian wrote:
> In fact, the kernel doesn't even contain have a way
> to measure microsecond timings.
Linux has patches available to do microsecond timings, but they're
nonportable, of course.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11
A comment on microsecond delays using select(). Most Unix kernels run
at 100hz, meaning that they have a programmable timer that interrupts
the CPU every 10 milliseconds. The kernel only gets to control the cpu
during those tick interrupts or if a user application makes a kernel
call.
Therefore
