timecounter, sleeps and GCE f1-micro instances

[Paul Ripke <stix%stix.id.au@localhost>]

I kicked up a Google Compute Engine f1-micro instance with
NetBSD 8.99.36, and noticed the clock losing time badly early on.
Searching around, I found that switching timecounter to ACPI-Safe fixed
this behaviour. However, the f1-micro instances throttle to 0.2 of a CPU
after a short burst period, leading to interesting timing behaviour.

Any known solution?

After kicking up some articifical CPU load: 

ksh$ perl -e 'while(1){}' &
[1] 25407
ksh$ perl -e 'while(1){}' &
[2] 22039

I tried various timecounter sources:

ksh$ sudo sysctl -w kern.timecounter.hardware=TSC
kern.timecounter.hardware: ACPI-Safe -> TSC
ksh$ time sleep 5
   20.76s real     0.00s user     0.00s system

TSC: loses time, ntp fails to sync well. "sleep 5" sleeps about 20s.

ksh$ sudo sysctl -w kern.timecounter.hardware=clockinterrupt
kern.timecounter.hardware: TSC -> clockinterrupt
ksh$ time sleep 5
    5.01s real     0.00s user     0.00s system

clockinterrupt: time proceeds at about 1s per 4s. "sleep 5" sleeps about 20s.

ksh$ sudo sysctl -w kern.timecounter.hardware=ACPI-Safe
kern.timecounter.hardware: clockinterrupt -> ACPI-Safe
ksh$ time sleep 5
   20.75s real     0.00s user     0.01s system

ACPI-Safe: ntp syncs fine, clock maintains time, but "sleep 5" sleeps about 20s.

ksh$ sudo sysctl -w kern.timecounter.hardware=lapic
kern.timecounter.hardware: ACPI-Safe -> lapic
ksh$ time sleep 5
    5.01s real     0.00s user     0.00s system

lapic: similar to clockinterrupt.

ksh$ sudo sysctl -w kern.timecounter.hardware=i8254
kern.timecounter.hardware: lapic -> i8254
ksh$ time sleep 5
    7.08s real     0.00s user     0.00s system

i8254: somewhat similar to clockinterrupt?

-- 
Paul Ripke
"Great minds discuss ideas, average minds discuss events, small minds
 discuss people."
-- Disputed: Often attributed to Eleanor Roosevelt. 1948.