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

Official YURT Design Thread (Development Discussion ONLY)

I'd be willing to work on something like this, but I have about eleventy too many things on my plate right now. Let me clear out some of the mess and see if I remember to pursue this.

 
That would be awesome if you could help, but I do understand that you have a lot of other things todo right now. I would like to get thisatleast started as soon as i can. I already had 2 programmers back out due to lack of time and I have been working on this project since October now. Had the idea for about 2 years just never started it.
 
enhanced08 said:
That would be awesome if you could help, but I do understand that you have a lot of other things todo right now. I would like to get thisatleast started as soon as i can. I already had 2 programmers back out due to lack of time and I have been working on this project since October now. Had the idea for about 2 years just never started it.
Click to expand...
there is only one problem that I can see...

As payment for mage's help, you must fold for team 33.
:D
 
Ya know what? if he does help me I'll turn over what machines I can to team 32 and fold under his name! I'll do this for anyone who helps me. I can only offer 8ish Ghz tho, but thats better than nothing I guess. :)
 
enhanced08 said:
Ya know what? if he does help me I'll turn over what machines I can to team 32 and fold under his name! I'll do this for anyone who helps me. I can only offer 8ish Ghz tho, but thats better than nothing I guess. :)
Click to expand...
Or team 33 for that matter ;)

 
yeah, 33, my bad.... but I need a programmer first :D ;)

EDIT: I was chatting with a guy from my home forums and he mentioned that while Java is great for client-server applications it can't do the hardware queries like I need to be able to do. He said C/C++ would be best. Lets make this easier... If you are a programmer and know a language that will be able to do what I want and would be willing to help, let me know! As long as it works I dont care what language you use, use assembly if you want! :p

The only problem with using something other than Java is going to be the fact that it will need to be ported to 3 operating systems.
 
It doesn't sound too difficult...Probaby the easiest way to do it would be to also run EM3 on the client or monitoring machine on the LAN. EM3 can generate an HTML file with all the stats from one or more machines. A simple program could periodically check the html file (or the .csv that EM3 generates) for new WU completions, and upload the information to a server. As far as poisoned data goes, each data point could be linked to a username/password, and if someone gets out of hand, just exclude the data from that user.

It doesn't sound too bad as far as programming goes. I don't have any expertise when it comes to writing the server program, but I could easily write the client code. Does someone around here want to take on the server code? All it would have to do is put the data points into a DB and spit out some HTML...

 
Ok, Mohonri, if you'll do the client side, I'll try server side. From the looks of the database, here's the information you need to gather:
CPU type, CPU core, socket, process size (eg 90 nm), multiplier, L[123] cache, fsb, ram amount, timings, speed, #channels, project id, percent CPU, hours/day, OS, and client version.
You may be able to get a lot of this information from CPU-Z. I'm not sure how to automatically extract it, though - maybe there's an option to dump all the system information?

In any case, we need to work out a division of labor. Are you just going to get a couple of text files and send them off, or are you doing the parsing out of each field? There are two hard parts to this project: getting the text files with everything in them generated, and figuring out what the files really mean. Actually putting things in the DB is dead easy; if you do all the parsing my code looks like this:
Code: 
if (isValidResponse())
 {
  stickInDB();
 }
It's a tough job, but somebody's gotta write it :p

Let me know what your thoughts are. I'm willing to write anything needed on the server.

enhanced08: I see you're using php. I haven't done anything with php before, and while I'm willing and eager to learn, it might be simpler for me to do it in perl. Is that an option, or should I go get a book on php?

 
unhappy_mage said:
Ok, Mohonri, if you'll do the client side, I'll try server side. From the looks of the database, here's the information you need to gather:
CPU type, CPU core, socket, process size (eg 90 nm), multiplier, L[123] cache, fsb, ram amount, timings, speed, #channels, project id, percent CPU, hours/day, OS, and client version.
You may be able to get a lot of this information from CPU-Z. I'm not sure how to automatically extract it, though - maybe there's an option to dump all the system information?

