Time is slow

[trasz]

With stock CheriBSD and Qemu, ystem time is mostly ok, except twice as slow as it should be:

# while :; do date; sleep 10; done                  
Thu Oct  5 13:06:40 UTC 2017                        
Thu Oct  5 13:06:50 UTC 2017
Thu Oct  5 13:07:00 UTC 2017
Thu Oct  5 13:07:11 UTC 2017
Thu Oct  5 13:07:21 UTC 2017
Thu Oct  5 13:07:31 UTC 2017
Thu Oct  5 13:07:41 UTC 2017
Thu Oct  5 13:07:51 UTC 2017

Each line takes exactly 20 seconds to display (as far as I've been able to measure it with a stopwatch).

[trasz]

(There is also what seems to be a separate issue, where time goes all over the place, along with "vmstat -i" showing the rate for clock0 to be around 700 instead of the usual 92, but it's harder to reproduce.)

[rmn30]

I seem to recall that on some MIPS processors the COUNT register increments at half the clock rate so perhaps there is confusion between FreeBSD timer tick driver and qemu about what the rate actually is... Robert

…

On 5 October 2017 at 15:58, Edward Tomasz Napierała < ***@***.***> wrote: (There is also what seems to be a separate issue, where time goes all over the place, along with "vmstat -i" showing the rate for clock0 to be around 700 instead of the usual 92, but it's harder to reproduce.) — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#54 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABWOpr0ITdg5NKX4xhGe3LfJHGEs3p2wks5spO6CgaJpZM4PvN56> .

[trasz]

That's what Robert mentioned to me as well. Still, I think it's good to have a ticket for tracking this particular issue until it's fixed.

[Jerryxia32]

The spec of our MIPS reference implementation says the count register should increment at half the issue width times the clock frequency, in this case 0.5 * clock freq, but the FPGA implementation increments the count register at the same frequency as the CPU clock. So unless the two implementations agree on each other or FreeBSD treats the two targets differently with respect to the clock, it is not easy to solve.

[davidchisnall]

Maybe FreeBSD startup code should read the count register, run 100 ssnops, read the count register, and see if the value is 50, or 100 more?

[rwatson]

Does Qemu actually pass through a host cycle count, or does it simply count instruction issues rather than having some other notion of cycle?

(Passing through host cycles might be a problem given the small scope of the MIPS cycle counter and the impact of host context switches -- and often ISA-level simulators simply report commit count/2 as the cycle count as a result. It would be good to confirm what Qemu does before drawing too many conclusions about remedies.)

[trasz]

According to http://www.cs.tau.ac.il/~afek/MipsInstructionSetReference.pdf, there's the CCRes returned by rdhwr, which defines how often the counter gets incremented. Judging by the code, Qemu seems to set it to 2, which means "CC register increments every second CPU cycle".

[trasz]

Should be fixed by CTSRD-CHERI/cheribsd@8b576af.

[arichardson]

It looks like this changed in b79c3d9

[trasz]

Good catch. Indeed, backing out b79c3d9 (and CTSRD-CHERI/cheribsd@8b576af) fixes the problem. It also fixes #55.

I have no idea why, though. There's something weird going on there; for some reason putting some CPU load on the guest results in timer interrupts firing faster, with and without that change.