> If you would like to report the result as soon as it's uploaded that can be done.
> Start the boinc-client whit this command:
>
> boinc_gui.exe -return_results_immediately
Great!! Thanks very much for that. Solves my problem immediately.
Saenger wrote:
> > I really want to know, why this is celebrated in such an extended
> fashion, and
> > not the quick'n'dirty way.
To which ralic responded:
>
> AFAIK, it's part of the design to prevent overloading the servers.
>
> In the current system, each host will upload data, but report results and
> request more data at almost random intervals, thereby bringing more
> equilibrium to the load on the servers.
I'm sure you are correct that it's to do with reducing the load on the servers but I don't see that just delaying will achieve this. Immediate requests would seem to be just as random as delayed requests. Maybe it's more to do with aggregation of multiple claims into a single request that achieves a reduction in server load. Whatever the actual reason, I'm happy with the thought that I can automatically use a command line switch to achieve immediate claim for credit and thereby not lose future valid results. Thanks to all who contributed.
> Your machine uploads the results as soon as they are finished. It reports
> them the next time it has a scheduled contact with the assignment server.
I don't think this can be exactly correct. As explained in another thread, I had 8 completed results which had been uploaded over a period of two days whilst I was overseas and the machine running unattended. A power glitch took the machine down just one day after I left and two weeks later when I arrived back and restarted the machine, the 8 results were claimed but by this time it was too late. The interesting thing is that I had a connect interval of 1.0 days which I had reduced to 0.2 days more than a whole day before I departed so my client would have been talking to the servers every 0.2 days approximately. Why weren't the accumulating uploaded results reported and claimed on one of those scheduled contacts? My guess is that because my cache was being run down from 1.0 days to 0.2 days scheduled contacts were not downloading any extra work. The machine in question does complete more than 4 results per day and I vaguely remember a cache size of about 6 or 7 on the day before I left.
>
> If your machine dies and never contacts the assignment server again (or not
> for a long time) the work unit will still get reported when the deadline
> arrives. Before it gives up on you, the system will actually check to see if
> the wu has been uploaded and just never reported. As long as it gets
> uploaded, it will find it - eventually.
I'm not exactly sure what you are saying here. 8 otherwise valid results were uploaded prior to the power glitch. So the system would have known it had 8 results that had not been claimed when the expiry date arrived. What does it then do? Presumably it does know where those results came from and therefore could register some sort of temporary claim pending an actual claim.
Please don't get me wrong. I'm not really griping about the lost credit. It's more to do with the waste of resources by those 8 results having to be recalculated by other machines when they could have been used.
> Holmis wrote:
>
> > If you would like to report the result as soon as it's uploaded that can
> be done.
> > Start the boinc-client whit this command:
> >
> > boinc_gui.exe -return_results_immediately
>
> Great!! Thanks very much for that. Solves my problem immediately.
>
>
> Saenger wrote:
>
> > > I really want to know, why this is celebrated in such an extended
> > fashion, and
> > > not the quick'n'dirty way.
>
> To which ralic responded:
> >
> > AFAIK, it's part of the design to prevent overloading the servers.
> >
> > In the current system, each host will upload data, but report results
> and
> > request more data at almost random intervals, thereby bringing
> more
> > equilibrium to the load on the servers.
>
> I'm sure you are correct that it's to do with reducing the load on the servers
> but I don't see that just delaying will achieve this. Immediate
> requests would seem to be just as random as delayed requests. Maybe it's more
> to do with aggregation of multiple claims into a single request that achieves
> a reduction in server load. Whatever the actual reason, I'm happy with the
> thought that I can automatically use a command line switch to achieve
> immediate claim for credit and thereby not lose future valid results. Thanks
> to all who contributed.
>
> Cheers,
> Gary.
>
Using the -return results imediately switch is discoraged because it generates nearly double the amount of scheduler RPCs. With that switch on the client will make 2 RPCs per workunit. With the switch off the worst case is about 1.1 RPCs per workunit.
The switch is unneeded anyway. The client will report once the deadline is less than 24 hours away.
> Using the -return results imediately switch is discoraged because it generates
> nearly double the amount of scheduler RPCs. With that switch on the client
> will make 2 RPCs per workunit. With the switch off the worst case is about 1.1
> RPCs per workunit.
>
> The switch is unneeded anyway. The client will report once the deadline is
> less than 24 hours away.
There must be some use for the switch otherwise it wouldn't be there. Whilst not knowing the details about scheduler RPCs, I had already figured out that the use of that switch would probably be antisocial to the health of the servers so I'd figured out an alternate strategy to get uploaded results reported in a more timely manner. I plan not to have too excessive a cache size so that the client more regularly downloads new work and reports results. I'm only going to keep work on hand of about 12-24 hours. If EAH is down for more than 24 hours and I run out of work, I'll simply switch to another project. I've got a number of boxes so I'll have a project per box and switch projects if a project goes offline.
> > Hello Steve,
> > It's not a bug, it's a feature ;)
> > No really, that's just the way it's supposed to happen.
> > Reporting a result is a two-step thing:
> > 1. Upload the data
> > 2. Report it (and claim credit)
> > Afterwards it will appear in your list.
> > And your machines will contact at least every 2-3 days, each time it
> decides
> > 'I havn't got enough to do for the next 2 days, come on, send me some
> WUs' and
> > contact the scheduler therefore.
> > The manual update is only a speed-up of the process.
>
> Hi Saenger,
>
> Your reply and mine were being composed at the same time but I'd like to point
> out a flaw in this "feature" as you call it. If step 1 is actually uploading
> the result and if a machine dies after a number of these results are uploaded
> but before the step 2 credit claim is done, all those results will be lost if
> there is just a few days delay in getting the dead machine back to life. Why
> does there have to be a delay??? Why can't a successfully completed result
> upload, trigger a reporting and credit claim, say one minute later?
>
> Cheers,
> Gary.
>
The data is uploaded to the data server, and the report is made to the scheduler. Each contact with the scheduler has a certain amount of overhead in the most accessed and updated database. Access to this database is the bottleneck for the whole system on most of the projects (exception being CPDN, I believe). The fewer accesses to the this database, the faster everything runs.
I hope this helped explain why the developers did this.
> The data is uploaded to the data server, and the report is made to the
> scheduler. Each contact with the scheduler has a certain amount of overhead
> in the most accessed and updated database. Access to this database is the
> bottleneck for the whole system on most of the projects (exception being CPDN,
> I believe). The fewer accesses to the this database, the faster everything
> runs.
>
> I hope this helped explain why the developers did this.
Yes, it's very understandable. However, as people seem to want instant gratification and as knowledge of the manual update function spreads, don't you think that over-zealous use of update might just make things worse in the long run? I can see many people over using that function just to be sure that everything has been reported and claimed.
> Using the -return results imediately switch is discoraged because it generates
> nearly double the amount of scheduler RPCs. With that switch on the client
> will make 2 RPCs per workunit. With the switch off the worst case is about 1.1
> RPCs per workunit.
>
> The switch is unneeded anyway. The client will report once the deadline is
> less than 24 hours away.
Thanks for the info. Didn't think to much of extra server load but now I know better.
> long run? I can see many people over using that function just to be sure that
> everything has been reported and claimed.
I agree with you that this is probably the case at the moment. But it's like anything new. People don't trust the system yet. Once the "shiny effect" wears off and the projects become more reliable (i.e. stable), people will realise that they will get their alloted credit and the system will operate as designed.
There also exist people like myself that operate via costly dial-up connections. It's likely that we will always report immediately after uploading, so that we are sure to immediately download new work for offline crunching, in order to maximize our connect time. But I reckon we're in the minority anyway.
As an example of how things change with time, I'm reasonably sure that many old hands (beta testers) who zealously checked their results pages in the past are now only giving them a glance every now and then.
Holmis wrote: > If you
)
Holmis wrote:
> If you would like to report the result as soon as it's uploaded that can be done.
> Start the boinc-client whit this command:
>
> boinc_gui.exe -return_results_immediately
Great!! Thanks very much for that. Solves my problem immediately.
Saenger wrote:
> > I really want to know, why this is celebrated in such an extended
> fashion, and
> > not the quick'n'dirty way.
To which ralic responded:
>
> AFAIK, it's part of the design to prevent overloading the servers.
>
> In the current system, each host will upload data, but report results and
> request more data at almost random intervals, thereby bringing more
> equilibrium to the load on the servers.
I'm sure you are correct that it's to do with reducing the load on the servers but I don't see that just delaying will achieve this. Immediate requests would seem to be just as random as delayed requests. Maybe it's more to do with aggregation of multiple claims into a single request that achieves a reduction in server load. Whatever the actual reason, I'm happy with the thought that I can automatically use a command line switch to achieve immediate claim for credit and thereby not lose future valid results. Thanks to all who contributed.
Cheers,
Gary.
Cheers,
Gary.
Darren wrote: > Your
)
Darren wrote:
> Your machine uploads the results as soon as they are finished. It reports
> them the next time it has a scheduled contact with the assignment server.
I don't think this can be exactly correct. As explained in another thread, I had 8 completed results which had been uploaded over a period of two days whilst I was overseas and the machine running unattended. A power glitch took the machine down just one day after I left and two weeks later when I arrived back and restarted the machine, the 8 results were claimed but by this time it was too late. The interesting thing is that I had a connect interval of 1.0 days which I had reduced to 0.2 days more than a whole day before I departed so my client would have been talking to the servers every 0.2 days approximately. Why weren't the accumulating uploaded results reported and claimed on one of those scheduled contacts? My guess is that because my cache was being run down from 1.0 days to 0.2 days scheduled contacts were not downloading any extra work. The machine in question does complete more than 4 results per day and I vaguely remember a cache size of about 6 or 7 on the day before I left.
>
> If your machine dies and never contacts the assignment server again (or not
> for a long time) the work unit will still get reported when the deadline
> arrives. Before it gives up on you, the system will actually check to see if
> the wu has been uploaded and just never reported. As long as it gets
> uploaded, it will find it - eventually.
I'm not exactly sure what you are saying here. 8 otherwise valid results were uploaded prior to the power glitch. So the system would have known it had 8 results that had not been claimed when the expiry date arrived. What does it then do? Presumably it does know where those results came from and therefore could register some sort of temporary claim pending an actual claim.
Please don't get me wrong. I'm not really griping about the lost credit. It's more to do with the waste of resources by those 8 results having to be recalculated by other machines when they could have been used.
Thanks for your comments.
Cheers,
Gary.
Cheers,
Gary.
> Holmis wrote: > > > If you
)
> Holmis wrote:
>
> > If you would like to report the result as soon as it's uploaded that can
> be done.
> > Start the boinc-client whit this command:
> >
> > boinc_gui.exe -return_results_immediately
>
> Great!! Thanks very much for that. Solves my problem immediately.
>
>
> Saenger wrote:
>
> > > I really want to know, why this is celebrated in such an extended
> > fashion, and
> > > not the quick'n'dirty way.
>
> To which ralic responded:
> >
> > AFAIK, it's part of the design to prevent overloading the servers.
> >
> > In the current system, each host will upload data, but report results
> and
> > request more data at almost random intervals, thereby bringing
> more
> > equilibrium to the load on the servers.
>
> I'm sure you are correct that it's to do with reducing the load on the servers
> but I don't see that just delaying will achieve this. Immediate
> requests would seem to be just as random as delayed requests. Maybe it's more
> to do with aggregation of multiple claims into a single request that achieves
> a reduction in server load. Whatever the actual reason, I'm happy with the
> thought that I can automatically use a command line switch to achieve
> immediate claim for credit and thereby not lose future valid results. Thanks
> to all who contributed.
>
> Cheers,
> Gary.
>
Using the -return results imediately switch is discoraged because it generates nearly double the amount of scheduler RPCs. With that switch on the client will make 2 RPCs per workunit. With the switch off the worst case is about 1.1 RPCs per workunit.
The switch is unneeded anyway. The client will report once the deadline is less than 24 hours away.
BOINC WIKI
BOINCing since 2002/12/8
> Using the -return results
)
> Using the -return results imediately switch is discoraged because it generates
> nearly double the amount of scheduler RPCs. With that switch on the client
> will make 2 RPCs per workunit. With the switch off the worst case is about 1.1
> RPCs per workunit.
>
> The switch is unneeded anyway. The client will report once the deadline is
> less than 24 hours away.
There must be some use for the switch otherwise it wouldn't be there. Whilst not knowing the details about scheduler RPCs, I had already figured out that the use of that switch would probably be antisocial to the health of the servers so I'd figured out an alternate strategy to get uploaded results reported in a more timely manner. I plan not to have too excessive a cache size so that the client more regularly downloads new work and reports results. I'm only going to keep work on hand of about 12-24 hours. If EAH is down for more than 24 hours and I run out of work, I'll simply switch to another project. I've got a number of boxes so I'll have a project per box and switch projects if a project goes offline.
Thanks for the info in your comments.
Cheers,
Gary.
Cheers,
Gary.
It was needed for testing way
)
It was needed for testing way back when. I think it is finally removed from the 4.2x clients.
BOINC WIKI
BOINCing since 2002/12/8
> > Hello Steve, > > It's not
)
> > Hello Steve,
> > It's not a bug, it's a feature ;)
> > No really, that's just the way it's supposed to happen.
> > Reporting a result is a two-step thing:
> > 1. Upload the data
> > 2. Report it (and claim credit)
> > Afterwards it will appear in your list.
> > And your machines will contact at least every 2-3 days, each time it
> decides
> > 'I havn't got enough to do for the next 2 days, come on, send me some
> WUs' and
> > contact the scheduler therefore.
> > The manual update is only a speed-up of the process.
>
> Hi Saenger,
>
> Your reply and mine were being composed at the same time but I'd like to point
> out a flaw in this "feature" as you call it. If step 1 is actually uploading
> the result and if a machine dies after a number of these results are uploaded
> but before the step 2 credit claim is done, all those results will be lost if
> there is just a few days delay in getting the dead machine back to life. Why
> does there have to be a delay??? Why can't a successfully completed result
> upload, trigger a reporting and credit claim, say one minute later?
>
> Cheers,
> Gary.
>
The data is uploaded to the data server, and the report is made to the scheduler. Each contact with the scheduler has a certain amount of overhead in the most accessed and updated database. Access to this database is the bottleneck for the whole system on most of the projects (exception being CPDN, I believe). The fewer accesses to the this database, the faster everything runs.
I hope this helped explain why the developers did this.
BOINC WIKI
> The data is uploaded to the
)
> The data is uploaded to the data server, and the report is made to the
> scheduler. Each contact with the scheduler has a certain amount of overhead
> in the most accessed and updated database. Access to this database is the
> bottleneck for the whole system on most of the projects (exception being CPDN,
> I believe). The fewer accesses to the this database, the faster everything
> runs.
>
> I hope this helped explain why the developers did this.
Yes, it's very understandable. However, as people seem to want instant gratification and as knowledge of the manual update function spreads, don't you think that over-zealous use of update might just make things worse in the long run? I can see many people over using that function just to be sure that everything has been reported and claimed.
Cheers,
Gary.
> Using the -return results
)
> Using the -return results imediately switch is discoraged because it generates
> nearly double the amount of scheduler RPCs. With that switch on the client
> will make 2 RPCs per workunit. With the switch off the worst case is about 1.1
> RPCs per workunit.
>
> The switch is unneeded anyway. The client will report once the deadline is
> less than 24 hours away.
Thanks for the info. Didn't think to much of extra server load but now I know better.
> long run? I can see many
)
> long run? I can see many people over using that function just to be sure that
> everything has been reported and claimed.
I agree with you that this is probably the case at the moment. But it's like anything new. People don't trust the system yet. Once the "shiny effect" wears off and the projects become more reliable (i.e. stable), people will realise that they will get their alloted credit and the system will operate as designed.
There also exist people like myself that operate via costly dial-up connections. It's likely that we will always report immediately after uploading, so that we are sure to immediately download new work for offline crunching, in order to maximize our connect time. But I reckon we're in the minority anyway.
As an example of how things change with time, I'm reasonably sure that many old hands (beta testers) who zealously checked their results pages in the past are now only giving them a glance every now and then.