Is Big Adv possible on GPU3? {Nope, bigadv is for CPUs only}

[*hondo*]

Hi Guys on a GTS 450 I’m utilising (Windows XP/2003/Vista/7 GPU3 6.41) on XP Pro, my GPU completes 6806 in Approx 3.50 hrs & 6805s in 3.00 Hrs rather than Stanfords expected 4 or 5 days.

I was wondering if there are any Big Adv WUs available & further more, how do you set them up? If this has already been posted a link to the how to would be great

Any info much appreciated

PS Please forgive my ignorance of the subject

Mod Edit: Appended Thread Title - PantherX

[Haitch]

Hondo,

No, BigAdv WU's are for CPU folding only, on machines with 8 or more CPU threads.

H.

[GreyWhiskers]

Not to put words into Hondo's mouth, but I think his question might have been whether Quick Return Bonuses were going to be implemented for GPU WUs.

I myself am seeing my modern Fermi GPU ridiculously outperforming the Timeout and Expiration deadlines. My performance fraction from a seemingly unending set of P6801 WUs is 0.9908968 (u=4). When I get assigned one of the odd 109xx or 112xx WUs, it is even faster.

7im's comment on my post Anatomy of a series of GPU Work Units from the trenches reiterates the importance of quick return on these long trajectory investigations.

So, it's not about points but science. How valuable is it to motivate these quick GPU returns?

Re: Anatomy of a series of GPU Work Units from the trenches
by 7im » Fri May 13, 2011 1:45 pm

This is one of the best depictions of the serial and time sensitive nature of the project, and why the quick return of work units increases the value of the work units. If one of those work units had been held up, as was likely around May 5-6th, it's easy to see the affect it has on the project.

It also shows how meeting short deadlines is important, and why caching of work units for offline processing is not very helpful.

[bruce]

How much faster will the average donor return the results if they do add a Quick Return Bonus? I agree that people are returning results ridiculously faster than the Timeout and Expiration deadlines but that's a problem with the way the deadlines are defined, not with any potential change in donor behavior. If you look at the way deadlines are set, there are minimums associated with intentional rounding of the numbers.

I'm not sure why the Pande Group does that but I wouldn't do it that way, myself. Perhaps it is an attempt to allow for server unreliability, but that doesn't make sense either. Sure, everybody gripes when a server goes down (which is pretty rare) and when the Collection Servers don't work (which is pretty much always) but why make everybody more upset that they would be anyway by taking away or reducing their bonus?

I would expect a Timeout just slightly larger than the speed associated with the slowest of Fermi, but there are no timeouts in that range and I don't expect the Pande Group to readjust them to what I'd call "reasonable values" [sarcasm mode on] but it if it would help you feel better about exceeding them you're welcome to start a campaign to shorten the deadlines[/sarcasm mode off].

Over the life of a project, the overall throughput depends on the average return period. That includes a few WUs that get lost and have to be reassigned and a few bad WUs that are repeatedly reassigned. Reducing the timeout would help with the WUs that are lost by getting them reassigned sooner, but to figure that into the overall picture, we'd need to know what percentage of WUs are lost and I don't have any idea about that number so I can't really draw any useful conclusions. Reassigning a bad WU more frequently doesn't help anybody.

I'm not really making a prediction about QRB for GPU. I have no information. I do know that the V6 GPU client didn't accept a passkey the last time I ran it, so it wouldn't really be fair to those folks who are running V6.

[GreyWhiskers]

Well, here's the log entry from my most recent WU. I'm still running v6.41 Systray client on my big system, so I can monitor the WUs and history with HFM.

Anyway, the client reports "Passkey found". The passkey is part of the systray client setup screen. Don't know if it actually passes it to the Stanford servers, but dialog over the last few months from PG seemed to indicate that they were striving for having ALL participants have a passkey.

Code: Select all

[19:31:43] - Preparing to get new work unit...
[19:31:43] Cleaning up work directory
[19:31:43] + Attempting to get work packet
[19:31:43] Passkey found
[19:31:43] - Will indicate memory of 4076 MB
[19:31:43] Gpu type=3 species=21.
[19:31:43] - Connecting to assignment server
[19:31:43] Connecting to http://assign-GPU.stanford.edu:8080/
[19:31:44] Posted data.
[19:31:44] Initial: 40AB; - Successful: assigned to (171.64.65.64).
[19:31:44] + News From Folding@Home: Welcome to Folding@Home
[19:31:44] Loaded queue successfully.
[19:31:44] Gpu type=3 species=21.
[19:31:44] Sent data
[19:31:44] Connecting to http://171.64.65.64:8080/
[19:31:44] Posted data.
[19:31:44] Initial: 0000; - Receiving payload (expected size: 44069)
[19:31:44] Conversation time very short, giving reduced weight in bandwidth avg
[19:31:44] - Downloaded at ~86 kB/s
[19:31:44] - Averaged speed for that direction ~76 kB/s
[19:31:44] + Received work.
[19:31:44] + Processing work unit
[19:31:44] Core required: FahCore_15.exe
[19:31:44] Core found.
[19:31:44] Working on queue slot 04 [May 16 19:31:44 UTC]
[19:31:44] + Working ...
[19:31:44] - Calling '.\FahCore_15.exe -dir work/ -suffix 04 -nice 19 -checkpoint 15 -verbose -lifeline 2800 -version 641'

[19:31:44] 
[19:31:44] *------------------------------*
[19:31:44] Folding@Home GPU Core
[19:31:44] Version 2.15 (Tue Nov 16 09:05:18 PST 2010)
[19:31:44] 
[19:31:44] Build host: SimbiosNvdWin7
[19:31:44] Board Type: NVIDIA/CUDA
[19:31:44] Core      : x=15
[19:31:44]  Window's signal control handler registered.
[19:31:44] Preparing to commence simulation
[19:31:44] - Looking at optimizations...
[19:31:44] DeleteFrameFiles: successfully deleted file=work/wudata_04.ckp
[19:31:44] - Created dyn
[19:31:44] - Files status OK
[19:31:44] sizeof(CORE_PACKET_HDR) = 512 file=<>
[19:31:44] - Expanded 43557 -> 171827 (decompressed 394.4 percent)
[19:31:44] Called DecompressByteArray: compressed_data_size=43557 data_size=171827, decompressed_data_size=171827 diff=0
[19:31:44] - Digital signature verified
[19:31:44] 
[19:31:44] Project: 6801 (Run 6824, Clone 3, Gen 13)
[19:31:44] 
[19:31:44] Assembly optimizations on if available.
[19:31:44] Entering M.D.

[*hondo*]

Thanks for the reply Guy's even though I'm disappointed

109xx or 112xx yep, I had about 2 days worth of those Gawd knows who gets them now, but after 392 WUs with the current GPU, it certainly isn't me.

Also I'm using the pass key & the log indicates it's found, although TBH I don't see what if any advantage this pass key gives my efforts, I don't give a toss who folds using my user name + team, therefore the passkey seems a complete waste of time & space to me.

[7im]

Okay. I'll make a trojan to run fah under your name and team number. And when Stanford tries to close your fah account and zero your points, how will you prove it wasn't you that did it? And you will say look, I fold with a passkey. These are all MY points. Some tosser has been impersonating me and wasn't using a passkey. Delete THOSE points, but not mine. Block that user without a passkey, but don't block mine.

Still not giving a toss?