![[H]ard|Forum](/styles/hardforum/xenforo/logo_dark.png){kind=logo}
Official YURT Design Thread (Development Discussion ONLY)
- Thread starter enhanced08
- Start date
I've added "hand made" processor names for processors which can't report their own names, so this takes care of older machines. You can see some P3's in the list, now, for example -- their naming scheme sticks out like a sore thumb.
There has been sublte fixes to some of the reports; aggregating points over frames wasn't exactly correct, though I don't think it's that noticable. There was an accumulated rounding error, and now there's no rounding at all.
For the client, I fixed a bug where the client would not report frame progress if the work unit had a very large number of steps -- more than 22,000,000 or so -- because some integer math overflowed.
I fixed a nasty bug where the state file couldn't be written, and failed with error 13. This was the main reason my machines were "pumpted" with stats, running again and again to repro the problem and figure it out.
There's also been a lot of changes to make the log files more readable. Most notably, I report which client directory is causing the current chain of events in a clear way.
Aside from the tweaks and fixes, I'm not doing any heavy work right now because I don't know where the project is headed.
There has been sublte fixes to some of the reports; aggregating points over frames wasn't exactly correct, though I don't think it's that noticable. There was an accumulated rounding error, and now there's no rounding at all.
For the client, I fixed a bug where the client would not report frame progress if the work unit had a very large number of steps -- more than 22,000,000 or so -- because some integer math overflowed.
I fixed a nasty bug where the state file couldn't be written, and failed with error 13. This was the main reason my machines were "pumpted" with stats, running again and again to repro the problem and figure it out.
There's also been a lot of changes to make the log files more readable. Most notably, I report which client directory is causing the current chain of events in a clear way.
Aside from the tweaks and fixes, I'm not doing any heavy work right now because I don't know where the project is headed.
Mike... I checked on the 3 PCs I have at home with YURT running... program seems to work fine, BUT..... I noticed that my P4 2.4C @ 3.0 has turned in 2 p2500_BBA5_pfold, and is working on numbers 3 and 4, but they don't show up on the website.... computer "a"... Stanford has record of them, EMIII tracked them.... YURT tracked them (I looked at the log), but it's not showing up on the website... I looked in the log and it said "SUCESS" after each 20 frame chunk.... So I'm not sure what's going on there.....
After looking at the Show All Proteins page, you don't have any proteins listed above about p2390... It is listed on Stanford's WU page , so it's not a beta protein.....
Keep on Folding!! For the [H]orde!!
After looking at the Show All Proteins page, you don't have any proteins listed above about p2390... It is listed on Stanford's WU page , so it's not a beta protein.....
Keep on Folding!! For the [H]orde!!
unhappy_mage
[H]ard|DCer of the Month - October 2005
- Joined
- Jun 29, 2004
- Messages
- 11,455
Hmm, I'd just been looking for errors in the log file. It says "SUCCESS" every time it uploads frames, but no WUs are showing up for my machine, quite a few frames are missing, and there's some strange behavior in the log file. Here's my FAHlog, and here's the YURT report for the same time period. As you can see, I rebooted after frame 22 of the first protein. But at [2006-04-01 23:19:28] I see some really strange behavior. It skips to line 443:
Also, what's the correct way to shut down the monitor when one's going to reboot? Control-C? Close the window? Ignore it and reboot, and it'll take the terminate signal gracefully? I tried the last method, and ended up with the somewhat odd results shown.
and reads some lines, but doesn't report any frames. It does this several times, with different numbers of lines, including once 0 lines, and essentially skips the rest of the report, including the end of the WU. Any ideas why this would happen?
Also, what's the correct way to shut down the monitor when one's going to reboot? Control-C? Close the window? Ignore it and reboot, and it'll take the terminate signal gracefully? I tried the last method, and ended up with the somewhat odd results shown.
unhappy_mage said:
This sounds exactly like the bug which I just reported finishing. Your log entry says that the work unit has 25,000,000 steps in it. Here's what I posted yesterday:
mikeblas said:
Does that sound like a match to you?
RTFM, please. I put a lot of work into it, and as a beta tester I expected you to include it in your testing. The manual carefully describes the shutdown issues. I think it's also come up in this thread that, when I migrate the code to a service, the shutdown situation will become simpler.unhappy_mage said:
The work your client has reported is safely in the datbase:OSUguy98 said:
Code:
[COLOR=SILVER]3652160844907852215,2500,06/04/2006,06:14:01,2,392945
5089611392280831012,2500,06/04/2006,10:50:48,1,182402[/COLOR]
270252400081119051,2500,07/04/2006,00:59:05,2,425682[COLOR=SILVER]
337267195555576083,2500,06/04/2006,18:48:27,4,480426
2022910694438681566,2500,07/04/2006,06:52:29,1,171518
7451579869239255759,2500,07/04/2006,11:50:33,1,183708[/COLOR]What's happening is pretty simple.
Work is tracked in two tables: a list of work items fully completed, and a list of frames completed against particular work items. That mechanism is described in an earlier post, including the table definitions.
Per Unhappy's advice earlier in the project, I used a copy of the proteins list from some ZIP file.
To implement queries where the number of points must be known, or where the protein ID is involved, I join the submitted work table against the list of proteins from the ZIP file on the Protein ID. If the Protein ID isn't found in the protein reference table, the rows for it aren't reported--even though they're still being tracked (as I pasted above) in the work tables.
The solution is to update the proteins reference table, then, with new data from the ZIP file. This isn't quite as straightforward as it might sound: we want to load a text file (with a really awkward format) into a database table. Doing it once wasn't hard; I ran a PERL script over the file (IIRC) and had it spit out an INSERT scrpit. Then I ran the INSERT Script on the server and that was that.
To take a new version of the file, we could truncate the table and completely reinsert everything. That makes the insert process easier, but it means any data that is removed from one version of the file to the next is lost. Does anyone know what the update policy is for the file that we're using?
I think we'd want to keep previously known proteins in the database. So if the proteins list file deletes old proteins, we want a more interesting mechanism. We want to upsert each row in the proteins file; if the protein is new, it is added. If the protein is old, its data is updated. If the protein is deleted, nothing happens.
Is there a way to be notified when the proteins data file is updated?
As far as I know, there is no official announcement if Stanford changes the value of a protein (unless it's a matter of complaint/etc in the official forum)... I'm not sure how LPerry gets his data, other than the assumption that he frequently checks the psummary page I linked to above...... If you took his data (Which is the zip file I think you were referring to), and ran a script to make it a text file similar to a *.CSV then it might make more sense and be easier to search/find/replace data..... something like:
protein,point value,frame count,whatever the other term is
pXXXXX,208,100,______
Then a server-side script could grab all the data out of that file and compare it...... I'm pretty sure that Lperry just adds new proteins to the bottom of the files.... so historically speaking, if a change was made to a protein value, it grabs the last known value....
Keep on Folding!! For the [H]orde!!
protein,point value,frame count,whatever the other term is
pXXXXX,208,100,______
Then a server-side script could grab all the data out of that file and compare it...... I'm pretty sure that Lperry just adds new proteins to the bottom of the files.... so historically speaking, if a change was made to a protein value, it grabs the last known value....
Keep on Folding!! For the [H]orde!!
What does "change the value of a protein" mean? I think we're worried about new proteins being added, and old ones being deleted. What is the "value" of a protein, and why would an established protein's value change?OSUguy98 said:
Is there an announcement when LPerry updates his list? Or are consumers of the list expected to poll his webstie for updates? How often is it updated?
OSUguy98 said:
Using a *.CSV doesn't make much sense for this case. I'm not trying to find and replace data in a flat file; I'm trying to update a table in a database.
This isn't the case. The new protein you're asking about is on line 24 of a file with 3466 lines.OSUguy98 said:
I'm not sure what a "change made to a protein value" means, or what "the last known value" means; therefore, I can't understand why you believe the order of the proteins in the file matters. I also don't know what is "it" that's grabbing the last known value; some script you're saying I need to write?OSUguy98 said:
Neglecting the idea of a "change made to a protein value", you've missed the point of my post. I'm asking what we do about proteins that are deleted from the list, or if we believe the list is ever-increasing in size.
value = point value assigned by Stanford.... which almost never changes... but in the case where users complain a great deal that the protein uses WAY too much RAM or take ALOT longer and doesn't fit into the range of time it takes to complete a similar point value protein, then they'll adjust the score addordingly.....
So maybe LPerry does it the opposite way, new goes on top.... that way the first return of a find would be the latest point value....
As for an announcment from LPerry, doesn't happen.... I usually go and get it when I see a "Unk" for the point value in EMIII.....
Keep on Folding!! For the [H]orde!!
So maybe LPerry does it the opposite way, new goes on top.... that way the first return of a find would be the latest point value....
As for an announcment from LPerry, doesn't happen.... I usually go and get it when I see a "Unk" for the point value in EMIII.....
Keep on Folding!! For the [H]orde!!
When such a change occurrs, is scoring changed retroactively? Is YURT expected to do so? Will we need to historize the Proteins table, then? I hope not, because it means we must historize the work unit completion records.OSUguy98 said:
Earlier, you said you were pretty sure about this; but now it seems like you're just guessing. Are you saying that the EMPROTZ.DAT file is historized implicitly by the order of the file? Maybe that's why you're saying the order of the records in this file matters -- but each protein ID appears in the file only once and threfore doesn't have a "first point value" or "latest point value".OSUguy98 said:
No, the score is the score is the score.... no changes are made to past WU records.... (unless, there is a significant breach of the EULA, where Stanford actually zeros out that specific users WU score/count)....... they never do retroactive changes....mikeblas said:
mikeblas said:
I was pretty sure, but was wrong, so now I don't know.... maybe we should drop LPerry a line and see the logic in the file?
Keep on Folding!! For the [H]orde!!
unhappy_mage
[H]ard|DCer of the Month - October 2005
- Joined
- Jun 29, 2004
- Messages
- 11,455
Yes, sorry. I missed that post.mikeblas said:
I apologize again. I did read the manual; the question (which I didn't make very clear) is what happens when one doesn't shut YURT down properly.mikeblas said:
No, nothing is changed retroactively. But doesn't this still pose a problem? You have to track that a client finished a WU, how long it took, and how much it was worth at the time. That probably means maintaining a list of the most current values and adding a field for "worth at the time" for the WU completion records. Is this what you meant by "historizing" them? I can't find a definition that matches what context tells me it should mean.mikeblas said:
Sorry for the poor quality bug reports; I've been studying for my Chem test, and everything else has suffered over the past couple of days. This weekend I should be more coherent.
That's a good idea; let me know what you find out.OSUguy98 said:
I think the file is a simple list, with no historization. So updating the YURT database with a new version of the EMProts.DAT file means we need to upsert, as I described before.
Doing that much only will retroactively adjust points shown by YURT. If you log 100 work units of protein #12, and protein #12 is scored at 5 points each, you'll get 500 points. If, six months later when you're not even working protein #12. the score is changed to 20 points each, you'll be credited with 2000 points overnight.
If we want to make it so the points don't move around, that means historizing everything. I'd have two records in the protein table, then. The shape of the protein reference table would change; instead of just (proteinID,points), I'd need (proteinID,score,StartDate,EndDate) for the scoring. All the completed work tables would need to record the date when the protein was completed so we can look up the correct score for the time the work was actually done.
Good; then it's already fixed. I'm not trying to be abrasive, BTW; if it doesn't sound like the same issue to you, please explain why and we can dig into it more.unhappy_mage said:
When YURTMonitor shuts down in an orderly way, it writes out a lot of state information. That state information includes the finished work items in the queue, and high water marks in the log files that it is monitoring. The high water marks include an offset into the log file where the last read was done, as well as a checksum for all the data that was previously read.unhappy_mage said:
When YURTMonitor starts up, it looks for the state file. If found, it reads the log file to the point hat was last read. If the checksum matches, it knows the log file hasn't changed or been replaced. If the file has changed, it abandons the high water mark and starts from the beginning of the file, parsing everything again. If the file is the one we recognize, we sit on the state and start parsing at the high water mark, ignoring everything previously written to the log file.
If YURTMonitor is shut down abruptly, it won't have a chance to write the state file. If there was a state file, the next run of YURTMonitor will use it and might re-parse and re-send all the data in the log file that's being observed starting at the old high water mark. So, some of the data (between the old high water mark and the end of the file) can be reported twice.
OTOH, if there's no state file at all, the program will re-parse everything again. Same thing; we'll send data we've already sent, but it ends up being the whole darn file.
I've been calling this "pumping" the stats, since it makes the stats for a machine where this happens artificailly inflated; the nubmer of completed work units can go really high, though the time per unit (and therefore points per day) numbers just average out.
ENDURO, my dev machine, gets pumped a lot. I might debug the monitor, restart, stop again, and so on. In this last week, I did so a few times to debug a problem with failing to write the state data. That's why ENDURO looks like it has a very large work count, and a very high time working total; I reported honest data, but reported it many times so the totals kept accumulating.
There is no serial number for a protein, and we don't record completed frames. As such, we can't tell at the server if work has been repeated. When I originally asked about this, I called it "ballot stuffing".
I dug into the EMProtz.DAT file and figure out that I was wrong about there not being duplicate ProteinIDs in there. There are; and lots of them!
I think what happened is that, when I ran the script to insert the values into the reference table, the errors weren't reported from the web-based query analyser tool I'm using because they didn't happen in the first 50 commands. (Sure enough, there's no duplicate IDs in the first 50.)
So we need to decide what we'll do about proteins that have changed their scores.
I think what happened is that, when I ran the script to insert the values into the reference table, the errors weren't reported from the web-based query analyser tool I'm using because they didn't happen in the first 50 commands. (Sure enough, there's no duplicate IDs in the first 50.)
So we need to decide what we'll do about proteins that have changed their scores.
mikeblas said:
for me, there are two ways to look at this....
1. The purpose of this project was to determine how many points you can get out of X CPU on Y Protein..... who cares if a P4 2.4C could get 250ppd on a certain protein a year and a half ago? I wanna know how much it can get now..... (In other words, keep only the most recent point value for each protein)
2. It's nice to look back and see which proteins were better.... to compare AMD vs Intel on certain proteins.... (In other words, you'd have to know what the protein point value was when it was turned in)
------------------
Suggestion for the web pages.....
On each
machine details page, how difficult would it be to include and avg. points/day of all the WUs that machine has completed?
Might even want to add that on the the All Machines page....
Keep on Folding!! For the [H]orde!!
Sure; either decision can be justified. I'm asking which one we'd like to pursue. I'm leaning towards #1, since we don't have to historize.OSUGuy98 said:
To serve the first goal, there are other solutions. For instance, perhaps we decide we'd like to "expire" work. That is, anything reported more than 6 months ago is removed from the database altogether. This requires some historization, too.
OSUGuy98 said:
It's easy to add in both places. On the all machines page in particular, though, it requires rearranging the page and its content since the columns are getting pretty wide.
I'm expecting MN Scout to provide some suggestions for the reports and their layout. He seemed to be interested in having a couple of lines per machine, and I think that's interesting so I'd like to see how it turns out. He said he'd be away, but that was a while ago and I haven't heard from him since.
I'm also waiting to hear from enhanced08; he wants to re-host the site, and I've asked him about my involvement in the project going forward.
The protein score historization issue is an expmple of what's sucking the fun out of this project for me lately.
The core issue is around making decisions. If I make a decision, I make progress. I can make tons of progress fast, in fact. But then I spend hours defending and explaining my decisions, and even after repeated passes, they're undermined, anyway. I've been accused of taking over the project.
OTOH, if I don't make a decision, I wait around for days and days. I can't make any progress--at best, I don't want to because I'd have to make a decision, even if it is just a bet on the anticipated decision.
My gut tells me that I should just go ahead and make the decisions, and get back to work. But I sense that won't be a very popular mode of operation. And what's the alternative? Abandon the project? Let it continue to drag out when it could've been completed?
So, what should I do?
The core issue is around making decisions. If I make a decision, I make progress. I can make tons of progress fast, in fact. But then I spend hours defending and explaining my decisions, and even after repeated passes, they're undermined, anyway. I've been accused of taking over the project.
OTOH, if I don't make a decision, I wait around for days and days. I can't make any progress--at best, I don't want to because I'd have to make a decision, even if it is just a bet on the anticipated decision.
My gut tells me that I should just go ahead and make the decisions, and get back to work. But I sense that won't be a very popular mode of operation. And what's the alternative? Abandon the project? Let it continue to drag out when it could've been completed?
So, what should I do?
I say that we go with the removal of the proteins after they are so many months old. Historize up to a point. We could keep the data and save it in sum form, so it could be called on at a later undetermined time. I like 1. We want to know how much X cpu gets now for a protein. To get that average we don't want to work with data that came in a year ago, we want to consider what came in in the last few months.
I've been very busy lately, work called me out, and I have a bunch of large tests, and notably physics and Lin Algebra going on. I assumed that that report on the machines was sort of a no go since it was deemed complicated to figure out what machines should go under what name. That sheet I was linked to was like a book, and I didn't have the time to sift throught it. That was the wrong assumption I guess. I'd like just a simple breakdown by GHZ, but "simple" is a tough word we all know. Just something that is non complicated to look at. Something a user can just glance at and see hey a P4 3ghzish machine will get me on average of all the proteins about 70ppd(whatever it ends up to be). The ranking would be anything from 3.0-3.999 ghz all the ppd average together(or 3.0-3.4 and 3.5-3.9). Not precise but there isn't that big of a folding ppd range there, the production differences from people using the machine is can be large at times anyway.
Make the decisions mike, you can't please everyone. Something is better than the nothing that we currently have.
I've been very busy lately, work called me out, and I have a bunch of large tests, and notably physics and Lin Algebra going on. I assumed that that report on the machines was sort of a no go since it was deemed complicated to figure out what machines should go under what name. That sheet I was linked to was like a book, and I didn't have the time to sift throught it. That was the wrong assumption I guess. I'd like just a simple breakdown by GHZ, but "simple" is a tough word we all know. Just something that is non complicated to look at. Something a user can just glance at and see hey a P4 3ghzish machine will get me on average of all the proteins about 70ppd(whatever it ends up to be). The ranking would be anything from 3.0-3.999 ghz all the ppd average together(or 3.0-3.4 and 3.5-3.9). Not precise but there isn't that big of a folding ppd range there, the production differences from people using the machine is can be large at times anyway.
Make the decisions mike, you can't please everyone. Something is better than the nothing that we currently have.
How can I tell how old a protein is? Or do you mean the age of the reported progress?MN Scout said:
Actually, this is pretty much done. The Work Rate by Processor Name report shows it. "Old" processors are in as of last weekend. The problem is that these names don't include chip core code names, or processor project code names. The names are eitehr what CPUID reports (which is the "marketing name") or, for the older processors, a name I entered when decoding the family/model/stepping information the processor gives.MN Scout said:
Sounds easy enough; I'll see if I can do it later today.MN Scout said:
What I'm most interested in hearing back from you about is ideas for the big "show list of machines" page. In particular, is there a neat, readable way to have a second line for each machine? Using color for groups, background color? This is what you seemed to be suggesting back in post #253.
My intention was to have this be the first statistical page people see. I've been resisting the urge to make the list wider, since it's already pretty big. I'm thinking of getting the OS version off there, and removing "Last update", too. Those can both stay on the machine details page.
With the additional space, I want to show the last time the machine reported work. What else should I show?
Thank you for your encouragement and feedback.MN Scout said:
I typed way more than I thought I would initially. Most of this post is about how to keep people coming back after the initial wow factor. Please read with an open mind. If something can't be done or is way to hard to implement just say so, I tried to only include things I knew we already had the data going for.
We are hoping that a lot of people will consider installing this. Not just from team 33 and e08's team. So we need to make it friendly and in some fashion that they are semi used to. If we look at Hardfolding and EOC we can see that there is a page that lists all the users from all teams, and there is a team breakout page and in our case also a machine breakout page(Yay!). So we should have those other to pages easy to access, but listed after the "Machine" page since we want to list our uniqueness first.
So the breakout would be like this:
Machine List:
We all want this to be a great database. I think we are on track to doing this. I think that we need to consider personalizing this so that are contributors want to comeback and install Yurt on more computers. I think the Yurt user profile page I mentioned would be a big help. Maybe we want to think about a user ranking within a team based on the number of total protein wu submissions and another ranking within the whole Yurt database. Create some competition. These rankings would be like the team rankings on Hardfolding and EOC and the global team rankings. The ranking within the whole Yurt database would go on the total User List page. Preferably this page would have sortable columns. Default to sort by global ranking, and then they could sort alphabetically by user name. If the user clicks on a team name within the team lists then that user page would have the first column be the users ranking within that team and then the total ranking second. I think we want people to say "Hey I'm the 5 highest contributor to the Yurt database."
We have a great base going here. Now we need to create it so people comeback after the initial wow factor.
I meant by the age of the reported progress.mikeblas said:
You are planning on breaking the page so it only shows 50-100 machines? I'm thinking that having a second line per machine might get a little much. You could color code the machines name like Hardfolding and EOC does does if the machine is in a certain ppd ranking. This same color coding idea could be brought over to a user list page. This brings me to the fact that I think you should have a page that lists all the users. Then you click on a user then it bring you to a list of their machines that they have running yurt.mikeblas said:
We are hoping that a lot of people will consider installing this. Not just from team 33 and e08's team. So we need to make it friendly and in some fashion that they are semi used to. If we look at Hardfolding and EOC we can see that there is a page that lists all the users from all teams, and there is a team breakout page and in our case also a machine breakout page(Yay!). So we should have those other to pages easy to access, but listed after the "Machine" page since we want to list our uniqueness first.
So the breakout would be like this:
Machine List:
- List all the machines collected, 25-100 per page
- Links to the users profile on the yurt database
- Link to the users profile on Stanford (Noticed this on the current Machine Page. Nice touch.
- I'd remove the pagefile and the CSD version info, the last updated can stay on the far right.
- List all the teams with members using the database.
- Team name would link to a list of all the users for that team.
- Total proteins that Yurt has collected for that team
- Current daily average of proteins collected
- Number of users of Yurt for this team(Also link to list of users for this team)
- Number of computers for this team(clickable link to page showing all machines for this team.)
- User Name(Links to Yurt Profile of this username)
- Number of Machines
- Column for link to Stanford Profile
- Average ppd from all machines(If they want more information that can always click to the user's Yurt profile, to get a list of machines and what they are producing)
- Big bold folding name
- Table that holds info. Something like this color coded table - holding diff. info though.
- Table columns would totals and averages for user: Total machines, Totals wus, Total Frames, Total Points(Don't know if you have this), Total CPU days - Frames and Wus
- Beneath this table would be a table that would have the list of this users machines. The column info would carry over from the Machines List page.
We all want this to be a great database. I think we are on track to doing this. I think that we need to consider personalizing this so that are contributors want to comeback and install Yurt on more computers. I think the Yurt user profile page I mentioned would be a big help. Maybe we want to think about a user ranking within a team based on the number of total protein wu submissions and another ranking within the whole Yurt database. Create some competition. These rankings would be like the team rankings on Hardfolding and EOC and the global team rankings. The ranking within the whole Yurt database would go on the total User List page. Preferably this page would have sortable columns. Default to sort by global ranking, and then they could sort alphabetically by user name. If the user clicks on a team name within the team lists then that user page would have the first column be the users ranking within that team and then the total ranking second. I think we want people to say "Hey I'm the 5 highest contributor to the Yurt database."
We have a great base going here. Now we need to create it so people comeback after the initial wow factor.
Yep. Pagination is hard, so I want to do it last, when the queries are very stable.MN Scout said:
This is implemented on the Work Rate by Owner page. You can click on a non-zero number in the machine count column and it'll take you to a list of that user's machines.MN Scout said:
Most of your suggestions aren't hard to implement at all; I'll see if I can get to them soon. Thanks for taking the time to write the note and get your ideas down; it's been one of the best contributions to the project so far.
I'll reorganize the Machine List page as we've discussed over the last few notes.
I can add a Teams List page to the top navigation bar. The only problem here is getting the team name; the FAH config file has the team number, but I've got no team name. Is there a public source for this info? Do I have to scrape the official Stanford site? (LATER: I found it linked from this page.)
The User List Page is also no problem; as above, it's already in the reports section. I can just reorganize it to make it more evident on the website.
The only one I don't think I can get to is the user profile page. The content isn't hard, but it means I have to implement security for the site, deal with passwords (which means dealing with forgotten passwords), and so on.
I think my terminology is a little confusing on the "user pfofile page". Really what I meant is just an extension of the "Work rate by owner" page that you already have. No passwords etc. to complcated. Just a page that is personalized and just has information relative to that folding user name. Everything else I listed under it still holds. I'll edit the post when I'm home from the gym. What do you think of the ranking based on # of proteins turned in to YURT?
I don't have time tonight, but tomorrow I'll spend an hour and get one or two mock pages made in Photoshop. I think that'll be a little clearer than the writing. So if you want to take a break for tonight and watch a movie, go out or something, take a needed rest. Pictures are always better.
Mikeblas - Something comparable to HardFolding's user stats would be great, and I think this is what MN_Scout is referring to as well.
For example, http://www.hardfolding.com/index.php?go=38&tm=33&id=176589
For example, http://www.hardfolding.com/index.php?go=38&tm=33&id=176589
OH, I see. What threw me was "individualized". There's nothing individualized about it, then; everyone gets the same report.MN Scout said:
I'm a little worried about competition, which'll temp people to abuse us, sine we've got no defense for validation. But we can go with it. The query is just the users list sorted descending by points. (I assume that's what you mean; you're not talking about covering the most number of protein IDs -- you're talking about doing the most work units and frames, right?MN Scout said:
Yes, that's true about the returning bad results. Maybe we only want to keep this to this to the slightly more die hard people, and not include the ranking. The ranking is a little bit more on the edge of competition then just letting them sort the points column. I'm just thinking in to the future about how we can drum up support for this and get new people downloading it. I guess we only want people who truly find the points interesting. Though this project go way past just are team. I find it difficult to think that the ballot stuffing wont happen sometime and maybe in large amounts. Will you have an easy way of removing the offenders name/computer and blocking it if need be? Any interface that an outside person could use to help you administrate this, if need be? I know this has come up before and we just basically decided that we hope the good results outweigh the bad.
We could try the ranking based on points and see how it goes?
We could try the ranking based on points and see how it goes?
MN Scout said:
No. As I've explained before, there are two problems: there's no validation. I can't prove that I really did the work that I'm reporting I've done. Then, there's no identity. So I can pump your results by impersonating your user ID.
That's a great way to win the competition; I score 1000. You score 1100. But I pump you for 2000 more. Someone notices you're pumped, and then has to delete all 3100 because they can't tell the good from the bad. So I win!
"But I guess we can go with it."MN Scout said:
mikeblas said:
mikeblas said:
Looking at these two posts together, does that mean that pumping the stats is not detrimental to the whole database. I'm just worried that the whole database is going to go down and we'll lose possibly months of data, because 1 person decides to fiddle around just one day with a whole bunch of usernames and stat pumping.
Otherwise, those changes you made last night are looking good.
It depends on what that person pumps.MN Scout said:
They could pump everything, since there's zero security. They could pump all my machines and all your machines, and every machine they can find. They can find lots of machines by looking at the machine ID lists.
So, yeah; they could pump the whole database.
If they pumpt only one machine, then the results are blown out for that machine. They'll slightly affect other reports that rely on data from that machine.
Look at the machine named "Enduro", for instance. That's my development machine here at home. As I explained, it gets pumped lots because I need to test; I run things more than once on purpose to measure and observe. I run things again after they worked halfway and then crashed.
So Enduro shows a really high work count. Any report that considers Enduro's work is going to be effected slightly; it's an Intel chip, so the list of Intel machines is pumped. That average is higher than it should be. The average is drawn down by all the machines that aren't pumped, but it's still high. There's one pumped machine with 15 other machines pulling it back.
The report by speed buckets that just went up is pumped for Enduro, too. There's only 3 machines in its speed bucket, so only two other machines pull down the average.
So it varies by the selectivity of the report. Mathematically, the effect of the pumping is related to the number of pumped machines divided by the number of total machines.
I'd rather defend against the bad behaviour than cut interesting features and still have them a chance at getting poisoned.MN Scout said:I hope that no one decides to do that.
Thinking about it, I can at least protect machines. Let's make a simple password in YurtInstaller at the time the machine is registered and stored that password at the site. YurtMonitor sends the password when it sends data. The site checks to see if the password is right; if not, the data is rejected.
The user doesn't even need to see this password; it's just a private key that the software knows and exchanges.
With this in place, any ability for one user to poison the data of another user by pumping is eliminated. A user can still pump themselves, but that just leads to their data and/or account being disabled.
The current todo list has some work for the client and the site.
Client software:
Website:
Client software:
- Add password
- Report how many directories are being monitored.
- Convert to a service
Website:
- Handle password checking
- Show cache size information
- Show physical/logical processor count
- Show number of clients running
- New reports as people submit ideas
- Consistency check; is given math done the same way on every page?
- Format/content changes as people submit feedback
- Still waiting for artwork decision
- Add Pagination
- Add sorting