Thanks for the answer.
I'm using Boinc View for a long time now, but never noticed this button

My satellite connection is fast download (up to 1.5M or better in burst mode) but slow 128k on uploads.

Host #1
At 8/8 It took about 3 hours to clear 1200 uploads.

I then set it back to 16/16, It took about 2.5 hours to clear the remaining 3800 uploads.

Around 1200 left I was able to restart other projects running.

--

Host #2
I was then able to attempt host 2 and got the 4800+ uploads sent from it.
But I left it to run other projects and only set file transfers to 16/16 with SciLINC's resource share set to 0.01 which yeilds 0.00% (A 1.00 on this host yields 0.06%)

--

Host #3
I turned this one on same time as #2, but made no changes to it. It ran overnight but this morning I detached SciLINC. It was so un-responsive I could never get an RPC into it to find out what was going on. I tried BOINCmanager, BOINCview and BOINCcmd. Non ever could get through.

I think I finally modified global_prefs_override.xml and set run_if_user_active to no to gain control and set file_transfers to 1/1. I could not tell how much work it had to download/upload but it was creating a backlog faster than it could clear. I didn't really look, I just gave up on this one.

Interesting situation, but now I know how to kombat it.

This sounds like an old problem to me. In the early days of Rectilinear Crossing Numbers (RCN) there were huge amounts of WUs taking less than .1 sec crunchtime and uploading 14 files each. Chances were one got 100's of these in a row and as an effect boinc got unresponsive towards the end.
Seemed to me boinc takes a bigger slice of CPU time as the size of the client_state.xml increases... even up til a point 99% of CPU time goes to boinc and none is left for crunching or even TaskManager... In the RCN case the file could become something like 2 Mb, equivalent to several 100's of files to upload. This all on my P4 1.8 (with a relatively slow disk).

As far as recovering any result-in-progress, in a few similar cases I've transplanted such results between comps. There seems to be no silver bullet for this, as each project specifically handles results and their states differently. What all projects seem to have in common though are project/result specific entries in client_state.xml and result specific entries in the project's project folder.

By examining these files and folders with an empty queue for a project and a queue of one for that particular project I was able to figure out the differences and thus how to move results between machines. After that and some trial-and-error (especially the use of notepad only and a physically disconnected network come to my mind...) I succeeded in moving results-in-progress between comps.
Always be sure though never to touch the (backed-up) back-up copy of all boinc folders...

/me dawns his flame proof fire suit.

Hello all,

I am the one responsible for SciLINC and the problems you have been experiencing.

First of all I would like to apologize for the problems everyone is seeing. When I returned Friday I realized that workunits were not flowing, the forums were disabled and an unexpected number of people and teams had joined the project. I would also like to say thank you to everyone here that has responded with helpful input for diagnosing and correcting these issues.

My first priorities were getting the work flowing again then turning on the forums so that there would be a place for feedback, venting and frustration resolution (that almost sounds politically correct.)

Just to let you all know, we did perform internal testing on the project and did not see these issues. Of the machines we tested, one had problems and that was my Windows development machine. The OpenGL driver was causing problems and the machine lagged a little bit. Nothing like what has been reported here. But that machine is also heavily loaded in a number of ways.

Of course the latency of the Internet is much higher than our local network. Unfortunately, I did not foresee that contributing to these problems.

Updates will be posted to the main SciLINC page as we get our database back on-line and are able to address the work unit issue.

Part of the discussion here has hints on improving SciLINC performance so that your machine may recover better once the database is back up.

Sincerely and regretfully,

Ron Parker

thx for taking the time to post an update here. far to ment admins do not take thise extra effert, and it is appriciated.

now, when will willy add new projects?

As soon as the site (stats) is stable again after all the DB changes.

ahh, sorry, I hadn’t noticed any probs...

Any estimates? (days, weeks, "when it’s done&quot

For so many tiny files, latency matters a lot more than speed, and as far as I know, satellite connections have quite bad (high) latency...

Months I think (better not to rise expectations)

months! :shock:

ok, well, good to know. I wont be wating for BAM! support to start some of these new projects then.

Thx for the quick update and the good work you do for us!

Thanks for the status report admin. I' look forward to crunching the project once all the details are worked out

They had to acknowledge that the current application was nort really DC-able. They have stopped for now (but have plans for the future.

There is a very good post about it in the forum over there.

I see that SciLINC has been added to BOINCstats. Yes!

Can it please be added to BAM! too?

Hi: When you are ready for more testers please send me an invite code to Mark Reiss at merko_1@juno.com -- Thank You

The project devs are asking for our input about whether to recommence the project or abandon BOINC in favour of another platform (not even sure whether the alternate platform is DC).