I have to assume it is a BOINC problem because the same pattern is happening on both computers.

This is BOINC by design as I see it. And IMHO it's flawed.

See this post.

I have to assume it is a BOINC problem because the same pattern is happening on both computers.

So I don't see any harm in having a little something for everybody who participates in BOINC. The dilemma is determining where to draw the line and who gets to decide.

My concept of helping is to let them tell me what they want me to do and then doing it. I don't try to tell them what or how.

I just installed Boinc x64, 5.10.8 on a Linux machine (Arch Linux). The client runs fine, and I can look at the tasks remotely, but when I try to look at things locally, I get:

boincmgr: No such file or directory

Logged in as root, boincmgr does exist, and permissions are set to 'Is executable'. ldd shows:

ldd: warning: you do not have execution permission for boincmgr, not a dynamic executable.

• this particular executable somehow got invalid. As it works fine on your other linux boxen, you might try to copy it over
  
• dynamic loader on your Arch Linux has some problems either with executable or some library that is required by boincmgr. Not much that you can do about it unless there are updates/upgrades available for your linux distribution
  
• file somehow lost execute permissions. You can set them by executing command chmod 755 boincmgr
  

HTH.

My firewall allows my machine to ESTABLISH a connection to any IP address on port 80. And any established connection can be replied to. So once I am connected as I imagine FireFox does, it goes along OK.

But there is something different about the way the BOINC client does it that gets all these rejects.

If you are building from source then you need the proper version of curl. And that keeps being changed as the new versions of curl provide newer features.

I tried building the 5.10.18 client (the current alpha version) on Linux (on Fedora Core 4), but it failed to build for me. I can build the current SVN HEAD, but not 5.10.18.

Now that might be because I don't understand branches in SVN as well as I did in CVS. I know CVS use of tags for both snapshots and branches was confusing, but I got used to it. Can someone who got 5.10.18 to build tell me how they checked it out?

svn co http://boinc.berkeley.edu/svn/branches/boinc_core_release_5_10/

Hmmm ... I just retried to compile my own BOINC CC and now I succeeded. The successful compilation was done using GCC 3.4.4 on Debian Sarge i686 and using GCC 4.1.2 on Debian Etch x86_64.

Previously I was using ICC and it still fails while trying to do some IPO over sandbox functions. It also failed when compiling using GCC on Debian Lenny x86_64 but I tried some fairly aggressive optimisation flags, so this might be the same problem.

Thanks for encouragement to retry!

I've got 11 boxes of various different flavours running the latest self-compiled SVN code without any problems.

I wasn't really thinking of dial-up users in particular - more about machines that aren't on that much which will finish tasks but then not upload them before being switched off.

I'd have thought retrying all connections from a given client (in serial as they do) would be better than them making the connection and sending one task, then disconnecting, and then repeating the same a later on... I understand the point about too many connections swamping the server but surely the server will just tell the client to wait if it's busy, in which case you've not lost out over the current functionality.

i'm not sure if this has been discussed/considered before, but I've noticed that if a machine doesn't/can't connect for a while and builds up a queue of completed jobs then when it comes to upload them they don't all upload at once. The countdowns continue and the retry isn't initiated until the countdown is complete on a task by task basis. It would seem beneficial to me to retry all transfers once a connection has been established, thereby increasing the likelihood of the jobs being uploaded if the connection is intermittent, and also reducing the number of connections to the project servers.

I don't think it would have to be on a project by project basis either because if the connection problems are due to an intermittent internet connection then it's beneficial to retry all projects communications.

i rarely shut anything down when defragging as i've got it running as scheduled tasks that run at night and never have any problems with BOINC. Defrag skips locked files anyway... of course that means that locked files aren't defragged though ;)

This is the way it should work ... If you suspend BOINC cc and then you don't suspend machine, do LTD and STD still change?

Yes, it does change with no relation to whether the PC was suspended in the time the computation was suspended or not.

If I set computation suspended in Boinc manager, it isn't the same as setting Boinc core client suspended? I don't know how to suspend the core client exactly, so tell me please how to... :)

For example: I've had my PC computation suspended overnight. The project that was running last, had a debt about 8000 seconds in the evening, and when I restarted computation in the morning, it had a debt about -19000 seconds. Seems like it was computing whole night, doesn't it? But it wasn't, especially because the whole PC was suspended in power saving mode. Is it a real bug, or is it an expected behaviour?

I'm running several BOINC projects on my PC and yesterday I found something like - lets say "bug".
Because of I've installed BOINC on another PC in my private network, I've downloaded and installed BOINC manager named BoincView to help me to manage both PC's at once. I found out that in this manager, you can see some more detailed informations about computations, especially STD and LTD of each project.

And now I get to the core of the problem. I found out, that if I suspend computation, the STD (and LTD as well) remains decreasing for the project that was running last before suspending and of course it remains increasing for all the other projects.