• Some users have recently had their accounts hijacked. It seems that the now defunct EVGA forums might have compromised your password there and seems many are using the same PW here. We would suggest you UPDATE YOUR PASSWORD and TURN ON 2FA for your account here to further secure it. None of the compromised accounts had 2FA turned on.
    Once you have enabled 2FA, your account will be updated soon to show a badge, letting other members know that you use 2FA to protect your account. This should be beneficial for everyone that uses FSFT.

F@H MySQL System/PPD database.

H

Haitch

Limp Gawd
Joined
Mar 8, 2011
Messages
383
Untitledone said:
Sweet! This is my personal opinion. I think the average joe would just need a basic web page showing the data. Not sure if everyone has excel and a basic web page would have a lot less resource cost.

The only reason I think that is because of the popularity of the stats trackers like hardfolding, and what not.

However importing the DB into excel would be good. I am sure that most power folders would prefer that format anyways.

Maybe we could have both options at some point? Obviously the excel option should be first since it would be the easiest to implement and then have the web front end come later when a good coder is found.
Click to expand...

We're going to be setting up a webpage for querying the data, along with direct MySQL access into the DB, and ODBC downloads. The MySQL direct connect and ODBC options are available and working now.

I foresee the direct MySQL connection being the most appealing to [H] SQL users - I know enough to be dangerous. ODBC works for people to use the spreadsheet or database of their preference.

The "problem" with the webpage is what data to show? There are so many possible queries you can do against the database that it's hard to know what the "average Joe" would like to see - I'm open to suggestions though.

The queries can range from the simple "What system has the highest estimated PPD" to the complex "Show Me the Maximum and Average estimated PPD for all WUs on systems with an Intel CPU running at > 3GHz with 8GB or more of DDR3 RAM running Windows" or "Show me the Maximum and Average estimated PPD for systems with 9-9-9-24 memory timings for each CPU clockspeed" or (when I have better detection of hardware under Linux) "What are the TPF differences for each WU on identical systems in Windows vs Linux"?

I've just uploaded the latest Windows version to PJ's ServeTheHome.com forums. We're working out how easiest to make the bench widely available, but for now, anyone that would like to try it can PM myself or pjkenned and we'll send you the access info you need.

H.
 
Well the best thing to do is add functionality as you go. For the first web front end a list with all the data sorted by PPD (ascending or decending doesnt matter too much) would be an easy first start and gets the info out for people. Thats one of the main things I did on the old google data base. I checked what PPD I was interested in, scrolled to it and saw which processors were hitting that target.

More input from other people will only help to see what many people want.
 
I've been beta testing this for a few weeks now. The live monitoring runs in the background and collects the data automatically on the work units being crunched.
 
I made a page with some info, and download link. It is still a bit rough as I fill out more over the next 72 hours (I am going to write some instruction guides and etc), but I figure that this is a good start for people:

Folding@home Benchmark central

I also made a forum linked on that page where people can report errors if they find any.

Congratulations are in order for Haitch's efforts thus far. Well done.
 
Here's an idea: how about making a google docs spreadsheet using the info from the sql database? It would definitely be easy to use.
 
The "free" Google Docs version does not import MySQL. What we really need is a php front end.
 
I Google searched about tying docs to SQL and it seemed possible, but I was on my phone so I didn't go in depth.
 
The best I can think of is to export a csv from SQL and then import it into docs
 
kirtar said:
The best I can think of is to export a csv from SQL and then import it into docs
Click to expand...

Which is what I've done - here for anyone who wants to see the data. But updating this is going to be awkward, native access, ODBC connector or Web front end are going to be better.

http://goo.gl/TZSXr

H.
 
There is an updated Linux build on the ServeTheHome forums.
- Much better CPU & Memory detection.
- Will monitor and update the DB with info on Linux WU's
- Should be a 6903 entry in the DB in about 6 hours :D

H.
 
Haitch said:
There is an updated Linux build on the ServeTheHome forums.
- Much better CPU & Memory detection.
- Will monitor and update the DB with info on Linux WU's
- Should be a 6903 entry in the DB in about 6 hours :D

H.
Click to expand...
nice. any progress on putting the data into a usable format? I think that would generate some interest if people could easily access the data.
 
jebo_4jc said:
nice. any progress on putting the data into a usable format? I think that would generate some interest if people could easily access the data.
Click to expand...

currently there is the suck it into Excel and manipulate it any way you want it option - now that I have this build, and a whole load of real life work, done - I'm going to be looking at what can be done in a web interface.

H.
 
Not ye, but have been out on vacation last week, won't really be looking at it until I get back next week.

H.
 
I've updated the Google Docs spreadsheet with all the latest data from the MySQL Database. Almost 600 entries in there now. The spreadsheet is readonly, but you can export/download a local copy for use in Excel/OpenOffice etc.

http://goo.gl/TZSXr

H.
 
Just something to note, a lot of the bigadv data isn't relevant/accurate anymore because of the change in base point value.
 
kirtar said:
Just something to note, a lot of the bigadv data isn't relevant/accurate anymore because of the change in base point value.
Click to expand...

.... tpf would be they need to recalculate the ppd ...
 
Patriot said:
.... tpf would be they need to recalculate the ppd ...
Click to expand...

So I have that for the old bigadv in a spreadsheet.

BTW if anyone can help on this, please let me know. I'm willing to throw in some hardware.
 
The bigadv PPD values will have been correct at the time, and as Stanford didn't retroactively change them, they are "correct". I'll get a new wus.csv out that has the corrected data for future bigadv units.

H.
 
