Folding Forum

It might be GPU3 client, but that's still GPU2 core and WUs ... so it doesn't prove anything.

GPU3 core is Fahcore_15 ... (and WUs are in the 106xx range).

Well, it doesn't say what client, does it- but it still didn't run.
I presume GPU3 can back run GPU2 wu's -if this IS a valid attempt.
It wasn't meant to be meaningful, only to show what happened, as you asked!
While work is turning over on the 57XX units, I'll stay with GPU2 for now, as I've got a better picture of what is going on.

GPU2 WUs running on GPU3 BETA Client is valid.

Yes, but we still don't know if GPU3 core and WUs have the same problem as p66xx ...

True, Tow- but the 66xx record seems solid on the 'down' side for 8400GS from all accounts hereabouts.
I just hope to get some 57xx or 105xx units to keep me ticking.
Later on, if it's any help ,I don't mind doing a few trials on GPU3, but without knowing much of the inside story on the development can't guess on whether it's likely to be any better.
I suspect not- code could have already been altered to suit 8400 users before now- but I suspect the weight of work flow [and folding farms high O/P] make it a poor return.
Even so, small steps can have a large impact on occasions.. there's still a lot of small folders 'out there'.

I've never been assigned any FahCore_15 WUs, only FahCore_11 WUs, so I have no idea if FahCore_15 works better for this card. I suspect I probably won't see any FahCore_15 WUs as long as there are more powerful cards to consume them. I've been running the GPU3 client since it was made available.

This begs the question- Does PG allocate work other than on a first come basis?
If not, then it would be easier to allocate units to people best able to utilise them on their system.
If I get too many first allocates to the 66xx server -I lay off for a few hours and then get something else I can run, having blocked the other server as advised elsewhere- so no wasted units occur with its attendant overhead.
This is far from ideal- but as I fold partly for 'fun' don't mind a bit of playing 'nursey'!
TBH- the ones that do work like 57xx, still make it worthwhile for me, at the low end of producers.

new08 wrote:This begs the question- Does PG allocate work other than on a first come basis?
If not, then it would be easier to allocate units to people best able to utilise them on their system.
If I get too many first allocates to the 66xx server -I lay off for a few hours and then get something else I can run, having blocked the other server as advised elsewhere- so no wasted units occur with its attendant overhead.
This is far from ideal- but as I fold partly for 'fun' don't mind a bit of playing 'nursey'!
TBH- the ones that do work like 57xx, still make it worthwhile for me, at the low end of producers.

I think it's a first come basis.

Managing assignments based on hardware idiosyncrasies has been requested many times but it seems to be too complicated to be included in the F@H plan. I think it's probably easier to write code based on the assumption that what works on one GPU has to work on another GPU. (If it doesn't work on some hardware, they can just call that hardware "unsupported".)

new08 wrote:This begs the question- Does PG allocate work other than on a first come basis?...

Yes and No. If a Fermi GPU and Non-Fermi GPU both asks for a WU at the same time, you will have this result:
Fermi = FahCore_15 WU only
Non-Fermi = FahCore_11 WU OR FahCore_15 WU

So you see, that if you match a certain hardware requirement, within that category, it's a first come first server bases. Other than that, it isn't.

gwildperson wrote:...Managing assignments based on hardware idiosyncrasies has been requested many times but it seems to be too complicated to be included in the F@H plan. I think it's probably easier to write code based on the assumption that what works on one GPU has to work on another GPU. (If it doesn't work on some hardware, they can just call that hardware "unsupported".)

My understanding is that this feature required support in two sides:
The F@H Client (I believe that it can be managed)
The F@H Servers (Very careful in doing so)

Earlier this year, there was a change in the Nvidia Server Code which resulted in a serious bug that took some time to find and fix. It had a negative impact on the F@H donation (read in post made by non-PG members; it may be wrong) which isn't what PG wants. Hence they will be carefully rolling out new Server codes. An example is the Passkey support. It is supported on some Servers while others don't have it (Details).

gwildperson wrote:Managing assignments based on hardware idiosyncrasies has been requested many times but it seems to be too complicated to be included in the F@H plan. I think it's probably easier to write code based on the assumption that what works on one GPU has to work on another GPU. (If it doesn't work on some hardware, they can just call that hardware "unsupported".)

I guess it depends on what you mean by idiosyncrasies. In the case of nvidia GPUs, there are two classes of WUs, for the nvidia_g80 and for the nvidia_fermi, which are managed by the servers. If you have one model of g80 and somebody else has a different model of g80, it's up to the hardware vendor to provide drivers so that either one of them will produce the same results. Assignments to g80s are FIFO (or is it FCFS).

If your 8400GS cannot complete WUs that other G80s can complete, Stanford isn't going to fix anything. It's either your hardware or nVidia's drivers.

Unfortunately, no one has been able to figure out what's going on with the very low end GPUs

I appreciate this is an old card- but still useful if handled creatively.
Why not code for requests for work including this marker - my card furnishes and redirect to a non 66xx [or whatever] server ? It's already been shown that such 'selective redirection' is being used by PG.
It's hard to tell, but there doesn't seem anything wrong with the cards basic capabilities- from a casual viewpoint, it looks like avoidance of tricky units is a the easier option -IF it can be done without compromising throughput..

Species = 0 ? Weird ... it doesn't seem to be able to determine which CUDA version you have ... do you use official drivers ?

Yeah, I wondered about that, but don't have your knowledge depth -Tow .
The current drivers are 258.96 (6.14.12. 5896) from nV update. Update check said: new drivers NOT req'd, btw.
In Dev.Mangr 4 components show as 'unknown',though- so I've reloaded these 2010 dated drivers [already onboard],for a later reboot.

Edit>>> PS: I notice that the latest CUDA development drivers from PG site is Ver 257.21 so, as I'm running some work, decided not to proceed with the install at this moment.