[Windows 7] 2500k & X6 Bigadv Folding w/ Native Linux Client - Page 4 - Overclock.net - An Overclocking Community

Forum Jump: 

[Windows 7] 2500k & X6 Bigadv Folding w/ Native Linux Client

 
Thread Tools
post #31 of 348 (permalink) Old 03-26-2011, 07:12 AM
New to Overclock.net
 
Boyboyd's Avatar
 
Join Date: Jan 2008
Location: Leeds Leeds Leeds
Posts: 16,093
Rep: 534 (Unique: 417)
ok i just tried this. It absolutely crippled my machine. Even the task managed graph stopped updating but the unit was still folding.

Might just upgrade to a 2600k and sell this.


Boyboyd is offline  
Sponsored Links
Advertisement
 
post #32 of 348 (permalink) Old 03-26-2011, 09:28 AM
New to Overclock.net
 
Join Date: Jan 2007
Posts: 859
Rep: 71 (Unique: 54)
Quote:
Originally Posted by Boyboyd;12876782 
ok i just tried this. It absolutely crippled my machine. Even the task managed graph stopped updating but the unit was still folding.

Might just upgrade to a 2600k and sell this.


If it were me that is what I would do. I have a feeling that when v7 comes out it will kill the walk around and the 2500's will no longer be able to fold bigadv WU's. Stanford has always said they do not want Quads doing bigadv. I do not know why though there have been sugestions before that the results they return are somehow corrupted. But I do not know if that is true or not.

A Little Common Sense Goes A Long Way

Grandpa_01 is offline  
post #33 of 348 (permalink) Old 03-26-2011, 10:08 AM
New to Overclock.net
 
Join Date: Sep 2010
Location: Nebraska
Posts: 103
Rep: 9 (Unique: 9)
Quote:
Originally Posted by Grandpa_01;12877714 
If it were me that is what I would do. I have a feeling that when v7 comes out it will kill the walk around and the 2500's will no longer be able to fold bigadv WU's. Stanford has always said they do not want Quads doing bigadv. I do not know why though there have been sugestions before that the results they return are somehow corrupted. But I do not know if that is true or not.
I've seen some on the FF say that but I've not read anything from Dr. Kasson or anyone from PG to suggest that that is the case. And if that were the case then wouldn't using -smp 7 do the same thing since that veers from the original 8 core/thread requirement?

We should be finding out shortly if v7 does kill x4 & x6 doing -bigadv but then tear will probably find another work around for that one too cheers.gif

brutis is offline  
Sponsored Links
Advertisement
 
post #34 of 348 (permalink) Old 03-26-2011, 11:55 AM
New to Overclock.net
 
Join Date: Jan 2007
Posts: 859
Rep: 71 (Unique: 54)
Quote:
Originally Posted by brutis;12878034 
I've seen some on the FF say that but I've not read anything from Dr. Kasson or anyone from PG to suggest that that is the case. And if that were the case then wouldn't using -smp 7 do the same thing since that veers from the original 8 core/thread requirement?

We should be finding out shortly if v7 does kill x4 & x6 doing -bigadv but then tear will probably find another work around for that one too cheers.gif

Yes we should find out soon. As far as the -smp 7 goes there are already some smp WU's that will not work with it. It is probably just a matter of time before there will be bigadv WU's that will not work with it. That is a core issue not a Stanford requirement.

If v7 does stop the X4 & X6 from folding bigadv then it would be v7 client or software doing it. I doubt that a work around could be made without changing the v7 client and or software which would be a EULA violation.

I do not know that this is going to happen like you said I have not heard anything official.

A Little Common Sense Goes A Long Way

Grandpa_01 is offline  
post #35 of 348 (permalink) Old 03-26-2011, 01:26 PM
New to Overclock.net
 
Join Date: Sep 2010
Location: Nebraska
Posts: 103
Rep: 9 (Unique: 9)
Quote:
Originally Posted by Grandpa_01;12879089 
Yes we should find out soon. As far as the -smp 7 goes there are already some smp WU's that will not work with it. It is probably just a matter of time before there will be bigadv WU's that will not work with it. That is a core issue not a Stanford requirement.

If v7 does stop the X4 & X6 from folding bigadv then it would be v7 client or software doing it. I doubt that a work around could be made without changing the v7 client and or software which would be a EULA violation.

I do not know that this is going to happen like you said I have not heard anything official.
Yes the prime number effect.

Even now without the work around the client will stop none 8+ thread systems from folding -bigadv so it's already doing that. One thing that it might do, besides looking at how many cores the OS reports to it, is to also see what the CPU identification string is saying...just speculating.

If there is a work around for v7 someone will find it without having to hack the client and break the EULA.

brutis is offline  
post #36 of 348 (permalink) Old 03-26-2011, 01:53 PM
New to Overclock.net
 
Join Date: Jan 2007
Posts: 859
Rep: 71 (Unique: 54)
Quote:
Originally Posted by brutis View Post
Yes the prime number effect.

