In message <[EMAIL PROTECTED]>, John Polstra writes:
>In article <[EMAIL PROTECTED]>,
>> 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
[EMAIL PROTECTED] | 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 [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
