• 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's got graphs

M

mikeblas

[H]ard|DCer of the Month - May 2006
Joined
Jun 26, 2004
Messages
12,777
I've added graphs to YURT. It'll be a little while before they're done and updating regularly. Perhaps by the end of the weekend, I'll have them fully installed and automated.
 
i'm assuming yurt stops working if you start using the SMP client? I'm running SMP using VMware, and it doesn't look like YURT is recording any of the wu's I've turned in over the last couple of months. I still have one of the regular clients running on my machine, to grab those clock ticks that the SMP isn't using, but it only turns in a unit once a week or so.

meisterbrau

 
Since I've never heard of it before, it's probably safe to assume YURT doesn't work with it. What's "the SMP client"?
 
SMP is Symmetric Mulitprocessor - Stanford developed a client to utilize more than 1 processor to chug away on one WU. You can run it on dual core processors too. It only runs on Linux or MacOS right now - unhappy mage developed a method to run in on a windows box using VMware. I've abount doubled my PPD using the SMP client on my dual core X2, instead of running two separate instances of the regular FAH.

meisterbrau
 
I'm very well aware of what "SMP" means. (Turns out it's "symmetric multiprocssing", by the way.) I just hadn't heard that Stanford was testing an SMP-capable FAH Client.

Why is it faster, even under VMWare, than multiple instances of the regular client?

Anyway, I suspect that the problem is it will run on the virtual machine, writing its log to a file on the VM's simulated hard drive -- and not anywhere YURT can actually see it. Perhaps, if a Windows version is made available, I can look into making YURT compatible with it.
 
mikeblas said:
Why is it faster, even under VMWare, than multiple instances of the regular client?
Click to expand...
I don't know that it actually performs more simulations/calculation in the same time, but it can finish a given WU much faster than a typical single-CPU setup. It lets Stanford get wome work units done much sooner. In any case, it's valuable enough to Stanford to get those results fast that they've put quite a hefty points bonus on those WUs.
 
mikeblas said:
Why is it faster, even under VMWare, than multiple instances of the regular client?
Click to expand...
VMware has fairly low impact on CPU-intensive things like FAH, and since the SMP client works on one job with four cores (or two, due to limitations on VMware's free product) it gets that single job done faster on average than two cores working on two jobs.
mikeblas said:
Anyway, I suspect that the problem is it will run on the virtual machine, writing its log to a file on the VM's simulated hard drive -- and not anywhere YURT can actually see it. Perhaps, if a Windows version is made available, I can look into making YURT compatible with it.
Click to expand...
Yep. It may be made accessible over SMB shares - \\vm\fold - but I don't think monitoring files for changes works as well as would be hoped over network.

I like the new graphs! It makes it quick and easy to see what kind of output you're getting from an individual box.
 
unhappy_mage said:
I like the new graphs! It makes it quick and easy to see what kind of output you're getting from an individual box.
Click to expand...
Thank you for your kind words. I'm hoping that I can get the per-user graphs up today or tomorrow, and then work on getting the whole thing automated.

unhappy_mage said:
and since the SMP client works on one job with four cores (or two, due to limitations on VMware's free product) it gets that single job done faster on average than two cores working on two jobs.
Click to expand...
Er, but two processes working on two jobs has the same overall completion rate as the SMP client, right? Or is there some performance win in the algorithm the client uses when it can throw two processors at the same work unit?
 
mikeblas said:
Er, but two processes working on two jobs has the same overall completion rate as the SMP client, right? Or is there some performance win in the algorithm the client uses when it can throw two processors at the same work unit?
Click to expand...

Yes, but Stanford would rather have work units back quicker. You could get slightly more overall work done with two single-core workers, but Stanford needs to finish a whole batch of WUs before they can create the next one. So if they get a bunch of SMP clients working, they can finish individual WUs faster and possibly create the next batch of work faster.

And since the SMP core is new, Stanford probably wants more testers to try it out, so they can find and fix problems quicker.
 
.B ekiM, you punk, how come I forgot you made yurt?

ps, ygpm on ocwiki
 
The graphs are up. I'll probably get the updates automated tomorrow night.
 
ok. Also, when clicking on the team list link at the top I get:

Microsoft OLE DB Provider for SQL Server error '80040e57'
Arithmetic overflow error converting expression to data type int.

/ShowRatesByTeam.asp, line 51
 
Fixed. This issue was unrelated to the charts. It turns out that the sum of seconds spent computing by all the members of one of the teams went higher than 2**31.
 
You must log in or register to reply here.
Back
Top