> I have something similar myself. I don't pretend to know the exact details
> behind it but I can see from my logs that I have uploaded and downloaded
> several workunits today from the server. What I can see is that, like you, I
> can see two 'work units' in the project folder. They are H1_0367.9 and
> H1_0344.4. All of the WUs I have uploaded and downloaded today start with
> these 'IDs' (actually they are all H1_0344.4__**)....
>
>
> Perhaps someone with a more detailed knowledge is reading these posts and can
> explain it to us?
Somewhere in another threat I saw a response to that: all the WU's we have are coming from one big file. The number of the files downloaded are depending from the resource share setting and the setting of "connect to". All the WU's are extracted from these files. Once a file like that is completely "used", this file is replaced by a new one.
> > Are you considering to give out work to computers grouped bye average
> > turnaround time?
>
> Yes -- in fact I made some modifications to the scheduler to do this. But
> then David Anderson (chief BOINC architect) persuaded me that what I had done
> was not a good idea. So I backed it out. I'll probably come back to it in
> the future.
What i was thinking of was to try to find a way to divide all computers in to two gropes that would crunch an equal amount of WU / time period, with all computers with the faster turnaround times in one grope and the slower in the other. To do this i would try to find out what the mean turnaround time for all the WU’s returned say in the last 7 days was, lets call this value T. Now then a computer would need WU’s from a new data set i would let it download data set A if it had a faster turnaround time then T and data set B if it was slower. If it were a new computer (turnaround time 0.00) i would give it the data set B. In my mind this wouldn’t put to much stress on the servers since it would only be used every time an computer would need a new data set and the value T would only be needed to be calculated say once a day.
Then you're really interested in a subject, there is no way to avoid it. You have to read the Manual.
> > Then the scheduler have to resend a WU, is it sent to the first
> available
> > computer or do you have preferences for who gets whose?
>
> During 3.5 days after creation, the WU goes to the first machine which has the
> right data file, that needs work. During the next 3.5 days, it also has some
> probability of being picked up by a machine that has NO data files. Finally,
> after 7 days, it goes to the first machine that requests work, which has a
> broadband (>100 kB/sec) network connection.
So if i would attach a new computer i would only get a resent WU as a first WU if the scheduler had been trying to send it out for at least 3.5 days. The reason i asked was because then i attached to SETI a couple of months ago the first WU i got was i WU that was resent out. Somehow this didn’t feel right, because i think the probability that something goes wrong is greater with the first WU downloaded.
Then you're really interested in a subject, there is no way to avoid it. You have to read the Manual.
> Here's a link to a E@H participant's CPU that is a perfect example of why I
> think the deadlines should be shorter, not longer. What’s the deal
> with this?
>
> Case
> study for shorter deadlines!
>
This is a perfect example why deadlines should be longer! The same will happen to the WUs I downloaded. I attached to the project with SETI@Home Preferences set to connect every 2 days. E@H downloaded 17 WUs. Running my computer 10 hours a day and doing some work beside E@H I can return approximately 2-3 WUs/day. Crunching Monday through Friday makes this 10-15 WUs (in Europe electricity costs money!). Therefore 2-7 WUs will time-out. When I go on holidays for 1 week all WUs will time-out. Is that the idea?
I joined E@H today. It seems to have downloaded just a single wu.
I think BOINC is missing several things right now, 2 I'd like to see soon are the old "stop_after_send.txt" mechanism whereby a participant can stop receiving units if desired, without detaching from the project and losing the current wu. Sometimes, I want to concentrate on a particular project for my own reasons, normally simple competitive issues.
Another nice feature would be to have some manual control over the scheduling - it may help the situation being described here. If I can see that a wu is getting close to it's deadline, I could flag CPDN/S@H/P@H/LHC as "disabled" at the client level. I realise I can go to the websites and adjust all the percentages, but that is a pain if like me, you participate in all the projects. Having this does not solve the problem above, since suspending a project at the client level would simply risk running it past it's deadline which is of no use to anyone.
Wave upon wave of demented avengers march cheerfully out of obscurity into the dream.
> I joined E@H today. It seems to have downloaded just a single wu.
>
> I think BOINC is missing several things right now, 2 I'd like to see soon are
> the old "stop_after_send.txt" mechanism whereby a participant can stop
> receiving units if desired, without detaching from the project and losing the
> current wu. Sometimes, I want to concentrate on a particular project for my
> own reasons, normally simple competitive issues.
>
> Another nice feature would be to have some manual control over the scheduling
> - it may help the situation being described here. If I can see that a wu is
> getting close to it's deadline, I could flag CPDN/S@H/P@H/LHC as "disabled" at
> the client level. I realise I can go to the websites and adjust all the
> percentages, but that is a pain if like me, you participate in all the
> projects. Having this does not solve the problem above, since suspending a
> project at the client level would simply risk running it past it's deadline
> which is of no use to anyone.
>
Some, if not all, these features are in the Alpha of Boinc CC now being developed.
Questions? Answers are in the BOINC Wiki.
Boinc V6.10.6 Alpha Test
WinXP C2D 2.1G 3GB
For the features you are requesting, you should check out Boincview. I am using the latest release candidate for the new core clients (Version 1.0 RC5). I never run the Boinc manager, it has a long way to go to come close to what Boincview is capable of.
This is indeed a very clear analysis of the situation.
> So what could be done to reduce the size of the database? If i am correct, the
> database that we are talking about hear are the database that consists of
> entries of what host have downloaded what WU. Then you download a WU an entry
> is made in the database. This entry remains in the database until all other
> users who have downloaded the same WU have bean accounted for or the deadline
> for unaccounted users have bean reached. My question is, are the entries in
> the database removed a.s.a.p. or is the removal delayed a couple of days so we
> can look at some past results? If so, i am willing to trade that feature for a
> couple of hour’s extension to the deadline.
I'd appreciate feedback on this. I decided to leave completed WU in the database for 7 days, to let our participants go back and examine them. Reducing this storage time would indeed help to keep the database 'lean and mean'. Would less than 7 days be OK? What do you propose?
> One thing that has become apparent to me is that people in general, at least
> the people that post here, set their caches to high. I don't know if it is
> motivated by a paranoia about not being able to connect and get more work or
> if it is just an over sensitivity to being out of work for a few minutes while
> their machines connect and get work but I for one want the absolute minimum of
> work units sitting on my hard drives and I have never had a problem of having
> no work.
>
> I think the default of 0.1 days to connect to the network is ideal if you have
> a connection that is always on. If you're crunching 24x7 then maybe 0.5 - 1
> days. If you're dial up, then that is another matter entirely and maybe most
> people are on dial up connections.
>
> There have been a very few instances where one of the 4 projects I'm working
> on couldn't provide me work but that's why there's BOINC in the first place,
> so you can work on multiple projects so this is a non-issue. One project has
> no work, BOINC just rolls to the next in line. On my machines, all projects
> share equally, it makes it so simple, why make it complicated.
>
I hve my queue set to 0.1 days. BOINC insists on downloading work from all projects, even though that overloads the computer to such an extent that deadlines are missed. I do not think that a 0.1 deadline is too long.
> I have something similar
)
> I have something similar myself. I don't pretend to know the exact details
> behind it but I can see from my logs that I have uploaded and downloaded
> several workunits today from the server. What I can see is that, like you, I
> can see two 'work units' in the project folder. They are H1_0367.9 and
> H1_0344.4. All of the WUs I have uploaded and downloaded today start with
> these 'IDs' (actually they are all H1_0344.4__**)....
>
>
> Perhaps someone with a more detailed knowledge is reading these posts and can
> explain it to us?
Somewhere in another threat I saw a response to that: all the WU's we have are coming from one big file. The number of the files downloaded are depending from the resource share setting and the setting of "connect to". All the WU's are extracted from these files. Once a file like that is completely "used", this file is replaced by a new one.
Anybody corrects me if this is not the case.
Greetings from Belgium
Thierry
> > Are you considering to
)
> > Are you considering to give out work to computers grouped bye average
> > turnaround time?
>
> Yes -- in fact I made some modifications to the scheduler to do this. But
> then David Anderson (chief BOINC architect) persuaded me that what I had done
> was not a good idea. So I backed it out. I'll probably come back to it in
> the future.
What i was thinking of was to try to find a way to divide all computers in to two gropes that would crunch an equal amount of WU / time period, with all computers with the faster turnaround times in one grope and the slower in the other. To do this i would try to find out what the mean turnaround time for all the WU’s returned say in the last 7 days was, lets call this value T. Now then a computer would need WU’s from a new data set i would let it download data set A if it had a faster turnaround time then T and data set B if it was slower. If it were a new computer (turnaround time 0.00) i would give it the data set B. In my mind this wouldn’t put to much stress on the servers since it would only be used every time an computer would need a new data set and the value T would only be needed to be calculated say once a day.
Then you're really interested in a subject, there is no way to avoid it. You have to read the Manual.
> > Then the scheduler have
)
> > Then the scheduler have to resend a WU, is it sent to the first
> available
> > computer or do you have preferences for who gets whose?
>
> During 3.5 days after creation, the WU goes to the first machine which has the
> right data file, that needs work. During the next 3.5 days, it also has some
> probability of being picked up by a machine that has NO data files. Finally,
> after 7 days, it goes to the first machine that requests work, which has a
> broadband (>100 kB/sec) network connection.
So if i would attach a new computer i would only get a resent WU as a first WU if the scheduler had been trying to send it out for at least 3.5 days. The reason i asked was because then i attached to SETI a couple of months ago the first WU i got was i WU that was resent out. Somehow this didn’t feel right, because i think the probability that something goes wrong is greater with the first WU downloaded.
Then you're really interested in a subject, there is no way to avoid it. You have to read the Manual.
> Here's a link to a E@H
)
> Here's a link to a E@H participant's CPU that is a perfect example of why I
> think the deadlines should be shorter, not longer. What’s the deal
> with this?
>
> Case
> study for shorter deadlines!
>
This is a perfect example why deadlines should be longer! The same will happen to the WUs I downloaded. I attached to the project with SETI@Home Preferences set to connect every 2 days. E@H downloaded 17 WUs. Running my computer 10 hours a day and doing some work beside E@H I can return approximately 2-3 WUs/day. Crunching Monday through Friday makes this 10-15 WUs (in Europe electricity costs money!). Therefore 2-7 WUs will time-out. When I go on holidays for 1 week all WUs will time-out. Is that the idea?
Martin, the settings should
)
Martin, the settings should be at connect every .05 days
and manually connect for more WU's.
The example listed returned two or three units compaired to the dozens not returned.
It's obvious that this unit is for work or other duties and then the unit is shut down when not in use.
This should be a case study on what not to do.......
Tim
If you need an Avatar, I'll create one for you!
Captain.Avatar-[at]-Gmail.com
I joined E@H today. It seems
)
I joined E@H today. It seems to have downloaded just a single wu.
I think BOINC is missing several things right now, 2 I'd like to see soon are the old "stop_after_send.txt" mechanism whereby a participant can stop receiving units if desired, without detaching from the project and losing the current wu. Sometimes, I want to concentrate on a particular project for my own reasons, normally simple competitive issues.
Another nice feature would be to have some manual control over the scheduling - it may help the situation being described here. If I can see that a wu is getting close to it's deadline, I could flag CPDN/S@H/P@H/LHC as "disabled" at the client level. I realise I can go to the websites and adjust all the percentages, but that is a pain if like me, you participate in all the projects. Having this does not solve the problem above, since suspending a project at the client level would simply risk running it past it's deadline which is of no use to anyone.
Wave upon wave of demented avengers march cheerfully out of obscurity into the dream.
> I joined E@H today. It
)
> I joined E@H today. It seems to have downloaded just a single wu.
>
> I think BOINC is missing several things right now, 2 I'd like to see soon are
> the old "stop_after_send.txt" mechanism whereby a participant can stop
> receiving units if desired, without detaching from the project and losing the
> current wu. Sometimes, I want to concentrate on a particular project for my
> own reasons, normally simple competitive issues.
>
> Another nice feature would be to have some manual control over the scheduling
> - it may help the situation being described here. If I can see that a wu is
> getting close to it's deadline, I could flag CPDN/S@H/P@H/LHC as "disabled" at
> the client level. I realise I can go to the websites and adjust all the
> percentages, but that is a pain if like me, you participate in all the
> projects. Having this does not solve the problem above, since suspending a
> project at the client level would simply risk running it past it's deadline
> which is of no use to anyone.
>
Some, if not all, these features are in the Alpha of Boinc CC now being developed.
Questions? Answers are in the BOINC Wiki.
Boinc V6.10.6 Alpha Test
WinXP C2D 2.1G 3GB
For the features you are
)
For the features you are requesting, you should check out Boincview. I am using the latest release candidate for the new core clients (Version 1.0 RC5). I never run the Boinc manager, it has a long way to go to come close to what Boincview is capable of.
You can download it here.
[img]http://www.boincstats.com/stats/banner.php? cpid=19ffeb205afac117477975798c4ada3f[/img]
This is indeed a very clear
)
This is indeed a very clear analysis of the situation.
> So what could be done to reduce the size of the database? If i am correct, the
> database that we are talking about hear are the database that consists of
> entries of what host have downloaded what WU. Then you download a WU an entry
> is made in the database. This entry remains in the database until all other
> users who have downloaded the same WU have bean accounted for or the deadline
> for unaccounted users have bean reached. My question is, are the entries in
> the database removed a.s.a.p. or is the removal delayed a couple of days so we
> can look at some past results? If so, i am willing to trade that feature for a
> couple of hour’s extension to the deadline.
I'd appreciate feedback on this. I decided to leave completed WU in the database for 7 days, to let our participants go back and examine them. Reducing this storage time would indeed help to keep the database 'lean and mean'. Would less than 7 days be OK? What do you propose?
Cheers,
Bruce
Director, Einstein@Home
> One thing that has become
)
> One thing that has become apparent to me is that people in general, at least
> the people that post here, set their caches to high. I don't know if it is
> motivated by a paranoia about not being able to connect and get more work or
> if it is just an over sensitivity to being out of work for a few minutes while
> their machines connect and get work but I for one want the absolute minimum of
> work units sitting on my hard drives and I have never had a problem of having
> no work.
>
> I think the default of 0.1 days to connect to the network is ideal if you have
> a connection that is always on. If you're crunching 24x7 then maybe 0.5 - 1
> days. If you're dial up, then that is another matter entirely and maybe most
> people are on dial up connections.
>
> There have been a very few instances where one of the 4 projects I'm working
> on couldn't provide me work but that's why there's BOINC in the first place,
> so you can work on multiple projects so this is a non-issue. One project has
> no work, BOINC just rolls to the next in line. On my machines, all projects
> share equally, it makes it so simple, why make it complicated.
>
I hve my queue set to 0.1 days. BOINC insists on downloading work from all projects, even though that overloads the computer to such an extent that deadlines are missed. I do not think that a 0.1 deadline is too long.
BOINC WIKI