Date: Tue, 05 Feb 2002 19:54:56 +0100 From: Poul-Henning Kamp <phk@critter.freebsd.dk> To: John Polstra <jdp@polstra.com> Cc: hackers@freebsd.org Subject: Re: A question about timecounters Message-ID: <91633.1012935296@critter.freebsd.dk> In-Reply-To: Your message of "Tue, 05 Feb 2002 09:21:31 PST." <200202051721.g15HLVW03792@vashon.polstra.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <200202051721.g15HLVW03792@vashon.polstra.com>, John Polstra writes: >In article <86051.1012909502@critter.freebsd.dk>, >> This may be a problem, I have yet to see GCC make different code for >> that but I should probably have committed the "volatile" anyway. > >It should be committed, but it is not causing the problem in this >case. I changed it and then compared MD5s of the object files. The >only changes that resulted were unimportant. Will do. >> >I also noticed this in tco_forward(): >> > >> > tco = timecounter; >> > tc = sync_other_counter(); >> > [...] >> > if (tco->tc_poll_pps) >> >> This code is actually correct, the tc_poll_pps needs to be done on >> the "old" timecounter, because that would be the reference for any >> captured hardware timestamps, if I did it on the new timecounter I >> might get negative deltas which would complicate things. Also the >> new timecounter may have a changed frequency/offset (tickadj/ntpd >> and all that). > >I don't think I follow your reasoning here. If the call to >sync_other_counter were inlined, we'd have something like this: > > tco = timecounter; > tco_in_sync_other_counter = timecounter; > [...] > if (tco->tc_poll_pps) > >Obviously tco and tco_in_sync_other_counter will have the same value >almost all of the time, so the code can't be relying on them being >different. It doesn't rely on them being different, they are used for two different purposes. sync_other_counter() sets up the next counter in the ring to be used for timekeeping, tco/tc_poll_pps is used to calculate any hardware captured timestamps which occured _before_ now. sync_other_counter() returns the next timecounter after fiddling it but we cannot use that for tc_poll_pps() purposes, we need the old (or if you will: still present one) for that. Trust me, this is not your problem because this is used only with the xrpu.c timecounter code anyway and you don't have the hardware for that :-) >Many of the systems where I see this problem are using the TSC as >the timecounter. They don't have APM in the kernel, and they aren't >running ntpd. I.e., it's not only the i8254 that's the problem. The >fastest of these systems is a 1.13 GHz PIII, and it would take the 32 >bits of the TSC which are actually used 3.8 seconds to wrap around. It would be a problem if the kernel is punched hard enough that code doesn't complete in the time it takes for the used timecounter to wrap, ie: if you can have something like: call microuptime() tc = timecounter; (interrupt and do other stuff for several seconds) ... overflow in arithmetic But you would have to pummel your kernel pretty bad for that. On the other hand, between a 10000 Hz and the network load you describe, that may be exactly what is happening... -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?91633.1012935296>