Project 8101 DDR3 1600 vs DDR3 1333 data

N

Nicolas_orleans

[H]ard DCOTM May 2016
Joined
Oct 7, 2012
Messages
352
From what I read, there has been some speculation that project 8101 favours the faster memory, which would explain why it has been reported 62xx perform better than 61xx on this project.

I found out that my 1600 MHz RAM was running at 1333 MHz (DDR Auto in BIOS) on my LGA 2011 rig . I paused client just after 73% completion, rebooted, forced DDR3 1600 in BIOS, and resumed from checkpoint the same 8101 WU that was previously engaged at 1333 MHz.

So I can provide some data for the same WU at two different RAM speed:
DDR3 1333 MHz – 73 frames observed – TPF 23min10s – 156k PPD
DDR3 1600 MHz – 17 frames observed – TPF 21min45s – 171k PPD

Conclusion: 6% decrease on TPF yielding a 10% PPD increase.
 
Nicolas_orleans said:
From what I read, there has been some speculation that project 8101 favours the faster memory, which would explain why it has been reported 62xx perform better than 61xx on this project.

I found out that my 1600 MHz RAM was running at 1333 MHz (DDR Auto in BIOS) on my LGA 2011 rig . I paused client just after 73% completion, rebooted, forced DDR3 1600 in BIOS, and resumed from checkpoint the same 8101 WU that was previously engaged at 1333 MHz.

So I can provide some data for the same WU at two different RAM speed:
DDR3 1333 MHz – 73 frames observed – TPF 23min10s – 156k PPD
DDR3 1600 MHz – 17 frames observed – TPF 21min45s – 171k PPD

Conclusion: 6% decrease on TPF yielding a 10% PPD increase.
Click to expand...


Stopping and starting leads to unstable frame times... often quicker after restart.
capture a wu and run it twice on both settings...starting and stopping leads to inaccurate tpf data.

While it will be faster... you cannot trust those numbers straight up without a bit more work.
Though given the number of frames it probably won't be far off.

Also... are you running langouste and kraken or anything else?
 
^^ +1

It's also important to determine whether DLB engaged (or not) on all runs.

There is architectural advantage 6200 series have when folding 8101; I have 6100s
and 6200s clocked at 3.0 w/memory clocked at DDR3-1600 -- 6200s perform better.

This is not the case w/8102, 6901 or older BA units.
 
Thanks guys, it appears my data is not so significant then. I will pass on the "capture a WU an re run it" thing, since I prefer to use my watts on a new WU.

Patriot, I am running v7.1.52 with next-unit-percentage=98, so no Langouste.

Regarding DLB, I have verbosity=5, but I never found a mention of DLB engaged in the FAH log. So not sure how to find out on v7 DLB is engaged ? (I have not yet installed GCC + thekraken)

Also, I run v7 as a service, I know this means when I boot at runlevel higher than 3, script in /etc/rc3.d will launch the script located in /etc/init.d/FAHClient. I have been wondering how to modify this /etc/init.d/FAHClient script so thekraken properly wraps the core ? Any idea on that ?

My target would be to compile thekraken, then modify the init.d FAH script so it's a kind of "DLB as a service" :) Thanks in advance for your support guys !
 
Kraken wraps FahCores (not the client) so there should be no need to adjust initscripts.

Did you try going through V7 setup instructions per Kraken's documentation (README) ?
The process is a bit laborious but should be reliable. Let know if you run into any issues...

Re DLB engagement
DLB engagement text doesn't make it to the log. With V6 one can see it in the terminal (FahCore's stdout)...

Universal (V6 and V7) method is actually checking wudata_XX.log file, e.g.:
Code: 
Started mdrun on node 0 Mon Oct 15 15:20:27 2012

           Step           Time         Lambda
       19250000    77000.00000        0.00000

   Energies (kJ/mol)
          Angle    Proper Dih. Ryckaert-Bell.  Improper Dih.  Improper Dih.
    6.92688e+05    1.63875e+05    1.46309e+05    1.25951e+04    3.02580e+03
          LJ-14     Coulomb-14        LJ (SR)   Coulomb (SR)   Coul. recip.
    2.43493e+05   -3.95342e+05    1.67117e+06   -1.86233e+07   -4.27286e+06
      Potential    Kinetic En.   Total Energy    Temperature Pressure (bar)
   -2.03583e+07    3.40236e+06   -1.69559e+07    3.10423e+02   -2.22575e+01
   Constr. rmsd
    8.80175e-06

DD  step 19250004 load imb.: force 125.0%

At step 19250005 the performance loss due to force load imbalance is 17.3 %

NOTE: Turning on dynamic load balancing

DD  step 19250999  vol min/aver 0.801  load imb.: force  0.4%

We're not discarding your results; rather encouraging you to make sure that scientific method was satisfied :)


