• 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.11 Released!

ahh now that you've added the 77x proteins it looks about right. Today is the first day I've got something other than one of those on the opty machine. Thanks Mike, yurt is much more exciting to me now that I can actually see the proteins i've been completing :)

 
Celerator said:
Mike,
I don't seem to be getting my new proteins added to the database.
Any suggestions? Would you like me to send you the FAHLog.TXT?

Click to expand...
If you've had a look and can't figure it out yourself, then I'd be happy to check it out. I'll need your YURTMonitorLog.TXT file, as well, and a clear description of what you think is wrong.
 
dekard said:
This is a powerful project, we need to get more publicity on this as a fully populated database would be usefull for all sorts of things... Not the least of which would be proper ppd estimation... Some kind of simulator function would be incredibly lovely in helping us to determine what to build \ retire for maximum ppd per kilowatt.. :)
Click to expand...
What part of the database isn't populating? What is preventing you from doing "proper" PPD estimation? What specifically is involved in the "simulator function" you're proposing?
 
mikeblas said:
The site is under a lot of load because people haven't upgraded to 1.11. The problem is in the 1.00 code; when it sends to the server, the server rejects it but the client doesn't make a note of it and just tries to send the same block again. (I didn't make the interface complicated enough.) So the old clients that are still running are trying to send hundreds of completions. Even though the script immediately rejects 'em, it still adds up a little -- mainly becasue of the traffic.

Setting up a new protein is just an INSERT statement, and takes about 3 milliseconds -- once I remember to download the new file and do the update, anyway.

Your machine stats seem to be working fine. Did you provide the right URL?
Click to expand...

why don't you have the server accept the data and then just have the server dump it? That way there is no repeated contact... eventually you could just switch the port that you receive the data on and let your firewall bounce back the packets from the old clients...
 
I vote that everyone get off their lazy asses and update! That would be the best situation. :D
 
dekard said:
why don't you have the server accept the data and then just have the server dump it? That way there is no repeated contact... eventually you could just switch the port that you receive the data on and let your firewall bounce back the packets from the old clients...
Click to expand...
I don't have control over the firewall at my ISP's data center.

Where would the server dump the data to, and how would that solve the problem? That is, how would it be any faster than ignoring the data that was sent?
 
Mike,
I was all ready to send you the files, and as I was checking YURT to give you an example of a missing protein, I noticed that YURT had updated the stats for the machine! Did you do something???

Anyway, it seems to be working now for some unknown reason. I'll let you know if I experience issues in the future...

 
Mike, I just updated mine, so hopefully I won't be killing your site anymore. Sorry about that.

Edit: Mike, how does the website determine the name of the CPU in the list? My dual xeon 5150s are listed as Genuine Intel(R)CPU @ 2.66GHz. Anyway to update this?
 
mikeblas said:
I don't have control over the firewall at my ISP's data center.

Where would the server dump the data to, and how would that solve the problem? That is, how would it be any faster than ignoring the data that was sent?
Click to expand...

you could dump the data to a null location... tell the client you got it, version check it then write to a null file..

the benefit would be the the clients wouldn't keep trying to resend the same old data, clogging your bandwidth and processor cycles...
 
dekard said:
you could dump the data to a null location... tell the client you got it, version check it then write to a null file..
Click to expand...

Writing it to a "null file" would take more time than ignoring the data.

I see; so you meant have the client dump the data. I thought of doing this, but I expected users to keep an occasional eye on their log files. They're apparently not even looking at the website, where their machines are showing no results at all.

There's been a few more fixed machines each week, so I figured we'd be out of the woods eventually.
 
mikeblas said:
Writing it to a "null file" would take more time than ignoring the data.

I see; so you meant have the client dump the data. I thought of doing this, but I expected users to keep an occasional eye on their log files. They're apparently not even looking at the website, where their machines are showing no results at all.

There's been a few more fixed machines each week, so I figured we'd be out of the woods eventually.
Click to expand...

I guess I'm still nmot explaining myself right, let me try again...

1: client tries to send completed data to server
2: server accepts client data
3: server compares client data version to database version and IF acceptable version adds it to database for use on website, IF NOT then data is dumped to NULL file OR another db for possible usage later.
4: client is happy and never tries to send that data again...
5: rinse and repeat for each and every client...

I like the idea of keeping the data from older version in another DB just in case you might need it down the road for something else. This certainly isn't necessary and you could just NULL it for simplicity's sake.

I'm glad that the problem is going away gradually though, its nice to know that you have a handle on this. I think you've got a terrific idea and that the database will prove to be highly usefull for quite sometime to come...

PS: have you thought about putting a paypal donation button? That will help with bandwidth costs and other expenses. I'm sure the amount of time you've already invested is considerable.
 
dekard said:
I guess I'm still nmot explaining myself right, let me try again...
Click to expand...
Your suggestion became perfectly clear to me once you clarified that you want the client to discard its data.

As I explained, I thought about returning a "false success" so that the client doesn't try sending the same data again. But since users have been making progress in upgrading their machines, I haven't bothered doing it.

There's no value in storing the data anywhere; it can't be trusted, can't be cleaned, and is useless.
 
I've got code to get the cache size detection working. AMD works great. The Intel enoding for cache size is whacky, and doesn't translate well to SQL. There's a couple of codes that aren't in the Intel document I have (they change it all the time).

Once I get that working, I can automate it so new machines are populated with cache info automatically.
 
I am sorry for being unable to help myself:
What is the difference in Frames PPD and WU PPD? Do I add them to find "machine PPD"?
 
drizzt81 said:
I am sorry for being unable to help myself:
What is the difference in Frames PPD and WU PPD?
Click to expand...

A frame is a part of a work unit. A work unit usually has 100 frames, but might have 400.

YURT observes what it can. Sometimes it can only observe contigious progress for a few frames before the client is paused or shutdown. Sometimes, it can see whole frames. (Then, it discards whatever frames it saw leading up to the full work unit.)

So progress rates by work unit are more accurate--YURT observed the whole thing. Frames are an interpolation; maybe only 1/400th of the work unit was observed, an we multiplied out by 400 to guess how long a whole work unit would take.

drizzt81 said:
Do I add them to find "machine PPD"?
Click to expand...
No.
 
ND40oz said:
Edit: Mike, how does the website determine the name of the CPU in the list? My dual xeon 5150s are listed as Genuine Intel(R)CPU @ 2.66GHz. Anyway to update this?
Click to expand...

Sorry, I only just now noticed your edit with your question.

YURT Installer executes the CPUID instruction. The CPUID instruction returns the processors name, among a bunch of other description. If you go to the Intel website and search for "AN-485", you'll find docs on exactly the mechanism we're using. (The doc for this instruction alone, is 80 pages. For Intel; the AMD application note for the same instruction is about 60 pages. The two manufacturers haven't standardized.)

Your machine is very curious because it returns several out-of-bound values. For example, the descriptor it reports for its L2 cache isn't documented by Intel in that application note.
 
mikeblas said:
Your machine is very curious because it returns several out-of-bound values. For example, the descriptor it reports for its L2 cache isn't documented by Intel in that application note.
Click to expand...

Must be because they're ES chips. I'll have a pair of the OEM version shortly, so we'll have to see if they show up correctly. I figured you were using CPUID and CPU-Z lists the specification as Genuine Intel(R) CPU @ 2.66GHz (ES), but it lists the name as Intel Xeon 5150.
 
ND40oz said:
Must be because they're ES chips.
Click to expand...
Probably.

The funny thing is that these brand names (and the internal project names) are commonly known, but aren't actually specified by either manufacturer.
 
I've finished all the TODO items in Post 30, except for getting logical/physical counts.
 
You must log in or register to reply here.
Back
Top