 |
lua-l archive |
|
|
||
|
Its less a CPU think, than an OS-Kernel/scheduler thing. Traditionally
most OSes use(d) "ticks" to seperate time. For example on Linux the
100Hz interrupt timer was standard, fireing very 10ms and thus
interrupting a process and giving control to the next one. Some people
who wanted more responsive interactiveness set it to 1000Z, many
server admins (me included) set it to 20 HZ without any problems. Less
interrupts means more performance overall for the price for a process
waiting a little longer to react on an event. Nowadays most linux
configurations are "tickless", the kernel sets the next tick on the
fly, depending on current needs. I'm not into the exact mechanics of
these.
Anyway, for high precession sleeps the basic problem is, what use is
there to provide a nanosleep, if the scheduler will anyway give the
next process a few milliseconds to have the CPU? On any Desktop-OS
today, you have to life with the fact if you call sleep, the kernel
might actually give you control back anytime later than that, just as
soon as it can do for you.
There are operating systems that can give you a guaranteed response
time - that are "real time" OSes. Everything gets more complicated so
the kernel can guarantee you timeliness in microseconds or fewer. Some
embedded devices need to do that. Most PCs do not. Most variants of
"Real-Time-Linux" is actually another micro operating system running
above Linux, in which the Linux kernel as we know it, is just one of
its processes.
On Tue, Aug 16, 2011 at 12:17 PM, Lorenzo Donati
<lorenzodonatibz@interfree.it> wrote:
> On 16/08/2011 10.54, Lorenzo Donati wrote:
>
> Enrico and Sean: thanks for the reply.
>
> I already knew some of those info, anyway. Sorry, probably I wasn't clear
> enough: my curiosity wasn't for the idiosyncrasies in themselves, but for a
> possible hardware-related reason beneath (that's why I marked OT the
> message).
>
> To be clearer: I'd like to know (whether or not an OS chooses to provide an
> high resolution sleep function) if the modern PC hardware is capable of
> providing such a timing resolution to the upper sw layer by default (using
> some standard BIOS call or standard I/O port or whatever), or if it depends
> on some peculiar hw characteristic such as CPU setup, chipset or similar
> things.
>
> TIA
> -- Lorenzo
>
>