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

Action Required: Upgrade your YURT client!

M

mikeblas

[H]ard|DCer of the Month - May 2006
Joined
Jun 26, 2004
Messages
12,777
YURT 1.11 was released about a month ago. A surprising number of machines are still running YURT 1.00, and haven't been upgraded.

This weekend, I'll start kicking machines out of the database which aren't running YURT 1.11. Please update your machines to YURT 1.11 if you wish to keep participating. If you don't wish to participate, please shut down and remove your YURT 1.00 clients.

Thanks.
 
sorry...i will get to that today or tomorrow depending on work load.
 
One of my systems are gone. You can eliminate it from the DB if you like. The_Beast is the system name.
 
I've done all mine that I can get to, only ones running the old client are my borgs
 
sobe said:
I've done all mine that I can get to, only ones running the old client are my borgs
Click to expand...
What does that mean?

ICE_9 said:
One of my systems are gone. You can eliminate it from the DB if you like. The_Beast is the system name.
Click to expand...
Thanks -- it should get picked up by the automated process soon.
 
OSUguy98 said:
borg = computer that you don't own/have 100% access to 24/7..... i.e. your neighbor's PC which is folding under your name.... you don't own the PC, but you have the go-ahead to run F@H on it...
Click to expand...
I meant more "what does that mean for getting that machine upgraded". Sobe, it would be great if you could ask the machine owner to either stop YURT or upgrade. Thanks!
 
AtomicMoose said:
Sounds like it's time for an auto updater. ;)
Click to expand...
It wouldn't do any good, since the code in the field doesn't support it and that's what needs to be updated. That horse has already left the barn. I don't think it would be so hard to implement, but I'm very leery of the security issues. Coupled with inadequate testing, it could be a disaster.
 
While I would love an auto-updater, I think that Mike has an excellent point about the security implications. I am in no way doubting Mike's programming prowess, but I think that having YURT auto-update would be quite a bit of risk, considering that it's running as a service, i.e. as the system account.

ps.:thanks for the tool :)
 
How about this: When YURT sends results, does the server give a return message? Perhaps it could send back a "you're outdated" message to older clients, and in response the client shuts down the service and sets it not to autorun. Then you don't get outdated information.

 
unhappy_mage said:
How about this: When YURT sends results, does the server give a return message? Perhaps it could send back a "you're outdated" message to older clients, and in response the client shuts down the service and sets it not to autorun.
Click to expand...
Sure. But that would require an update to the client, which users apparently aren't willing to install.

If you check the log for your own machine, I think you'll see

Code: 
0,Error: Client version no longer supported.

from all the time you were running 1.10 after 1.11 was released.

unhappy_mage said:
Then you don't get outdated information.
Click to expand...
No outdated information is reaching the database now, as it's being turned away by the scripts. The only problem is that the client keeps the information and tries to send it again (and more) later. I haven't gotten 'round to writing a script to analyse it in my logs, but I don't believe this adds up to much load. I is load, however, and it would be nice to make it stop.

I can mitigate it by making the server "lie" to the outdated clients, saying the data was accepted. The client will discard it and not send it again, but the client will still run and send new data later.

For each completed work unit, the work time, and the ID are sent. The protein ID is never longer than 4 characters, and the worktime could be five characters at most (99999 seconds is 1.15 days). So maybe it's six, but that's really bad.

A thousand work units would be at most 11,000 bytes, all of which are ignored. It doesn't seem like such a great bandwidth problem, but I'd rather see people who've taken the time to install the client upgrade so they're still participating in the proejct.
 
mikeblas said:
Sure. But that would require an update to the client, which users apparently aren't willing to install.
Click to expand...

Hey now, I upgraded mine... After you made the second post about it.... :p :D

Drunk talk: Was just installing YURTisfreakingawesome on another computer, and realized how much time you must have put into this endeavor. The manual is 10 pages long, and with 100% perfect grammar I might add, and must have taken a while to write. So, from the bottom of my heart, I thank you Mr. Blaszczak, for creating this awesome program/database/website for us to use.

Drunk Talk Disclaimer: Drunk talk does not in any way, shape, or form reduce the sincereness of said drunktalker's statement.

 
<drunktalk>
sheshis, Oldbenwa, you're the best. I mean, man, shesish, seriousssshit. Man.
</drunktalk>

Seriously, thank you for your kind words. It was [mostly] fun to work on, though a lot more data would make it even more interesting.
 
It's past next weekend, so I'm pruning machines. Rigs owned by Tigerbiten and roftranspo are two of the next big contributors on the chopping block.
 
