Date: Fri, 03 Dec 1999 00:11:52 +0100 From: Poul-Henning Kamp <phk@critter.freebsd.dk> To: peter.jeremy@alcatel.com.au Cc: arch@freebsd.org Subject: Re: Threads stuff Message-ID: <1591.944176312@critter.freebsd.dk> In-Reply-To: Your message of "Fri, 03 Dec 1999 10:03:34 %2B1100." <99Dec3.095608est.40342@border.alcanet.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <99Dec3.095608est.40342@border.alcanet.com.au>, Peter Jeremy writes: >On 1999-Dec-03 07:22:54 +1100, Poul-Henning Kamp wrote: >>In message <99Dec3.070619est.40333@border.alcanet.com.au>, Peter Jeremy writes: >>>On my PII-266, clock_gettime(CLOCK_REALTIME) takes 2.48usec and >>>gettimeofday() takes 2.42usec - slightly better. > >>The time it takes depends on the "timecounter" you are using for >>your timekeeping. I will venture to guess that the above numbers >>come from a UP machine using the TSC. > >Ooops, I forgot about that. Yes, this is an UP system using the TSC. >AFAIK, I can't swap to the 8254 w/o rebooting. > >I tried the same thing on a P-133 using the i8254 and got: >clock_gettime(CLOCK_REALTIME) 6.92 usec >gettimeofday() 5.93 usec > >(And on a 386SX25 running 2.2.5, I got 115usec). > >>If the timestamps don't need to be more precise than 1/hz, > >I suspect that for the purposes in question, it _does_ need to >be SMP safe (which writes off the TSC) and will need better than >1/hz precision (though I'm not definite about this). It would be possible to make it optional, so that the routine would try to use the "all-in-userland" timekeeping only if available and resort to the kernel if not. -- Poul-Henning Kamp FreeBSD coreteam member phk@FreeBSD.ORG "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1591.944176312>