• 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.

YURT 1.0 Released

Status
Not open for further replies.
Hades12 said:
We got one of mine working. Will start adding more machines.
Click to expand...
Great, glad to hear it. One of the challenges of this project was moving through different languages: HTML, CSS, and ASP on the website, SQL, and C++. Your team number is larger than 2**15, and I had used CINT() in VBScript to convert it to a number because I think an integer is 32 bits wide, so that's what caused the script to fall over when you tried to register.
 
Annnnd my "big dog" (Colossus) is now registered! Between it and "Lil-Blue", they'll give me my own stability test to see if I should drop it on the rest of the farm crates.

Quick skim of the docs shows it doesn't monitor remote machines. Limitation of Windows share function, Samba, or is it more along the lines of machine ID mixing? At any rate, if it passes, you get all the crates I have in Boomerhaus and at the office.


Heh. "YURT". Never thought that name would make it to the program when I floated it. I thought Travois had a better chance... :)

 
Strikemaster said:
Quick skim of the docs shows it doesn't monitor remote machines. Limitation of Windows share function, Samba, or is it more along the lines of machine ID mixing? At any rate, if it passes, you get all the crates I have in Boomerhaus and at the office.
Click to expand...

It's a limitation of the Folding at Home client, actually. (I've been looking at its code, and it's scary-bad, by the way.) The client publishes no event to let any observer know that a frame or work item has been completed. So we're left spying on file writes, which is both awkward and difficult.
Strikemaster said:
Click to expand...
 
Can someone read the very well written manual, then answer a few questions for me?

:p
 
I'm going to start deleting machines. Any machine that has previously submitted work, but hasn't submitted anything for 60 days will get deleted. Any machine that hasn't submitted work ever will get deleted 30 days after its registration date.

There are a few machines that have registered but haven't submitted any work. Before I delete them, I'd like to know if their owners think they should have submitted work. If so, send me an email or a PM over the next week and we'll see if we can figure it out. Otherwise, they get the axe.

If that process reveals no bugs, I'd like to release Yurt 1.01. That fixes a problem with machines that see pause at the wrong time submitting work against protein ID -1.
 
I got one machine down right now not doing output due to heat problems. Please don't delete ICE_9. It has only been down a week. I just need to get some AS5 and I will be as good as new.
 
It's not a manual process, so I can't intervene. You've got 60 days since your last work unit, so you still have more than 8 weeks before you're in trouble.
 
installed on most machines, waiting for laptop still.

update: installted on all machines that I have direct access to. There are a few that -may- be crunching some # at times, but they are hard to get to (location).

Question:

How does it deal with the dynamic clockspeed of my Pentium M proc?
 
drizzt81 said:
How does it deal with the dynamic clockspeed of my Pentium M proc?
Click to expand...
From what I understand it scans the speed during the initial install (or therea a bouts) and records that in the database. There's no support for dynamic clock speeds, I hope soon tho.
 
dekard said:
There's no support for dynamic clock speeds, I hope soon tho.
Click to expand...
Things that nobody has ever asked for are very unlikely to be supported.

How would you imagine this support to work, meanwhile?
 
mikeblas said:
Things that nobody has ever asked for are very unlikely to be supported.

How would you imagine this support to work, meanwhile?
Click to expand...
my concern was that my Pentium M does change its clockspeed every once in a while. I had it downclocked to a 12x multi recently (even on AC) and now I have it back up to a 15x multi. I guess I need to re-register it?
 
question: why would one delete old computers that aren't producing anymore? i'm assuming the information gathered is still saved, just actual computers?
 
drizzt81 said:
my concern was that my Pentium M does change its clockspeed every once in a while. I had it downclocked to a 12x multi recently (even on AC) and now I have it back up to a 15x multi. I guess I need to re-register it?
Click to expand...
Almost any machine can change its clock speed at any time. Processors downshift to throttle for heat or power saving or noise. The Pentium M chips do it for battery life.

But why does it matter to YURT? The numbers collected aren't involved in any math; they're just shown on the machine details. Since the clock speed can change very frequently, there's no good way to historize it.

If you don't like the speed that's shown for your machine, just reregister. Doing so won't wipe out your previous work and will override the old clock speed (and memory, and so on) with your current values.