Would it be possible to have a post of the machine names that are currently on the wrong version or whatnot? Maybe throwing that up in here would get everyone a little more proactive about upgrading their clients.
 
mikeblas said:
<drunktalk>
sheshis, Oldbenwa, you're the best. I mean, man, shesish, seriousssshit. Man.
</drunktalk>

Seriously, thank you for your kind words. It was [mostly] fun to work on, though a lot more data would make it even more interesting.
Click to expand...

:D Added my Dual Athlon MP 2400+ box to the mix, and now I'm off to add my lappy. :D
 
Great! That gets us from 39% obsolete clients to 37%.
 
OK, I finally chased down the last couple cpu's running the old client. Basically I just disabled the the service on all machines.

To be honest , I have not updated the clients and restarted the service because I'm not totally sold that we are getting meaningful data out of the project. As Mike has noted, there has not been much correlation to date between proteins vs. PPD , or machine speed vs. PPD..
This is not to say that YURT has no value. But taking into account the "gut" knowledge that more machines = more PPD, I think that so far YURT has shown that we are not taking enough of the variables into consideration. Initially, the concern was over OC'd machines vs. stock cpu speed reported. But I think that configuration variability plays an even bigger part. I know that by tweaking each machine's FAH config, I can significantly increase my PPD. As simple as putting the -forceasm switch on when I had forgotten it in the initial setup on one machine cut the frame times in half ! So if it is that easy to double my PPD on that machine without changing the stats that YURT collects, what are we finding out with YURT ?
MikeBlas has put considerable effort into a unique project, but I think we need to review what we expect to get out of the project & whether the input needs to be tweaked to get those results.

Respectfully,

RPhArrow --\\\\---------------------------->
 
RPhArrow said:
To be honest , I have not updated the clients and restarted the service because I'm not totally sold that we are getting meaningful data out of the project.
Click to expand...
Well, we're certainly getting useful data. We might not be getting the information you expect, though. That's not a semantic quibble; the data we're amassing (as disappointing as the participation is) isn't available anywhere else, as far as I know. Information takes interpretation and mining. What other correlations and aggregate statistics do you think we should try looking for?
 
mikeblas said:
Well, we're certainly getting useful data. We might not be getting the information you expect, though. That's not a semantic quibble; the data we're amassing (as disappointing as the participation is) isn't available anywhere else, as far as I know. Information takes interpretation and mining. What other correlations and aggregate statistics do you think we should try looking for?
Click to expand...
I think (from what I recall of the early discussions) the initial expectations of the project were meaningful information regarding PPD per protein. Then the obvious issue of processor speed became involved. Then OC'ing became an issue.... I did not follow that discussion to it's end... When the initial project started, I just began submitting data.

As a data submitter, I am neither the designer, nor the requesting consumer of this project 's results. However, IF the original goal was to determine PPD for specific proteins or cpu's or cpu speeds, you seem to have stated that there is no apparent correlation. Ergo, project done ?

No, I don't think the project is done either... but I also think if there are no clearly stated goals, then you cannot design the proper data collection. On the other hand, if you just want to collect raw data and decide later what information you want, then fly at it, hell, that's what Google does... but don't expect too much willingly blind participation.

OK, what information would I like ? Disregarding what I know of YURT data collection, I would like to know how the assignment servers dish out WU depending on cpu/memory/os . I would like to know how PPD varies for same protein depending on OS. I would like to know how various client flags affect PPD (frame rate) . I'd like to know how using wine with a windows FAH client fares vs. a straight linux client. I'd like to know what client optimatizations to use depending on cpu & OS . With all these (and more possible) variations, I think that a straight PPD per protein or PPD per cpu speed is too simplistic.

Yeah, that's a big shopping list, but again, that's why we should define some goals. And obviously I think we need to bring linux OS into the mix also...(oh yeah, then that means the Mac folks will want in too... ??)

RPhArrow ---\\\\------------------------------>
 
RPhArrow said:
No, I don't think the project is done either... but I also think if there are no clearly stated goals, then you cannot design the proper data collection.
Click to expand...
This is pretty obviously false in the general case, and I think it's false for YURT, too.

Thing is, there's not much more data that we could collect. Aside from observing the configuration options and recording aborted work units instead of discarding them, what else does the FAH client do that we could observe and record?

I think the client flags were discussed in the design thread, and the problem was they could change over time. We were not quite sure what to do with that kind of data, as it would mean adding another dimension to the database. The other time-variable dimensions include CPU load and CPU speed. Do we add these dimensions to the work unit completion history? If so, then how do we report that multi-dimensional relationship on a web page in an approachable manner? It's not like Star Trek; you can't just ask the computer questions and have it decide which method for reporting the answers is best.

We have much of the data we'd use to try to draw the inferences you're asking about. Given a given proten, is a certain clock speed or memory size favored? I don't see an corrlation here; that protein has been worked by one of the slowest machines we have (756 MHz, 855 MHz) and one of the fastest (3519 MHz). It's been worked by two machines with 250-something Megs of memory, and several machines with two gigs of memory.

Of course, we also have a pretty small sample size. There's 5000 people on the Stanford page for team 33. Even if assume only the top third of the list is serious about contributing, that's a market of 1666 users. We've only got 60, right now. Three percent?

At the moment, I'm the only volunteer the project has. If there's an experienced programmer who wants to step up to port the client code to any of the different Linux flavors, then I'm happy to receive the help.

RPhArrow said:
I'd like to know what client optimatizations
Click to expand...
Or am I missing something more about what data could be collected? What "client optimizations" would you consider using, and which should be collected?

RPhArrow said:
Yeah, that's a big shopping list, but again, that's why we should define some goals.
Click to expand...
We should define some goals because you have a big shopping list? I'm a little confused by that one.
 
Hey, I'm just trying to respond to your questions about what information (as opposed to data) I am looking for in a project like this. Due to the limitations you bring up and I acknowledge, my "shopping list" of ideas obviously won't be addressed in this particular project (nor did I expect them to be). In the phrase "client optimizations" I was referring to the various flags (-forceasm -advmethods , etc).

Let's just make it simple: The reason I haven't bothered to install the latest YURT clients on my machines is that I'm not seeing any information useful to me coming out of it. Most likely I do not understand what the goal of this project IS. I opted in as a data submitter to help while I watched to see what the project could produce, and now I am opting out. Thank you for the opportunity to invest more time in this project, but at this time I respectfully decline.

8607
 
Grumpy- either update the client or uninstall it I think are the options. The old client is hammering Mike's server is the problem I think.

:)
 
RPhArrow said:
In the phrase "client optimizations" I was referring to the various flags (-forceasm -advmethods , etc).
Click to expand...
And as I asked, what other collections would you think are interesting, beyond the state of these two options?

RPhArrow said:
I'm not seeing any information useful to me coming out of it.
Click to expand...
I guess I'm missing something. You said you wanted to see if there was a correlation between protein assignemnts and machine CPUs, or between assignments and memory. I provided a link to a report which shows their isn't. Did I misunderstand your request for that data? Or does that report somehow not actually answer your question?

RPhArrow said:
Thank you for the opportunity to invest more time in this project, but at this time I respectfully decline.
Click to expand...
I'm sorry to hear that you won't be sending us your data. I can understand if someone would rather contribute data than actively participate. We'll eventually find some way to fill the gaps, but without incoming data (and lots of it), YURT will never have enough data to statistically be meaningful.
 
mikeblas said:
And as I asked, what other collections would you think are interesting, beyond the state of these two options?

I guess I'm missing something. You said you wanted to see if there was a correlation between protein assignemnts and machine CPUs, or between assignments and memory. I provided a link to a report which shows their isn't. Did I misunderstand your request for that data? Or does that report somehow not actually answer your question?

I'm sorry to hear that you won't be sending us your data. I can understand if someone would rather contribute data than actively participate. We'll eventually find some way to fill the gaps, but without incoming data (and lots of it), YURT will never have enough data to statistically be meaningful.
Click to expand...
Ok, multiple questions here...

1, I think the project should collect all flags for the client ( those client options with a "-" in front of them) and I think the project should collect all configuration options elected by the contributor. (Those would be the questions answered by the contributor when the -config or -configonly flags are imposed.)

2. I never asked for a correlation between assignments and anything. I asked for a correlation between PPD and various client configurations ( specifically effect on output, not assignments)

3. I agree that YURT will never have enough data to be statistically meaningful.

4. Number 1 most likely won't happen, number 2 is irrelevant, number 3 may be the real sticking point in the project.

5. I never claimed to be a database designer or database miner... only a contributor... but , you ask, you get.....


RPhArrow ---\\\\-------------------------------->
 
RPhArrow said:
all configuration options elected by the contributor
Click to expand...
Why? I mean, some would appear useful, like the big packets option. Others are of no concern -- like the HTTP proxy options.

