changing RTC frequency on the fly = sync problems (RTC virtualization)

Benno Senoner (sbenno@gardena.net)
Sat, 30 Oct 1999 23:35:59 +0200


Hi folks,

we are trying to develop some sort of RTC virtualization,
that means several clients (userspace processes) which share the RTC timer.

Assume that we can use an rtc daemon (or a kernel module) (which actually opens
the RTC device and periodically wakes up the clients throught some sort of IPC
(socket/pipe etc) ).

Now comes the fun:
of course we want maximum efficiency, so it would be very useful to change the
RTC frequency when needed.

assume the following idiotic case:

client1 requests RTC at 256HZ (the daemon opens the RTC device at 256HZ and
periodically "wakes up" the client)
now comes client2:
client2 wants RTC at 128HZ
no problem for the server: just wakeup client2 every 2 RTC ticks.
now client3 wants RTC at 1024 HZ
in this case the server has to change the RTC frequency to 1024HZ and
wakeup client2 every 4ticks and client2 every 8 ticks.

now client1 exits, nothing happens just remove the client from the wakeup list.
later client3 exits, the server changes the RTC frequency to 128HZ and servers
client3.

My question: are there major delays when changing RTC frequency on the fly ?
If yes, what is the order of magnitude of the delay ?

I ask this because it would just be a waste to run an RTC at 8192HZ only to
serve potential 8192HZ clients (8192HZ causes nice IRQ overhead).

comments ?

PS: please CC me because I'm not on the list.

regards,
Benno.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/