Hardware timer per thread?

[thewrongchristian]

So, to avoid an O(n) insert time, you want the ISR to do an O(n) search of outstanding timers looking for expired timers?

Yes, it is an O(n) search but I think it could be done extremely fast. 1024 timers could be represented by 32 32-bit timeout status flags. It is just a matter of searching 32 regs for a non-zero status indicating a timer timed out. It may also be possible to have hardware accelerate the bit search, so it would just be a loop for how many ever timers expired.

Hardware timers just fire an interrupt to indicate they've expired, they don't set arbitrary bits in memory to indicate expiration.

That is the job of your ISR.

Another possibility may be to have a separate interrupt ISR for each timer. Then there would be no need to search. But that is a lot of ISRs.

What hardware are you targeting? I'm not aware of any platform with an arbitrary number of independent hardware timers.

Nor a platform that has an arbitrary number of interrupt lines.

More typically, the platform will provide A timer of some description. This may be all you get, or you may get a per-CPU timer instead of or as well, such as the timer built into the local APIC of each x86 core.

But hardware timers are a very limited resource, and have to be multiplexed to support an arbitrary number of software timers.

And that multiplexing requires some sort of queue on which timers sit waiting to expire.

And that queue should be sorted by expiration deadline, to make it quick and easy to bound the search to just those timers that have expired.

[Gigasoft]

If you'd read the actual question you'd see that he is the one designing the hardware, so it can do anything he pleases.

[rdos]

If you'd read the actual question you'd see that he is the one designing the hardware, so it can do anything he pleases.

Only if his hardware design is in sync with his software. After all, he can only implement a fixed number of timers, and then his software will need to live with that fixed limit or use more standard approaches like lists of timers.

[robfinch]

I am considering doing both listed and unlisted timers. Multiplexing the timers in hardware reduces their resolution. It may be necessary to split timers up into groups depending on their resolution or time base. One high precision timer per CPU, and many lower precision ones. The high-res timers need to be 48-bits or more or they cannot time long intervals. Lower res timers can have fewer bits in them because they are effectively pre-scaled. I put 256 lower-res timers in my system using two timers “overloaded” 128 times. Driven by a 200MHz clock that gives them about 640 ns resolution.

There would be a limit on the number of timers, or a list could be used. But I checked on my desktop and it reported 160 active timers. I think a number like 256 may be enough.
Currently the timer ISR (excluding the system tick timer) looks something like:

Code: Select all

 void FMTK_AlarmISR(__reg("d0") long ndx)
{
	MBX* mbx;
	hMBX h;
	
	PIT[ndx].iack = 1;
	h = PIT[ndx].hMbx;
	if (h > 0 && h <= NR_MBX) {
		mbx = MBXHandleToPointer(h);
		if (mbx->owner==GetRunningAppid())
			FMTK_PostMsg(h,0xffffffff,0xffffffff,0xffffffff);
//		else
//			Priv_Error();
	}
}

There is a little bit of assembler code for a launchpad that loads the timer index into d0. 256 small timer ISR’s in assembly language.

There may be better performance with the timer ISR not needing to traverse a list and manage timeout values. The ISR does not directly reschedule or perform context switching.

It may be desirable to run the timers on different time bases. I think timers not related by nice multiples of the clock frequency may be used to at least simulate more entropy.

[thewrongchristian]

If you'd read the actual question you'd see that he is the one designing the hardware, so it can do anything he pleases.

To quote the original post:

Contemplating the use of hardware timers. How many timers is enough? I think this can be done in hardware. If they had a pre-scaler they do not all have to operate in parallel. For instance, if pre-scaled by 32, 32 parallel hardware timers could be turned into 1024 timers using dedicated RAM to keep track of the counts and sequencing through the timers using the 32 pre-scaler counts. A larger pre-scale and more RAM would allow more timers. Would a timer per thread be enough?
Pre-scaling could affect the timer resolution, but would still allow high-resolution.

There is little indication there that new hardware is being designed. Just that he is contemplating the use of hardware timers, which could be existing hardware timers.

A basic hardware timer needs just a counter register, some means of decrementing the register, a comparator to detect when zero is hit, and a reliable clock source to drive it all at a known, steady rate. Very simple, and you can probably pack a lot of these timers into a small space.

Given that such hardware would presumably be interrupting a CPU, we'd still be limited to the how parallel the CPU can be (SMP, thread per core, assuming interrupts cycle between cores), so we may have 32 parallel timers, but unless you have 32 or more cores, there is no way you can process them all in parallel.

Basically, the number of hardware timers is not the bottleneck in how many timers you can have at any time. An arbitrary number of CPUs and thus threads are unlikely to overwhelm even a single high resolution timer.

If he is designing the hardware, then I'd still recommend a single timer and multiplexing that in software.