In any case, we need to work out a division of labor. Are you just going to get a couple of text files and send them off, or are you doing the parsing out of each field? There are two hard parts to this project: getting the text files with everything in them generated, and figuring out what the files really mean. Actually putting things in the DB is dead easy <snip>
Let me know what your thoughts are. I'm willing to write anything needed on the server.
Click to expand...
Perhaps we could combine a few things. How about this idea:
You write a few web pages that will allow anybody (with a login) to enter data. Then my client can just parse whatever files, fill out the form, and submit it. You do a nice, simple insert into a DB. And your server generates the spreadsheet. This way, people can enter data manually, and 'bots' can also add data automatically. This would essentially replace the Processor Performance Matrix.

Another thought: I'm a very strong proponent of the KISS strategy. While all the information listed above is nice, for our purposes (F@H), not all of it is necessary. I think that Core, Clock Speed, and Project number are by far the most important fields to have. The rest of the CPU data (process/cache/fsb) can be inferred. While amount of RAM *might* make a difference, I don't see the timings making a large impact. And I would like to maintain the assumption that the CPU is folding at 100% 24/7. I think people can scale the PPD on their own (or you can write a page to do it for them!) if they're not running at 100%, or if their machine isn't on all day.

Oooh, ooh, feature idea: nice pretty graphs showing, say, the range of PPD on Venice core CPUs on the various cores/projects. But that's for later. What do you think?

 
I think it would be cool to have a companion program to EMIII that could do this.... BUT.... have you guys talked to LPerry at all? would he be okay with us using EMIII to send data/etc? (he already has an EMII server that does a similar function, albeit for personal use)....

another thing you may want to keep track of, is which flags are being used... or, if that's too difficult to determine/etc, then show which WUs you can get with flag combos....


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

 
I asked LPerry about using his leet windows programming skills to do something like this a while back, and his response (if I recall) was that he didn't have time to work on it. I don't remember if I asked about using EM3's results to make a database, though.

Mohonri: Yes, we probably don't need to keep track of all this. However, there's no program that I know of that just gets the cpu speed, so as long as you've got to retrieve that value you might as well get all of them. Cpu-z does know how to dump a report of all the config values, and you get back an easily parsable file with lines like this:
Code: 
Clock Speed			2405.3 MHz
Clock multiplier		x12.0
Front Side Bus Frequency	200.4 MHz
L1 Data Cache			8 KBytes, 4-way set associative, 64 Bytes line size
L1 Trace Cache			12 Kµops, 8-way set associative
L2 Cache			512 KBytes, 8-way set associative, 64 Bytes line size
So that seems like a good way to go about that part of it. And best of all:
cpuz-readme.txt said:
CPU-Z is a freeware and can be freely distributed.
Click to expand...
:D

 
Are you aiming for a periodic use program (user operated)? or a "F@H finished a WU, send in the data" program (runs in the background)?



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

 
So you guys are willing to help?? yay! :D

Lets see if i forget any info here....

Some ideas I had were to use CPUz to collect the system data and save it to a txt file. CPUz can be run in "ghost" mode which runs the program with no window and saves everything to a text file. This should be able to be done with a simple DOS command or something. I asked and am allowed to bundle CPUz in a zip file as long as I include the readme.txt. This would leave it up to the makers of CPUz to keep it updated with the newest CPUs and such rather than you guys. The problem here is that it only runs in Windows.

As far as the manual and automated data entry, thats already in place. On the "beta" area of the site a user can register and add data. I dont plan on taking this down even once I get a program to automatically do it.

I like the idea of using EMIII to create a file and parse from that, but not everyone uses EMIII. Just a thought.

Using the form thats already inplace would be fine with me. Its not "my" server, its a simple webhost so I dont think I would be able to run any kind of server application on it, I dont know for sure tho. What Might be a better idea is for me to create another form just for the program incase I decide to change something on the webpage the program wouldn't need changed. That shouldnt be a problem.

