Re: gettimeofday() goes backwards on FreeBSD 4.9
От | Marc G. Fournier |
---|---|
Тема | Re: gettimeofday() goes backwards on FreeBSD 4.9 |
Дата | |
Msg-id | 20031128220142.U99096@ganymede.hub.org обсуждение исходный текст |
Ответ на | Re: gettimeofday() goes backwards on FreeBSD 4.9 ("Marc G. Fournier" <scrappy@postgresql.org>) |
Ответы |
Re: gettimeofday() goes backwards on FreeBSD 4.9
|
Список | pgsql-hackers |
On Fri, 28 Nov 2003, Marc G. Fournier wrote: > On Fri, 28 Nov 2003, Tom Lane wrote: > > > "Marc G. Fournier" <scrappy@postgresql.org> writes: > > > I'm suspecting that the issue is amplified by load on the server itself > > > > That would fit right in with my idea that the failure occurs when the > > process loses its timeslice partway through gettimeofday(). Heavier > > load would presumably make it more likely to lose the CPU. > > I'm posting to the freebsd lists about it, see if they have anything to > say ... Just got my first response on this, and, in fact, this is 'acceptable behaviour' to a certain extent ... there is a kernel tuneable called kern.timecounter.method, that is either 1 or 0: 0 sacrifice precision in favor of faster code execution 1 return the more precise time (the same as calling microtime() or nanotime()). The intent of the getmicrotime() and getnanotime() functions is to enforce the user's preference for timer accuracyversus execution time. Now, reading the man page, there seems to be a 'microtime' vs 'getmicrotime' function ... these might be preferable to using gettimeofday on FreeBSD? ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
В списке pgsql-hackers по дате отправления: