Quickie #6: Nitecore MT06 and Thermal Throttling

I recently bought a Nitecore MT06 at my local retailer (i went in to get a Nitecore Tube, but bought both the Tube, and the MT06. The Nitecore MT06 is a great pen sized flashlight featuring a 165lm max light output.. but for how long before the thermal throttling feature starts?

The specs
the official ones

Benchmarking
The tools

To get an idea of the flashlight performance i needed a way to measure the Luminous intensity (cd). Having no professional tool for that i used the CT406 light sensor that is embedded in the Moto G first gen (XT1032) : the results won't be complying with the ANSI/NEMA FL1 standard but will be good enough to get our own idea of the flashlight performance.

Tools and Methods:

• Power source: 2*AAA Energizer Rechargeable NH12 (Brand New)
• Light sensor: CT406, giving results in illuminance in Lux(lx) turned into Luminous intensity via this formula:
  Iv(cd) = Ev(lx) × (d(m))^2
• Calculated light output in Lumens (lm) :
  lm = cd × ( 2π(1 - cos(apex angle in °/2)) )
• Calculated throw (beam distance in meters) :
  throw (lm) = sqrt(candela/0.25)

How to get the experimental light outpout?
As written above, the formula is the following : lm = cd × ( 2π(1 - cos(apex angle in °/2)) )
The measured apex angle is roughly 18° (result that we also can get using the advertised light output and the peak beam intensity [165lm, 2120cd ==> 18°])


EDIT: How to get the Surface temperature?
A simple crappy medical contact less thermometer (the Powerscan TH23F -that i recently got for 3€, and does not worth much more-) allows to measure the surface temperature of the flashlight body (with a maximum inaccuracy of about 1°C) , this does not give the real chip temp, but gives some interesting clues.

The experiment was carried out during 40 minutes. In three phases :

1. MT06 set to high, as long as it can (meaning until it was too hot to even touch and hold... the ON/OFF switch!
2. After a two minutes cool down (from really hot to warm), another period on high mode. untill it reaches the same heat trigger : human pain...
3. Sixteen minutes in low mode to see how consistent the light output is when regulated.

EDIT: A second experiment is now added : full run from max to 1lm, to show both thermal throttling and runtime

Results...

Measured vs Advertised specs (high mode):
The FL1 standard asks to wait for 30 to 120 seconds before measuring the peak beam intensity
The first result (max) is obtained right after turning ON the flashlight, the second (FL1) complies with the FL1 standard and is compared to the official specs.

	Advertised	Measured
Peak Beam Intensity (max)		2238 cd
Peak Beam Intensity (FL1)	2120 cd	2114-2135 cd
Light Output (max)		173 lm
Light Output (FL1)	165 lm	163-164 lm
Beam Distance (max)		94 m
Beam Distance (FL1)	92 m	92 m

Considering the inaccuracy of the angle measure and the use of a CT406 as light sensor, it seems that Nitecore claims are absolutely legit.

Measured vs Advertised specs (low mode):

	Advertised	Measured
Peak Beam Intensity (FL1)		422 cd
Light Output (FL1)	32 lm	32.5 lm
Beam Distance (FL1)		41 m

... and Thermal Throttling

Here is what Nitecore says on the MT06 user manual : "NOTE: The MT06 will begin adjusting output lumens automatically after 5 minutes of use, thus preventing overheating and extending battery life"
Let's see how much this is true and how long we can get the advertised 165lm!

Having nothing to measure the own flashlight temperature, an apparent temperature has been used instead (human felt temperature in a subjective range : room temp, warm, hot, and too hot)

• Phase One:
  • for 5 minutes is at about 165lm (as advertised) but heat is increasing quickly until no one would like to hold the flashlight any more... (green circle)
  • Then, Thermal throttling start and the driver limits the led to 145lm which is still acceptable, though temperature decrease, the flashlight is still to hot to be comfortable to hold for a long time! (red circle)
  • Nitecore advertises 165lm, 45 minutes of life time with two 1.2V 750mAh batteries, this mean that roughly 1A of current is flooding through the flashlight. Considering that a LED turns about 20% of energy to light, it means that 80% is turned into heat... so here the flashlight needs to dissipate about 2W of pure heat with its small aluminum boddy.
• Short period of cool down (from minute 10 to 12)
• Phase Two: This time the flashlight starts throttling less than one minutes after lighting up (not cooled enough during the 2 minutes stop period)
• Longer period of cool down : about 4 minutes
• Phase Three : Low mode, not much to say about it... It works without thermal throttling -hey, the heat to dissipate is only about 0.25W!-

EDIT: I made another benchmark with Surface temperature measurements:
This time, i made a full run from full batteries -at max output (aka 165lm mode)- until getting as low as 1lm of output (after 41 minutes of runtime)

Here we can see 4 phases

1. Phase 0, the flashlight is turned ON and gives maximum output until thermal throttling strikes (when reaching a surface temp of about 50°C)
2. Phase 1, thermal throttling shows up, and reduces the max output to limit heat dissipation, light output is really stable, but temperature rises slowly until reaching about 58°C
3. Phase 2, thermal throttling gets a little more aggressive, lowering output to stop heat from rising more than 58°C, temperature is maintained this way for about 2 more minutes
4. Phase 3, End of game: Batteries are dying and simply cannot supply enough current to maintain the light output, so it decreases - and so does surface temperature-

Conclusion

Don't expect to get 165lm for more than 5 minutes when the flashlight is starting at room temperature (but before thermal throttling start your hand won't feel good with that little heater after 3 mins...)
Nevertheless, this little flashlight performs great at low mode (high enough for what it's made for) and provides 165lm if needed, for short times (thanks to thermal throttling you won't get heat burn...).

Keep in mind that the MT06 is not meant to be a tactical kubotan but more to "provide great assistance to engineers, mechanical and medical personnel" (quoting Nitecore). for the late group (medical personnel, this flashlight lacks a firefly/moonloght mode (0.3lm - 3lm) that could be used to perform Pupillary light reflex without blinding the patient...)

Note that although i couldn't see PWM in low mode, i could hear a very little noise (near to ultrasound) that appears both in low mode, and during thermal throttling. Don't worry this sound can only be heard with the pen light close to the hear -i never noticed anything like this on my Fenix LD12.

Quickie#4 CM12.1 vs Exodus ROM: CPU/GPU

After Pure SQLite databases transactions performances, it is time to have a look at CPU/GPU pure performances (meaning benchmarking, not real-life ...)

CPU
RgbenchMM

both ROMs were tested on RgbenchMM (4 threads):

On this Benchmark, CM12.1 is slightly ahead in performances (this has no real-life impact though)

GPU: 2D
fps2D

For 2D graphics, i use fps2D, and old app that is quite great for the purpose (an keeping it helps looking back in the ages and see progression.

No, there is absolutely NO single difference regarding 2D performances. a 0.1 fps difference with a standard deviation of 10fps is not significant at all!

GPU: 3D
GPUbench

Looking at average fps performance on this benchmark shows less than 1 fps difference between the two ROMs. lowest and highest are much more variable (look at stdev!) and thus cannot be compared.

What about the score?

Looks like CM12.1 gets some higher scores here? Right, but mainly because the Benchmark didn't recognized the same screen resolution (although both are set to 320dpi [default]) ==> normalized scores are similar. This might need further investigations.

Conclusion
regarding CPU/GPU

• Contrary to the huge performance increase in SQLite (up to 900%!!) CPU/GPU performances are not better (even a little behind? not sure we can say that) on Exodus compared to CM12.1
• So after hours of benchmarking, i couldn't show Exodus superiority here. So for people wanting a pure CM experience there is no point switching to Exodus of Falcons (XT1032 at least.) to burst CPU/GPU Benchmarks.
• Nevertheless, those ROMs are pretty similar but Exodus features lots of things CM12.1 doesn't which is not something to throw out!
• Later we will try to see if various other points of comparison can (or not?) differenciate Exodus from CM12.1.
  But are we really searching overkill performances in Exodus on Falcon? I personally don't. CM12.1 is a great stable base that gave me all i wanted for a while (Features and performance wise).
  What i searched for in Exodus is not extra performances, but extra features (Pie, navigation bar customs, bottom right clear-recent, ...)

Quickie#3 CM12.1 vs Exodus ROM : SQLite performance

Having two devices with similar hardware helps a lot for "real-time" comparisons of different ROM at a given time. Here we are comparing CM12.1 (20151012 nightly) with Exodus ROM (based on 12.1 ... 20151012) regarding SQLite databases performances, this is not like a full ROM versus, simply a comparison on a very specific point.

The devices
Similar Hardware ? yes, and no...

The two devices are both XT1032, with pretty similar hardware, but with some differences regarding memory :

*	Device 1	Device 2
ROM	CM12.1	Exodus
eMMC	8GB Sandisk	16GB Toshiba
/data file system	F2FS	F2FS
DRAM	1024MB Samsung S4	1024MB Hynix S4

(does this adds a significant bias? hmmm maybe, but it won't explain the gigantic differences seen later)

Benchmarking
AndroBench 4.1

Here i am testing pure SQLite performances with AndroBench 4.1 on both devices using BFQ scheduler (default CM and Exodus I/O scheduler since quite a while)-results in Transactions Per Seconds (TPS)-

	Exodus-BFQ		CM12-BFQ
	average	stdev	average	stdev
SQLite Insert	1241,40	21,19	116,22	4,48
SQLite Update	632,82	12,41	107,78	2,82
SQLite Delete	952,57	16,57	118,21	5,81

Looks like there's quite a big difference... isn't it?
In day to day usage i don't feel much gap between those two ROMs, but this specific benchmark shows that Exodus had more in-depth optimizations regarding SQLite database operations

Discussing bias:

• Memory brand is different, your results are messed up: No, in fact other devices (aka Moto E 1st gen [XT1022, eMMC: Hynix, DRAM 1024MB Hynix S4, Snapdragon200] or MotoG 2d gen) show similar results on CM12.1 (or even lower for the MotoE). So even if the brand may have a little impact on performance, it won't explain the 10^1 between results.
• As Processing unit has a fairly big impact on I/O performances, both devices are featuring a Snapdragon 400 @1.2GHz, Interactive governor, MP decision enabled.
• Is choosing BFQ as scheduler impacts results? and why choosing it? BFQ is the default scheduler for both CM12.1 and Exodus, for this simple reason there is no point testing another in first-line. Plus it could be interesting to see if the optimizations have been directly applied to this specific scheduler or if they are more system-wide. On previous tests i couldn't show any difference in performance between BFQ and Fiops regarding SQLite Update or Delete operations.
• SQLite databases are not reflecting real-life performance though, so this only shows a very little part of everything -but should make benchmarks addicts happy ;-) -

Quick review: 32GB PNY Micro Metal Attaché USB Flash drive

Today, i was thinking to get a new small USB flash drive to keep in my pocket, my choice went for the PNY 32GB USB-2.0 Micro Metal Attaché: P-FDI32G/APPMT2-GE

Why choosing a 2.0 flash drive?
... When 3.0/3.1gen1 are available and 3.1gen2 will come soon...

• Price : 19€ for 32GB
• My laptop is from 2011, it doesn't feature any 3.0 host...
• I already have an EMTEC 16GB USB 3.0 flashdrive when i need high speed on compatible computers
• Will USB type-C flash drives come soon??

Form factor and characteristics

• Size: 18 x 12 x 7mm, 5g, this is quite small and light, perfect for my needs here; it is quite smaller than my little 16GB EMTEC of the above picture
  
• Reliability :
  • 2 years warranty, Data retention: 10 years.
  • Write/erase cycles: 10,000 minimum.
  • It doesn't look rock solid (the metal part is really thin), really looks cheaper than the LaCie 16GB Key.
  But something interesting is written on the back of the box:
  
• Speed (theoretical):
  • Write Speed: up to 8MB/s
  • Read Speed: up to 25MB/s
• Speed (real-life): With 10MB files (the benchmark default value), we get 18.2MB for Read speed, and 4.5MB/s for Write speed, far below the theoretical values... !
  
  
  
  With 100MB files, we get some better results R:21.9MB/s, W:9.7MB/s:
  
  
  
  With 1GB files (only 10 tests, not to spend the whole day waiting...)R:22.4MB/s, W:11.4MB/s:
  
  
  
  Let's see how it behaves with small files :
  With 1MB files R:17.8MB/s, W:566.3kB/s:
  
  
  
  With 4MB files (approximate size of a song or a 12MPx picture):
  
  
  
  
  
  
  So, we can see that small size file are pushing the flash drive to its limits, resulting in very low speed (566kB/s!!!); Storing larger files shows better results (as good as the theoretical speed announced by the brand)
  

Conclusion
Pros ... and Cons

• + Nice size and weight
• + doesn't protude much from the computer USB host
• + Average speed is OK for medium and large files
• - Extremely low speed for small files, cannot be really used as a liveUSB medium (my USB3.0 EMTEC 16GB gets R:35MB/s W:10MB/s with 10MB files on a 2.0 host!)
• - Not very tough construction, might not survive for years?

Moto G and Moto E : snapdragon 400 vs 200 Round2

A while ago we discussed about S200 vs S400 using the Old CPU Benchmark tool called "Linpack For Android", an app that had not been updated since ages. It was convenient for one reason : no update = no artificial MFLOPS increase due to app optimization ... but with CM11,12 and 12.1 i noticed huge performance drops in Linpack whereas i didn't feel any. It was time to try something else

Linpack for Android
A dead Benchmark app...

Linpack vs RgbenchMM on MotoE and MotoG:

RgbenchMM	1190MHz
	Moto E (S200)	Moto G (S400)
1	270	290
2	611	641
4	587	1280

Linpack	1190MHz
	Moto E (S200)	Moto G (S400)
Single	79	55
Multi	145	150
Per Core	72,5	50

Why is there so much disparity? the way the app make the CPU work and the way the workload has been set are different and so are results.
2 disparities :

• In Linpack Single Core results for MotoE (S200, stock rooted KK) and MotoG (S400, CM12.1) are not similar although they should regarding the Core frequency and the similar architecture. (results Are similar with RgbenchMM)
• MultiThread results are strange on Linpack : How a QuadCore CPU couldn't perform better than a DualCore one??
  • Linpack cannot handle more than 3 Threads
  • MotoG with CM12.1 starts with about 20% less MFLOPS with one core, and that is still the case in the multithreaded run... Not expected

Let's see how RgbenchMM performs in similar situation!

RgbenchMM
A Great CPU Benchmark app!

What do we see here?

• Results for RgbenchMM are similar with MotoE and MotoG for single and dual threading benchmarks : this is expected in the way S200 and S400 are clocked at the same frequency.
• 4 Threads run give more than 4 times the score of Single Thread one with the QuadCore S400
• Results are strictly linear to the number of cores for S400 (r²=0.97, which is pretty good for Benchmarks results)
• 4 threads benchmarking is only suitable for MotoG (the S400 is a quad-core) and gives inconsistent results with S200 (only dual-core, so 4 threads handled by 2 cores cannot give good results)
• Little lower results with MotoE could be explained since the S200 has its 2 cores shared between Benchmark and System, whereas MotoG (S400) has still 3 and 2 cores left to handle system processes during single and dual threads (although 4 threads run is strictly twice higher than 2 threads ... so even with all the cores used S400 MFLOPS/Core results are better than S200?)

• On both devices, MFLOPS/Core results are slightly better in Dual Thread run and Single Thread one

RgbenchMM dev explains the following:

it does about 6 loads and 8 multiply-accumalates (or 16 flops) inside the loop. The load instructions (FLDD) are also VFP instructions as are the FMACD instructions. Thus, the benchmark is testing the VFP performance almost exclusively. One other detail about the code is that the threads are setup so that ideally they are reading the same columns of one of the input matrices. This will be beneficial on architectures with at least 1 level of shared cache and thus you may see more than 2x speedup on a dual-core processor.

• The Extremely lower MFLOPS/Core result for 4 threads run on the DualCore S200 shows how it would handle hard multitasking.

Is the Conclusion changed?
Compared to the previous S200 vs s400 article

• Does Changing the Benchmark app modifies the conclusion about the S200 vs S400 comparison? No, i doesn't
• Does it changes the "Pure CPU benchmarks: the limits" article conclusion? Not exactly, in fact the results can't be compared since my MotoG was running CM11 at that time, but it could explain the high gap between CM11 and stock KK : it was more a Linpack bias than a ROM issue, i'll be able to test Stock ROM on a S400 soon, then the final conclusion will come.

Lower CAS latency on a legacy Computer: Is it worth it?

Some Story background

With time going on, i got enough DDR2 modules to play a little with them.
An old question was how CAS latency is important and impacts performace on a legacy computer (with a CPU that doesn't feature any L3 cache)

Clock and CAS Latency
Modules used:

Name	PC2-	Frequency (MHz)	CAS latency	Size (MB) per module
Nanya NT2GT64U8HD0BY-AD	6400	800	6-6-6-18	2048
Corsair Value Select VS2GB800D2	6400	800	5-5-5-18	2048
Gskill Extrem2 PC6400PK	6400	800	4-4-4-12	1024
Gskill Extrem2 PC6400HZ	6400	800	4-4-4-12	512
Hynix HYMP564U64BP8-C4 AB-T	4200	533	4-4-4-12	512
Micron MT8HTF6464AY-53EB3	4200	533	4-4-4-12	512

only the green modules will be compared in this article, we'll play with the others later on.

Testing Conditions
Hardware & Software

CPU : AMD Athlon X2 64 5600+ (@2.9GHz)
MotherBoard:  Gigabyte GA-M61PME-S2P
RAM : Tested Criteria
GPU : Geforce 8400GS
HDD : Seagate Barracuda 7200.8 250 GB (7200rpm)
CD/DVD :  writer
Floppy

The Software used is nothing complicated: Memtest86 v4.20

Results
Single and Dual Channel CAS battle (DDR800)

Both Modules are 2GB DDR800 (PC2-6400), the only discriminating criteria is the Cas Latency : CL5 (5-5-5-18) vs CL6 (6-6-6-18)
Signle Channel (1*2GB) and Dual-Channel (2*2GB) results are the following:

• SC-5-5-5-18: 2369MB/s
• SC-6-6-6-18: 2252MB/s
• DC-5-5-5-18: 2861MB/s
• DC-6-6-6-18: 2643MB/s

Upgrading from ↓ to →	Single Channel 5-5-5-18	Dual Channel 5-5-5-18
Single Channel 6-6-6-18	+5 %
Dual Channel 6-6-6-18		+8 %

There is definitely a performance increase in pure RAM bandwidth, though this has barely any impact on real life work on a legacy PC.
NB: i also tried to mix the Corsair (5-5-5-18) and Nanya (6-6-6-18) modules, the motherboard set them to dual channel even though the chips are quite differents... and gave the following result:
It down-clocked the RAM to 667MHz (351MHz), and reduced latency to 5-5-5-15; for a 2410MB/s bandwidth.

MotoG : Pure CPU Benchmarks, the limits

To point out pure CPU Benchmark flaws, we'll observe how does a moto G (Falcon or Peregrine, this has no relevance) behaves with Linpack Benchmark when running on Stock 4.4.4 Motorola ROM or CM11-20141124-nightly (4.4.4).

We have seen previously that Linpack didn't use all cores and was limited to 3 threads in multi-thread benchmarking (when comparing s200 and s400 SoC).

Now, we will compare MFLOPS performance between two ROMs that has similar user experience (smoothness mostly)

Stock 4.4.4 Motorola ROM vs CM11

both @1190MHz, Interactive governor.

Stock Motorola features a nearly doubled score for both Single and Multi-Thread, but does that mean it is really better optimized?

• In a way, yes, CM11 is made to be compatible with most devices, so we encounter similar problem seen with Windows against iOS : 
• An OS that fits all against a fully optimized one made for a few specific hardware. Motorola obviously optimized their software to get the best of this great device
• If you compare with the MotoG vs MotoE test, you'll see that the MotoG running CM11 has lower results than MotoE running stock ROM ...

• On the other hand, that's not all a matter of optimization :
• CM11 features KSM, zRAM, and many things that use CPU cycles to compress memory (zRAM) or merging merge-able things (KSM) ==> this reduces CPU pure performance but increase multi-tasking ability.
• The war of versatility and customization against slickness and stability...
• Honestly i can't see difference in user-felt performances...

Actually, i don't see any issues by using CM11 as a daily driver on my XT1032 (Falcon), it is not because a Benchmark say something that it is true in "real life"...

• Don't use CM11 on Moto G if you want to show off with high CPU benchmark results ...
• Stock Motorola ROM is close enough to AOSP to be acceptable as daily driver
• Xposed helps you to get the best of stock ROM
• CM11 is great for end-user customization

The real conclusion is the following :

Don't trust Benchmarks as incontestable truth, they helps to compare devices and  ROMs, but never really tell you how good devices/ROMs are.

Moto G and Moto E : snapdragon 400 vs 200

Snapdragon 400 vs Snapdragon 200 based on msm8926/8226 vs msm8610

After we studied MFLOPS per MHz ...

It is now time to compare MotoE and MotoG:

Moto G and E features a Snapdragon 400 and 200 (respectively a Quad-core Cortex A7 @1.19GHz and a Dual-core Cortex A7 @1.19GHz)

Note that previous benchmarks were performed with ONDEMAND governor on CyangenMod11 ROM, but stock Moto ROM uses Interactive by default (i didn't expected that...) so the following has been made with interactive for both devices (needed to re-bench MotoG >_<)

to check above results are applicable despite governor modification : 

MFLOPS per governor on MotoG (Falcon, CM11) @1190MHz

No significant difference between ONDEMAND and Interactive governors for the specified test.

Moto G (Peregrine) vs Moto E (Condor) msm8926 vs msm8610

To improve accuracy, instead of using my Falcon (XT1032) running CM11, we will compare results obtained on a Peregrine (XT1039) running Stock Motorola ROM :

Both Benchmarks have been run on Motorola Stock 4.4.4 ROM on Moto G (Peregrine) and Moto E (Condor):

There is no differences between msm8226 (Falcon) and msm8926 (Peregrine) despite LTE capability of msm8926, that's why we will use a Peregrine for the following part.

MotoG (Peregrine) vs MotoE (Condor) @1190MHz, stock 4.4.4

We have quite similar results on Single Thread application for one simple reason, the number of cores does not have any impact. Since the clock speed is the same, the results are the one expected.

On Multi-thread the difference is quite huge between the quad-core and the dual-core, though we don't see a x2 ratio by doubling the cores number.

MFLOPS divided per the amount of cores

x/4 for msm8926 and x/2 for msm8610, Single Thread as control.

We should have observed a similar result between Single and Multi/nbCore...
Is the msm8926 really shitty at multithreading? i don't think so, looks more like if linpack or the system only uses 3 Threads...

If we apply a corrective divider (3 instead of 4) the results are perfect :

MFLOPS divided per the amount of threads used

x/3 for msm8926 and x/2 for msm8610, Single Thread as control.

Moto E (Condor) and Moto G (Peregrine or Falcon) should have similar performance in single threaded applications.

Though the 4 Cores may no be used at their full potential in some apps, multi-threaded applications should be better handled by the msm8926/8226 featured by moto G.

Moto G? or Moto E? Which one for What...

For moderate usage, Moto E is quite enough compared to Moto G : 

• It is not weaker on Single Threaded applications
• It has a smaller battery but both smaller CPU and half size Screen in pixels (960*540 vs 1280*720) will give it a great battery life.

Moto G is still the best quality/price in its category (prefer the Peregrine version and not the Moto G 2014 aka Titan)

• Multi-threaded applications will obviously run better on it
• The better Screen density improves user experience on long term usage
• A far better Camera...

A complete Moto G - Moto E versus is available on versus.com (note that Moto G Peregrine does not have 16GB of internal memory ... but only 8, and an SDcard slot.)

CPU Freq and Performances : Single and Multi Thread

Linpack Benchmarking for Moto G, Single and Multi-Threads...

Before we compare Moto G and E Snapdragon 400 and 200 (respectively a Quad-core Cortex A7 @1.19GHz and a Dual-core Cortex A7 @1.19GHz), let's see how the Moto G performs with ONDEMAND governor and increasing CPU Clock.

MFLOPS and CPU Clock speed On Moto G XT1032 aka Falcon, CM11

A MotoG XT1032, running CM11-20141124-NIGHTLY has been used for MFLOPS per MHz tests.

The CPU is downclocked at 787MHz, and then frequency is raised up to nominal Frequency that is 1190MHz. Here are Single and Multi-Thread MFLOPS results.

You can note that 998MHz had inconsistent results due to high standard deviation...

MFLOPS/MHz A closer look to the results

Multi-thread results raise quicker than Single Thread, let's explore this closer :

As we can see, 

• MFLOPS/MHz ratio does not increase much for Single Thread, but,
• For Multi-thread the ratio increases between 787 and 998MHz but then stagnates : This means that MFLOPS increases in a linear way as Frequency is raised.

This can be explained by the following fact : 

The OS needs some CPU cycles to stay ON, so under a certain frequency it conflicts with Linpack work and decreases performances more than expected.

Conclusion? As a conclusion, we can say that CPU clock increase is more effective on multi-threaded applications (in a quite linear manner) than on Single threaded ones.

Intel : Pentium CPUs through time

Here is a story of Intel Pentium processors (desktop), based on the ones i own :

Pentium CPUs were first launched in 1993 (P5 @60MHz), but the following will start in 1995 with a P54CS @133MHz :

A large part of this collection was possible thanks to "donations" from friends that gave me their old hardware.

Pentium: A80502 @133MHz (released on June 1995)

• Codenames : P54CS, A80502
• Process size : 0.31µm
• Nb of transistors : 3.3 millions
• Socket : 7
• TDP : 12 W

Pentium II:  80522 @233MHz (released on May 1997)

• Codenames : Klamath, 80522 
• Process size : 0.35µm
• Nb of transistors : 7.5 millions [source]
• Socket : Slot 1
• TDP : 35 W [source]

Pentium!!!: 80526 @733MHz (released in 2000)

• Codenames : Coppermine, 80526
• Process size : 0.18µm
• Nb of transistors : 28 millions
• Socket : 370
• TDP : 23W

Pentium 4: 80531 @1700MHz (released on August 2001 [source])

• Codenames : Willamette, 80531
• Process size : 0.18µm
• Nb of transistors : 42 millions
• Socket : 478h
• TDP : 64W

Pentium D: 820 @2800MHz (released on May 2005)

• Codenames : Smithfield, 820
• Process size : 90nm
• Nb of transistors : 230 millions
• Socket : 755
• TDP : 95W [source] or 130W [source]

The Family:

Some Charts: 

Clock and TDP between 1995 and 2005 
The Core i3-3220 is there as a "modern reference" that shows TDP didn't continued to increase with clock speed : Modern CPU are more and more efficient.

With time, Clock speed and TDP increased : respectively from 133MHz to 2.8GHz and from 12W to 95W. Fortunately, this scheme has stopped and TDP is decreasing back (for Intel CPUs at least) while a few MHz are added with each new generation.

And what about AMD?

I cannot make a similar story with AMD CPUs yet: the time range isn't large enough (2001-2006): 

Desktop: 

• AMD Athlon 64 3000+ (ADA3000AEP4AX) @2GHz, socket 754
• AMD Athlon 64 3400+ (ADA3400DAA4BZ) @2.2GHz, socket 939
• AMD Athlon 64 3500+ (ADA3500IAA4CW) @2.2GHz, socket AM2
• AMD Sempron 2800+ (SDA2800IAA2CN) @1.6GHz, socket AM2
• AMD Athlon X2 64 3800+ (ADA3800IAA5CU) @2.0GHz, socket AM2
• AMD Athlon X2 64 4200+ (ADO4200IAA5CU) @2.2GHz, socket AM2
• AMD Athlon X2 64 5600+ (ADO5600DOBOX) @2.9GHz, socket AM2

Mobile: 

• AMD Athlon XP-M 1500+ (AXMH1500FQQ3C) @1.3GHz, socket A (462)
• AMD Turion 64 MT (TMSMT34BQX5LD) @1.8GHz, socket 753
• AMD Athlon XP 2800+ (AXDA2800DKV4D) @2.1HGz, socket A (462)

Credits:

Thanks to Ark, CPUworld, TechPowerUp, and Wikipedia that helped me to get all the documentation needed to set up this article.