How about a Team Rally?

[em99010pepe]

No offense BC, but Predictor is not stable. It seems to be down more than it's up. But I know your doing your best to get it up. I'm just being an ass.

Predictor@home is in alpha-test phase. Please consider that we are still fixing minor (and sometimes major) problems and therefore some results might be deleted and some credits reset at any time.

[BC]

To ALL: (includin those who are not in the main loop)

Current status: (Please excuse the tired, cranky nature of this post)

-- Item 1 --
BOINC was written on the Solaris operating system. Anyone who has done multi-process ( fork() ) programming and 'signal()' processing knows that Linux and Solaris are different because one is BSD based and one is System V based. This is the fundamental issue because BOINC DEV admits that they did NOT code for anything OTHER than Solaris.


--- Item 2 ---
I just re-wrote most of the work unit generators Mfold and Charms. I did it in about 2 1/2 hours. They are both running stable and are completely reloading the database at this time.

The work unit queue was completely empty. It will run overnight. It can now generate 3600 WUs/hour compared with approx 250/hr before.

I did this, tested it, and ran tests on the test server at Predictor all in 2.5 hours.

The WU generators will now run overnight and build up a supply of WUs to give to start handing out. The decision was made, mostly by *MY* vote, that the WU generation be given top priority. There should be enough work units built up by morning for all 100,000 computers attached to the project... YES, 100,000+


--- Item 3 ---
I am going to continue working as long as I can tonight (and am willing to accept the help of anyone who understand 'child process termination' in C, Python, Perl, and or PHP (C & PHP preferred) to edit ***EVERY SINGLE FILE ** and get the signal handling code written and tested for System V operation. SETI/BOINC let us down. PERIOD.

--- Item 4 ---
The system will return tomorrow morning. You will be able to download & upload work and view the basic web page, but all statistics display will be disabled (the 'CGI' modules) until they are fixed individuallly.


--- Item 5 ---
Tomorrow, A Solaris machine will be setup and at some point, the web / cgi side will be moved to the Sun box. The workhorse machine (which works fine and is actually running right now) is going to be offloaded of its web duties. This, plus the 4 GB of memory now present, will allow it to keep our hungry AMD machines (Yes, the stats do confirm a 9x increase in AMD WU traffic) fed.

--- Item 6 ---
All new WUs will have a quorum of 3, not 2.. This will prevent unfair low-ball scores from screwing anyone up. The credit granted will be the mean value. This is also the farest way to give benefit to slow machines and to fast machines. This is being done in conjunction with the pairing / grouping of machines more tightly based on benchmarks. You will see WU's start being handed out to machines of equal performance. This gives EVERYONE a fair chance at getting a decent score for donating their CPU time.

The logic is this: If you donate 100% of a CPU that asks for 45 credits, you should get it (or what the group quorum of similar machines agree on). If you donate 100% of a CPU that asks for 20 credits, you should get it (or what the group quorum of similar machines agree on).

The "Seti" technique / method is going to be discarded. Your credit will be based on "Percentage of CPU time donated".. period.

--- Item 7 ---
Thursday (PST), the web server will be rehosted (and switched over transparently). You will know the web server switch has been completed because stats are going to be available again.

--- Item 8 ---
I am going to to continue re-writing (with assistance from anyone willing to help), as much code as possible to be platform independent.

I am going to make one of my machines available to Predictor as the AMD WU Generator. This will hurt my stats, but help the rest of the project overall until 2 more machines can be setup.

Predictor is now going to Beta phase.





---- Item last ---
Anyone with suggestions may email me directly, (I prefer candor and prefer it in private). I welcome *ALL* comments, suggestions, and offers of help.


PM me if you can't get my real email address. If you do write me direct, please put ' AMDUSERS as the first word of the subject so I know to give it top priority reading.


Thanks,
Chuck

[Ototero]

Excellent work BC, While you're mucking about with the code, how about a patch to treble points for team amduser :D :D :D :D :D

Let today be Big Crunch Day

[BC]

Excellent work BC, While you're mucking about with the code, how about a patch to treble points for amduser teams :D :D :D :D :D

Let today be Big Crunch Day [/i]

Ototero,
To be candid, it was the load that we, and the 'other big hitters' put on the machines that pushed them over the edge.

The same architectural failure that hit Seti hit Predictor. ... We will be victorious.

The PM is the scientist and ensuring data is validated. The Web guy is DONATING his Sun box for the web service until the new machine arrives. The ONLY real difference is that I am coding/architecting now (instead of Seti/boinc doing 100% of it) and writing/re-writing OS level code


Last, but by far least, the participation and patience of all participants is GREATLY appreciated.


Predictor MUST be ready for the July 26 CASP presentation if it and D2OL are to continue. We have LOTS of work to do... so pass the word.

ANd yes, I did forget to post the personal thanks of the PM and Science Department head for the effort and results obtained in this amount of time by the contibuting members of Predictor. We got lots of 'kudos' for helping a) producing the results we did b) find this error and c) fix it a LOT fast and better than Seti.

