lawrencehardin, Dagorath:

You are close, but not quite right. My understanding is the switch was left in by accident, and was only meant for testing.

The reason for the two step mechanism makes more sense if you remember that the steps are entirely separate - there is download and upload, and there is scheduling. On a large scale, you can count on these being different machines. Also, downloading and uploading is easy. Scheduling is harder. So, the idea is to minimise the load on the scheduler by combining the reporting with a normal scheduled scheduler request.

BOINC uses a different mechanism to handle server downtime. It's called exponential backoff, and is commonly used to prevent contention.

Lawrence and Keith,

There is definitely a need to prioritise service requests during peak loads. However, on my system I see reports delayed 24/7/365. Apparently, it's not the exception, it's the rule. Does that mean the servers are under peak load all the time? There is never a time when they can relax and take a result and report together? It always makes sense to double the time spent just for the connect/disconnect protocols just to delay a report that can't be more than a few hundred bytes?

I'm not in any rush to receive my credits and I can't see why anyone else would be either... they're just credits, not money and some people need to be reminded of that, even those waiting for the 2 more credits to hit their first million, sheeesh, take a valium and get a life.

My concern is that the chance of a report getting trashed by a host increases the longer it sits on the host. Again, it's not the loss of credits. It's the time wasted on the host and even more time wasted sending the WU to another host to be crunched yet again. I assume that even if the result has been received, if the report is not received by the deadline then the WU must be re-issued?

Has anybody considered using a star-hub-spoke system, something like the way FidoNet worked back in the 80s?

PS Sorry, my last question is way off topic, most of my comments regarding return_results_immediately as well. Let's postpone that discussion to another day and a different thread and get back to Lawrence's original topic. Thanks to all who have addressed my concerns so far, I have much to learn from all of you.

Hello paradoxial,
I have an answer, which ought to get into Member News soon. The FPUs on the Intel chips use a different architecture than the PowerPC FPUs, so they do not produce identical results (even in emulation mode). This presents validation problems, so the Mac Intels will have to be treated as a separate platform by the server. The WCG intends to set this up soon, but is busy with other issues just now.

If I recall correctly from a generation ago, the IEEE 754 floating point standard tries to minimize error propagation in floating point and keeps track of some types of error (underflow, etc) but just what bits show up when it loses significance will depend on the specific architecture and is not specified in the standard.

Lawrence

A, another issue: I dont know if this was an issue in 5.2.13, but for sure the following happens in 5.4.9:

1. WU completes and as per settings, perm.connection. uploads result almost immediately.
2. @ WCG,, the WU is validated, then the BOINC points are allocated. It can be seen that validation has taken place and whatever points awarded, most of the time when the validators are not on hold, within the minute.
3. The BOINC GUI reports something like Awaiting to Report Result. Nothing happens further in BOINC GUI stats, graphs etc.
4. Hit the Project Update button, which creates a Sending Scheduler Request which has an automatic 10 minute delay and message is created to state "Reporting 1 Task" (or however many which were on standby for reporting).
5. After 10 minutes, nothing happens in BOINC GUI on stats or graphs.
6. Repeat step 4, no update in GUI.
7. Repeat step 4 again, and only then the BOINC local stats are updated.

In effect, presently 3 scheduling request must be done before GUI stats/graphs update. Usually the update happens within seconds of step 7. Can that be right?

Why a 4th, 5th, 6th, and even 7th unit is send i can understand. Aside the reported Error and Other and strange transmissions dated 1.1.1970 , some "flushers **" sometimes sit for days, a week or longer on WUs, whilst WCG wants the job to be finished, indexed, filed and moved on from the grid.

** When i travel, i take my machine off-line, so stock up on WU's. The 3 week window is perfect for that, thus seems the rush to find a quorum of 3 is wasteful (but that again is just an opinion from my angle)!

knreed says that he has set the servers to handle Mac Intels running BOINC 5.4.9 or 5.2.13. We still have to use a PowerPC (PPC) compiled version of AutoDock in emulation mode. It will be a while before we can compile and test a native version for Mac OS X (Intel).


Lawrence