Re: kqueue timer timeout period
On 2012-Jul-10 10:03:08 -0500, Paul Albrecht albre...@glccom.com wrote: I have a question about the kqueue timer timeout period ... what's data supposed to be? I thought it was supposed to be the period in milliseconds, but I seem to off by one. For example, if I set date (the timeout period) to 20 milliseconds, I often wait 21 milliseconds which is very undesirable for my application. FreeBSD is not a real-time OS. The timeouts specified in various syscalls (eg kevent(EVFILT_TIMER), nanosleep(), select(), poll()) specify minimum timeouts. Once the timeout (rounded up to the next tick) has expired, the process will be placed back into the queue of processes eligible to be run by the scheduler - which may impose a further arbitrary delay. Periodic timers are somewhat better behaved: Scheduler delays only impact process scheduling after the timeout expires and the average rate should be very close to that requested. -- Peter Jeremy pgpaFY3z3IfaV.pgp Description: PGP signature
Re: kqueue timer timeout period
On Wed, 11 Jul 2012, Peter Jeremy wrote: PJOn 2012-Jul-10 10:03:08 -0500, Paul Albrecht albre...@glccom.com wrote: PJI have a question about the kqueue timer timeout period ... what's data PJsupposed to be? I thought it was supposed to be the period in PJmilliseconds, but I seem to off by one. PJ PJFor example, if I set date (the timeout period) to 20 milliseconds, I PJoften wait 21 milliseconds which is very undesirable for my application. PJ PJFreeBSD is not a real-time OS. The timeouts specified in various PJsyscalls (eg kevent(EVFILT_TIMER), nanosleep(), select(), poll()) PJspecify minimum timeouts. Once the timeout (rounded up to the next PJtick) has expired, the process will be placed back into the queue PJof processes eligible to be run by the scheduler - which may impose PJa further arbitrary delay. PJ PJPeriodic timers are somewhat better behaved: Scheduler delays only PJimpact process scheduling after the timeout expires and the average PJrate should be very close to that requested. While it is certainly true that FreeBSD is not a real-time OS, this does not explain the timer problems. 2 or 3 month ago I did a simple test with select and poll: I observed a systematic error of about 3-5% of the waiting time. So when you wait for 20ms, you may get 21ms (if running with a low HZ value) because of rounding. But if you wait for 100s, you get 103 or even 105s on a completly idle machine (all services disabled). I think that this is not a problem with beeing non-realtime, but a problem with time-keeping. Shouldn't it be possible to do this better? harti ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: kqueue timer timeout period
Hi. Historically FreeBSD used completely different hardware time sources for time keeping and time events. Not sure about 5%, but the last could be less precise in some cases. FreeBSD 9.0, depending on hardware, can be more precise because of using same time source in both cases. Also there is ongoing GSoC project now by Davide Italiano to handle sub-HZ resolution for time events. Present tests show reaching 20 microseconds precision; and I think it can be improved further. -- Alexander Motin ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: kqueue timer timeout period
On Wed, 2012-07-11 at 03:36 -0500, Harti Brandt wrote: On Wed, 11 Jul 2012, Peter Jeremy wrote: PJOn 2012-Jul-10 10:03:08 -0500, Paul Albrecht albre...@glccom.com wrote: PJI have a question about the kqueue timer timeout period ... what's data PJsupposed to be? I thought it was supposed to be the period in PJmilliseconds, but I seem to off by one. PJ PJFor example, if I set date (the timeout period) to 20 milliseconds, I PJoften wait 21 milliseconds which is very undesirable for my application. PJ PJFreeBSD is not a real-time OS. The timeouts specified in various PJsyscalls (eg kevent(EVFILT_TIMER), nanosleep(), select(), poll()) PJspecify minimum timeouts. Once the timeout (rounded up to the next PJtick) has expired, the process will be placed back into the queue PJof processes eligible to be run by the scheduler - which may impose PJa further arbitrary delay. PJ PJPeriodic timers are somewhat better behaved: Scheduler delays only PJimpact process scheduling after the timeout expires and the average PJrate should be very close to that requested. While it is certainly true that FreeBSD is not a real-time OS, this does not explain the timer problems. 2 or 3 month ago I did a simple test with select and poll: I observed a systematic error of about 3-5% of the waiting time. So when you wait for 20ms, you may get 21ms (if running with a low HZ value) because of rounding. But if you wait for 100s, you get 103 or even 105s on a completly idle machine (all services disabled). I think that this is not a problem with beeing non-realtime, but a problem with time-keeping. Shouldn't it be possible to do this better? I don't think it has anything to do with realtime either. I've been using gentoo linux to run my application using timerfd_create/read for 20 millisecond timing without any problems. harti -- Paul Albrecht ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: [[SPAM]] Re: kqueue timer timeout period
On Wed, 2012-07-11 at 04:42 -0500, Alexander Motin wrote: Hi. Historically FreeBSD used completely different hardware time sources for time keeping and time events. Not sure about 5%, but the last could be less precise in some cases. FreeBSD 9.0, depending on hardware, can be more precise because of using same time source in both cases. Also there is ongoing GSoC project now by Davide Italiano to handle sub-HZ resolution for time events. Present tests show reaching 20 microseconds precision; and I think it can be improved further. I'm definitely not getting getting 20 millisecond timing with freebsd kqueue which surprised me because I get it with linux linuxfd_create/read using the same hardware. -- Paul Albrecht ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
kqueue timer timeout period
Hi, I have a question about the kqueue timer timeout period ... what's data supposed to be? I thought it was supposed to be the period in milliseconds, but I seem to off by one. For example, if I set date (the timeout period) to 20 milliseconds, I often wait 21 milliseconds which is very undesirable for my application. -- Paul Albrecht ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
