I know this has been reported on the list recently, but I think I can
provide better detail. I'm running 2.4.2 with atyfb on a K6-2/266
running at 250. This system has no history of clock problems.
adjtimex-1.12 --compare gives me "2nd diff" readings of -0.01 in quiescent
conditions.
flipping consoles rapidly cboosts this number to -3 or -4.
catting the full documentation to ntpd (seemed appropriate) gives me
"2nd diff" numbers a little over 34. If I read the numbers correctly,
47 seconds of CMOS time passed while the system clock only passed 13
seconds.
The processor and the CMOS clock were moving at zero velocity relative
to each other, and were both in normal Earth gravity.
I would appreciate cc's of replies (ore requests for further
information), as I am not subscribed.
-Eric
Eric Buddington wrote:
>
> I know this has been reported on the list recently, but I think I can
> provide better detail. I'm running 2.4.2 with atyfb on a K6-2/266
> running at 250. This system has no history of clock problems.
>
> adjtimex-1.12 --compare gives me "2nd diff" readings of -0.01 in quiescent
> conditions.
>
> flipping consoles rapidly cboosts this number to -3 or -4.
>
> catting the full documentation to ntpd (seemed appropriate) gives me
> "2nd diff" numbers a little over 34. If I read the numbers correctly,
> 47 seconds of CMOS time passed while the system clock only passed 13
> seconds.
>
> The processor and the CMOS clock were moving at zero velocity relative
> to each other, and were both in normal Earth gravity.
The kernel blocks interrupts during console output. fbdev
consoles are slow. Net result: many lost timer interrupts.
I'm working on it. Slowly. Should have something next week.
-
We have the same trouble on PPC but we make sure to re-sync on each
interrupt. We can see several lost timer interrupts after a ^L in emacs
running on the fb console. The resync lets us catch up on those interrupts
(and not lose time) but we still spend a lot of time not servicing
interrupts.
Does x86 not resync on timer interrupts?
} Eric Buddington wrote:
} >
} > I know this has been reported on the list recently, but I think I can
} > provide better detail. I'm running 2.4.2 with atyfb on a K6-2/266
} > running at 250. This system has no history of clock problems.
} >
} > adjtimex-1.12 --compare gives me "2nd diff" readings of -0.01 in quiescent
} > conditions.
} >
} > flipping consoles rapidly cboosts this number to -3 or -4.
} >
} > catting the full documentation to ntpd (seemed appropriate) gives me
} > "2nd diff" numbers a little over 34. If I read the numbers correctly,
} > 47 seconds of CMOS time passed while the system clock only passed 13
} > seconds.
} >
} > The processor and the CMOS clock were moving at zero velocity relative
} > to each other, and were both in normal Earth gravity.
}
} The kernel blocks interrupts during console output. fbdev
} consoles are slow. Net result: many lost timer interrupts.
}
} I'm working on it. Slowly. Should have something next week.
} > We have the same trouble on PPC but we make sure to re-sync on each
} > interrupt. We can see several lost timer interrupts after a ^L in emacs
} > running on the fb console. The resync lets us catch up on those interrupts
} > (and not lose time) but we still spend a lot of time not servicing
} > interrupts.
} > Does x86 not resync on timer interrupts?
}
} The fbdev console problem is too horrible to pretend to solve by resyncing
} on timer interrupts. At least for the x86 the fix is to sort out the fb
} locking properly
How close is that?
On 28 Feb 2001 23:37:40 +0000, Andrew Morton wrote:
> Eric Buddington wrote:
> >
> > I know this has been reported on the list recently, but I think I can
> > provide better detail. I'm running 2.4.2 with atyfb on a K6-2/266
> > running at 250. This system has no history of clock problems.
> >
> > adjtimex-1.12 --compare gives me "2nd diff" readings of -0.01 in quiescent
> > conditions.
> >
> > flipping consoles rapidly cboosts this number to -3 or -4.
> >
> > catting the full documentation to ntpd (seemed appropriate) gives me
> > "2nd diff" numbers a little over 34. If I read the numbers correctly,
> > 47 seconds of CMOS time passed while the system clock only passed 13
> > seconds.
> >
> > The processor and the CMOS clock were moving at zero velocity relative
> > to each other, and were both in normal Earth gravity.
>
> The kernel blocks interrupts during console output. fbdev
> consoles are slow. Net result: many lost timer interrupts.
>
> I'm working on it. Slowly. Should have something next week.
You may want to check out the linuxconsole project on Sourceforge. I
believe one of their goals is to remove/minimize the console lock...
Brad Douglas
[email protected]
http://www.linux-fbdev.org
> } The fbdev console problem is too horrible to pretend to solve by resyncing
> } on timer interrupts. At least for the x86 the fix is to sort out the fb
> } locking properly
>
> How close is that?
Its not in itself a big problem, but since it doesnt reformat your hard disk,
explode randomly or drop you off the network its not at the top of my priority
list right now
> We have the same trouble on PPC but we make sure to re-sync on each
> interrupt. We can see several lost timer interrupts after a ^L in emacs
> running on the fb console. The resync lets us catch up on those interrupts
> (and not lose time) but we still spend a lot of time not servicing
> interrupts.
> Does x86 not resync on timer interrupts?
The fbdev console problem is too horrible to pretend to solve by resyncing
on timer interrupts. At least for the x86 the fix is to sort out the fb
locking properly
} > } The fbdev console problem is too horrible to pretend to solve by resyncing
} > } on timer interrupts. At least for the x86 the fix is to sort out the fb
} > } locking properly
} >
} > How close is that?
}
} Its not in itself a big problem, but since it doesnt reformat your hard disk,
} explode randomly or drop you off the network its not at the top of my priority
} list right now
I'll stick with the pretend fix that results in accurate time-keeping,
then.
Thanks for the info.