est

[Ian Smith]

On Fri, 13 Nov 2015 12:51:30 -0600, Adam Vande More wrote:
 > On Fri, Nov 13, 2015 at 11:33 AM, Ian Smith <smithi at nimnet.asn.au> wrote:
 > 
 > > There are parts of that article that don't ring true to me, not that I
 > > know anything about latest Xeons and how they handle Turbo mode.
 > 
 > TurboBoost is applicable to more than just Xeons.

Of course.  As mentioned, my Core2Duo has it, or at least an earlier 
implementation.  I expect it to have become more capable in more recent 
years, but as said, I don't know any details for more recent CPUs.

 > > I do
 > > know that FreeBSD never, so far, runs different cores at any different
 > > frequencies,
 > 
 > FreeBSD has supported TurboBoost for years.

Of course.  But we do NOT support setting different CPU frequencies on 
different cores.  TurboBoost may clock selected cores up to turbo speed, 
internally determined by microcode, but that has nothing to do with the 
clock speed FreeBSD sets for ALL CPUs, except that the highest (XX01) 
setting is what _enables_ turboboost, and then for ALL cores.

Quoting from the referenced article in question:
https://www.ateamsystems.com/tech-blog/increase-freebsd-performance-with-powerd/

 : SpeedStep is the selective and rapid slowing down, idling and 
 : possibly even sleeping of cores which are not being used or used 
 : much. This increases the power and thermal windows for TurboBoost to 
 : work effectively as slowing down/idling little-used cores means more 
 : thermal dissipation and power to boost busy cores with. Much like 
 : HyperThreading, windows of opportunity quickly close and open, and 
 : the CPU and OS work in rapid conjunction to calculate and exploit 
 : them. TurboBoost will not engage if SpeedStep information is not 
 : being received from the OS, so it is crucial to enable the powerd(8) 
 : service and ensure that SpeedStep is performing properly.

Do I need to detail the several incorrect assumptions at play above, 
regarding FreeBSD's role in interacting with the CPU/s re TurboBoost in 
particular and SpeedStep in general?

 > I don't know what you've done to disable a generally useful feature, 
 > but I suggest re-enabling it on your systems if you want better 
 > single core performance.

If you read my post you'd know precisely what I'd done to disable the
feature that proves less than useful on my particular CPU, running both 
hotter and (marginally) SLOWER on repeatedly timed single-core tasks, 
and considerably hotter on longer multi-core tasks like -j buildworld.

Don't take my word for it .. please read: 
http://lists.freebsd.org/pipermail/freebsd-mobile/2015-February/013240.html 
then feel free to argue with Warner about advice that worked for me :)

The first sentence you quoted above, and others in my post, were meant 
to inform and invite discussion, not score points.  I tried making clear 
that other, more recent CPUs may provide different outcomes.  Some real 
results from proper testing on various hardware would be most welcome.

cheers, Ian