Official YURT Design Thread (Development Discussion ONLY)

[AtomicMoose]

It would be neat to have a favorites icon.

What size are they typically?

 

[Kvothe]

Moose isn't the only one who can do artwork.

 

[mikeblas]

What size are they typically?

16x16. See this article for more details: http://msdn.microsoft.com/library/default.asp?url=/workshop/author/dhtml/howto/shortcuticon.asp

 

[AtomicMoose]

16x16. See this article for more details: http://msdn.microsoft.com/library/default.asp?url=/workshop/author/dhtml/howto/shortcuticon.asp

Why not use the small one I sent you?

 

[mikeblas]

Why not use the small one I sent you?

Okay.

 

[OSUguy98]

Has e08 ever mentioned a color scheme that he wanted or already has? I can't go to his website (from work)....


Keep on Folding!! For the [H]orde!!

 

[AtomicMoose]

Has e08 ever mentioned a color scheme that he wanted or already has? I can't go to his website (from work)....

This is a good question that I need to know the answer to.

 

[amenthes]

Moose isn't the only one who can do artwork.

So are we turning this into another design-a-logo competition with community voting and such?


/deja-vu

Oh and moose, that font/style reminds me of Ice Age!

 

[amenthes]

Just finished catching up on pages 8-15. Impressive. I'll be checking here regularly from now on to see if I can contribute in any way.

mikeblas: you mentioned a while back that CSS work was still TODO. I didn't see a mention of that being completed, but it appears that you're using style sheets now by looking at your html source. If you still need any assistance with that, please let me know, I can certainly help with html/css where needed.

 

[mikeblas]

mikeblas: you mentioned a while back that CSS work was still TODO. I didn't see a mention of that being completed, but it appears that you're using style sheets now by looking at your html source. If you still need any assistance with that, please let me know, I can certainly help with html/css where needed.

I thought I made a post about it being finished (mostly), but I can't seem to find it.

It's done, but now it looks like OSUGuy wants to let e08 to redesign the site, so I'll leave it to him to give you the final answer.

 

[OSUguy98]

whoa whoa... I never said anything about redesigning the site.... I'm talking colors for the logos/etc... If he likes Moose's banner, but wants green text, so be it.... I never said anything about changing your site......


Keep on Folding!!

 

[OSUguy98]

mikeblas... just a heads up.... I think you may have something wrong with one of your PCs... looking down through, I saw that this PC has one WU that's getting something like 1 min per frame..... not to mention 9700 ppd....


Keep on Folding!!

 

[enhanced08]

Talking about CPU Usage:

Nope, it doesn't; you're the first to suggest it. I guess I can see why you'd want it to look, but that number is just a suggestion. We have no idea if it's running more or less CPU time than the suggestion.

Actually this was one of the bits of data I wanted collected in the first place.

Right now you are collecting:
CPU speed, can we get this even on the older processors that you can't get the cpu string?
model
stepping
...pending we can get old machines information somehow, or ever, I guess we need to way this decision.

frame time
protein name
user name
team
computer name

Any reason why you decided not to collect more of the data I wanted collected? I realize that some of it would be hard to detect and other bits might not be as helpful. I said it before and i'll say it again, I think CPUz can help you out with this. Simply have your program run the CPUz program in ghost mode which will take about 1 sec to spit out a text file with all the system info I originally asked for. Then all ya gotta do is read the text file. CPUz can be bundled with YURT.exe and kept updated as new versions come out. The text file shouldnt change format too much between versions i wouldnt think. I'm not asking you to rewrite the code now for this but you mentioned making a revision down the road. Maybe add this in there since it seems to have been missed from the start. I'm willing to eliminate some of the items such as L1 or L3 cache, the processing tech (90nm) and such but I would like more than whats gathered now.

As far as webspace goes, you dont have to save all the data from each frame, thats a waste. Once a WU finishes and the average time and all other calculations are made the actual frame data can be deleted as long as the calculation results are saved. On my database at fah-database i have 105 total WU's submitted and its taking up something like 20kb which includes all of the system data i collected, the WU data, date, username, etc. If all of team 33 sent their data (about 2500 WU a day) that would be about 480kb worth of data per day, 15000KB per month and 175000KB per year.

