Official YURT Design Thread (Development Discussion ONLY)

What's the oldest machine that will run the Folding at Home client? Pentium III? Pentium II?
 
Rather not rewrite the code? I wasn't expecting you to, but you still never said how the data was to be uploaded.


I'm still not following how uploading on each frame is going to be better. We are talking about the same "frames" right? I'm speaking of the frames of each work unit. A system might finish a unit every 3 min, so every 3 min you want to send data? This would mean that the database would have to have some way of keeping track of each frame of each work unit of each machine which in my mind would get tricky. I was thinking more along the lines of.... folding@home runs, finishes work unit, PTRAK or YURT or FART, whatever its going to be called runs and figures up the average time per frame some how then reads some text file which contains the system info (CPU, RAM, etc) and uploads all the data in a single shot. If the user isn't connected to the net then the data would be saved to a text file and uploaded later. Once the server has the data it would do some basic math to figure the points info and add that to the database.

sorry if thats hard to follow, its late and i'm just shy of being up for 24hrs with only a few hours sleep last night. :eek:

Folding will run on just about any system. I personally have had it running on an old Pentium 75mhz system with 32mb RAM. It was very slow, but it ran.
 
enhanced08 said:
Rather not rewrite the code? I wasn't expecting you to, but you still never said how the data was to be uploaded.
It's POSTed to a script that inserts it into a database.

enhanced08 said:
I'm still not following how uploading on each frame is going to be better. We are talking about the same "frames" right? I'm speaking of the frames of each work unit. A system might finish a unit every 3 min, so every 3 min you want to send data?

No. I queue them up. 20 at a time, maybe; so if you're finishing a unit every 3 minutes (Which would be really fast, wouldn't it? Did you mean a frame?), you won't try to upload until 3 * 20 == 60 minutes has gone by.

enhanced08 said:
If the user isn't connected to the net then the data would be saved to a text file and uploaded later.
This is what "enqueued' means.

enhanced08 said:
This would mean that the database would have to have some way of keeping track of each frame of each work unit of each machine which in my mind would get tricky. I was thinking more along the lines of.... folding@home runs, finishes work unit, PTRAK or YURT or FART, whatever its going to be called runs and figures up the average time per frame some how then reads some text file which contains the system info (CPU, RAM, etc) and uploads all the data in a single shot.

Once the server has the data it would do some basic math to figure the points info and add that to the database.

Databases are for keeping track of things in big lists, so we've got the right tool!

All of this is elsewhere in the thread, but let me see if I can quickly summarize it.

Right now, there's two programs. FAHInstaller and FAHMonitor. Yes, the names can change—it'll take about an afternoon for me to fix all that. FAHMonitor is not done yet, but all the pieces are ready and they just need to be put together. FAHInstaller is in good shape, and OSUGuy and UnhappyMage have already tested it with me. It's some of their machines that are listed at the website.

FAHInstaller runs and shows a dialog box. That dialog box lets you choose which directories you've got clients installed to. When you choose some directories, it stores some info in the registry. There's also a "Send" button which lets you post the information about your machine -- memory, clock speed, CPUID info, and so on. That registers your machine at the statistics website.

InstallerShot.jpg


That's all that FAHInstaller does (for now; maybe it needs more options). You press Cancel and it is done.

You can run FAHMonitor, now. FAHMonitor will end up being a service, but we'll probably test it as a console application so that it is easier to debug. It looks at the registry for the directories that FAHInstaller setup. Then, it starts monitoring them. When it sees the log file change, it reads the file to figure out what happened.

If it finds a good time stamp on a work unit or a frame, it will make a note of it. It also finds the protein that was being processed at the time. It adds this information to a queue. If the queue gets full, it tries to send that information in a batch to the website where it's recorded with the other work that machine has done in the database.

This approach dynamically adjusts the average for the protein as more work is being completed. It's just a little math; nothing tricky about it.

enhanced08 said:
Folding will run on just about any system. I personally have had it running on an old Pentium 75mhz system with 32mb RAM. It was very slow, but it ran.
I'd like to know what the minimum system it'll run on is. I don't see that information listed at the Stanford website -- it seems that the client will run on Windows 98, but I need to know what the lowest processor is.
 
