Yeah, should have thought of the interruption risk with Bigadvs.  They are a lot less tolerant to that than standard SMPs, especially in Linux it seems.  To answer your question about which processor I'm selecting when first starting Linux, the selection has been "Nehalem" which is the Xeon predecessor to our Xeons which are "Westmeres".  I'm gonna guess that there was no need to make a distinction between those families of Xeons, so Nehalem was retained.
 
I finished the standard SMP, took the opportunity to disable NUMA in my BIOS, restarted, wrapped the Kraken on the A5 core and am now processing an 8101 on my SR-2.  We'll see if I can finish it in time.  Too early for any TPFs and it will be well into the night before I hit 3-5%, so I'll check back in the morning.  It's been fun today...

Well, not looking good for my ability to use VBox on my SR-2 (@3.8GHz) to Fold an 8101 or maybe all 8101s in general.    I'm running a TPF of 34:21 and HFM is forecasting that I will miss the "Preferred Deadline" by 14mins.  My own estimated completion calcs are in that same vicinity.  I need a good stiff tail-wind!!!   I will stick with the 8101 WU and see it through.  If I do miss the deadline, then it will likely be the end of Bigadv for this setup and I'll have to go back to native Windows and run standard SMP.  But you don't know until you try right?  Could also keep my eyes open for a deal on some hexa Xeons too. 
 
On the Kraken question, I'm at a loss for being able to say that it is doing anything for me at this point.  Yesterday, when I enabled it, after having tracked TPF on a standard SMP, I did not see any TPF improvement all the way through the balance of the WU.  It was the same TPF that I'd seen before I wrapped the Kraken on the A3 Core.  On the 8101 I'm running now, I don't have an pre-Kraken data so I can't comment.

@ the wolf: before wrapping the Kraken, make sure you already have downloaded the A3/5 cores. Otherwise it won´t be able to wrap around it.
idk how far you´re into your first bigadv (if started at all). I usually wait till its uploading, or is downloading/ just starting a new wu to make any changes

