texinga


I was up in the top root directory when I typed that kraken command.

Typed:
cd ~
./thekraken -i

Maybe you were in another directory?

I've seen that CPU splash screen you mentioned when first starting up VirtualBox, but before I can even read all the choices it scrolls off and goes onto other things.  Are you doing something to make it hold while you check those selections?

oh well stopping fah to trying the above "cd ~
./thekraken -i" I lost the WU. Start at 0% "crap" so much time lost.
Guess I'll set up 1.5 image now and start over. Its one thing I forgot & learned with linux folding.

Don't stop & start fah as you take a change of starting back at 0%. I should have known better.

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...

Looks like 1.4.1 was getting better times than 1.5 is.
30:27 with 20 cores & 1.5.0 vs 30:15 with 1.41 & only 18 cores.
 
I started the kraken,  was it suppose to help with frame times?
My cores don't seem to be as fully loaded as they where in 1.41 image.
 
Any hints from any one on what I might be doing wrong or didn't do?
 
Thanks in advance for any help & for looking in.

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.

Regular SMP's need love too you know. That's what I'm folding on my I7 970. It's disappointing that you can't do -bigadv on that machine, but it is what it is...
Great effort though, texinga!

@ 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

You bet on the regular SMPs Mf and that is why I do them on my other machines too.  I can say that the test of using VirtualBox was an overall success.  It does work quite well, so for those that have capable Xeon setups and need to still have Windows available, I think it's a possibility they can try.
 
I was taking a last look over at some threads about tweaking Xeon systems that are running the Kraken.  Seems I should have NUMA "enabled" instead of disabled if I'm running the Kraken.  So I took a chance, stepped out of the 8101, reset NUMA to "enabled" in my BIOS and am back running the 8101 with no loss other than a couple minutes to get into the BIOS and back.  I'll be re-checking TPFs (after I get enough run-time) to see If I can get any improvement from that change.

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
 

Well, I'm not gonna know now because one of the intermittent problems with my GTX690 and the latest Nvidia drivers reared its head, blue-screened me, memory dumped and forced a reboot.  I lost my working 8101 when I finally got back into Linux and restarted it.  It said something about couldn't recover from where it was and started a whole new 8101 at 0%.  I decided that was enough for now, especially since my forecasts were saying I could not make the deadlines.  I was off track way before I anything happened and with nothing else being done on the PC.  So, my guess is that the only shot I might have at completing an 8101 would be in Native Ubuntu 10.10.
 
Since I was back to square-zero, I decided to ditch the Linuxrouter version of Linux and install Ubuntu 10.10 desktop into VirtualBox instead.  I just prefer having the GUI and it's what I'm used to working with.  So, I did a little "Kraken test" using this new setup and a couple of standard SMP WUs.  The first WU, I did not wrap the kraken onto the A3 core.  On the second WU, I wrapped the Kraken onto the Core and ran it.  Here's the results:
 
1st WU (6977) - TPF = 1:51
2nd WU (6980) - TPF = 1:49
 
When I run that same series of WU 69xx under native Windows7, my TPFs are typically 1:45, so not much loss using Virtualbox.
 
Not any important differences from the Kraken test, but this is a much smaller piece of work than an 8101 and runs way shorter in time.  So, my unscientific thinking is that over the course of a couple days, on an 8101, the TPF savings would be higher and the Kraken would be helping. 

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
 

texinga

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

Thanks, I'll have a read.

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.

Good for you Wolf, knock those 8101s down buddy!! 

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

texinga

Good for you Wolf, knock those 8101s down buddy!! 

This showed up as a single WU at 3am for Team 111065
214K credit \ 107k PPD
Edit: I spent about 2 hrs down time "tweaking" so 107k should
be about right coming in at around 48 hrs to complete.
 