I started a simple search page tonight. It's only got a couple of criteria and is a little fragile, but it's good progress.

The machine details page has also been enhanced to show details of the machine's featureset. (I still could use some help from someone with a dual-core machine.)

Over the weekend, I'll see how far I can get with FAHMonitor. It's probably best to try and get that into a state where you guys can test it, so that we can work it over while I'm playing with the website.

I think there should be a search for proteins page, as well, which shows how various machines do on a given protein. I don't think I can put together a comparison graph like Unhappy wants, but maybe someday ...

Right now, the search page leads to a list of matching machines. That might also show some protien work rate information, I guess.
 
If it finds a good time stamp on a work unit or a frame, it will make a note of it. It also finds the protein that was being processed at the time. It adds this information to a queue. If the queue gets full, it tries to send that information in a batch to the website where it's recorded with the other work that machine has done in the database.

What about if you are monitoring more than 1 instance of folding? Would the queue get full faster or is it a seperate queue for each instance? If you were watching 20 systems then it would be uploading quite often.

No. I queue them up. 20 at a time, maybe; so if you're finishing a unit every 3 minutes (Which would be really fast, wouldn't it? Did you mean a frame?), you won't try to upload until 3 * 20 == 60 minutes has gone by.

Yes, I meant frame, sorry.

Databases are for keeping track of things in big lists, so we've got the right tool!

Well, ya got me there.... lol


Everything sounds like it should work fine, I still dont agree with uploading data with every few frames. What do you see as an advantage here?

I'd like to know what the minimum system it'll run on is. I don't see that information listed at the Stanford website -- it seems that the client will run on Windows 98, but I need to know what the lowest processor is.

As far as I know there is no "minimum", the client can run on any system that windows linux or mac can run on. Some have gotten Linux to run on the Xbox and then installed Folding. Some talked about installing it on a Microsoft Cable TV box or something, they had Linux on it but I dont know about folding. I would say to use something like a P133 or so as the min. I know of people who run it on a PII 233mhz system.

(I still could use some help from someone with a dual-core machine.)

I have that dual PII 500, its not the fastest but its dual....


One other thing, I started a #fah-database channel on the undernet server. I have never created a channel before so I guess I did it right, seems pretty simple.
 
enhanced08 said:
Everything sounds like it should work fine, I still dont agree with uploading data with every few frames. What do you see as an advantage here?
The idea is to get perf-frame timing, and to provide a quick reward to people who install it. If they have to wait a day (or more) for a whole work unit to finish, they'll not see the results of their participation until then. Worse yet, if something is wrong, they won't know it until a while later.

What don't you like about it?

The number of frames to queue could be made configurable.

Have you tried the installer prgoram yet? Do you have any feedback after using it? What about the search page, or the machine details page? I haven't heard from anyone about these enhancements.

enhanced08 said:
As far as I know there is no "minimum", the client can run on any system that windows linux or mac can run on.
Does anyone know? Obviously, there is a minimum: it won't run on an 8088, I'm sure. An 80286? A 486?

enhanced08 said:
Some have gotten Linux to run on the Xbox and then installed Folding.
Which is illegal, and something I can not discuss.

enhanced08 said:
I have that dual PII 500, its not the fastest but its dual....
I'm asking about a dual-core machine. You've got a dual-processor machine.
 
The idea is to get perf-frame timing, and to provide a quick reward to people who install it. If they have to wait a day (or more) for a whole work unit to finish, they'll not see the results of their participation until then. Worse yet, if something is wrong, they won't know it until a while later.

What don't you like about it?

The number of frames to queue could be made configurable.

Thats a good point, people dont like to wait. I just think it would be easier both in the client and server-side to send once at the end of a unit rather than every few frames. Seems like it will be more work than is needed.

Have you tried the installer prgoram yet? Do you have any feedback after using it? What about the search page, or the machine details page? I haven't heard from anyone about these enhancements.

No I havnt tried the installer but I would like to, send me a PM with a download link? I glanced at the webpage and it seems to have a good bit of data. Using the Stanford ID is also a good idea, something I never thought of.

