Re: PSA: Clock drift and pkgin

For what it's worth, I think these lines also suggest something is wrong 
with the clock (this run under simh, simulating a VAX8650):

[  91.2854336] WARNING: lwp 854 (sh): negative runtime: (-1 + 
0xfee8c21d5277ae5a/2^64) sec
[  91.2854336] WARNING: pid 854 (sh): negative runtime; monotonic clock 
has gone backwards

   Johnny

On 2023-12-15 23:25, Johnny Billquist wrote:
> On 2023-12-15 18:37, Maciej W. Rozycki wrote:
>> On Fri, 15 Dec 2023, Johnny Billquist wrote:
>>
>>> 983136 is pretty close to 1000000. However, without looking at the 
>>> code, isn't
>>> that the diagnostics timecounter? Now used for anything really 
>>> related to time
>>> keeping, but just for some other information, like sampling the state 
>>> of the
>>> cpu and so on?
>>
>>   It's just a free-running counter, as good as any.  The KA46 has no ICR.
> 
> Sortof. ICR and NICR are not required to exist. A machine is allowed to 
> have a subset implementation of ICCS, only capable of generating an 
> interrupt every 10 ms with no further control. Which is still the normal 
> clock used as a source for time in the OS, if I'm not completely confused.
> The code in clock.c always sets NICR to -10000, which basically means 
> that we are requesting it to interrupt every 10 ms. So in case the CPU 
> only have the ICCS subset, we will also be getting interrupts every 10 ms.
> 
> So that's the basic clock the system runs from. Oh, and I should maybe 
> mention that the VARM calls out that the precision of this clock is only 
> required to be to 0.01 % accuracy, so a drift of up to 8.64 seconds per 
> day are within specs. (VARM page 8-22, section 8.3.5 Interval Clock 
> Register).
> 
> More things while I'm at it: VAX_BTYP_46 is not using ICR to find the 
> current time, but instead have another function to work out time at some 
> higher precision. I haven't gone and chased through that bit.
> 
> What is perhaps worse is that if you have VAX_BTYP_48 we're not calling 
> tc_init() for any kind of clock, which seems broken.
> 
> So in the end, what we have is that for most machines, we're getting a 
> higher resolution clock based on ICR. We basically have the clock tick, 
> which gives something at 10 ms steps, and then we add in what ICR is at 
> the moment. For CPUs that don't have an ICR, the clock will just be at 
> the 10 ms resolution and that's it.
> With the exception of the VAX_BTYP_46, which uses another source, that is.
> 
> But disregarding that one for now, as I'm not going to dive down that 
> rabbit hole this moment. The vax_mfpr_get_counter() function seems 
> potentially broken. If getticks() returns a negative value, we seem to 
> be potentially getting into a weird condition where we only slowly are 
> moving forward from prev_hardclock, which isn't even initialized.
> 
> I need to think a bit more about that code, and maybe do some tests...
> 
>    Johnny
> 

-- 
Johnny Billquist                  || "I'm on a bus
                                   ||  on a psychedelic trip
email: [email protected]             ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol