I realize that run-time projections can be very wrong. The unusual thing on this was that after the reboot on all 6 beta WU's I had at the time, the time between steps nearly doubled. They reached 50% in about 5.5-6 hours, but then ended up taking around 17-19 hours each to complete.

Thanks,
Ed

Interesting reading. It raises for question for me


In the event a user decides to have networking disabled for longer than 30 minutes what will the server do. Would it mark the job in valid?

It's a harder read, but my take is:

1) Trickle message request send for the 10K step upload
2) Server waits max 30 minutes for the trickle upload to come.
3) No Upload, the End. (Better get your BOINC version up to scratch ;)

This can very well happen for those on e.g. a scheduled connection period. If that is set to say 08:00 to 18:00 and the trickle msg is sent at 7:59:58, the client will cut of networking at 08:00 and upload is in limbo.

Maybe, maybe WCG may wish to ask Dr.Anderson to make a mod to scheduling, which is already designed to report immediately in the 30 minutes before cut-off time: If upload/trickle cycle is in progress, hold off flipping network switch till upload is finished, none are queued. A 10K block is on my comps 2.1 to 5.5 hours going by this test. Swiped aside in the 'unfortunate' event? Can see cries of frustration coming, if this is the correct interpretation.

There's rush it appears, but if a deadline is 7-10 days for the whole work unit, I wonder. Also we have regular work that takes less than an hour. A trickle is 1-5.5 hours computing, maybe some had even longer times. The actual mean-times for past 4 days in hours of the beta:

13.7383
19.1683
17.5747
19.6399

i.e. 1.3 to 1.96 hours between upload intervals [assuming all were 100K results]

Plan B, maybe just get rid of the trickle notion. Yes it's fun playing with features, but this whole complexity may not be needed as when we have production tasks of under 1 hour. Just wonder if instead of 20-22 computers being involved in the 2M steps, with 200-220, how close the last step would be compared to the whole 2M being computed on 1 computer. It'd be interesting to understand how QC is maintained on such a jumble of computer results being concatenated, not my problem, but interesting nonetheless.

Thanks Rob for the explanation. It is certainly going to be interesting when this phase (if that is the correct terminology) goes live to see what happens.

I was curious about the figures for the latest beta so I made a little spreadsheet just for this beta.



I have one completed at 27.18 hours on Linux with 99.92% efficiency with a Xeon E5410. I have two more in progress on other machines with one of them looking to go about 52 hours on an AMD 9150e at 1.8ghz with Win 7. Hope they allow at least a 10 day window for completion once the project is up and running. Based on the chart, the bulk of the units have been completed by some pretty fast machines, but there are some units which have been done by some pretty slow machines. If individual results were available it would be possible to calculate the median value which may be a better indicator of the machine speed distribution.The overall mean time is 18.39 hours.

Cheers