Which is illegal, and something I can not discuss.

I wasn't trying to make it an issue, the fact is that its been done and can be done which was my point.

I'm asking about a dual-core machine. You've got a dual-processor machine.

My bad, read it too fast. If need be I can talk to a friend of mine, he has a dual core system and has already told me that he would help beta test this program when it gets that far. He was one of the first people I talked to about this project back in November.
 
enhanced08 said:
I just think it would be easier both in the client and server-side to send once at the end of a unit rather than every few frames. Seems like it will be more work than is needed.
More development work? It's not trivial, but it's easy and almost completed. More work for the machine? I don't think it adds up to much. The ad-hoc queries are far more troubling.

enhanced08 said:
No I havnt tried the installer but I would like to, send me a PM with a download link?
Sent.

enhanced08 said:
I wasn't trying to make it an issue, the fact is that its been done and can be done which was my point.
My programs do not and will not support illegal XBox modifications.
 
More development work? It's not trivial, but it's easy and almost completed. More work for the machine? I don't think it adds up to much. The ad-hoc queries are far more troubling.

Your better at database work than I am, I just started with it and PHP back in NOvember when I started this. The only downside to having you do the database is that my server only has a MySQL database and hosting is paid up on it till next November so unless we could host the database on a different server from the website, I dont know what should be done here.

My programs do not and will not support illegal XBox modifications.

Thats fine with me, I only mentioned it as a way to explain that folding will run on almost any system that can run windows, linux or mac operating systems.
 
I'm nearly code complete.

The website has a ton of new features, and is coherently navigable. Kinda. I'm still looking for requests and suggestions here.

The monitor tool stops and starts and queues requests. It stays coherent between restarts, and sends requests correlty to the site. If the site isn't up, gives an error, or is unreachable, the queued requests say -- if they're accepted, the queued requests are correctly removed from the queue.

The parsing code doesn't detect or report full work unit completion yet. I thought I had coded this, but I guess I didn't. It won't take long to add, though it's a bit of a pain to test since I have to pile up some work unit completions for sample data.

I'm going to test on my machines for a few days, and you'll see that data on the site. After that, I'll need some beta testers. (I would hope that this time I'll get more than two or three.)
 
I'll help as always......


actually.... if you guys want to help, shoot me a PM, and I'll compile to the beta testers

Just send me a PM with your email address... or if you don't feel comfy about that, just send me a PM and let me know you're interested in beta testing....


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

 
Do we have a name yet? I see the voting thread is now locked, but I hadn't been notified of any decision. I'd like one soonest, as the longer we wait the more I have to rename and change and edit, and so on.

Any artwork?
 
I started a thread asking for help with artwork..... e08 sent me a PM with the name he wanted (YURT), I just assumed he sent one to you also.......



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

 
OSUguy98 said:
e08 sent me a PM with the name he wanted (YURT), I just assumed he sent one to you also.......
Nope, I haen't received anything. Thanks for letting me know about the decision; maybe in the next couple of days I'll have time to rename everything.
 
Looks like the first day of testing went well; you can see that some of my machines at home have been uploading all their progress and it's visible on the site.

I'm surprised I'm receiving so little feedback; perhaps I shouldn't be spending so much energy on this. Counting the C++ utilities, the database scripts, and the ASP pages, I'm just under 10,000 lines of code.
 
I have a dualcore machine and am willing to test, just pm me.

I have been following the project but have not commented until now, but I do appreciate all your hard work Mike!
 
sobe said:
I have a dualcore machine and am willing to test, just pm me.
Since I received no useful responses, I ended up sorting it out myself. (In fact, later tonight, you should see the difference between "logical" and "physical" procs show up at the website.) If you can run CPUZ on that machine and send me the *.TXT file output, that would be helpful, tho.