MaoKhan said:
question: why would one delete old computers that aren't producing anymore? i'm assuming the information gathered is still saved, just actual computers?
Click to expand...
I'm far more interested in deleting machines that have registered and haven't produced anything.

Machines that haven't produced for a while are contributing stale data: they're likely to not have used current versions of the clients, not likely to represent current scoring for the proteins, and so on.
 
MaoKhan said:
ah makes sense, carry on :)
Click to expand...
Well, I'm open to convincing. It's not like query perf or space is a problem so far.
 
If it wasn't for YURT... I wouldn't have noticed that one of my computers was having problems with all the power resets from the storms....


oh well :)

I got it installed on 4/7 computers, with 5 active procs.
 
One thing i had to recommend to you mike (not sure if this is the right thread):
Maybe a quick batch file that comes with YURT to install it as a services. I made a quick one for myself to make installing quicker. Just a thought. and yea...you did do a great job on it. I keep forgetting that it is even installed :)
 
yes service install would be sweet. might be one of the big problems keeping this from taking off, people just forget to turn it on...and on that note... :p
 
roftranspo said:
Maybe a quick batch file that comes with YURT to install it as a services. I made a quick one for myself to make installing quicker. Just a thought. and yea...you did do a great job on it. I keep forgetting that it is even installed :)
Click to expand...
I'm not sure how a batch file would be simpler than typing "yurtmonitor install". What is it that you would want the batch file to do? What does your file do?

Thank you for your kind words.
 
I'm guessing it's just something you click on in the directory that YURT stuff is un-zipped too, double click and it does the whole cmd :\ yurt install stuff all in one go
 
KodiakStar said:
I'm guessing it's just something you click on in the directory that YURT stuff is un-zipped too, double click and it does the whole cmd :\ yurt install stuff all in one go
Click to expand...
pretty much....my just went:
cd \yurt
yurtmonitor install
net start yurtmonitor

i think that is how it went or something close (the one i used is on a computer that i currently dont have access to) but yea...anything that keeps people out of command prompt and services.msc is usually a good thing :)
 
mikeblas said:
Almost any machine can change its clock speed at any time. Processors downshift to throttle for heat or power saving or noise. The Pentium M chips do it for battery life.

But why does it matter to YURT? The numbers collected aren't involved in any math; they're just shown on the machine details. Since the clock speed can change very frequently, there's no good way to historize it.

If you don't like the speed that's shown for your machine, just reregister. Doing so won't wipe out your previous work and will override the old clock speed (and memory, and so on) with your current values.
Click to expand...

First off: I was not trying to critizise your work. I greatly appreciated it. I understand that saving a history would be difficult, I was asking, since I was under the impression that yurt was partially intended to provide statistics on how quickly certain cores were able to complete work. I did not want to poison the source data. I will re-register my laptop tomorrow, when it'll be back in use.
 
drizzt81 said:
First off: I was not trying to critizise your work. I greatly appreciated it.
Click to expand...
No offense taken at all.

drizzt81 said:
I understand that saving a history would be difficult, I was asking, since I was under the impression that yurt was partially intended to provide statistics on how quickly certain cores were able to complete work. I did not want to poison the source data. I will re-register my laptop tomorrow, when it'll be back in use.
Click to expand...
It's not really poisoning, since the clock speed can't be that dramatically off. Also, since we don't know what users are doing with the machine, the cycles the folding process has available to it vary greatly. A couple of my machines are almost completely idle; others are development and test server machines that are heavily loaded whenever I'm in front of 'em. FAH might be getting 0% CPU for hours at a time on those rigs. There's just no realistic way to measure it or historize it.
 
I think as-is is great, and just fine for the purposes we need it for... this isn't a controlled test to find out EXACTLY everything, but gives us a better clue for those who can't get enough numbers
 
mikeblas said:
Well, I'm open to convincing. It's not like query perf or space is a problem so far.
Click to expand...
Depending on what statisitics are to be collected and for what reason, there would always be the option to "weigh" the data with repect to the time it was added to the DB. More recent data in the DB would have a greatest influence on the expected output from a certian processor while older data would be incorporated but at a lesser weight. Then again, it is probably easier and less computationally expensive to just delete the records.
 
