Just thought I'd share this info for others that are wondering if the SR-2 with 5620 Xeons (OC'd to at least 3.8Ghz) might make the new (much shorter) deadlines of the 8101 Bigadv WU.
 
I'd previously attempted to run one of the new Bigadvs (WU 8101) on my SR-2 using VirtualBox and Ubuntu 10.10.  TPFs from that experiment showed that I would miss the "Preferred Deadline" by ~14mins.  So, I shelved trying to do anymore 8101s until I could get the opportunity to dedicate the SR-2 to a native run of Ubuntu Desktop 10.10.  I still need Windows, so I installed the WUBI version of Ubuntu 10.10 which allows me to dual-boot.  I tried the latest WUBI Install of Ubuntu 12 and found it to run very sluggish on my SR-2, so that got replaced right away.  I got Ubuntu 10.10 installed late last night, runs wells and fired up an 8101 this morning at 6:25am.
 
Things are looking good so far and here's the info:
 
Ubuntu 10.10 (WUBI Desktop version)
SR-2 OC'd to 3.8Ghz (stable)
NUMA enabled in the BIOS
Running "The Kraken" on the A5 core
WU = 8101
WU Progress thus far = 6%
TPF thus far = 31:45
Estimated completion = 52:55
(should land WU completion at 4:41 hrs/mins before the preferred deadline of 57:36 hrs/mins)
Estimated points = 213,501
 
I'll report back when the WU has completed and hopefully have good news that my SR-2 can still do a Bigadv.

Yeah 8101 has wildly differing tpf's.  I've seen a 2 minute difference between the fastest and slowest times on my x5670 rig

When I had my SR-2 running 5620's at 3.8 I was always able to complete the 8101's. Points ranged anywhere from 105k to 117k PPD.

I know what everyone is saying about the 8101s and variable TPFs.  I've seen a few times where a 2min swing happened on my 4P rig too.  Buying more Xeons aint in the cards at this time.  I just finished building a new 4P, so this is gonna have to do for now.  The SR-2 is up to 26% on this particular 8101 and the TPF is still holding well enough to finish ahead of the deadline.

Yes, the SR-2 made it with 4hrs and 42mins to spare (at least for this particular 8101).  Wahooo!!

• Ending TPF across the entire 100 frames was 31:44
• Total ending time to complete = 52hrs 54mins

The ending 8101 credit was mixed-in with a tally for an 8102 and two other standard SMPs that completed within the same hour.  So, I don't know the exact ending credit for the 8101.  But it was holding pretty even during the term at ~213,800 and change.

Thanks bud, our venture into VirtualBox SR-2'in is what got me kick-started to try again.  Estimates (before the WU croaked on me) when I tried doing it under VBox said that I was close.  Then moving on to straight Ubuntu 10.10, did the trick and gave me enough margin to feel comfortable.  I used Ubuntu 10.10 Desktop with the EXT4 file system because I needed a dual boot setup.  I timed the upload/send time for the 8101 when it finished and it was complete in 5mins 43secs.  All was good, except that it would be better (for me) if I could use VBox like you have done.  If I ever do upgrade the Xeons to hexas, then that would be possible (until PG makes things more stringent again). 

From what I understand, if you need to dual-boot (Linux and Windows) and install Ubuntu using the WUBI installer, EXT4 is the only choice.  I do have EXT3 in use on my 4P, but that is because it is a dedicated Linux machine.  I have Ubuntu (EXT4, WUBI install) running on two other rigs that Fold 24x7 and I have never seen the upload lag that has been reported with the EXT4 file system.  5-6 minutes tops is the upload time.

To my knowledge, and having read several reports from others using EXT4, the problem does not exist when you are installing Ubuntu within Windows (using WUBI).  With the WUBI installer, Ubuntu runs all by itself from the dual boot setup, but is installed under Windows and can be removed under Windows too.  It it basically a drive area that is within the Windows file system from what I understand.  I think that is also what requires having to use the EXT4 file system with a WUBI install.  When you use the WUBI installer, you don't get the opportunity to choose a different file system.  It is all managed and controlled by that installer, but works like a champ. 
 
I'm guessing that the EXT4 file system Folding upload problems occurred when people were using a native installation of Linux/Ubuntu and were not choosing the EXT3 system, but allowing the default EXT4 system to be used.  With the WUBI installer, that problem does not exist from the several installs I've done.

barnhartmd051977
Wish i had an sr-2 mobo! Maybe i will get one!

NewEgg had some SR-2 refurbs for sale earlier this week IIRC for ~$250.  Just checked and it looks like they are all gone. (Edit:  Ha!  Wolf found them as shared in his message below).     EVGA is still selling them in B-stock for $399.  But yeah, with Xeon Hexacores adequately OC'd, the SR-2 can still work these Bigadvs today within time-frames.  I'm doing it with my Xeon Quads, but would recommend Hexas to have better margin on the completion time and better points results.

 from my own experience using EXT4... there was no issue for me
 

Ouch, cutting it fine! :P Just goes to show i'd never be able to complete a 8101 on my E5-2630's

Installing Linux alongside Windows on ext4 file system using WUBI works, but in actuality it is not an ext4 file system, it has been so long since I used an alongside WUBI install that I can not remember what the actual file system was but it was not a true ext4. Linux just called it that for some reason when you used WUBI,
tear looked into it back in 2010 when I reported that the ext4 file system worked on WUBI here is what he figured out back then.
 

Indeed, it's a file-backed ext4 on ntfs-3g (FUSE). So, we've got ext4 -> loop -> ntfs-3g -> fuse -> block device.

My take on this: by using Wubi you're taking more risk than with ext3 (or any other FS with barriers turned off).

Suffice to say both FAQ and Wikipedia entry mention that Wubi doesn't handle corner cases
very well:

(...) a Wubi installation faces some limitations. Hibernation is not supported and the filesystem is more vulnerable to hard reboots[1]

So while you're getting performance it happens at the cost of reliability.

I sustain my original statement. All goals of FAH can be achieved by use of the techniques listed in one
of previous posts without sacrificing robustness or reliability.

I also briefly examined GROMACS code and it seems it has dedicated, fah-specific hooks for syncing == no way
of figuring out _why_ FahCore does things without resorting to reverse engineering.

Of course, it's infinitely easier to ask, so let's ask. Peter, Kyle, can you please find some time to share the
code and/or reasoning behind writing/cleaning/syncing logic?

barnhartmd051977

Wish i had an sr-2 mobo! Maybe i will get one!

i wish i could even afford one along with the rest of the compnents id need to build it, but that just isnt in the cards for me and wont be until the board is down to like 250.00 or less and by then there wont be any new ones only used and refurbished :(