How do timers work in simAVR?

[leptun]

How do the timers work in simAVR? Do they function just like in the real hardware by having their clock tied to the CPU's clock source? I'm asking this, since the way the timers+WDT behave looks a lot like they are tied to the host's clock, not actually to the simulated program.
I have a feeling (not sure how to test it) that when the simulation slows down because of many IRQs or something like that, the timers keep on ticking at the usual rate. This would explain why I get WDT resets with the Print from SD menu when it has to load a lot of data (when it has to find a file on the card by filename).

I'm also curious why the CPU seems to be overclocked all the time. Is it really clocking so fast or are the timers running faster than they should (aka, _millis()/_micros() tick too fast)? Maybe we could make a "TPS" (ticks/s) reading derived from the program counter so that we can see how fast the simulation is running at any time.

[vintagepc]

Jotting down some thoughts and observations on this so far:

I kinda poked at some of the timer stuff yesterday (but I need to do something simpler first... my brain is still melting after the dive into why avrdude-slic3r wasn't flashing things right.) I'll dig into this in more depth afterwards.(Holy crap, have I learned a lot about the hardware the last few weeks...)

I did some timing measurements which seem to suggest we're not horribly overclocked, with CPU ticks happening about every 40-50ish nanoseconds. (16MHz suggests once per 62 ns). so I think that it's a combination of things as the above would only explain being about 1/3 too fast, and not the very high values observed coming out of the timer for millis/micros.

Probably the place to start is timer2's overflows are ticking as expected, for the delay handling.

From what I've seen of the timers in general (and the wdt) they appear to register themselves for a number of AVR CPU cycles in the future, which is correct for the situation and should stay in sync when one cycle takes longer than expected due to excessive IRQ load, or if the simulation is overclocking.

I think the WDT issue is also partially compounded by #59.