I was 32% done on my 1st WU when it started back at 0%. :(
On my 2nd WU I was at 9% when I turned off the kraken -u.
My times per frame are now 29:13 & at 35% into this WU.
Perhaps my virus software or something did a scan & caused lower frame times when it was 30:27 last night??
I was thinking it was theKraken so I disabled it, but once disable it did look as tho I had more load on my cores.
Before with it enabled only 90 to 95% load, disabled I was seeing 95 to 97/98% load on all cores.
Any links on this Kraken for info on just what it suppose to do?
 
Sorry if I missed any questions, I was up to 4am & just woke up. no coffee yet. lol
 
Edit: @ Texinga ask zophar if he was able to make the deadlines.
he ran them on this SR2 with 2xE5620 @ 3.8Ghz.
Perhaps its just all the messing with the rig that's causing it to miss the deadline?
 
My HFM time log. This is a mix of 18 cores & 20 cores times.
Project ID: 8101
 Core: GRO-A5
 Credit: 22607
 Frames: 100


 Name: SR2 -SMP 20
 Number of Frames Observed: 65

 Min. Time / Frame : 00:28:27 - 114,469.2 PPD
 Avg. Time / Frame : 00:29:58 - 105,889.9 PPD
 Cur. Time / Frame : 00:29:15 - 109,091.2 PPD
 R3F. Time / Frame : 00:29:14 - 109,173.0 PPD
 All  Time / Frame : 00:29:12 - 109,337.0 PPD
 Eff. Time / Frame : 00:30:19 - 104,061.1 PPD
 

TheWolf
Any links on this Kraken for info on just what it suppose to do?

Tear's original Kraken thread with the background, etc:
http://www.amdzone.com/ph...php?f=521&t=138463
 

Think I may have everything set now. Took a big chance at 41%
shut down the WU made some changes in SR2 bios, set kraken enabled.
After restart of WU it took off again at 41% but now shows
Note: Turning on Dynamic Load Balancing
It'll be a while before I know anything "if any change in times" I'll post back when I know something.
 
Thanks for the help & links.
 
Edit: BTW almost forgot to say, I'm now seeing 97 to 100% load across all cores. mostly 98/99%
So its looking good & times may fall some with better use of all cores.

Finished the 8101, not sure this SS will be of any help to anyone.
The performance & times I'm sure could have been a little better.
I only stopped it 8 times with a 6 mins. delay or more each time
testing different setting in hope to improve frame times.
This should show up as a single upload score at 12 midnight or 3am for 111065

Great to see that you pulled it off!  Seems your results are indicating what some others have reported...that Folding within VirtualBox on Linux was actually yielding slightly better results compared to native Windows.

Here is something I found that may help others when there not seeing a full 100% load across all cores.
Say its only in the 90 to 95% load range on all cores. In my case its 20 cores.
 
I can open Task Manager right click on the VirtualBox go to Set Affinity uncheck the last 10 cores, click ok to set, this will put the other 10 cores up to a full 100% load.
 
I leave this for about 15 to 30 seconds then click the box at the top to have all cores included again. Once done and clicking ok it now loads up all 20 cores at 98 to 100% load.
 
I have no idea why this works or forces more of a load, but it does hold an I see better times per frame.
Edit: also I might add that the time drop in my post above this one is when I found this.  Did a 3rd regular smp
and it yield the same 3:55 times.  Now testing the same on a 8101 and its frame times are looking better than ever.

Nice, your Vbox'ed SR-2 is level with my dedicated x5670 rig in native linux and you can still run windows!

WT heck could this be correct or some frames are just shorter to work than others?
if it stays like this, this bad boy is smoking.
 
Min. Time / Frame : 00:26:40 - 126,141.8 PPD
Cur. Time / Frame : 00:28:04 - 111,843.2 PPD
R3F. Time / Frame : 00:27:53 - 112,642.7 PPD
 
Edit: Project ID: 8101
 
Edit2: NVM looking at the log I see it worked 4 frames in a row at shorter times & when back to as it was. 
 
Since I edited this I'll add something I found that seems to help when shutting down the client.
At setup "this last time" I set my checkpoints to 3 mins. instead of every 15 mins. Now when stopping the client
and seeing the post on screen "stopping at next" don't recall just what it said but something to that nature.
Before when seeing this waring  it would start back at 0% done, but only sometimes.
If I stop it now and see this I wait 3 to 4 mins before making any move or quitting Virtualbox & haven't seen the
problem where the WU starts over. Might just be luck that it hasn't, but thought it might be worth mentioning.
 
Shorter checkpoints on something that takes this long to do just seem like a better idea to me

This is how I use the 3 min. checkpoint. I start my client at the hour or half hour mark by the clock.
If for some reason I need to stop the client I wait until it finishes a frame then wait 3 to 4 mins after
that frame has finished before stopping the folding client "checkpoint written". Starting on a hour or
half hour point just make it much easier for me since I know it takes about 30 mins to work a frame
so if there is something I need to do I can be there waiting.
Better than having to wait 15 mins before shutting the client down to insure a checkpoint has been written.
Could this be the wrong way of thinking? So far its been working for me but would like to get others input
on setting a checkpoint time.  How much does this cut into the folding time or does it effect it at all?
 

Thanks for the links. The 1st one was helpful.
The 2nd I don't think was to the correct thread, as I didn't see
anything about the quoted info you left.
The 1st one pretty much answered my questions.
Thanks

mflanaga

Good discussion about checkpoints here:
http://m202.sgded.com/~folding1/viewtopic.php?nomobile=1&f=16&t=21674&start=0
Waiting a few mins after stopping the client usually works, once the unit stops at the next ns step. Check system processes to make sure the A5 core has ceased running and you should be good to quit Vbox. There is a way check whether the checkpoint file is corrupt or not. I need to find it and will update later...

Found it:
  "To tell whether checkpoint was written correctly check the size
  of work/wudata_XX.ckp file (XX being current slot number).
  It should be 75160 (for core A5). If it's not -- better switch to backed up
  directory."
This info came from this thread here:
http://foldingforum.org/viewtopic.php?f=55&t=17774

Thanks my questions have now been enlighten to a better understanding.

Working on a new 2p rig & was looking for this thread, wow was it hard to find. lol

tedster59
just double checking, around what OC do I need in order to run -bigadv on a 8 core/16 thread sr-2 setup?

3.8GHz or faster if you can.  My 5620s are stable at 3.8G, but anything faster and they're unstable for Folding.  Here's my thread on completing the 8101 Bigadv on my 8-core/16-thread SR-2.
http://forums.evga.com...=1730933&high=sr-2