In message <[EMAIL PROTECTED]>, John Polstra writes:
>In article <[EMAIL PROTECTED]>,
>Poul-Henning Kamp <[EMAIL PROTECTED]> wrote:
>> In message <[EMAIL PROTECTED]>, John Polstra writes:
>>
>> Can you try to MFC rev 1.111 and see if that changes anything ?
>
>That produced some interesting results. I am still testing under
>very heavy network interrupt load. With the change from 1.111, I
>still get the microuptime messages about as often. But look how
>much larger the reported backwards jumps are:
>
> microuptime() went backwards (896.225603 -> 888.463636)
> microuptime() went backwards (896.225603 -> 888.494440)
> microuptime() went backwards (896.225603 -> 888.500875)
> microuptime() went backwards (1184.392277 -> 1176.603001)
> microuptime() went backwards (1184.392277 -> 1176.603749)
(Ok, I'll MFC 1.111)
Sanity-check: this is NOT a multi-CPU system, right ?
We now have three options left:
hardclock interrupt starvation
scheduling related anomaly wrt to the use of microuptime().
arithmetic overflow because the call to microuptime() gets
interrupted for too long.
Looking for the first, add this to hardclock:
static u_int64_t lasttsc;
u_int64_t delta, now;
now = rdtsc();
delta = now - lasttsc;
lasttsc = now;
if (delta > (tsc_freq * 3) / (2 * hz)) {
printf("delta = %llu \n", delta);
}
In theory, you get no printfs. If you do, hopefully they have small
delta values.
Looking for the third:
Add splhigh() protection around the stuff in microuptime();
--
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