Decided "-oneunit" to work a couple regular SMP to see how they scale.
Current Project:
 
 Project ID: 6097
 Core: GRO-A3
 Credit: 1593
 Frames: 100


 Name: SR2 -SMP 20
 Path: \\192.168.1.109\fah\
 Number of Frames Observed: 96

 Min. Time / Frame : 00:04:00 - 67,427.2 PPD
 Avg. Time / Frame : 00:04:03 - 66,182.4 PPD
 Cur. Time / Frame : 00:04:26 - 60,082.5 PPD
 R3F. Time / Frame : 00:04:16 - 62,454.9 PPD
 All  Time / Frame : 00:04:03 - 65,830.9 PPD
 Eff. Time / Frame : 00:04:05 - 65,288.2 PPD
 
You'll have to look over the current time, I been working & posting from the SR2.
the Avg. time shown is about the right times I see with this project while folding only.
actually 4:01 w/ theKraken enabled 4:08/4:10 disabled
about 9 seconds improvement per frame.
Looking at my old times in native W7 it was 4:11/4:14 per frame for this same project.  
 Project ID: 6097
 Core: GRO-A3
 Credit: 1593
 Frames: 100 

 Name: E5645+E5620=20
 Path: \\E5620\Folding@Home Windows SMP\
 Number of Frames Observed: 100
 Min. Time / Frame : 00:04:11 - 63,043.7 PPD
 Avg. Time / Frame : 00:04:14 - 61,930.0 PPD

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.

texinga


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.

Yes its looking good!
2nd regular SMP

 Project ID: 6098
 Core: GRO-A3
 Credit: 1593
 Frames: 100

 Name: SR2 -SMP 20
 Path: \\192.168.1.109\fah\
 Number of Frames Observed: 7

 Min. Time / Frame : 00:03:58 - 68,278.9 PPD
 Avg. Time / Frame : 00:04:06 - 64,975.5 PPD
 Cur. Time / Frame : 00:04:02 - 66,392.5 PPD
 R3F. Time / Frame : 00:03:59 - 67,614.4 PPD
 All  Time / Frame : 00:04:06 - 64,819.6 PPD
 Eff. Time / Frame : 00:04:22 - 59,108.1 PPD
 
: update on frame time for the last 26 frames idle folding only :
Project ID: 6098
Name: SR2 -SMP 20
 Path: \\192.168.1.109\fah\
 Number of Frames Observed: 36

 Min. Time / Frame : 00:03:55 - 69,590.5 PPD
 Avg. Time / Frame : 00:03:58 - 68,278.9 PPD
 Cur. Time / Frame : 00:03:55 - 69,347.6 PPD
 R3F. Time / Frame : 00:03:55 - 69,347.6 PPD
 All  Time / Frame : 00:03:58 - 68,197.4 PPD
 Eff. Time / Frame : 00:03:59 - 67,821.2 PPD
 
Sad part is I have no old data on this project to compare to.
But it looks to be wrapped & times are looking great.

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!

nathan_P


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

Thanks for letting me know. Good to know my work is paying off. How does this look for 20 cores?
Here is a update on Project 8101 Last 3 frame time 29:20 All Frames time is coming in at 29:42 by HFM.

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?
 

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 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

The quote I used for the second link actaully came from here:
http://foldingforum.org/viewtopic.php?f=55&t=21541
8th post down..
 
The idea for it originated here:
http://foldingforum.org/v...c.php?f=55&t=17774
 
last post..
by tear » Wed Mar 16, 2011 1:41 pm
Two more observations (ran into the issue several more times since):
1. all failures I experienced show the ckp file being 20 bytes short (75140 vs. 75160);


sorry for the confusion..
Glad I could help

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

Upping the checkpoint time made some improvement in frame times.
I went from 3 mins to 6 mins checkpoints and dropped into a avg of 29:00 to 29:09.
So I may up it more now that I have everything set & know its stable plus I will not be
stopping and starting it as much as I was testing settings. lol

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

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

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://www.evga.com/forum...=1730933&high=sr-2