(no commit message) master
authordillon <dillon@web>
Mon, 22 Oct 2018 02:41:47 +0000 (02:41 +0000)
committerIkiWiki <ikiwiki.info>
Mon, 22 Oct 2018 02:41:47 +0000 (02:41 +0000)
performance/index.html

index 91c7d18..fcf49c2 100644 (file)
@@ -37,9 +37,9 @@
 
 <p>The purple curve is the TPS, the green curve is the measured TPS/cpu-thread (with 16 threads selected as the baseline 1.0 ratio), and the light blue curve shows the approximate cpu performance for the system (load x CPU frequency).  This particular CPU was running at around 4.16 GHz with one thread, 3.73 GHz @ 16 threads, 3.12 GHz @ 32 threads, and 2.90 GHz or so at 64 threads.  The horizontal thread count is the number of client processes.  There is also a server process for each client process so the actual number of CPU cores in use begins to use hyperthreads past 16, but don't fully load full cores until it hits 32 due to the IPC between client and server.  pgbench was allowed to heat-up during each run, an average of the last three 60-second samples is then graphed.</p>
 
-[[!img tr2990wx02.png align="right" size="" alt=""]]
-
 <p>To best determine actual cpu performance, the load factor percentage is multiplied against the CPU frequency of the non-idle cores and then normalized to fit against the TPS graph.  The match-up starts to diverge significantly at just below 32 clients (32 client and 32 server processes).  At n=1 the load is 1.6%, at n=16 the load is 25.7%, at n=32 the load is 51%, and at 64 the load is 100% x 2.9 GHz.</p>
 
-<p>From this it is reasonable to assume, roughly, that the hyperthreads really get dug into past n=32.  At n=32 we had around 750K TPS and at n=64 we had 1180K TPS, 57% higher.  So, roughly, hyperthreading adds around 50-60% more TPS to the results.</p>
+<p>From this it is reasonable to assume, roughly, that the hyperthreads really get dug into past n=32.  At n=32 we had around 750K TPS and at n=64 we had 1180K TPS, 57% higher.  So, roughly, hyperthreading adds around 50-60% more TPS to the results. 
+ While this test is a bit wishy-washy on when hyperthreads actually start to get exercised, the DragonFlyBSD scheduler is very, very good at its job and will use hyperthread pairs for correlated clients and servers at N=32, with one or the other idle at any given moment.  This bears out in where the graph begins to diverge.  Since there is no SMP contention, the divergence left over from this is likely caused by memory latency as more and more cpu threads bang on memory at the same time.</p>
 
+[[!img tr2990wx02.png align="right" size="" alt=""]]