One reason I decided to go with all the information (L1, CAS, etc) is because no one knows 100% for sure whats better, even if only a little, if nothing else this site will prove that infact L3 or amount of RAM has no effect. I dont like to assume anything so this site will prove it. I actually had more items when I first started like hard drive speed, type of drive (IDE, SATA, SCSI) and things like that. The amount of data and the way its collected is whats going to make the difference between this site and fahinfo.org. I'm not compeating with him, we talk quite often about each others site, so dont think that. I respect him and what he is doing. NOt everyone runs at 100% either, most people who run it on servers back it down to 80-90% just incase and some "borg sites" like mine (high school) only runs the systems up to a max of about 6 hours each day.

Pretty graphs huh? I'll have to look into that once we gets things moving. :)

I have never used Perl and only just started with PHP a few months ago when I first started this. I dont know what you mean by that? if you want to use Perl, go for it, if there is a problem we can figure out something, i'm sure!

If you guys really want to help out, I have AIM and MSN we can chat on if thats easier. I wont be around till next weekend because of a new job and move, but if at all possible I'll try to get online before then, but i cant promise anything.

Thanks for the help!
 
I'm not sure which would be easier to implement. I think for starters it'd be easier to have it periodic. Is there support for running a program when a WU finishes in EM3? That'd make ir easier to have it on a per-WU basis.

 
I would like to have it run in the background but if a text file from EMIII or something is used to collect the times then its not needed to be run 24/7. The only reason I wanted it runing 24/7 was so that it could get an average time per frame of the units.
 
Are you aiming for a periodic use program (user operated)? or a "F@H finished a WU, send in the data" program (runs in the background)?
Click to expand...
The idea is that this would just run in the background, periodically (say, twice a day) checking one or both of the EMIII output files (one a csv, the other html), looking for newly completed WUs.

This raises another question: how will we ID CPUs? If someone is folding on three boxen, and monitoring via EMIII from a fourth, it would seem ...inconvenient to have to run CPU-z on each machine. At the same time, the "CPU Info" that's manually entered in EM3 for each machine won't be in a reliably-parsable format. Maybe my client will scan the html file, detect "unknown" CPUs, and prompt for information? What do you think?

 
I had 2 ideas for this, one was to have this program run on each computer that runs folding and the other was to have it run on a single machine and be able to collect the data via a networked folder on each machine, just like EMIII does. I dont know how to do this, but I'm no programmer either.... I just comeup with ideas and no idea how to use them.... lol
 
I'm home for the weekend and am still trying to get some internet at theplace i'm staying durring the week. Are you guys still willing to help?
 
I'll willing to help where I can.... but I'm not much help beyond brainstorming and a little C and VB....


Keep on Folding!!

 
I'm willing to help...I just need a nice set of specifications. I guess we *could* run it on each folding box and have it parse the fahlog.txt...that sounds messy, even though I've done a fair amount of text parsing, but that's not such a big deal.

 
enhanced08 said:
I'm lookin for a programmer, I started a thread in the programming forum (http://hardforum.com/showthread.php?t=1022849) and was told to check the DC forum as well, so here I am. Is there any intrest in helping me or am I wasting my time?

Thanks! :cool:
Click to expand...

Other than general and dedicated curiosity, I don't see the purpose of this. Your monitoring program will tell you how long the WU will take, shortly after the WU starts up.

Having this large database, will not make it happen any sooner!

Although I'm interested in how long it will take on my system, I really don't care how long it would take to complete my WU if it were being folded with a celeron CPU, or an Athlon 1900+..

Seems irrelevant to me. Actually running this kind of reporting program will inevitably SLOW DOWN your folding, and for what benefit - other than dedicated, perhaps too dedicated, curiosity. Every cpu type, clock speed, FSB speed, cache size and type, memory settings, and amount, different NB chipset, etc., will have a different result - AND the one that takes the cake is "every program and service that is taking some cpu cycles away from the core".

How are you going to measure how many cpu cycles have been taken by a program other than the core? This is NOT a small difference, as we all know.

Adak
 
Adak said:
Other than general and dedicated curiosity, I don't see the purpose of this. <snip>
Click to expand...
You pose some good questions. I agree that for existing boxen, this wouldn't be that big of a deal. However, it would provide a very nice perspective for people looking to build a new box. Knowing how many ppd/Watt/$$ is important to a lot of people.

Besides, it's just cool. I have to keep some semblance of programming skills alive, since I don't do anything remotely similar in my job.

 
I see where your comming from stating that it will actually hurt folding, but those monitors do the same thing, if not worse!

The main reason behind this is all the new guys who ask how fast their machine will fold, its hard to give a good answer because of all the differences in systems and WUs. This site should help with that problem.

Mohonri, unhappy_mage, and OSUguy98, do you guys have MSN, AIM, or anything? That would make it easier for us to chat about this. Once again, I'll be leaving today and wont be home till friday evening. I'm really trying to get some internet down there....
 
No instant messenger, sorry. MooseEdit: You know better...

Adak: The purpose of this is to help people figure out what CPU to buy for farm machines. There it matters (a lot!) what chip is fastest, completing the most WUs or points per day. As for how much CPU this uses, it'll hopefully only be running in the time when one WU has finished and another one hasn't yet started.

 
I used to have an AIM/ICQ account, but that was years and years ago. I have gmail, and somewhere I think I've got a yahoo account that I could dig up...

I don't see running these programs as being a problem. I would set them to run once a day, if that often. We're talking about maybe ten seconds worth of CPU time per day, and most of that will be sending the data to the master site.

 
unhappy_mage said:
However, there's no program that I know of that just gets the cpu speed,
Click to expand...

There is one included with EMIII.....
It's called speed.exe.
You invoke it once and EMIII reads the txt file it generates for it's results.


 
I'm interested in helping out, but I obviously have no interest in Java.

Here's what I posted in the other thread:

Encryption obviously isn't the answer to verifying the results; authentication is.

Getting the system description information isn't hard. But how is the progress and sizing information gathered from the F@H software? Doesn't F@H run at idle priority? Then how do we know if the system is giving any (few, many, or all) cycles to the work unit?
Click to expand...

Where do we stand? Catching up to this thread, I don't see anything having been done. Do we have hosting? On what platform? Any details to the specs (what should be collected, how it should be recorded, and so on)?
 
Mikeblas: The database is here. enhanced08's hosting it. It's php+MySQL (as far as I can tell). There's a login system; it's simple enough to create a username and password. Dig through a bit. The way it's set up right now will get clumsy for lots of users - you select the system from a list (which is associated with the hardware specs) and then input data for a WU. Maybe associate certain machines with certain usernames, so you only see the machines you own.

Not all the parameters are passed back and forth; logging in creates a cookie (I'm guessing) that then allows you to add info to the DB. Not sure how to go about doing this, but I have faith in you ;)

Thanks for the help!

 
unhappy_mage said:
Mikeblas: The database is here. enhanced08's hosting it. It's php+MySQL (as far as I can tell).
Click to expand...
Bummer about MySQL and php.

Wow, so it's already done, huh? I didn't think I had missed that much when the thread in Webmastering and Programming was abandoned!
 
Right here :p

In any case, the server stuff is done (I think - but it'll probably need some changes as mentioned) but we can still use a lot of help on the client side stuff if you're willing to help out. It'll have to have some text files generated, parse them, create an authentication token, and make a HTTP GET request to the server. I could eventually do it, I think, but this is win32 and (probably) c/c++ and not my environment-of-choice. I agree php and mysql wouldn't be my first choices, but that's what abstraction is for - if we later discover the limitations of this system, we can rewrite the web interface, use a different database, anything we need, as long as it takes the same input from the client.

 
Your link led to a web page and not a database, by the way; where can I find table definitions?

unhappy_mage said:
Right here :p
Click to expand...

How does a client submit data to that website programatically, without any user intervention? Poking around, it looks like the user just enters what they "know" their computer to be. From a programming point of view, the client doesn't have that information -- there's no code I can execute to tell me what chipset is installed or what the code name for the processor core is.

I can execute CPUID and collect its information; I whipped that up this morning:

Code: 
Y:\projects\FAHCollector\debug>fahcollector
MaxCUPID: 5
Basic string: "GenuineIntel"
0x0001: 0x00000F41 0x00020800 0x0000441D 0xBFEBFBFF
   Stepping ID    : 1
   Model          : 4
   FamilyID       : 15
   Type           : 0 ("Original OEM Processor")
   Extended Model : 0
   Extended Family: 0
   Logical procs  : 2
   CFLUSH size    : 64
0x0002: 0x605B5001 0x00000000 0x00000000 0x007C7040
0x0003: 0x00000000 0x00000000 0x00000000 0x00000000
0x0004: 0x00000000 0x00000000 0x00000000 0x00000000
0x0005: 0x00000040 0x00000040 0x00000000 0x00000000
MaxExtendedCPUID: -2147483640
Processor brand string: "              Intel(R) Pentium(R) 4 CPU 3.00GHz"

It seems like the best bet would be to have the client just submit as much raw data as it can, then store that. The server can interpret (or re-interpret) the raw data into data that's actually shown on the website whenever it wants.

Was the intent to have the client "forge" the data entry form that exists on the website now? Forgive me if this was discussed before; obviously, the thread forking threw me off.
 
I think "forging" a site visit was the place we arrived at; it's simpler than creating your own protocol, it's http so it'll pass most people's firewalls, and it's upgradeable - if you later want different client or server code all they have to do is deal with http requests. And this keeps things nice and abstract - you don't need to worry about the table definitions as long as you put stuff in and get the same stuff out.

Essentially, I think what we need is a one-to-many relationship with users->computers and a one-to-many with computers->WUs, but I think this is already set up. What the client has to do, then, is:
1) create a new "computer" row (named based on its Stanford ID? they're unique and accessible by registry) with values from CPUID if one doesn't exist.
2) Set itself up to be scheduled to run after a WU finishes. This is the hard part of the problem, as far as I'm concerned - how can one tell when a WU has finished? I'll post on the folding community forums about this.
3) Send back data when run on a schedule. This should be straightforward - parse the FAHlog.txt or unitinfo.txt file and you get most of it. Some things are more tenuous - how much CPU did it actually get to use? - but I think for now we can disregard that. If we figure it out in the future, all the better.

 
unhappy_mage said:
I think "forging" a site visit was the place we arrived at; it's simpler than creating your own protocol, it's http so it'll pass most people's firewalls, and it's upgradeable - if you later want different client or server code all they have to do is deal with http requests. And this keeps things nice and abstract - you don't need to worry about the table definitions as long as you put stuff in and get the same stuff out.
Click to expand...

Well, of course I need to worry about the table definitions. I need to come up with all the data that the tables will store, and ask for the tables to be changed to include data that I can provide, and revised to not include data I can't get.

For example, the form interface requires the code name of the processor core. How does the client figure that out? That information simply isn't available; the client would have to look up the CPUID parameters in a huge table and get the name. The table would never be complete enough (since more than one core can return similar CPUID values, particularly for older processors) and the client would then have to be updated for every new core that became public.

There's plenty of similar examples. In fact, here's the fields I can get, for sure:

  • Manuf
  • Name // though it's not equal to the one listed
  • Speed // from registry, and/or from timing loop measurement
  • Operating System
  • RAM

I'd assume "Client" comes from the log, as well as "Project". Is "CPU Usage" in that category, too? It's impossible that it's 100%; at best someone is rounding.

Here's the ones that I can't get (or, can't get easily):

  • Core
  • Socket
  • Multi
  • nm
  • FSB
  • Mhz
  • CAS
  • Dual Chan

Cache size (L1, L2, L3) are sometimes available and sometimes not, depending on the age of the processor. For older procs, certainly not. For newer procs, the CPUID instruction turns out to be pretty descriptive.

Here's the ones where I don't even know what the column means:

  • Time/Fr
  • ppd
  • /Ghz

Getting this fixed up will prevent some of the crappy data that's already happening. For example, the Pentium II certainly didn't use a 25 nM process -- but someone's entered that.

unhappy_mage said:
2) Set itself up to be scheduled to run after a WU finishes. This is the hard part of the problem, as far as I'm concerned - how can one tell when a WU has finished? I'll post on the folding community forums about this.
Click to expand...
This is easy. If the Folding code broadcasts a message or sets an observable event, then we can use that. If not, then we just wait for the log files to be updated; they can be watched with FindFirstChangeNotification().
 
