>> There is no problem whatsoever to set the clock to other >> speeds. , it's jsut a #define in the kernel sources (look for HZ) >> >> In kernel 2.6.x this #define is configurable via the regular "make >> *config" facility. For 2.4.x there's a patch that accomplish the same >> and I've used it for several projects with not problem. For 2.2 you can >> just change the value of the HZ define yourself. A value of 1024 is recomended. Good to hear. It indeed a good feature.
>> With this patch, nanosleep (and even usleep) will give you what you want. It can, unless one need various different timings with low common denominator ... Another issue is periodical vs. random activities. While for periodical tasks you can set the clock easily, a task that activated from outside (some interrupt from a device) and then send a signal (discrete) and need to wait up to 1mSec (as timeout if no response) can't do with 1000Hz. If you tolerate 100uSec it can do with 10000Hz clock but no one want such a clock - it will kill the system. For such a random timing events you need an auxiliary timer. So, it depend of the application characteristics and allowed jittering. >> *IMPORTANT* If timing is important to you as it seems it does, make sure >> to use sched_setscheduler() and sched_setpriority() to give real time >> priority to the proccess that requires these short sleeps, otherwise >> NONE of the methods suggested above (by me or other people) is >> guranteed to work. In fact, it's guranteed not to work :-) True. Notes : 1. Interrupt masking can create a latency. Make sure you remove all unnecessary services and applications. 2. If periodic task is needed, read some fast clock right before you calculations to find jittering and do the correct extrapolations (i.e. tick->ISR->semaphore->user level thread->your algorithm may take different time each cycle). 3. If activating auxiliary timer that need arming every time make sure you do it as soon as posible (in the periodic case - in the ISR itself) so you won't have time sweeping. Good luck. This e-mail message has been sent by Elbit Systems Ltd. and is for the use of the intended recipients only. The message may contain privileged or confidential information . If you are not the intended recipient you are hereby notified that any use, distribution or copying of this communication is strictly prohibited, and you are requested to delete the e-mail and any attachments and notify the sender immediately. ================================================================= To unsubscribe, send mail to [EMAIL PROTECTED] with the word "unsubscribe" in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
