Downloading 0.15 seconds of work??!!
26 Mar 2005 22:27:15 UTC
Topic 188755
(moderation:
I have 2 x Pentium 4 (HT) 3.0 GHz machines and have downloaded the new BOINC client (4.25) and get messages like "Downloading 0.15 seconds of work". At any givven time I have only three workunits downloaded per machine. Under 4.19, I would have 9 to 10 workunits in queue. The machines are fast enough to handle the workload, so why the drip feeding of workunits?
Downloading 0.15 seconds of work??!!
)
> I have 2 x Pentium 4 (HT) 3.0 GHz machines and have downloaded the new BOINC
> client (4.25) and get messages like "Downloading 0.15 seconds of work". At
> any givven time I have only three workunits downloaded per machine. Under
> 4.19, I would have 9 to 10 workunits in queue. The machines are fast enough
> to handle the workload, so why the drip feeding of workunits?
>
this also happend to me 2 or 3 times.
Don't worry.
I take that as a glitch somewhere - the wus requested turned out to be just normal; the time required to compute them was totally in limits
By all accounts this is
)
By all accounts this is merely a superficial issue, however, I am concerned with the lack of downloaded work units held in queue. If the work unit distribution server goes down for more than a few hours, my PCs will be idle without anything to process.
You say this has happened to you 2 or 3 times? This happens to me consistantly every time since downloading the new BOINC client (4.25).
Something is amiss...
> this also happend to me 2 or 3 times.
> Don't worry.
> I take that as a glitch somewhere - the wus requested turned out to be just
> normal; the time required to compute them was totally in limits
>
>
> By all accounts this is
)
> By all accounts this is merely a superficial issue, however, I am concerned
> with the lack of downloaded work units held in queue. If the work unit
> distribution server goes down for more than a few hours, my PCs will be idle
> without anything to process.
Several instances of boinc all the way back to beta have had issues where they ask for a very small amount of work (typically 1 second). The project doesn't have data units that small, but the project should always send enough data to be more than the amount asked for by whatever is necessary for a whole work unit.
If your computer takes 5 hours, for example, asking for 1 second should send you 5 hours worth of work, as that's the smallest amount einstein can send.
Hi Darren, Yes, that is
)
Hi Darren,
Yes, that is what we are finding as well, though I'd expect more than a single workunit to be downloaded, as per v4.19 where I got 8 to 9 at a time. Any ideas why I am being drip-fed?
I wish they would pull out the IV, I can chew. ;)
> Yes, that is what we are
)
> Yes, that is what we are finding as well, though I'd expect more than a single
> workunit to be downloaded, as per v4.19 where I got 8 to 9 at a time. Any
> ideas why I am being drip-fed?
Sorry, don't know how you can get past it. I would suggest that you trying making a small change to your setting for your cache size, rerun your benchmarks then try updating the project after that. I don't know if it will help or not, but that will cover the things you can readily adjust that effect how much work you ask for. Maybe a nudge in one direction or the other will help.
Daren, Sure enough, I
)
Daren,
Sure enough, I adjusted the communication frequency with the server and that did the trick--I have now downloaded a fair chunk of workunits.
Thanks for everyone's help with this--this was not a bug but a user preference configuration issue.
> Thanks for everyone's help
)
> Thanks for everyone's help with this--this was not a bug but a user preference
> configuration issue.
Having just read through this thread, I'm guessing that you had the default of 0.1 for the connect interval and that you have now changed this to something like 2.0 days. Your faster machines now have a bunch of work which they should be able to handle but what about your slower machines? Many of them don't seem to have updated yet but when they do they will also get much more work and might not be able to handle it within the time limit. Just thought I'd warn you about this, although if you have it all under control just tell me to bugger off and mind my own business :).
When you are deciding on an appropriate cache size, please be mindful of the fact that if you have about 20 workunits on hand (as you seem to have with one of your faster boxes), the last work will be rather stale by the time your box gets around to processing it and this will continue with the newer units that are being added on an ongoing basis. The E@H project seems quite stable and probably doesn't really require you to keep so much on hand.
There are a couple of disadvantages with a large cache, including the risk of exceeding deadlines and having your work count for nothing. Also you slow down the process of clearing the older validated units out of the online database, requiring it to be larger than it really needs to be. This is probably the major factor why the E@H developers are staying with the one week deadline. It's a bit of a catch22 situation really.
Cheers,
Gary.
Hi Gary, All of what you
)
Hi Gary,
All of what you said makes perfect sense, and yes, I did have the update frequency set to 0.1 days initially. I now have it at 1.0 days which should be sufficient for each of the machines I am running.
Now, as for downloading too many workunits and the potential for workunit expiration, I believe there is a daily quota, and mine appears to be 16 workunits downloaded per day. If I have the update frequency set to 1.0 days, I do not think I should exceed that quota. This is just about what I process in a day. So we should be fine there. I will give this a few days to see if I start queueing up.
Thanks for your inputs--I will keep this in mind.
> I now have it at 1.0 days
)
> I now have it at 1.0 days which should
> be sufficient for each of the machines I am running.
Sounds like that should be fine. I was just a bit worried you might have it larger than that.
With the number of boxes you have you should soon rack up an even more impressive score. It's already pretty impressive now.
All the best with your crunching efforts and keep up the good work.
Cheers,
Gary.
> By all accounts this is
)
> By all accounts this is merely a superficial issue, however, I am concerned
> with the lack of downloaded work units held in queue. If the work unit
> distribution server goes down for more than a few hours, my PCs will be idle
> without anything to process.
>
> You say this has happened to you 2 or 3 times? This happens to me consistantly
> every time since downloading the new BOINC client (4.25).
It is far more often than I noticed before, I just looked it up.
Out of 53 requests for work there are 27 requesting less than 1000 secs and 12 of them requesting less than 10 secs.
I found it by sorting the messages for all computers with Boincview - which I consider a very good tool if you have more than just 1 or two machines running.
You can get this tool here:
http://boincview.amanheis.de/?page=download