Date: Thu, 30 Mar 2000 11:03:08 -0700 From: Warner Losh <imp@village.org> To: Matthew Dillon <dillon@apollo.backplane.com> Cc: Poul-Henning Kamp <phk@critter.freebsd.dk>, Bruce Evans <bde@zeta.org.au>, Mike Smith <msmith@FreeBSD.ORG>, freebsd-current@FreeBSD.ORG Subject: Re: SMP buildworld times / performance tests Message-ID: <200003301803.LAA25466@harmony.village.org> In-Reply-To: Your message of "Thu, 30 Mar 2000 09:15:54 PST." <200003301715.JAA73702@apollo.backplane.com> References: <200003301715.JAA73702@apollo.backplane.com> <1274.954416252@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <200003301715.JAA73702@apollo.backplane.com> Matthew Dillon writes: : The general problem with the timecounter is that not only is the hardware : indeterminant, but the timecounter structure itself is *NOT* MP safe, : at least not by my read of it. : : It also doesn't appear to be interrupt safe. If a microtime() or : getmicrotime() call is interrupted and the interrupting interrupt calls : microtime(), it can corrupt the data returned by the first guy and : even corrupt the structure. We've hacked the parallel port interrupt to be a fast one on one of our boxes. It is connected to the pps driver which calls getnanotime to timestamp the pps pulse that came in. We've seen, in carefully plotting ntp data, that there are often (1 in a thousand) large dropouts in the times reported. They are in the neighborhood of the clock tick. Since ntp discards the outliers, this was a low priority issue for us given the overall nature of that particular system. At the time I took a look at it, and couldn't see how access to the counter could be mp safe, but didn't have a lot of time to pursue it. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200003301803.LAA25466>