[em99010pepe]

--- Item 2 ---
The work unit queue was completely empty. It will run overnight. It can now generate 3600 WUs/hour compared with approx 250/hr before.

That's a great improvement!

--- Item 3 ---
I am going to continue working as long as I can tonight (and am willing to accept the help of anyone who understand 'child process termination' in C, Python, Perl, and or PHP (C & PHP preferred) to edit ***EVERY SINGLE FILE ** and get the signal handling code written and tested for System V operation. SETI/BOINC let us down. PERIOD.

Can't help you here. I only know a few languages like visual basic, fortran, CNC, autolisp.

--- Item 5 ---
Tomorrow, A Solaris machine will be setup and at some point, the web / cgi side will be moved to the Sun box. The workhorse machine (which works fine and is actually running right now) is going to be offloaded of its web duties. This, plus the 4 GB of memory now present, will allow it to keep our hungry AMD machines (Yes, the stats do confirm a 9x increase in AMD WU traffic) fed.

Could you send an email to those guys running AMD processors to see if they want to join us!

--- Item 6 ---
All new WUs will have a quorum of 3, not 2.. This will prevent unfair low-ball scores from screwing anyone up. The credit granted will be the mean value. This is also the farest way to give benefit to slow machines and to fast machines. This is being done in conjunction with the pairing / grouping of machines more tightly based on benchmarks. You will see WU's start being handed out to machines of equal performance. This gives EVERYONE a fair chance at getting a decent score for donating their CPU time.

The logic is this: If you donate 100% of a CPU that asks for 45 credits, you should get it (or what the group quorum of similar machines agree on). If you donate 100% of a CPU that asks for 20 credits, you should get it (or what the group quorum of similar machines agree on).

It would be fair if the system score was related to time giving to process not by number of processed wu's. That's my opinion. I have a slow machine and i'm always losing to fast ones although sometimes i have more processing times.

[AMDave]

BC,

thanks for your "Howdy" couple of days back.
Bit difficult to assist from Oz via a modem - too infrequently connected
(a friend donated a new 56Kbps Winmodem to my effort BTW) .

But I would like to add a thought to the Teaam melting pot...

Think about it guys...Isn't it great to be part of a team that sets out to exceed expectations...and succeeds !
:D

Have ramped back up on D2OL until things clear up.

If you are back on SysV, (don't know your CPU count, h/w etc.) remember to optimise the parallel process count to maximize the process completion rate. Yes I have created wonderful bottlenecks before

Best I can offer right now is - make sure there's a Coke / Coffee machine inside 50 metres and a pillow under your desk ! Oh ... and biscuits ... 'coz you can leave them on your desk and get back to them later ;)


The sun will still be shining tomorrow.

[Beerknurd]

BC,

Pls forgive my last post. I feel that it was a little harsh. I know that you are working very hard. Keep up the good work.

Jason

[BC]

It would be fair if the system score was related to time giving to process not by number of processed wu's. That's my opinion. I have a slow machine and i'm always losing to fast ones although sometimes i have more processing times.

Please allow me to ammend that comment.. it's not quite worded right.

Faster machines will CLAIM less credit for the same WU as a slower machine because of the ratio of the standard_computer/benchmark *IF* both spend 100%. This is because the 'elapsed time' is also taken into the equation.

The actual equation is closer to:
Complexity_Factor * (standard_computer / ('cpu time'/'elapsed time') )

This basically says... give all your time to a difficult WU and get the most credit... Notice that 'cpu_time/elapsed_time' is the key. The next factor is the 'standard computer'.. and finally the 'complexity....

I will post the equation after I'm all done with getting things working and we can work it out as a group... because it *DOES* need fixing.


For now, Good night my friends....

I have fixed enough code for one night... it's 5:24am and I must be at work on time (mid-day shift.... 12pm - 8pm). The morning team arrived already at 4am.... (we are in sync with east coast right now..that's why).


Cheers all,
BC.

[BC]

BC,

Pls forgive my last post. I feel that it was a little harsh. I know that you are working very hard. Keep up the good work.

Jason

Jason,

WHAT post???? I didn't see any

Chuck

[em99010pepe]

BC,

What you are saying to me is this:

If you have two computers, one computer A 2x faster than computer B, the credit score given will be the same at the end of a day.

Pepe