I've got code together to measure the processor frequency (in a loop) as well as pull it from the registry.

I'll try to download and install Folding At Home and see if I can observe the changes and then parse the files; that should be quite easy, though lacking a specification from ya'll, I'm still not positive I know exactly what I'm looking for.

Then, I'll just need someplace to send the results, and information about the format expected at that site. Again, need a spec.

Maybe I can get through this before the weekend; the first race of the season is coming up, and I'll be "going dark" from Friday thru Sunday, inclusive.
 
  • Time/Fr - Time per Frame. I don't know if this is calculated server-side or not. Folding@Home is based on Work Units (aka WUs) which are further subdivided into frames.
  • ppd - points per day. Each WU is worth a given number of points, listed at this site. Probably is (or should be) calculated server-side.
  • /Ghz - points per day per gHz. See above, divide by gHz.
Thanks for jumping on this. Anything we can do to pay you back, let us know ;)

As for where to send results, what format, etc, you'll have to hear back from e08 to see what he has going and what changes (if any) he's going to make.

 
I'm going to follow this guide to try and get a client started.

Is there a way that I can force small work units to maximize the writes to the log file to accelerate my testing?
 
what CPU are you running? "Timeless Tinkers" or "Deadline-less" units take about 2 days on my P4 2.66..... they're faster on AMDs...

Be aware, the FAHlog.txt file will change based on what protien it's crunching.....


Here's an example of a timeless tinker (all that I have access to at the moment

Code: 
[08:43:46] + Processing work unit
[08:43:46] Core required: FahCore_65.exe
[08:43:46] Core found.
[08:43:46] Working on Unit 04 [January 27 08:43:46]
[08:43:46] + Working ...
[08:43:46] Folding@Home Client Core Version 2.53 (June 29, 2004)
[08:43:46] 
[08:43:46] Proj: work/wudata_04
[08:43:46] Done: 22952 -> 142984 (decompressed 622.9 percent)
[08:43:46] nsteps: 5000000 dt: 2.000000 dt_dump: 250.000000 temperature: 298.000000
[08:43:46] xyzfile:
[08:43:46] "   393  p1152_L939_K12M_ext_from638
[08:43:46]      1  N    -13.563173  -55.236455   43.607..."
[08:43:46] keyfile:
[08:43:46] "parameters	./proj1152.prm
[08:43:46] NOVERSION
[08:43:46] ARCHIVE
[08:43:46] 
[08:43:46] cutoff        16.0
[08:43:46] taper         12..."
[08:43:46] 
[08:43:46] - Couldn't get size info for dyn file: work/wudata_04.dyn
[08:43:46] Starting from initial work packet
[08:43:46] 
[08:43:46] Protein: p1152_L939_K12M_ext_from638
[08:43:46] - Run: 120 (Clone 65, Gen 3)
[08:43:46] - Frames Completed: 0, Remaining: 400
[08:43:46] - Dynamic steps required: 5000000
[08:43:46] 
[08:43:46] Writing local files:
[08:43:46] 
[08:43:46] parameters          work/wudata_04.prm
[08:43:46] - Writing "work/wudata_04.key": (overwrite) successful.
[08:43:46] - Writing "work/wudata_04.xyz": (overwrite) successful.
[08:43:46] - Writing "work/wudata_04.prm": (overwrite) successful.
[08:43:47] - Writing "work/wudata_04.key": (append) successful.
[08:43:47] 
[08:43:47] PROJECT="work/wudata_04", NSTEPS=5000000, DT=2.0000, DTDUMP=25.000000, TEMP=298.00
[08:43:47] TINKER: Software Tools for Molecular Design
[08:43:47] Version 3.8  October 2000
[08:43:47] Copyright (c)  Jay William Ponder 1990-2000
[08:43:47] portions Copyright (c)  Michael Shirts 2001
[08:43:47] portions Copyright (c)  Vijay S Pande 2001
[08:50:42] Finished a frame (1)
[08:57:35] Finished a frame (2)
[09:04:29] Finished a frame (3)
[09:11:21] Finished a frame (4)
[09:18:14] Finished a frame (5)
[09:25:04] Finished a frame (6)
[09:31:54] Finished a frame (7)
[09:38:44] Finished a frame (8)
[09:45:34] Finished a frame (9)
[09:52:27] Finished a frame (10)
[09:59:22] Finished a frame (11)
[10:06:17] Finished a frame (12)
[10:13:08] Finished a frame (13)
[10:19:58] Finished a frame (14)
[10:26:50] Finished a frame (15)
[10:33:45] Finished a frame (16)
[10:40:37] Finished a frame (17)
[10:47:30] Finished a frame (18)
[10:54:21] Finished a frame (19)
[11:01:11] Finished a frame (20)
[11:08:06] Finished a frame (21)
[11:14:57] Finished a frame (22)
[11:21:49] Finished a frame (23)
[11:28:42] Finished a frame (24)
[11:35:33] Finished a frame (25)
[11:42:21] Finished a frame (26)
[11:49:10] Finished a frame (27)
[11:56:01] Finished a frame (28)
[12:02:51] Finished a frame (29)
[12:09:44] Finished a frame (30)
[12:16:36] Finished a frame (31)
[12:23:27] Finished a frame (32)
[12:30:25] Finished a frame (33)
[12:37:53] Finished a frame (34)
[12:44:58] Finished a frame (35)
[12:52:00] Finished a frame (36)
[12:58:56] Finished a frame (37)
[13:06:07] Finished a frame (38)