I havnt tried the Beta client yet but am excited to do so.

As far as the website goes, I'm willing to find a webhost that has microsoft database if you would be willing to help me learn to use it. I might be able to talk my host into switching me over to a windows server as they offer both linux and windows services. I have been playing around with some banners but need to get them on a CD so I can get them to a computer with internet.

 

[mikeblas]

mikeblas... just a heads up.... I think you may have something wrong with one of your PCs... looking down through, I saw that this PC has one WU that's getting something like 1 min per frame..... not to mention 9700 ppd....

Yeah; there was a problem hooking up historized logging. I have to decide even if I'm going to disconnect it altogether or fix the client, or what.

The gory details:

CompletedWorkUnits has (MachineID, ProteinID, UnitCount, WorkTime, LastUpdatedDate). There's a unique index on (MachineID, ProteinID). When someone finishes a workunit, we update LastUpdateDate to the current date time (that the website was contacted and the stored proc executed). We incrememt UnitCount, and add what the client to told us to WorkTime as a total.

HistoryCompletedWorkUnits has (MachineID, ProteinID, WorkTime, CompletedDate). There's a unique index on (MachineID, ProteinID, CompletedDate). Since the completed date is the time that the website actually got the record and not the time that it was completd (because that's hard to calculate, since the log file is crappy about dates), I just use the time the record was inserted. But since more than one record might be entered in a submit to the website, I end up witht duplicates across the indexed column.

Then, the page that does the update fails the insert, so it reports a failure, which means the insert isn't removed from the client queue and that record is inserted again and again.

So if I have time this weekend, I'll work un the client to see if it can get a real date completed. If I can't, then I'll just get make the index not unique... but that doesn't enable the kind of queries we wanted to write against the table.

LATER: Hmm. Maybe this still is the root cause, but then why isn't affecting more machines? I'll have to look at MIKEBLAS5's log later to see if I can find anything interesting.

 

[mikeblas]

Actually this was one of the bits of data I wanted collected in the first place.

I think I already answered this adequately: there's just no way to measure it. We have no idea how much time the process really spent running.

Any reason why you decided not to collect more of the data I wanted collected?

It's at least partially because you weren't here to participate in the disussions as they went on.

Parsing the CPU-Z output is a little too fragile for my liking; it means I have to write a ton more parsing code, which isn't interesting work. We're locked into CPUZ's output, which may change from version to version, and we're stuck with their bugs.

