Messages in this thread | | | From | Benno Senoner <> | Subject | changing RTC frequency on the fly = sync problems (RTC virtualization) | Date | 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/
| |