(LATER: Maybe not. Either AMD and Intel are doing things differently, or they've written their specs/docs differently and are doing things the same. I can't tell. For now, I guess we'll just track only logical processor counts until I can get this sorted.)

sobe said:
I have been following the project but have not commented until now, but I do appreciate all your hard work Mike!
Thank you for your kind words. While they're cheerful, they give me little guidance about what's needed in the project. More reports? With what details? Better searching? Different search parameters? And so on.
 
Looking at the web page now.... trying to figure out what else is needed/etc.....

I did notice on the "All proteins" page that you have a typo on the "Show unworked Proteins" button... After following that link, maybe it should say "Show All Proteins" because you do include those that are in progress/etc....

Also.... should the next-to-last column heading on this page be "Frames" instead of WUs?

I'm sorry that I can't offer much guidance.... I'm trying to help out where I can.... but I'm not sure if e08 would want more info than that..... Eventually, server-side, I guess the aim would be to show a chart for each WU (or similar group of WUs) that showed each type of processor and how it fared compared to the others.... similar to the MSpaint graph mage posted here....


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

 
OSUguy98 said:
I did notice on the "All proteins" page that you have a typo on the "Show unworked Proteins" button...

Fixed.

OSUguy98 said:
After following that link, maybe it should say "Show All Proteins" because you do include those that are in progress/etc....
Fixed. I think, anyway—I don't know what you mean by "it".

OSUguy98 said:
Also.... should the next-to-last column heading on this page be "Frames" instead of WUs?
Yes, fixed. For now, this will show frames. When I get frames reported, it'll show both and I'll add another column.

OSUguy98 said:
Eventually, server-side, I guess the aim would be to show a chart for each WU (or similar group of WUs) that showed each type of processor and how it fared compared to the others.... similar to the MSpaint graph mage posted here....
I thought I previously responded to the graph suggestion, but I can't seem to find the post. I don't think a graph is a realistic goal for now. Drawing a graph in ASP isn't exactly possible without an add-in component, and I'm not sure I'm prepared to spend that kind of money on this project. We can cobble together graphics/HTML table based charts, but I think they're a little grody.

Table-based reports, though, are no problem. I put this one together last night. I have to see if the math is correct, because it doesn't seem quite right. Should this report be further broken-down by protein so that the same workloads are being compared?

That is, are work units normalized so that no matter what project they relate to, they're intended to take about the same amount of time? Is it points that are normalized? If I know what work event is comparable, then I know what the target entity of each report should be.

Mage also suggested that the queries the site should show is "A topic for discussion", but I've seen zero discussion here on the matter.
 
OSUguy98 said:
did notice on the "All proteins" page that you have a typo on the "Show unworked Proteins" button...

OSUguy98 said:
After following that link, maybe it should say "Show All Proteins" because you do include those that are in progress/etc....
mikeblas said:
Fixed. I think, anyway—I don't know what you mean by "it".

the "it" is the button I mention in the first question.... it says "unworked proteins", but (I think) you're linking to a complete list of all the proteins..... so maybe it should say "Show All" instead of "unworked"....

Wow... didn't think we'd have to spend that kind of $$$ on a graphing program (though, I've never researched it)......

Hardfolding and EOC both use graphs from Advanced Software Engineering which you can see here

Would this work?


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

 
OSUguy98 said:
the "it" is the button I mention in the first question.... it says "unworked proteins", but (I think) you're linking to a complete list of all the proteins..... so maybe it should say "Show All" instead of "unworked"....
Oh, I see. I guess I originally meant "include unworked proteins". It's fixed.

OSUguy98 said:
Hardfolding and EOC both use graphs from Advanced Software Engineering which you can see here

Would this work?
As far as I can tell, it would work -- but it isn't much cheaper. (Their license page is a little confusing.) Also, with the hosting plan I have, I don't think I can install objects like that, anyway. I'd have to look into it.
 
they have a "free version" but I don't know what all that entails..... or if it would fit our needs..... I would assume HF and EOC run the free version since they say (unregistered) at the bottom of the graphs....

mikeblas said:
Mage also suggested that the queries the site should show is "A topic for discussion", but I've seen zero discussion here on the matter.
I'm not sure what he meant.... I'll look back through the thread and see if I can find where he mentioned it....


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

 
OSUguy98 said:
I'm not sure what he meant.... I'll look back through the thread and see if I can find where he mentioned it....
It was in the very same note you linked to, with the MS Paint graph. I think he meant what he said: that we should have a discussion about which queries are interesting and which are not. That's the discussion that I'm trying to start.

I've provided a few examples on the website already, but I haven't heard much back about them. More of the same? Some detail needed? Something missing? Some scoping required? And so on.
 
points per day (ppd) and $$/GHz are two of the figures that are discussed most.... Most of us buy based on "best bang for the buck" because we're all cheap SOBs :D

Points are reflective of the "value" to stanford... they know we like our stats so they'll put bonuses on WUs they want returned quickly... they know we'll do what we can to get them..... the points are based off of a benchmark machine (2.8 Northwood with all the bells and whistles disabled...) More info here..... So to answer your question earlier.... It's points that are normalized....

Basically, what we need to know, is what proteins a certain CPU can get (for example, AMD chips can't get QMDs..... no one can right now, but they should be back someday)..... the flags people run do alot to determine the type of WU they get assigned..... So if there was a "hypothetical" page where the user picked the CPU they were thinking about buying, they could play with how much RAM they put it, which flags and which OS.... and we could give them a range for ppd....

Does that make sense?

examples:........

Any CPU, with the client set to "deadline-less" WUs will basically just get ~240 point TINKERs, no matter the RAM, no matter the OS...

Any CPU can recieve "Big WUs" unless the PC has less than 256MB (or 512, can't remember)....

An Intel chip, can get any WU across the board

An AMD can get most WUs (sans the QMDs)

The newest core from Stanford (GROMACS33) is only available to Linux boxen....


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

 
It'd be nice to be able to sort CPUs by average points per day generated (over a large number of WUs). Just a list of CPU name -> clock speed -> PPD triplets. It'll be a long list; maybe you could filter it to a certain range of speeds, or CPUs where the clockspeed is +/- 1% of "nominal" - that is, stock-clocked. The second filter would be the really hard one to write.

That's all I can think of for now. The $$/gHz is a completely different problem, I think.

 
Yup.. for the $$/GHz... you'd almost have to have a link to my folding farm spreadsheets....


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

 
mikeblas said:
What's the oldest machine that will run the Folding at Home client? Pentium III? Pentium II?
I missed this, let me respond. The oldest that will actually run FAH is a 486, I think. I haven't run it on one, but I know it'll work without MMX or SSE.

However, most people don't actually do that - a 486 would take several weeks to turn in a single timeless WU, so I'd expect the lowest you'd find would be a 586 (aka Pentium).

 
OSUguy98 said:
Basically, what we need to know, is what proteins a certain CPU can get (for example, AMD chips can't get QMDs..... no one can right now, but they should be back someday)..... the flags people run do alot to determine the type of WU they get assigned..... So if there was a "hypothetical" page where the user picked the CPU they were thinking about buying, they could play with how much RAM they put it, which flags and which OS.... and we could give them a range for ppd....

Does that make sense?
Not really. What's a QMDs?

Until this point, we haven't said anything about collecting the command line options the user is using for the client. Is that a new requirement?

Also, before now, I've never heard mention of collecting $$/GHz. I already measure clock speed in GHz in the client; what is "$$"? Cost for the machine, in total? Just the CPU and motherboard? Do we have the user input that value in the FAHInstaller program?

If the Stanford folks can adjust the scoring to make certain work units more attractive, then it means the points don't normalize anything -- you don't know when you're dealing with a fudged score, do you? Or do you mean that they loosely normalize the workload, and that despite the adjustments, we can still normalize to points per unit of time?

unhappy_mage said:
It'd be nice to be able to sort CPUs by average points per day generated (over a large number of WUs). Just a list of CPU name -> clock speed -> PPD triplets.
I can modify the rate by name report to give that later.

Thanks for the details about the 486. Since current versions of Windows don't run on the 486, I'll skip it. I needed to figure out if I had to detect the availability of the CPUID instruction before actually executing it.

Would a Pentium take more than a day to run a work unit, or a frame, without restarting? If so, then I need to account for that -- there's no date stamp in the log, so I have to guess at time going by.
 
mikeblas said:
Not really. What's a QMDs?
A QMD is an example of a WU that was very large, so the Stanford people put a bounty on it. It took a large amount of memory and memory bandwidth, so it stressed systems pretty hard, so they gave out double points (IIRC; in any case, a multiple of what they benchmarked at) for QMD units.
mikeblas said:
Also, before now, I've never heard mention of collecting $$/GHz. I already measure clock speed in GHz in the client; what is "$$"? Cost for the machine, in total? Just the CPU and motherboard? Do we have the user input that value in the FAHInstaller program?
I think this is a pretty broad question, as well. I think for now we can safely ignore it.
mikeblas said:
If the Stanford folks can adjust the scoring to make certain work units more attractive, then it means the points don't normalize anything -- you don't know when you're dealing with a fudged score, do you? Or do you mean that they loosely normalize the workload, and that despite the adjustments, we can still normalize to points per unit of time?
They don't very often re-value work units, so it's usually safe to assume point values don't change; in any case, if you use EM3's data files they'll change to reflect the differences.
mikeblas said:
I can modify the rate by name report to give that later.

Thanks for the details about the 486. Since current versions of Windows don't run on the 486, I'll skip it. I needed to figure out if I had to detect the availability of the CPUID instruction before actually executing it.
Cool and cool. As long as the 586 works it should be no problem.
mikeblas said:
Would a Pentium take more than a day to run a work unit, or a frame, without restarting? If so, then I need to account for that -- there's no date stamp in the log, so I have to guess at time going by.
A WU, yes, a frame no.

 
mikeblas said:
Since I received no useful responses, I ended up sorting it out myself. (In fact, later tonight, you should see the difference between "logical" and "physical" procs show up at the website.) If you can run CPUZ on that machine and send me the *.TXT file output, that would be helpful, tho.

(LATER: Maybe not. Either AMD and Intel are doing things differently, or they've written their specs/docs differently and are doing things the same. I can't tell. For now, I guess we'll just track only logical processor counts until I can get this sorted.)

OK, just put the call out if you need my dual-core services :)

Thank you for your kind words. While they're cheerful, they give me little guidance about what's needed in the project. More reports? With what details? Better searching? Different search parameters? And so on.

I did not get in on the beta test but I have been looking at the website. A few things I would suggest adding if possible would be the username associated with each machine, and an option to search for all machines under a specific username. What about showing each machine type's average PPD, PPW, etc? I may add more suggestions later, I've got to go do some work now.
 
sobe said:
OK, just put the call out if you need my dual-core services :)
YGPM. (Soon, anyway.)

sobe said:
I did not get in on the beta test but I have been looking at the website. A few things I would suggest adding if possible would be the username associated with each machine, and an option to search for all machines under a specific username.
Yeah, that seems interesting to me too -- but it wasn't on the website that was offered as a spec to me, and so I figured it was actively eliminated. Maybe because of privacy concerns, or something. (I guess I should give up on this project having a spec, and therefore ever being done, or ever being correct.)

Should I add the user name? It seems like username isn't unique; you need username and team number taken together. Is that true? I can have FAHInstaller.EXE pull it out of the Client.CFG file.

sobe said:
What about showing each machine type's average PPD, PPW, etc?
What are PPD and PPW? Points per day and points per week? That's coming up tonight.
 
Yeah, that seems interesting to me too -- but it wasn't on the website that was offered as a spec to me, and so I figured it was actively eliminated. Maybe because of privacy concerns, or something. (I guess I should give up on this project having a spec, and therefore ever being done, or ever being correct.)

Should I add the user name? It seems like username isn't unique; you need username and team number taken together. Is that true? I can have FAHInstaller.EXE pull it out of the Client.CFG file.

Anyone can submit workunits under any given username, but a single username can not be bound to more than one team at a time. As far as privacy concerns go, I think that anyone wanting to freely contribute their stats to this project would not mind having their username show up for their machines. This is not so much a different concept as any other stats tracker that shows user's information.

What are PPD and PPW? Points per day and points per week? That's coming up tonight.
You are correct sir, I will be watching for the implementation!
 
The update is there -- that is, the points/day column is now on the per procname report.
 
Just checked it out, it's lookin' good! I will be thinking about other additions etc that we might add to it.
 
OK, so I'm thinking of making a beta available for this weekend. Here's what's blocking the beta:

  • A decision about tracking the name. No use sending out another beta if this will be implemented later, since it's quite core to the way things work.
  • Renaming everything. This is a PITA, but I guess I've just got to buck up and do it.
  • Getting the parser to notice completed work units.
  • Write some documentation.

I can take care of the last three, but the first one needs the group to form a concensus.

Here's other work items. These are mine, unless people help:

  • Come up with a style sheet for the website.
  • I have to make a decision about the data model for compelted work units and frames. It might be a good idea to store them in the same table, or keep them seperate. I have to sit and think about how it will affect the queries. But since I don't know what queries we'll want, I can't get to this.
  • A little more ASP cleanup. There's some copy-and-paste going on, and I could fix most of it with includes.
  • Tone down the logging. For the beta, I want all the debugging spew I can get. I'll either remove the logging, or make it configurable.
  • Various clarity/prettyness fixes to logging.
  • Rotate the monitor program log file so it doesn't get big. One day is 800K, at the moment.
  • Add searching by common name, like "Pentium 4". This will help with the older processors.
  • Add searching by family/model/revision.
  • Fix the search page do use client-side script so that searching by common name is exclusive to searching by family/model/revision.
  • Can't have the monitor log to the same directory it's watching. I can document this for the first beta, but it would be best to make the monitor notice it and quit. It would cause a hang: the monitor would write to the log, the change event would fire, and so the monitor would write to the log, causing the change event to fire, ...
  • Convert the monitor to a service. This is another thing that would make debugging more difficult, so I'm putting it off for the first betas.

Here's things for the group:

  • Moar queries.
  • There's no artwork. I haven't received a response about it, even, so I pinged the other thread.
 
I'm all for tracking by user name, but we don't have a concensus.

And I have questions: can they change? Sobe says that you can't use the same UN in two different teams at the same time, so I don't need the team for uniqueness. But can a user change their username? Do we put passwords on it, or just push the user name to the server? We're not very tight about data security and integrity. Is that OK? It's obviously not the way I'm used to working. Do we store the username at install time, then just use that forever? Or should we get the username from the config file when the monitor starts up and use that?
 
I think we should include the folding name if it's easy to find/track....

I don't think most people who would use this program would mind their folding name being attached to the data.......

---------------------------
are queries something we can add down the line? if we get what we have now tested/etc, is it difficult to come back and add a query to two somewhere down the line?

---------------------------
Usernames can change at the whim of the user.... most set it and forget it..... If this is going to be a team-independent thing like e08 wants, I say we keep the team in there... that way we know where the points are coming from, who turning them in,etc........ Is the easiest way to do that to check the .cfg file to get user and team?

Also, usernames (for Stanford) are case sensitive......... relic != Relic....


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

 
OSUguy98 said:
I think we should include the folding name if it's easy to find/track....
It's easy to find, but I don't think it's easy to track. I'm not into historizing the ownership of a particular machine ID against a list of usernames.

OSUguy98 said:
---------------------------
are queries something we can add down the line? if we get what we have now tested/etc, is it difficult to come back and add a query to two somewhere down the line?

---------------------------
Yes and no. If I know a particular query is interesting, then I can make sure the data model on the database server supports it -- and supports it efficiently. At this point, I need to screw-down the data model. If there are queries we can forsee wanting, I'd like to know about them so I can make sure we have the data to drive them and that the database structure makes them easy and efficient.

It's possible to add queries down the line, if the data has been collected the whole time. It's just that the query might not be optimal because the data model wasn't designed with that query in mind.
 
Ok Mike, here are some icons that I whipped up.

32x32
yurt.jpg

16x16
yurt_small.jpg


Suggestions welcomed. I can make changes and once the design is finalized, I will send you the .ico files.

What type of art are we looking for the site? Size requirements, etc...
 
Back
Top