Just a thought to everyone out there on the "Connect to network about every" settings. I keep mine very low compared to some that I have read. On my work systems I use .4 hours This means that when every I'm within 9.6 Hrs of running out my computer will go get some more. One system, a 2.8Ghz P4 normally has 4 work units at any given time. When It starts the last one it gets 3 more. More important it reports the 3 that have finished and already uploaded "ready to report". Even if a completed work unit has been uploaded it doesn't get validated and credit given until it has been reported. When I had that setting at 1-2 days I did cache a large amount of work units but I also had a large group in the "Ready to Report" status. The point I'm trying to make is that a lower setting helps everyone. By taking less work units there is more for everyone else. By reporting completed ones quicker, credits come faster IE: the Validater que isn't so big waiting for that 3rd result. My setting are Home .1 days which means I start asking for the next one at about 2Hrs out from completing the current workunit and at work I use .3 days (school 4 cpu) & .4 days (work 3 cpu or less)

I really can't see the need for any setting above 1 to 1.5 days unless you know that you'll be disconnected (NOT SETI going down) from the internet for a long time.

If you question how well this works look at my stats
http://setiweb.ssl.berkeley.edu/team_display.php?teamid=19670

Steve

Hey Matt

Or any one else for that matter. Any comments on my post

Steve

If everyone attached every 2 hours, the requests would be overloaded. I think a minimum should be forced at like 1/2 day, or even once a day. This will allow for more random hits for people asking for work, and the bandwidth saved from 200,000+ people trying to hit the servers every 2 hours.

Just in how to cut the numbers. It's not a perfect science, but at least it's working.

---

My movie https://vimeo.com/manage/videos/502242

> I really can't see the need for any setting above 1 to 1.5 days unless you know that you'll be disconnected (NOT SETI going down) from the internet for a long time

there are some additional points to include:

lets say you have a client with 4 attached projects.
3 Project are having a resulting project share of 20%, the last, due favorite,
gets 40%.

With this settings, even a 1.5 Day setting CAN be to low to get work from a project having a low share setting.

Tried the setting with 0.1 in above constellation, the clients finished, but didn't got new work until the queue of the other project is done.


An other reason can be, our dial in users. At their place, I would *stuck* work also for a *resonable* amount of days and doing the download while the connections costs are cheap.

A coins always have 2 sides. sometimes even more;-)

It's a long time ago, I stoppend to try to understand all, it's enough sometimes, to just accept..

The higher number labeled clients are dealing much better with the ready to Report stated Work, at least in *my* environment, the are no longer sitting for hours here. This was not the case in earlier releases.

happy chrunching!
friendly

> If everyone attached every 2 hours, the requests would be overloaded.

I agree, with the .4 setting at work my fastest system 2.8G P4 connects when it's on it's last of 4 work units. It reports 3 and gets 3 more. the slower PIII 600mhz connect once maybe twice and never has more than 2 work units. These systems are up 24x7. At home I use .1 that way I only have 1 work unit and about 2 hours before it finishes it asks for the next one. I'm also running just Seti@home at this time so I have no idea what the interaction is with other projects. My main point was with those who set 5 - 10 days grabbing a large chunk of work and then not reporting the results for several days.

Thanks for the thought Steve

---

> If everyone attached every 2 hours, the requests would be overloaded. I think
> a minimum should be forced at like 1/2 day, or even once a day. This will
> allow for more random hits for people asking for work, and the bandwidth saved
> from 200,000+ people trying to hit the servers every 2 hours.
>
> Just in how to cut the numbers. It's not a perfect science, but at least it's
> working.
>

Not allowing the number to be set to something less than one day sounds great in theory, but will have huge consequences and make big problems in practice. Al of us doesn’t have fast computers running only one project 24/7. With 4 projects this would mean that i would have to cache minimum 4 days of work. This would limit the number of projects a computer could be attach to. The Einstein wu’s I am currently running take 40H and have a 7-day deadline. If I would have to have a one-day cache instead of my current 15-min I would have one day less of margin towards the end of the deadline, and possibly make me run over.

---

> Not allowing the number to be set to something less than one day sounds great
> in theory, but will have huge consequences and make big problems in practice.
> Al of us doesn�t have fast computers running only one project 24/7. With 4
> projects this would mean that i would have to cache minimum 4 days of work.
> This would limit the number of projects a computer could be attach to. The
> Einstein wu�s I am currently running take 40H and have a 7-day deadline. If I
> would have to have a one-day cache instead of my current 15-min I would have
> one day less of margin towards the end of the deadline, and possibly make me
> run over.

You can set it to a fraction of a day. So, one of the more common settings is 0.1 days. I tend to do 2-4 as I like to keep a little work queued up. Though when the LHC@Home gets going and Einstein@Home gets a few more bugs out I may try a real short turn around to see how it goes.

Remember, we are still in semi-testing mode on all of the BOINC projects. We are doing science, but we are also doing troubleshooting of the infrastructure at the same time. Once we have the bugs down into the noise, I think we shall see more stability ... but we don't even have a full "feature complete" version of BOINC yet (GUI on Mac and Linux).

---