Messages

Yes, it's the localhost.

After a reboot of the PC.
I start BT, connect to the localhost client.. ~ 2 mins until the menu is clickable.

Currently I can't/don't use the remote function (only one machine running currently).

Your Priority tool shouldn't disturb, because no CUDA app running - until the menu is clickable.

If I start BT and start the client, I can't enable computation/network.
I need to do then exit of BT, restart BT and then the menu is available and I can enable again the computation/network.

It may take some time before the menu is available. Initially it's grayed out and becomes active after communicating with the client.

I tested it again.. I start BT, connect to the client..
It looks like it last ~ 2 mins until the menu is clickable.
It's possible to speed up this?


BTW.
Maybe it's possible that you could add a feature, that in the 'Stderr output' at S@h we could see that we use your nice BT? Advertisement for your nice software!

Maybe something like:
<core_client_version>6.12.28</core_client_version>
<core_manager>boinctasks V1.04 by eFMer</core_manager>
<![CDATA[
<stderr_txt>
Windows optimized S@H Enhanced application by Alex Kan
Version info: ...
(...)

I see now, maybe a mistake it should look like:

<config>
   <refresh>
      <downloads>3600</downloads>
      <uploads>7200</uploads>
      <refresh>14400</refresh>
   </refresh>
</config>

?

[Thanks!]

I meant, maybe if it would be possible to add an automatically retry for the update function, you could set a minimum time we could choose, e.g. 30 mins, 1 hour or any.. - so the scheduler server isn't attacked.

I will add it to the next 1.06 release.

Thanks!


I repeat your new (added info) first message:

Add these lines to the config.xml file.
The config.xml should be placed together with the BT exe.

<config>
   <refresh>
      <downloads>   3600   </downloads>
      <uploads>     7200   </uploads>
      <refresh>     14400   </uploads>
   </refresh>
</config>

BT will now retry any pending downloads every hour and the uploads every 2 hour.
This will only affect the localhost.

As of V 1.06 an example can be found here: C:\Program Files\eFMer\BoincTasks\examples

The minimum value for the 'update' (report/request) is 4 hours?

You mean the log.xml file which is in the ..\BoincTasks\examples\log folder, which I could copy to the ..\BoincTasks folder (in which is the boinctasks.exe)?

The log.xml is for diagnostics/debugging, so don't use this here.
Create a plain text file and call it config.xml
Copy the following:

<config>
   <refresh>
      <downloads>   3600   </downloads>
      <uploads>   3600   </uploads>
   </refresh>
</config>

Safe the file in the same folder as the BoincTasks.exe and restart BT.

You wrote here:

The minimum Upload/Download settings are 120, that is in seconds
So setting it to 1800 should give you 30 minutes. You can check the logging if the value is accepted.
You should see: upload refresh: 1800 Seconds

For to see if the set values are accepted, I could see it somewhere.
In the BoincTasks/Messages I can't see it. Where I could see it?

The minimum Upload/Download settings are 120, that is in seconds
So setting it to 1800 should give you 30 minutes. You can check the logging if the value is accepted.
You should see: upload refresh: 1800 Seconds

I'm new with BT..

You mean the log.xml file which is in the ..\BoincTasks\examples\log folder, which I could copy to the ..\BoincTasks folder (in which is the boinctasks.exe)?
If yes, I should copy the whole file (with all entries - no change), or maybe make a new empty log.xml file?

I'm sorry. English isn't my mother language. 
I didn't meant the retry time for UL/DL.

I meant, maybe if it would be possible to add an automatically retry for the update function, you could set a minimum time we could choose, e.g. 30 mins, 1 hour or any.. - so the scheduler server isn't attacked.

This would be very nice.

I mean, a 24 hour backlog (also next try 24 hours later) for the update (report/request) is way too much for a high RAC machine.

What you think?

Maybe you could make it possible that we could set a time for a shorter update retry?
This would be very helpful, thanks. *thumb up*

I don't want to be responsible for more network traffic and overloaded servers.
That's why this feature is limited.

Is there no BOINC setting for a timed report?

Yes, sure I wouldn't like to have a minute retry.. 
BTW. The min contact is ~ 5 mins at S@h. If you press 'update' earlier the scheduler send an info.

Maybe it's possible to add the feature, but the min possible retry is 30 mins, 1 hour or something?
Because up to 24 hours could be way too much for a high RAC machine.


I don't know, if there is a setting in BOINC.
AFAIK, it could last up to 24 hours. And if the scheduler server isn't reachable again, again 24 hours and so on..

If I want to stop BOINC/S@h I disable computation/network in BoincTasks. Then finish client and exit BT. I do this for to be sure, that no UL/DL/scheduler contact is running and a well checkpoint is set for CUDA WU. In past I suspended a CUDA WU in the preparation time on CPU, when I restarted BOINC the CUDA WU finished immediately with an error.

If I start BT and start the client, I can't enable computation/network.
I need to do then exit of BT, restart BT and then the menu is available and I can enable again the computation/network.

Maybe a BUG?

This is a very nice feature, thanks!

Is this possible also for the report/request backlogged update function?
In past I had a ~ 12 hours backlogged update, in this time no report of results and request of new WUs.
IIRC, this can be up to 24 hours.

Maybe you could make it possible that we could set a time for a shorter update retry?
This would be very helpful, thanks. *thumb up*

BTW. Current I use BT 1.04 BETA.