Re: TSC Timecounter and multi-core/SMP

In message <200804181235.29530.doconnor_at_gsoft.com.au>, "Daniel O'Connor" writes
:
>> You'd think that an invariant sync'd clock (fast to read) [...]
>
>Probably because it's very very difficult to get right :)	

Actually, I think people miss a number of points here.

One is that timekeeping, scheduling and benchmarking has different
needs.

Timekeeping:
	By definition needs to be system global, and preferably
	cheap.  Rates above 100 MHz are pointless, because of the
	nature of the sort of bus-structures we have these days.
	A good 32 bit counter which can be read atomically, running
	at > 10 MHz is perfect for this purpose.  The ACPI timer
	is usually pretty perfect for this, apart from the cost of
	reading it, which is incredibly high.
	The ACPI-timer should be distributed to all cpu sockets to
	speed up access, and a hardware reset line, either shared
	with other purposes or a dedicated signal, should be used
	to synchronize them.

Scheduling
	Can, and should, be per core, and needs deadline interrupts.
	Access should be very cheap.  Resolution of approx 1µs is
	usually overkill due to the cost of context switch times.
	HPET gets this wrong in a number of ways.

Benchmarking
	Only needs to be per CPU, needs to be high resolution which
	makes it almost impossible to keep them perfectly in sync.
	If not in sync, they are very hard to use without kernel
	support unless threads a locked to CPU for measurement.
	TSC has too unpredictable properties to be used without
	a lot of chip-type conditional code.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk_at_FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.