[13:11:27] + Attempting to send results
[13:11:39] + Results successfully sent
[13:11:39] Thank you for your contribution to Folding@Home.
[13:11:39] + Number of Units Completed: 46

[13:13:27] Finished a frame (39)
[13:20:59] Finished a frame (40)
......................................................... frame 41-380 omitted to shorten this code
[04:16:17] Finished a frame (381)
[04:23:06] Finished a frame (382)
[04:29:56] Finished a frame (383)
[04:36:45] Finished a frame (384)
[04:43:33] Finished a frame (385)
[04:50:19] Finished a frame (386)
[04:57:06] Finished a frame (387)
[05:03:55] Finished a frame (388)
[05:10:47] Finished a frame (389)
[05:17:36] Finished a frame (390)
[05:24:24] Finished a frame (391)
[05:31:09] Finished a frame (392)
[05:37:56] Finished a frame (393)
[05:44:46] Finished a frame (394)
[05:51:34] Finished a frame (395)
[05:58:21] Finished a frame (396)
[06:05:11] Finished a frame (397)
[06:12:01] Finished a frame (398)
[06:18:53] Finished a frame (399)
[06:25:43] Finished a frame (400)
[06:25:43] TINKER is Exiting following Normal Termination
[06:25:43] 
[06:25:43] Finished Work Unit:
[06:25:44] ARC file integrity verified
[06:25:44] logfile size: 441529
[06:25:44] Leaving Run
[06:25:48] - Writing 1486153 bytes of core data to disk. 
[06:25:48]   end (WriteWorkResults)
[06:25:48] - Shutting down core
[06:25:48] 
[06:25:48] Folding@home Core Shutdown: FINISHED_UNIT
[06:25:51] CoreStatus = 64 (100)


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

 
OSUguy98 said:
what CPU are you running? "Timeless Tinkers" or "Deadline-less" units take about 2 days on my P4 2.66..... they're faster on AMDs...
Click to expand...
Well, that's going to make testing less than facile. I'll see what I can do, tho ... meanwhile, I need to hear back about what data, precisely, needs to be captured from the log or if the Folding At Home program makes available an observable event so I don't have to sniff the file in the first place.
 
You must log in or register to reply here.
Back
Top