Even now without the work around the client will stop none 8+ thread systems from folding -bigadv so it's already doing that. One thing that it might do, besides looking at how many cores the OS reports to it, is to also see what the CPU identification string is saying...just speculating.

If there is a work around for v7 someone will find it without having to hack the client and break the EULA.
That is the assignment server that is checking for 8 cores not the client. The work around is fooling the AS therefore it is not breaking the EULA. If v7 has the ability to read CPU’s it is different and any hack to the client or software would be breaking the EULA.

A Little Common Sense Goes A Long Way

Grandpa_01 is offline  
post #37 of 348 (permalink) Old 03-26-2011, 03:00 PM
New to Overclock.net
 
Join Date: Sep 2010
Location: Nebraska
Posts: 103
Rep: 9 (Unique: 9)
Quote:
Originally Posted by Grandpa_01 View Post
That is the assignment server that is checking for 8 cores not the client. The work around is fooling the AS therefore it is not breaking the EULA. If v7 has the ability to read CPU’s it is different and any hack to the client or software would be breaking the EULA.
Learn something new every day.

I always thought that when you started the client one of the first things it showed was "reporting 8 cores" or something to that effect and that it was the client that was reporting to the AS that it had 8 cores to use, then the AS would pass that off to the proper WU server.

I'm sure it's the client that reports the number of cores to the AS. Bruce and I talked about that before.
link

Quote:
Originally Posted by bruce
The Assignment Server bases it's decisions on the information supplied by the client. Your discussions are centered about about a concept called performance. Performance is only indirectly related to getting the AS to assign or not assign bigadv is The client DOES NOT KNOW the performance of your system.
So the work around is fooling the client that then fools the AS which doesn't break the EULA.

brutis is offline  
post #38 of 348 (permalink) Old 03-26-2011, 04:26 PM
New to Overclock.net
 
Join Date: Jan 2007
Posts: 859
Rep: 71 (Unique: 54)
Quote:
Originally Posted by brutis View Post
Learn something new every day.

I always thought that when you started the client one of the first things it showed was "reporting 8 cores" or something to that effect and that it was the client that was reporting to the AS that it had 8 cores to use, then the AS would pass that off to the proper WU server.

I'm sure it's the client that reports the number of cores to the AS. Bruce and I talked about that before.
link



So the work around is fooling the client that then fools the AS which doesn't break the EULA.
Yes the AS reads what the client detects from the OS then makes the assignment. But what if the new client or software has the ability to register how many cores are actually dedicated to running the WU and thus refuses to run with less than 8. That is where the EULA comes into play. You would have to alter the client or software.

A Little Common Sense Goes A Long Way

Grandpa_01 is offline  
post #39 of 348 (permalink) Old 03-26-2011, 04:41 PM
New to Overclock.net
 
Join Date: Sep 2010
Location: Nebraska
Posts: 103
Rep: 9 (Unique: 9)
Quote:
Originally Posted by Grandpa_01 View Post
Yes the AS reads what the client detects from the OS then makes the assignment. But what if the new client or software has the ability to register how many cores are actually dedicated to running the WU and thus refuses to run with less than 8. That is where the EULA comes into play. You would have to alter the client or software.
I agree with you if the only way is to hack the client, then yes that is breaking the EULA and should not be done. I wouldn't do it and wouldn't use any app that would. I would also warn people not to as you would too.

But...if the client still queries the OS, BIOS, CPU for that answer and a work around can be done then yes it's not breaking the EULA and I wouldn't have a problem with it.

brutis is offline  
post #40 of 348 (permalink) Old 03-26-2011, 05:28 PM
New to Overclock.net
 
Join Date: Jan 2007
Posts: 859
Rep: 71 (Unique: 54)
I personally do not see any problem with Quads and 6 core machines running bigadv as long as they do not slow the project down and return usable results. Hell I ran a couple of bigadv WU's on a Q9650 in 2.5 days sneakerneting over a year ago when they said it could not be done. But it did not take Stanford long to block sneakerneting after I did it.

I do believe that if Stanford does not want Quads and 6 core machines to run bigadv they could, would or will stop it. If they do not care then it will continue. When I did it they stooped me with no problem.

A Little Common Sense Goes A Long Way

Grandpa_01 is offline  
Closed Thread

Quick Reply
Message:
Options

Register Now

In order to be able to post messages on the Overclock.net - An Overclocking Community forums, you must first register.
Please enter your desired user name, your email address and other required details in the form below.
User Name:
If you do not want to register, fill this field only and the name will be used as user name for your post.
Password
Please enter a password for your user account. Note that passwords are case-sensitive.
Password:
Confirm Password:
Email Address
Please enter a valid email address for yourself.
Email Address:

Log-in



Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools
Show Printable Version Show Printable Version
Email this Page Email this Page


Forum Jump: 

Posting Rules  
You may post new threads
You may post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are Off
Pingbacks are Off
Refbacks are Off