(I think I explained most of that earlier, too. The forum is really effective for capturing decisions, but I guess only to the extent that people are willing to trudge through a long thread to find everything. Since search stinks here, it's not working out too well.)

Meanwhile, the code is already collecting everything that the CPUID instructions offer; it's just a matter of cracking more of it.

I'm willing to eliminate some of the items such as L1 or L3 cache, the processing tech (90nm) and such but I would like more than whats gathered now.

Such as?

As far as webspace goes, you dont have to save all the data from each frame, thats a waste.

So you don't like MN Scout's ideas for the reports based on that data?

Once a WU finishes and the average time and all other calculations are made the actual frame data can be deleted as long as the calculation results are saved.

This is what's currently implemented.

 

[enhanced08]

I think I already answered this adequately: there's just no way to measure it. We have no idea how much time the process really spent running.[\QUOTE]

Read it from the config file. Sure its not going to be 100% correct due to the way the system is used but it can be used for a reference. If at all possible it will use xx% of the CPU. 2 systems running the same speed will show different results if one runs folding 100% and the other 50%. Even if each system is a gamming system, the one at 100% will finish faster than the other simply because folding can use more of the CPU and uses it at every chance it gets. This is like with cars, MPG of a car isn't always what the manuf says it is, there are a ton of variables that come into play but in general it should get xx MPG and people will look at that and go with it. Same here, sure it will bounce around a bit but in general it will get xx% of the CPU.

It's at least partially because you weren't here to participate in the disussions as they went on.

I understand that, but I also had a website setup that was displaying this data as well as posting it in this thread.

Parsing the CPU-Z output is a little too fragile for my liking; it means I have to write a ton more parsing code, which isn't interesting work. We're locked into CPUZ's output, which may change from version to version, and we're stuck with their bugs.

Meanwhile, the code is already collecting everything that the CPUID instructions offer; it's just a matter of cracking more of it.

I understand this as well, I'm just trying to save some work on your part. The way I see it is either write your own version on CPUz or use it to collect the data for you and in my eyes its easier to use it.

Such as?

Socket, process tech, L1, L3, CAS, and hours. These things seem to make the least impact on the speed of folding except for CAS and we all know that the tighter the timming the faster the whole system will run including folding. Its also something that can be different on 2 systems which are "the same" just because of different brands and the amount of overclock. Plus from what I understand its hard to detect.

So you don't like MN Scout's ideas for the reports based on that data?

I dont think we are on the same page here. What can you gather from each frame other than average time per frame? once you have that I see no point in keeping the rest.

This is what's currently implemented.

I dont think we are on the same page with this.... How and what data is stored in the database as far as the WU times go?

 

[enhanced08]

I have YURT beta installed on a system now and am getting a second setup. I have noticed a problem already.

For some reason A unit I was working on today was lost when I restarted the system and it only finished 12 frames. In the FAH log file it only says

[01:50:34] Folding@Home Gromacs Core
[01:50:34] Version 1.86 (August 28, 2005)
[01:50:34]
[01:50:34] Preparing to commence simulation
[01:50:34] - Assembly optimizations manually forced on.
[01:50:34] - Not checking prior termination.
[21:49:54] - Expanded 3972861 -> 20311029 (decompressed 511.2 percent)
[21:49:55] - Error: Bad work unit. Digital signatures don't match
[21:49:55] Error: Could not open work file
[21:49:55]
[21:49:55] Folding@home Core Shutdown: FILE_IO_ERROR
[21:49:58] CoreStatus = 75 (117)
[21:49:58] Error opening or reading from a file.
[21:49:58] Deleting current work unit & continuing...
[21:50:02] Trying to send all finished work units
[21:50:02] + No unsent completed units remaining.
[21:50:02] - Preparing to get new work unit...

and doesnt display the EUE statment. Maybe there should be some script on the server that will compare how many unfinished units are vs the number of clients on a specific system and will delete any units that might be EUE and not get detected by YURT.

If you are still looking for a way to list physical cores/cpus in a system rather than the "HT core" you could have a script check to see how many CPUs it has and if it detects HT'ing then divide the CPU count by 2. Its a flaky way of doing it but it would work.

A second error I'm getting now is a program error on my second machine when trying to run YURTInstaller. Says YURTInstaller has created errors and must be closed. You need to restart the program. I'll check the logfile and see if I can figure out the problem, Its win2k btw.

 

[mikeblas]

I understand this as well, I'm just trying to save some work on your part. The way I see it is either write your own version on CPUz or use it to collect the data for you and in my eyes its easier to use it.

Changing to use it certainly doesn't save any work; right now, I just have to finish cracking the CPUID bits and can do that on the webiste (or in the database server) and it's done.

Moving to CPU-Z means that I write parsing code, figure out how to get CPUZ installed, figure out how to get it spawned (which isn't as trivial as you've assumed; oddly, it returns before writing the file!), change the database to represent the results, fix the website to accept the results, and so on.

Plus, I'll have to commit to reviewing and upgrading in the future.

Is this explanation adequate? Can we consider the matter closed?

Socket, process tech, L1, L3, CAS, and hours.

Actually, I'm asking about the ones that you'd like to see added, not the ones you are willing to eliminate; that would help me prioritize the work to crack more information from the CPUID data.

Cache sizes are easy to detect and can be inferred from the family/model/stepping when they're not reported by the CPUID instruction directly. That's clumsy, but workable.

CAS is all but impossible to reliably detect.

Process size and socket size can't be detected in any way that I know of, and must be inferred from the family/model/stepping. If you have a table of that data, it would help greatly. The ones I've got (previously linked in this thread) are usable, but incomplete.

I dont think we are on the same page here. What can you gather from each frame other than average time per frame? once you have that I see no point in keeping the rest.

MN Scout had some interesting suggestions about tracking how the rate changes over time, how the assigned proteins change over time, and so on. Post #247 is where he first submitted those ideas, I believe.

I dont think we are on the same page with this.... How and what data is stored in the database as far as the WU times go?

I explained not only what is stored, but the algorithm for updating in post #294 just a couple hours ago.

 

[mikeblas]

I have YURT beta installed on a system now and am getting a second setup. I have noticed a problem already.

What is the problem?

and doesnt display the EUE statment. Maybe there should be some script on the server that will compare how many unfinished units are vs the number of clients on a specific system and will delete any units that might be EUE and not get detected by YURT.

So you're saying that the problem is a work unit completion was reported to the website by YURTMonitor.EXE given those log entries? I don't see any completed work units for your machines at the moment.

 

[enhanced08]

Is this explanation adequate? Can we consider the matter closed?

Yup, I didn't know that it was all in the CPUID data which is already collected. That stuff id greek to me and I was out in the cold on that one. Just trying to help, sorry.

Actually, I'm asking about the ones that you'd like to see added, not the ones you are willing to eliminate; that would help me prioritize the work to crack more information from the CPUID data.

Cache sizes are easy to detect and can be inferred from the family/model/stepping when they're not reported by the CPUID instruction directly. That's clumsy, but workable.

CAS is all but impossible to reliably detect.

Process size and socket size can't be detected in any way that I know of, and must be inferred from the family/model/stepping. If you have a table of that data, it would help greatly. The ones I've got (previously linked in this thread) are usable, but incomplete.

Things I would like to include would be CPU core, CPU name, Multiplier, Speed (mhz), FSB (mhz), L2 (other cache's could be included but I dont think they are needed), amount of RAM, speed of RAM (mhz), Dual channel (could be left out but would be nice to include as well), operating system, and cpu usage as far as the computer specs goes. The you have your frame times, username, etc which is already included.

MN Scout had some interesting suggestions about tracking how the rate changes over time, how the assigned proteins change over time, and so on. Post #247 is where he first submitted those ideas, I believe.

Ah, ok. Something like frames 1-30 take an average of 1234 sec to complete while 31-100 take 4321sec to complete?

I explained not only what is stored, but the algorithm for updating in post #294 just a couple hours ago.

I'll re-read that post.

I mentioned a second error in an edit above, not sure if you caught it or not but after looking at the error closer it says "YURTInstaller.e.exe" caused an error, the program is correctly named as YURTInstaller.exe and I'm unsure where the extra ".e" came from.

So you're saying that the problem is a work unit completion was reported to the website by YURTMonitor.EXE given those log entries? I don't see any completed work units for your machines at the moment.

No, the unit never finished, it there was an error and it was deleted just like an EUE. Once deleted a new one was downloaded and is running now. YURTMon picked up both units and uploaded them both. The problem is that the one with only 12 frames will never finish because I dont have it anymore, its been deleted. Its just like an EUE only for some reason it didn't display the EUE error in the log file.

 

[enhanced08]

Now it seems the website has doubled the frames. It jumped from 12 to 24 on the first unit and from 38 to 76 on the second. The last frame uploaded from YURT was frame 38 on unit 2060 so its something server-side.

 

[mikeblas]

Says YURTInstaller has created errors and must be closed. You need to restart the program. Its win2k btw.

I need the exact error message; provide a screenshot (but preferably a text capture), if you have to. This might be hard to diagnose, though, since I have no machines which are running Windows 2000.

 

[enhanced08]

I played around with it and it was an error with a folder or something, I moved the program to the desktop and it works fine now. Rather odd. btw, apparently one day when a friend of mine was here he changed that system to fold under his name, t3ch so if you see that on your website its my system. Sorry about that I didn't know he had changed it.

Hmm.... this brings up something. I looked on my config files and it seems he only changed 1 file and not both since its a dually. On the website its showing up as a dual CPU machine but only running 1 instance under the name t3ch while not showing any under my username. There are some people who fold for more than 1 team and they may have something like this, one core folding for this team and another folding for that team.

 

[mikeblas]

Sorry, I missed this before:

As far as the website goes, I'm willing to find a webhost that has microsoft database if you would be willing to help me learn to use it.

I'm signed on to develop, and that's mostly fun. I answer lots of specific questions over in the programming forum, and write essays to post here and there on the site -- but I'm not really interested in tutoring.

And I missed this because the QUOTE tag was broken and I thought I had written it:

Read it from the config file. Sure its not going to be 100% correct due to the way the system is used but it can be used for a reference. If at all possible it will use xx% of the CPU. 2 systems running the same speed will show different results if one runs folding 100% and the other 50%. Even if each system is a gamming system, the one at 100% will finish faster than the other simply because folding can use more of the CPU and uses it at every chance it gets.

The idea of reading it from the config file was discussed before.

Your assertion about the machine set to run at 100% will finish faster than the machine set to run at 50% isn't true. The default priority for the folding at home processes is "idle". If both of the machines are never idle, or the 100% machine is idle less often than the machine set to 50%, the machine set to 50% will finish the same FAH work faster than the 100% machine.

You might be closer to correct if the client is set to run at "low" priority instead of "idle". Seems like we'd have to get both the priority and the percentage from the config file. (And what if it's not there? We have to assume the default -- and the default might change.)

The questions I have about how to present and categorize this data in the reports remain open. They are in post #228.

Ah, ok. Something like frames 1-30 take an average of 1234 sec to complete while 31-100 take 4321sec to complete?

I think the date would be the more likely axis rather than a frame number. Note that we've also been talking about doing this for work units, not for frames.

Things I would like to include would be CPU core, CPU name, Multiplier, Speed (mhz), FSB (mhz), L2 (other cache's could be included but I dont think they are needed), amount of RAM, speed of RAM (mhz), Dual channel (could be left out but would be nice to include as well), operating system, and cpu usage as far as the computer specs goes. The you have your frame times, username, etc which is already included.

I'm not sure how to respond to this because so many of the things you've listed are already collected and very apparent at the website. Many other things are items which I've said can't be detected easily, way back when I first started working on the project. Repeating every discussion and rewriting every explanation whenever you come back to the thread isn't fun for me.

Here are the things that are not only collected, but already shown on the site:

• Speed (Mhz)
• Amount of RAM
• operating system

These things are collected, but not yet decoded from the CPUID data:

• L2 cache

I can't guess what you mean by "cpu usage as far as the computer specs goes" means. Can you clarify that?

As I previously explained, "CPU core" isn't detectable, though I think it can come from a table given the vendor, family, model, and stepping. Again, if you have a table of these values for available processors that is better than the one I previously linked to, it would be helpful. CPU Core names are not official; they're internal code names for the development projects, and as such they're in no official public documentation offered by Intel or AMD.

There's no specific thing called "CPU name". The processor reports a brand name, which we currently show. (For example, your machine reports as "Intel(R) Pentium(R) 4 CPU 3.20GHz".)

There's also a brand ID which older processors can provide, given a table. I need to get the table from the spec I have into the database, and write a query that gets it back out for each processor. This is why older processors, like my Pentium III machine, don't report anything in the "name" field.

No, the unit never finished, it there was an error and it was deleted just like an EUE. Once deleted a new one was downloaded and is running now. YURTMon picked up both units and uploaded them both.

As far as I can tell, it didn't. The only machine that you've registered is shown here, and it indicates no submitted work units.

 

[mikeblas]

I played around with it and it was an error with a folder or something, I moved the program to the desktop and it works fine now. Rather odd.

I don't have enough information to make any diagnosis. But I will point out that the desktop is just another folder.

btw, apparently one day when a friend of mine was here he changed that system to fold under his name, t3ch so if you see that on your website its my system. Sorry about that I didn't know he had changed it.

If you want to fix the name, do so with the -CONFIG option on the FAH client, then rerun YurtInstaller.EXE. Isn't it explained in the documentation, that you can rerun the Installer any time you'd like? I thought I had covered it.

Hmm.... this brings up something. I looked on my config files and it seems he only changed 1 file and not both since its a dually. On the website its showing up as a dual CPU machine but only running 1 instance under the name t3ch while not showing any under my username. There are some people who fold for more than 1 team and they may have something like this, one core folding for this team and another folding for that team.

Only the information in the first configuration file found is registered. The website doesn't track instances.

If we want the same machine ID to be able to track work seperately for different instances of the client, I'll have to substantially remodel the database. The MachineID is used as a key for everything; the key would have to become a composite of the MachineID and the directory name, since there's no other way to identify an instance of the client program. The directory name(s) can change, and so they don't make a very good key.

 

[mikeblas]

Wow; I've burned two straight hours answering questions here. Again. My morale is pretty low; maybe I should take a few days away from this project.

 

[enhanced08]

I'm signed on to develop, and that's mostly fun. I answer lots of specific questions over in the programming forum, and write essays to post here and there on the site -- but I'm not really interested in tutoring.

I didn't mean teach me everything you know, I meant point me in the direction to learn some basics and if I have a question I would be able to ask you.

And I missed this because the QUOTE tag was broken and I thought I had written it:

Sorry.

I'm not sure how to respond to this because so many of the things you've listed are already collected and very apparent at the website. Many other things are items which I've said can't be detected easily, way back when I first started working on the project. Repeating every discussion and rewriting every explanation whenever you come back to the thread isn't fun for me.

Here are the things that are not only collected, but already shown on the site:

• Speed (Mhz)
• Amount of RAM
• operating system

These things are collected, but not yet decoded from the CPUID data:

• L2 cache

I know some of that is already on the site but I figured I would list it all anyway.

I can't guess what you mean by "cpu usage as far as the computer specs goes" means. Can you clarify that?

"cpu usage, as far as computer specs goes" as in, all of that information would be the computer specs. Must have missed a comma.

As I previously explained, "CPU core" isn't detectable, though I think it can come from a table given the vendor, family, model, and stepping. Again, if you have a table of these values for available processors that is better than the one I previously linked to, it would be helpful. CPU Core names are not official; they're internal code names for the development projects, and as such they're in no official public documentation offered by Intel or AMD.

There's no specific thing called "CPU name". The processor reports a brand name, which we currently show. (For example, your machine reports as "Intel(R) Pentium(R) 4 CPU 3.20GHz".)

There's also a brand ID which older processors can provide, given a table. I need to get the table from the spec I have into the database, and write a query that gets it back out for each processor. This is why older processors, like my Pentium III machine, don't report anything in the "name" field.

Ok, I see what you mean about the core name. Thats understandable. I know the official name isn't "CPU name", but you knew what I meant.

As far as I can tell, it didn't. The only machine that you've registered is shown here, and it indicates no submitted work units.

It hasn't finished a unit yet but its showing 2 units. One of them is being worked on now and the other was deleted before it finished. Something caused an error and the unit was deleted. I can't make it anymore clear. If I happen to download that same unit again and finish it then i'll have 112 frames finished where I should have 200, its not a complete unit, unless you had planned on collecting data from unfinished units...

If you want to fix the name, do so with the -CONFIG option on the FAH client, then rerun YurtInstaller.EXE. Isn't it explained in the documentation, that you can rerun the Installer any time you'd like? I thought I had covered it.

Yes, I know how to change the name and yes the docs covered that. What I'm saying is that what if someone if folding under 2 different names for 2 different teams on the same system? The website isn't showing the data correctly for this.

 

[mikeblas]

Now it seems the website has doubled the frames. It jumped from 12 to 24 on the first unit and from 38 to 76 on the second. The last frame uploaded from YURT was frame 38 on unit 2060 so its something server-side.

How did you shut down the YURTMonitor.EXE? What happened when it restarted?

I didn't mean teach me everything you know, I meant point me in the direction to learn some basics and if I have a question I would be able to ask you.

That's what I meant, too.

Ok, I see what you mean about the core name. Thats understandable. I know the official name isn't "CPU name", but you knew what I meant.

Actually, I didn't know what you meant. The whole point of my explanation is that "CPU name" doesn't mean anything consistent or specific. When working with databases, its imperative to be very consistent and specific. Otherwise, bad things happen; from running into data that's to inconsistent to be aggregable, to having bad data integrity problems.

If I happen to download that same unit again and finish it then i'll have 112 frames finished where I should have 200, its not a complete unit, unless you had planned on collecting data from unfinished units...

Yes, we collect data from unfinished units. A trackable section of work from an unfinished unit is called a "frame". You've got some data from different frames listed there, but you have no data from any units, at all, listed on the site.

What I'm saying is that what if someone if folding under 2 different names for 2 different teams on the same system? The website isn't showing the data correctly for this.

The website is behaving as designed. I provided an explanation for this in post #305.

 

[enhanced08]

How did you shut down the YURTMonitor.EXE? What happened when it restarted?

I did nothing, it was running the whole time, i simply refreshed the webpage and noticed the numbers changed.

Actually, I didn't know what you meant. The whole point of my explanation is that "CPU name" doesn't mean anything consistent or specific.

By cpu name I was talking about something like what you had mentioned about my system. "Pentium 4 3.2" or "Athlon XP 3200+"

Yes, we collect data from unfinished units. A trackable section of work from an unfinished unit is called a "frame". You've got some data from different frames listed there, but you have no data from any units, at all, listed on the site.

So you have data from frames and data from the whole unit seperate? How does this work? For the frames is it a total of all frames of a given unit? ex. if I do 10 of unit 1234 and each is 100 frames, unit 1234 would be listed as a total of 1000 frames completed? This is the way I understand it from looking at the site.

 

[mikeblas]

I did nothing, it was running the whole time, i simply refreshed the webpage and noticed the numbers changed.

Then I'd like to see your complete YURTMonitorLog.txt file for the machine in question, as it is very strange that the application would spuriously send out the data again without having been restarted.

So you have data from frames and data from the whole unit seperate? How does this work? For the frames is it a total of all frames of a given unit? ex. if I do 10 of unit 1234 and each is 100 frames, unit 1234 would be listed as a total of 1000 frames completed? This is the way I understand it from looking at the site.

Yes, data from frames and data from completed units is tracked seperately.

When you ask "For the frames is it a total of all frames of a given unit?" and I can't guess what "it" means. The submitted frames list shown is exactly what it says: the monitor program noticed that the client has completed a frame and told the database at the website about it. The frame is not associated with any particular work unit; it is related to a ProteinID and a machineID.

Yes, if you complete ten units and each unit has 100 frames, then we'll know about 1000 frames; as long as the timespan from every frame in that bunch was usable as it was found in the log, anyway.

 

[enhanced08]

I'l send you an email with the log file.

 

[mikeblas]

I'l send you a PM with the log file.

I'd prefer an email, please.

 

[enhanced08]

Sent via email.

On the website, where you display the average time per frame, I assume you do this from all frames of that protein, which would be logical but there is a problem with that. I'm not sure if this is the case with all work units but I know that some finish specific frames faster than others. For instance frames 1-30 might go real quick while the remaining take much longer. This could be a problem for instances like with the protein frames returned for unit 1481 on my machine where it only has 12 frames. These 12 frames could have a much lower time than the others and cause the average to be wrong. So you either would need to delete the uncomplete units or not use this data as an average. I'll try and find more detail on this.

 

[mikeblas]

Sent via email.

Thanks for the email.

The log you sent shows that the client application was terminated without being shut down cleanly. Why, then, did you tell me that "I did nothing, it was running the whole time"?

On the website, where you display the average time per frame, I assume you do this from all frames of that protein,

It depends on where you're looking. The value might include only for the frames run by the given machine, or a particular user. I think that the "Show List Of Proteins" page is the only place where all frames of a protein are considered.

I'll try and find more detail on this.

Please do. Nobody else here has brought that issue up. I've based the current behaviour on your advice that PPD is calculated using the average time per frame. You made no mention of the frames not being consistent fractions of a workunit. And when I explained that scheme to you the last time you were participating in the thread, you said it should work fine.

 

[ICE_9]

Review of manual:

1. I am happy to answer questions and take suggestions about the software at the
HardForums Pg.6

Correct "HardForums" to be "Hard|Forum" to match the title of the forums.

2. You might want to put a disclamer in there about monitoring a networked FAH folder. I don't understand the background of the reports but it makes me wonder if reports for the other network folder will be registered under the computer that was registered for that YURT client.

Beyond that, I saw no error in the Manual. Very well done!!!

 

[mikeblas]

Beyond that, I saw no error in the Manual. Very well done!!!

Thank you for your encouraging words.

I've fixed #1 and #2 and you should see the changes when there is another update of the software.

 

[enhanced08]

I found a typo in the manual, page 4 under YURTMonitor, third paragraph, line 4 it says "YURTINstaller" where the "N" should be lowercase. Other than that the manual seems very complete and is packed with information.

EDIT: This isn't a big problem, but the registry entry is under [H]ardOCP which would move away from the idea that this is not attached to a specific team.

Right under that on page 5, the Using the Website section has an error in the first paragraph. It reads "...using to run the Stanford at Home client..." It should be either 'Stanford Folding at Home client' or 'Folding at Home client'. There is no "Stanford at Home client".

 

[enhanced08]

I wanted to take this time to thank mike and the rest of you for that matter, who have helped get this project moving. I started this back in November and in a matter of weeks I was pretty much at the end of what I could do on my own so for about 4-5 months I have been looking for some help. I was turned down by a number of people because of time or lack of intrest and for "copying" the website www.fahinfo.org.

I try to do what I can to help, but I'm new to databases, new to PHP, and am in no way a programmer! You all have helped fill the gap where I couldn't and I thank you for your help thus far.

Mike and I have been chatting via email for a number of hours now and I hope we have things figured out. Things should be a little smoother now, I hope. Sorry Mike!

Lets move forward!

Graphic Design:
I'm not great with Photoshop or anything but play a little here and there. If you guys want to come up with some banners we can vote on the best one and use it or even have a few different ones. The layout on my website can be used if you wish. A friend of mine helped me with it and I would like to use it or a form of it as the final layout. I have heard some nice thoughts on it. What do you all think?

As I stated earlier, I'll take care of the hosting and all, just let me know what your looking for in a database. MySQL is all I have ever used so I dont know what to even look for in a Microsoft database. MS SQL and MS Access are the 2 I have noticed, which do you prefer?

Please do. Nobody else here has brought that issue up.

Here is some info on it. Bruce calls it a "Folding Event". This folding event is the reason the average time per frame might be wrong if its calculated based off all the frames recorded for a specific protein. If for some reason your working on a unit that causes an error and is deleted durring the "faster" frames, these frames will be uploaded and could throw off the averages. It wont do too much damage if its only a few frames but if it happens often then it will cause more damage.

 

[amenthes]

enhanced08 - MSSQL is what you want, Access is not really a widely-used database in my experience. Different SQL flavors are preferred for web-based things (MySQL, PostgreSQL, MSSQL, etc)

Mikeblas would have to confirm the details, but I imagine you want a hosting plan that runs on a Windows server with MSSQL 2000 or newer, and support for ASP.net. All of that should be pretty standard. The big considerations would be disk space and bandwidth.

 

[OSUguy98]

So what's going on? it's been kinda quiet for a day or two.... where do we stand on things?

mike, server-side, did we rule out removing outlier data? i.e. not considering frame times that are ___% above the average.... or is that something we're doing already?


Keep on Folding!! For the [H]orde!!