HTH,
tear

P.S.
Welcome to [H]!
 
Last edited:
Thanks a lot, tear !

I get some compiling errors, however install appears to be fine, I can now see a thekraken-FahCore_a5 in the core home directory, close to the regular FahCore_a5, and top shows a wrapped core.

Only comment compared to readme, the awk script recommended to locate the home directory of cores returns /usr/bin/FAHCoreWrapper and not the expected /var/lib/fahclient/cores/ based on where I know cores are. I ran sudo thekraken -w /var/lib/fahclient/cores/ anyway.

On wudata_XX.log file I could see a DLB engaged after 1% resuming of checkpoint, it was not the case before I stopped the client in order to wrap core. Sounds pretty good !!! Let's wait a for 100% DLBed WU before drawing TPF conclusions :)

Finally, I think there should some thekraken.log somewhere, but I could not find it in var/lib nor the regular fah folders ?

Thanks again for your enlightning support !
 
Found the kraken log in var/lib/fahclient/work. DLB engaged in less than one minute on the next 8101.

I guess tweaking of the rig is complete, let's fold on !
 
These PPD are not good for a dual E5-2660 rig. Did you enable the TB (Turbo Boost) mode for it?
The dual E5-2660's TPF for 8101 with TB on could be as low as about 18m30s, with a PPD of 210k - 220k.

Nicolas_orleans said:
DDR3 1333 MHz – 73 frames observed – TPF 23min10s – 156k PPD
DDR3 1600 MHz – 17 frames observed – TPF 21min45s – 171k PPD
Click to expand...
 
These runs were pre-Kraken + unknown DLB. I'm sure Nick's numbers have improved since...

Though I agree, checking Turbo in the BIOS does make sense. I would also suggest making sure
that scaling governor is set to "performance" in Linux.
 
Here is my BIOS information, in bold what I manually changed. All the other settings are auto or default.

Bios 0405 - 19/03/3012

Advanced/CPU Power Management:
Enhanced Intel SpeedStep Technology [Enabled]
Turbo Mode [Enabled]
Energy Performance [Performance]

Advanced/Chipset configuration/Memory configuration
DDR Speed [Force DDR3 1600]
Numa [Enabled]

Monitor Menu
FAN Speed Control [High Speed Mode]

My chips are spicey, with a BCLK of 100 MHz and a multiplier of 23, so a non turbo speed of 2300 MHz.

cat /sys/devices/system/cpu/cpuxx/cpufreq/scaling_max_freq will return
2301000 2300000 etc...

In my understanding, the 2301000 means 2300000 and Turbo on?

Whatever I run grep MHz /proc/cpuinfo or cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq, I will get 2301000 for all 32 logical cores. I think it means Turbo is on from the perspective of linux kernel, but the actual frequency is determined by the BIOS?

How to know the real frequencies achieved?

tear, my scaling governor is by default set to ondemand, and it appears in Ubuntu 12.04 there is some nasty daemon called cpufreqd-daemon which resets the governors this way. Right now, no clear how to set up to performance and make it stay this way. If all my cores have scaling_cur_freq = scaling_max_freq, I would think scaling governors do not matters that much?
 
Thanks Punchy, below i7z output

BCLK = 100,57 MHz - CPU Multiplier 23x
Max frequency without considering Turbo 2413.57 MHz (100,57 MHz x 24)
Max TURBO Multiplier (if Enabled) with 1 / 2 / 3 / 4 / 5 / 6 cores is 25x
Real Current Frequency 2413,57 MHz (24x) for all 8 cores

It appears my spicey chip have :
- default multiplier of 23
- a +1 multiplier Turbo boost when running 7/8 cores - total multiplier 24
- a +2 multiplier Turbo boost when running 1/2/3/4/5/6 cores - total multiplier 25

This may be different of non spicey chips that appear to have based on CPU World data :
- default multiplier of 22
- a +5 multiplier Turbo boost when running 7/8 cores - total multiplier 27
- a +6 multiplier Turbo boost when running 5/6 cores - total multiplier 28
- etc until 30 multiplier for 1/2 cores

So it appears with 8 cores under load, the best I can expect is 2,4 GHz and that is not as good as the non spicey 2,7 GHz.
 
Nicolas_orleans said:
Unfortunately I have no kill-a-watt nor LCD display at home.

For E5-2660/QA90 you probably already know the data from meroy on FF http://foldingforum.org/viewtopic.php?f=38&t=22120&start=15 eg 270 Watts Turbo On with Platinum PSU, and the data from coolamasta with spicey chips stepping 1 http://forums.bit-tech.net/showthread.php?t=241675&page=2 eg 252 Watts Turbo On
Click to expand...

Thanks for the links, i'd forgotten about the FF thread - which is worrying as i posted in it several times:confused:
 
You must log in or register to reply here.
Back
Top