Haitch said:
The bigadv PPD values will have been correct at the time, and as Stanford didn't retroactively change them, they are "correct". I'll get a new wus.csv out that has the corrected data for future bigadv units.

H.
Click to expand...

I didn't say that they were wrong, but that they are more or less irrelevant (or accurate to current conditions). Obviously TPF is the best measurement because it is only affected by the WU and machine, but PPD is certainly a more... umm... concrete or tangible value.
 
yeah, it's awkward. I can go back and retroactively change them to account for "current" values - would make more sense than leaving the "correct at the time" values.

H.
 
time for a new table with new results
 
I've added a link on the "Latest Downloads" with the latest wus.csv to take into account the "re-normalization" of the bigadv units. Download and over write the existing file.

Rather than dump the old bigadv units from the DB, when I get back from vacation I'll update the database and spreadsheet to reflect current ppd/ppwu based on the observed tpfs.

H.
 
I am hammering hard to get a real fix done on the pt system of folding at home...

I will probably try and submit more data today... is there an updated live bench that I can use on linux?

I need as much tpf data as I can get a hold of to try and suggest a fix for the system that would work and scale across the board.

What I think is rigth...
is base pts should be the majority of the points with a small bonus for upload requirements and whatever time bonus depending on how important the unit is...

75-85% of ppd should be on computational requirements of units done...
 
Patriot,

The linux live bench is currently at 1.08, but it still doesn't get the clock speed right for overclocked Sandy Bridge & Nehalem Xeons and better. For stock clocked Intel and any AMD it should be fine. Have some new code I'm working on but Intel made getting the real freq of these a bitch.

I've also posted on that FF thread - suggesting that rather than have the curve be exponential all the way, at some point cut it off and make it linear from that point. Spreadsheet and graph here: http://goo.gl/IQymz

H.
 
jebo_4jc said:
what exactly are you showing there?
Click to expand...

YEah, it's quick and dirty, but from the FF post:


Rather than having a one size fits all exponential curve over the full range of tpf, how about having a cut off point, then use a linear equation for each reduction in TPF after that ?

As an example I did a spreadsheet and graph of 6901 and 6903 using the original QRB, vs the modified with linear.

Its set so that for:

> 9 min TPF, use the original QRB
at 9 min or less use:

For 6901: 145K + ( 9 - n ) * 14,375
For 6903: 470K + ( 9 - n ) * 35,000

where in is the TPF in minutes.

It gives an exponential bonus for "normal" SMP systems then an increasing, but linear, bonus for the "extreme" SMP systems.

A hypothetical machine that can do a 6903 with a 0.001 minute TPF will get 784,965 points, rather than 46,032,261

Red/Green are for 6903, Blue/Orange for 6901.

Rather than continuing to be an exponential curve all the way down to very low tpf, times < 10 minutes go onto a linear increase rather than exponential. WU's that are returned quickly get a bonus based on how fast they're returned, but the point's per WU are capped. This was 7im's big complaint, that the QRB was not sustainable, as machines got faster the points/wu tended towards infinity. With this scheme, that can't happen.

H.
 
hmmm time to figure out what kind of formula you used for the linear part. Also, aren't the WUs 100 frames and not 250? Now I must pose the question: will there then be a one-size fits all method of determining the linear (WU point not ppd) cutoff or will there need to be another variable added?
 
kirtar said:
hmmm time to figure out what kind of formula you used for the linear part. Also, aren't the WUs 100 frames and not 250? Now I must pose the question: will there then be a one-size fits all method of determining the linear (WU point not ppd) cutoff or will there need to be another variable added?
Click to expand...

Don't know how that 250 got in there - corrected to be 100.

The initial values I gave for the linear part were chosen to give a linear approximation of the trend at the cutover point. That would require specific values per WU, so I've instead substituted a "one size for all formula"

For TPF > 10 - use the usual QBR formula.

Call Pten the points the WU is worth with a 10 minute TPF.

For TPF < 10 then Points = Pten + (10 -n ) * (Pten / 10)

ie, for every minute under a 10:00 TPF, you get an additional 10% of the value of the WU at 10 minutes.

H.
 
Wow, there is a lot of info in that spreadsheet.

I like the green line on the graph you posted. Which gives us some good exponential scaling for a bit, and enough incentive to push into the linear zone, while also capping it off. Looking at the green line it could actually improve points for some machines over the exponential curve.
 
Untitledone said:
Wow, there is a lot of info in that spreadsheet.

I like the green line on the graph you posted. Which gives us some good exponential scaling for a bit, and enough incentive to push into the linear zone, while also capping it off. Looking at the green line it could actually improve points for some machines over the exponential curve.
Click to expand...

My original didn't have the one size fit all, on that one under 10 minute tpf, the linear was below the exponential. I could lower the 10% factor, but on the 6901 the linear slope is lower than before. Maybe the best way is to just add a new variable, say C, where if you're below C minutes tpf you get 1/C of Pc points additional over Pc per minute under C. That way it can be tuned, eg c=8 for 6901, C=12 for 6903 etc.

The main advantage is that points for a WU can't trend to infinity, the WU points are capped at 2 x Pc.

H.
 
I definitely like that it has the leveling off at the end. Personally I feel that the QRB should be an incentive to return WUs quickly, but should still have reasonable limits to avoid the problems we currently have. One thought I've had is trying to make the number of points a WU is worth look like a logistic curve. That way if you're barely making it you don't get much of a bonus, but there is a potentially sharp incline (call that the "preferred deadline") after which it levels off.
 
great for those that cant do under 10.... shitty to make the incentive less for more powerful machine owners...

No dont make it hard on yourself.. linear for all....
 
You must log in or register to reply here.
Back
Top