mikeblas said:
It's not really poisoning, since the clock speed can't be that dramatically off. Also, since we don't know what users are doing with the machine, the cycles the folding process has available to it vary greatly. A couple of my machines are almost completely idle; others are development and test server machines that are heavily loaded whenever I'm in front of 'em. FAH might be getting 0% CPU for hours at a time on those rigs. There's just no realistic way to measure it or historize it.
Click to expand...
Slightly different topic, since you mentioned it: CPU time usage.

Since the Yurt serivce is running, would it be possible to 'locally' compute the CPU time consumed by FAH? Looking at task manager, I can see a "CPU Time" column. If Yurt ran as admin/ system would it not have access to this? Of course, the problem would be at which point to record and send this data. Maybe during shutdown (there has to be a hook). Then again, what is FAH was restarted or has died before we get to look at the "cpu time" statistic.

Certainly all these factors make this problem rather complicated.
 
Looking around the stats page... is it possible to get an average PPD? I see it's listed for each individual protein (or frame), but it'd be nice to see what each machine puts out on average... so I can see how my machines stack up.

I'll get this setup on my two AXP machines and my Opty 165 later tonight.
 
ElektronikSeraph said:
Looking around the stats page... is it possible to get an average PPD? I see it's listed for each individual protein (or frame), but it'd be nice to see what each machine puts out on average... so I can see how my machines stack up.
Click to expand...
Which page do you mean? After all, they all have stats!
 
mike,

Why on the Machine page does it not show frames for all proteins, or the current protein?
I only seem to have frame stats for the first protein YURT tracked and no others.

Enjoy the stats! :)

 
mikeblas said:
Which page do you mean? After all, they all have stats!
Click to expand...

Well I was kind of expecting to see average PPD on a Machine Details page, at the bottom of the PPD column - like where the Totals are listed for Protein IDs, Work Units, etc.

EDIT: Guess it was kind of stupid of me to not specify, lol. Sorry about that.
 
Celerator said:
mike,

Why on the Machine page does it not show frames for all proteins, or the current protein?
I only seem to have frame stats for the first protein YURT tracked and no others.
Click to expand...

Frames for all proteins known? Because most people don't work even 1% of the available proteins, and you'd have a big long page of zeroes.

Frames for all proteins that you've worked? Because frames are only recorded for proteins that YURT partially observes. If you work a protein from start to finish, without pausing, and YURT sees it all, then it reports the whole protein. If it doesn't see everything, or sees that you paused (or rebooted, or restarted) it will report only the frames.

We don't track proteins in progress -- to much traffic. Plus, we'd have to go back and remove the 99 (or 399) frames you'd reported when you finished the 100th (or 400th) and convert the work to a full protein.

ElektronikSeraph said:
Well I was kind of expecting to see average PPD on a Machine Details page, at the bottom of the PPD column - like where the Totals are listed for Protein IDs, Work Units, etc.
Click to expand...
I can add it, it shouldn't be too hard.

ElektronikSeraph said:
EDIT: Guess it was kind of stupid of me to not specify, lol. Sorry about that.
Click to expand...
It's not stupid; just really vauge. Since I'm not psychic, I'm bad at guessing games and have to ask.
 
mikeblas said:
I can add it, it shouldn't be too hard.

It's not stupid; just really vauge. Since I'm not psychic, I'm bad at guessing games and have to ask.
Click to expand...

I'd appreciate it! And I'm setting my machines up now.
 
ICE_9 said:
Congratulations YURT on reaching 200+ registered machines!!! :eek:
Click to expand...
I've run the scripts to nuke machines which haven't ever submitted work for more than a month. That knocked us down to 202 machines from 208.
 
Simple Request:
Add a PPD column to the Detailed Work Unit History on the Details for Machine report. I think this is a simple calculation based on the information in two existing columns. Edit this would allow me to see how tweaks to a dedicated folder impact PPD of specific WU's over time.

I love YURT! However, knowing that a rig has spent 78 days out of 178 total days crunching it's three least productive WUs is very frustrating! See units 1700, 1714 and 2055.
 
Status
Not open for further replies.
Back
Top