RPhArrow said:
2. I never asked for a correlation between assignments and anything. I asked for a correlation between PPD and various client configurations ( specifically effect on output, not assignments)
Click to expand...
Sorry; then what did you mean by "I would like to know how the assignment servers dish out WU depending on cpu/memory/os"? I assumed it was trying to find a correlation between work units (identified by protein ID) and CPU speed, memory size, and OS brand (and version).

RPhArrow said:
3. I agree that YURT will never have enough data to be statistically meaningful.
Click to expand...
I'm not sure who you're agreeing with. What I said was that it won't have enough data if people don't participate. You asked what the point was; the point was to make something that collected data, that we'd then go and explore for interesting inforamtion. Without enough data to do interesting exploration, it's hard to get any further.

RPhArrow said:
5. I never claimed to be a database designer or database miner... only a contributor... but , you ask, you get.....
Click to expand...
I'm sorry; I can't understand what you mean with this one. Can you explain it, please? I'd hate to guess at your meaning incorrectly twice in a row.
 
mikeblas said:
I'm sorry; I can't understand what you mean with this one. Can you explain it, please? I'd hate to guess at your meaning incorrectly twice in a row.
Click to expand...
You ask for feedback, but don't like what you hear, you ask for design input, but don't like it when I say I'm no database designer, you ask for what I would like to see in resulting information but say it's not possible. I'd say we are at an impasse and no further communication will be meaningful.... Bye
 
RPhArrow said:
You ask for feedback, but don't like what you hear, you ask for design input, but don't like it when I say I'm no database designer, you ask for what I would like to see in resulting information but say it's not possible. I'd say we are at an impasse and no further communication will be meaningful.... Bye
Click to expand...
Huh? What didn't I like? I just asked for clarification and explanation. I'm not sure why you don't think it's meaningful to more precisely spell-out your ideas.
 
RPhArrow said:
OK, what information would I like ? Disregarding what I know of YURT data collection, I would like to know how the assignment servers dish out WU depending on cpu/memory/os . I would like to know how PPD varies for same protein depending on OS. I would like to know how various client flags affect PPD (frame rate) . I'd like to know how using wine with a windows FAH client fares vs. a straight linux client. I'd like to know what client optimatizations to use depending on cpu & OS . With all these (and more possible) variations, I think that a straight PPD per protein or PPD per cpu speed is too simplistic.
Click to expand...

Some answers for Grumpy I hope,

How the AS assigned WU's: Based upon the client setting, taking into the possibility of flag settings. IE if you have big packets set to on, you can (but not always) get a large WU. Same with -adv, if on it's possible, but not always, to get -adv WU's. Exceptions are timeless and the QMD combo of past (big/-adv). The AS also checks reported memory from the client, if < 256 no large WU's and < 504 no QMD's of old. Total RAM and timeless flag only thing set in stone, rest is a crap shoot.

That being said, one must know the general WU offerings and play the odds. Case in point, currently -adv/big in not the best flag combo. Only big is as this will net you ribo/tets/DoubleGromacs. -adv will get you poopers. However, once certain WU's come out of beta and into -adv (1495) these will then out preform the big only setting. Flag sets, if going for most PPD, vary by offerings.

Flags affect PPD- don't really. Mostly covered by above (type of WU to begin with), -forceasm is just a must have flag and should not be looked at as a way to increase production--- just normalize it in my opinion (yea, I always forget it too. Stupidest thing ever).

Linux/Win/Wine vs. Linux- I can't say. All reports lead to less than one would assume, and less these days with the latest client (5.x). All in all, I'd say a moot point. Flag setting for various WU types- hard to say. Yes, there are fewer servers available for Linix so therefor you options are less. Around 8.9% of active CPU's per Stanford are Linux. Interesting, check the WEIGHT column on the Stanford server listing. I'd say same guidelines as Windows flagging apply, however if you trying for a WU type and it's not offered to Linux your SOL. Stanford seems not too descriptive on which WU's go to which OS inside a single server.

Conclusion:

Always flag -forceasm.

95% of the time flag for big.

-adv need to keep up with all the forums (not [H] as this is never reported here) to see which is having the better WU offerings.

edit: in my opinion the -adv flag is commonly misused (myself included)
 
RPhArrow said:
This message has been deleted by p[H]ant0m. Reason: (1) Absolutely NO FLAMING, NAME CALLING OR PERSONAL ATTACKS.
Click to expand...
Wow. Does anyone remember why I volunteered for this?
 
You must log in or register to reply here.
Back
Top