My top dawg ran thru it's cache of work now i have only 1 dl to process... Web says everything is up...
Does anyone know if you can transfer work between machines? I have several slower hosts that I could move the work to here....

My top dawg ran thru it's cache of work now i have only 1 dl to process... Web says everything is up...
Does anyone know if you can transfer work between machines? I have several slower hosts that I could move the work to here....

-Searcher

I can be done...but as stated it is noe worth the effort. Better to wait for the splitters to catch up.

If you want to try it the thing to remember is that the host that was assigned the WU has to be the host that returns it. I.E. you have to copy the whole BOINC folder to the fast host, crunch everything with network access disabled, re-copy the folder to the original host and then activate the network to have it report the results.

There might be more to it, but again, I'd wait for the splitters to catch up.mambo

No one has ever explain why, but it seems that the longer the network lag or ping time between a system and the Berkeley servers, the less likely you are to get work during a recovery or when they are out of work, and depending on work coming directly from the splitters. I have my own ideas about why that happens but have not had the time to explore them and see if they hold up. And any "fix" might either slow the server response down too much or be a little to complicated for them to implement.

All you can do is wait.
Keep checking those machines every 10 minutes to make sure the Communications deferred backoff for requests is not longer than 10 minutes. If they are, try the "Commands - Retry Communications" option and the the Update option the next time.

Keep checking those machines every 10 minutes to make sure the Communications deferred backoff for requests is not longer than 10 minutes. If they are, try the "Commands - Retry Communications" option and the the Update option the next time.

Increasing the traffic on the servers won't help.

From the looks of things, the problem isn't the network, but the result creation rate. As they're being created, they're being dished out, there's no buffer there- hence the occasional "No work from project".

Wild guess- Possibly the large number of results & work units that were waiting for deletion was impacting on the result creation rate. I notice that they've finally dropped down to stuff all so now the result creation rate may pick up as a result. And the fact that most machines will have refilled their caches means there won't be as many requests for work either...Grant
Darwin NT

Iam not getting any either. I keep getting the message " No work from project."
I am out of work and can not get any more. It is very frustrating.

If you click on the Server Status line on the home page you will see that as of "right now" there are 11 units available to be sen out. The number is NOT real time though and they could have been sent out already. But if you keep an eye on it it should give you an idea of the availability of the new units.

The average workunits in progress lately (before the downtime) was around 2.5 million workunits, so there are still a lot of people looking for work. Everything is working and the splitters are creating work as fast as I've ever seen them (15 per second). Everyone don't fret. I'd say things will be back to "normal" by the end of today.

Iam not getting any either. I keep getting the message " No work from project."
I am out of work and can not get any more. It is very frustrating.

If you click on the Server Status line on the home page you will see that as of "right now" there are 11 units available to be sen out. The number is NOT real time though and they could have been sent out already. But if you keep an eye on it it should give you an idea of the availability of the new units.

I am back to my 30 unit buffer ... :-))Get with the Power of Computing ... USE A MAC, dammit, USE A MAC ! ;-))

To understand the current problem look at the current creation rate. It is running between 15 and 17 per second.

Just to keep up with normal demand (WU's being completed and new work sent out to replace them) takes a creation rate of 12 to 13 per second.

That only leaves about three WU's per second to fill the backlog of demand (empty queues) or build a surplus. For some reason the splitters have slowed down a little so that surplus rate is closer to 2.5 per second.

After the outage was over, there was NO surplus as that surplus queue had been drained. With the server Data Base down they could not split new work. And there was a backlog (empty queue requests) for about 1,400,000 results above normal demand to crunch or about 350,000 WU's. Add to that the additional demand caused by people increasing their queue size trying to get work, and you have demand for at least 470,000 WU's. Which means it is going to take about 52 hours to fill that backlog of request and get all the queues full again. Only then with the "No Work from Project" for most requests stop. We are only about 33 hours into this recovery, so it will be at least 19 to 20 hours before there is any surplus to fill every request. That should occur sometime early Monday morning when almost all queues will be full again.

My systems queues are currently about 90% full and am still getting "No work from Project" on most requests, only one to two WU's at a time when I do get something. Those systems with longer lag times (distance or behind proxy servers) should start seeing some WU's trickle in soon. Just keep checking your Communications deferred status and if it has backed off much over 15 minutes, try a manual Update request. Some systems might be backing off for two or three hours between request for work.

I agree with your analysis here except I think you may be underestimating the steady-state result burn rate. I think with the recent influx of crunchers it's closer to twice that. I've been estimating it will be mid week before the RTS queue gets back to anywhere near normal, and if your observation about people pushing their caches out to compensate is correct it could take longer than that.

FWIW, I've picked up about 35 results over my machines since the splitters went back online, which filled the caches for the K6's, but the PIII and 4 are at about a third of what they normally carry and holding more or less at that level for the time being.

As far as the apparent slowdown on the creation rate goes, that may be due to the fact the return rate is building up again, so the splitters have to give up some access time to the MSD to the assimilators.

I realize that some of you are in the midst of some grand competition, and that you are all very proud of how fast you are, but when we are in this situation it seems it would be fair to limit the number of work units to individuals so that some of the little folks can get some too....

LOL, I certainly can't argue with your observation on the fairness of how work seems to get sent during the shortage after big outages like this.

On the other hand, whoever said a DC project is a democracy? :-)

FWIW, I am not in the 10 day cache work hog category. I run a 2 day cache on the fast machines and 1 day on the slow ones, and utilize secondary projects to keep the CPUs hot when events like this occur.

The people on dial-up are having the hardest time getting workunits...I'm on DSL..So i'm always hooked up...ready to accept WU downloads as they beoome available...But if you're on dial-up and there's no work available from the project when you login...then you have to wait 10 minutes before BOINC manager can make another request...So it ends up being a long frustrating wait for those on dialup.

No arguement there, DU'ers have always seemed to get the short end of the stick with BOINC.

To add to your observation, the thing that gets me at least with Win 9x is BOINC has never been able to handle the modem correctly since I started running almost a year ago. I would gladly let BOINC dialup on its own, except for the fact that it can't seem to hang up the modem when it's done, regardless of what you have the preferences set to do.

Considering virtually every other internet aware app I have has no problem talking to TAPI in 9x (or any newer version for that matter), I can't understand why this hasn't been addressed in all this time.

No arguement there, DU'ers have always seemed to get the short end of the stick with BOINC.

To add to your observation, the thing that gets me at least with Win 9x is BOINC has never been able to handle the modem correctly since I started running almost a year ago. I would gladly let BOINC dialup on its own, except for the fact that it can't seem to hang up the modem when it's done, regardless of what you have the preferences set to do.

Considering virtually every other internet aware app I have has no problem talking to TAPI in 9x (or any newer version for that matter), I can't understand why this hasn't been addressed in all this time.

Alinator

When i first switched to BOINC in '04...I had dial up...and i remember that BOINC liked to phone home...alot!...I had to turn the sound down so i wouldn't here it calling Berkeley...over and over again...That's been several versions of BOINC ago...so i don't know what it's like now...But i'm glad i've got DSL...that's for sure.

Whoehaaha. Just read Gulley's remark in Message 257760 - Posted 5 Mar 2006 14:47:40 UTC
So I looked at the messages in Boinc en saw not granted requests for work since 14:27 UTC til now (requesting for an average of every ten minutes) and then since 18:43 it took half an hour. So I just looked at the defered time wich was over two hours en then hit the update button. You guess what, I got 7 wu's.LOL
Heaving set a low catch of 0.15