TSC timekeeping and cpu states

[Ian Smith]

On Mon, 14 Aug 2017 17:16:22 +1000, Aristedes Maniatis wrote:

 > On 14/8/17 3:08PM, Kevin Oberman wrote:
 > > Again, the documentation lags reality. The default was changed for 
 > > 11.0. It is still conservative. In ALMOST all cases, Cmax will yield 
 > > the bast results. However, on large systems with many cores, Cmax 
 > > will trigger very poor results, so the default is C2, just to be 
 > > safe.

Given it's a server, anything beyond C2 is likely not worth trying. 
OTOH, C2 is perhaps not worth avoiding; it's probably low latency and 
should result in lower power consumption, so heat, and unlikely to hurt.

Or at least, I suspect that's the case .. cc'ing Alexander, as the wiki 
article you referenced was his doing, so he's among those best placed.

 > > As far as possible TSC impact, I think older processors had TSC
 > > issues when not all cores ran with the same clock speed. That said,
 > > I am not remotely expert on such issues, so don't take this too 
 > > seriously.

I wasn't aware that FreeBSD could yet do different freqs on different 
cores?  But I'm less expert than Kevin, and certainly behind the times.

 > Thanks Kevin
 > 
 > What does 'large' and 'many cores' mean here? Is 24 cores large or 
 > small? For a server do we ever want the CPU to enter states other 
 > than C1?

If C2 works well on your box, I don't see why you wouldn't want to use 
it .. but others might.  I have no personal experience beyond 2 cores, 
but I'm perennially curious about such issues, as Kevin knows :)

Are you using powerd?  And what says, for example:

 sysctl -a | egrep 'cx|available|_freq|freq_|choice' | grep -v net\.

which should include your timecounter and eventtimer setup too.

cheers, Ian