I just remembered when I had SETI@Home running on both my new computer and the Pentium II. I went to the message board at SETI@Home, and asked everyone if there was a point to running it on the old computer because the new one processed so many more work units in less time. Everyone replied saying I should run it on both computers because every little amount of processing helps the project. I thought that was good advice. Why doesn't Einstein@Home recognize that? I'm sure the data in the database can't take up that much space if they found a good way to organize it. Think about it, they could probably find a way to keep all of this data in a text file. Text files take up very little space. I tested this myself, and you can have 1,389,343 characters of text in a file that takes up the same amount of space as the default desktop background image of Windows XP. That image is only about 1.37 MB. With today's hard disks, I don't think space should be much of a problem.
> ... I'm sure the data in the database can't take up that much
> space if they found a good way to organize it. Think about it, they could
> probably find a way to keep all of this data in a text file. Text files take
> up very little space. I tested this myself, and you can have 1,389,343
> characters of text in a file that takes up the same amount of space as the
> default desktop background image of Windows XP. That image is only about 1.37
> MB. With today's hard disks, I don't think space should be much of a problem.
The issue, for good or ill, is that BOINC is a system. And an integral part of that system is the database and its defined structure. If Einstein@Home were to try to change that component they may as well have started their own custom project.
Also, at this point, Einstein@Home is hosting the entire BOINC project on one server because that is all they have. So, that compounds the need for speed.
So, if you wish to use that older P II on projects use it on SETI@Home where the deadline is longer and the Work Unit processing time is shorter. You could also go to Predictor@Home though they too have a 7 day deadline.
I agree, deadlines are important to any project. Having everything tied down to one back-end server can't help matters, but there's not much they can do about that.
What still does worry me though, is the accuracy of the estimated time it takes to complete a WU. Currently each WU on the 1900+ that I previously mentioned is taking 3 - 4 hrs longer than estimated. Is there any way the Einstein team could make this "fudging" any more accurate?
> What still does worry me though, is the accuracy of the estimated time it
> takes to complete a WU. Currently each WU on the 1900+ that I previously
> mentioned is taking 3 - 4 hrs longer than estimated. Is there any way the
> Einstein team could make this "fudging" any more accurate?
There are a number of efforts underway to improve many of the aspects of scheduling work and ensuring it is done on time. When we will see that in production is anyone's guess.
For now, our best defense is to not have too large of a queue of work. I have mine set to 0.5 and have for all 7 of my computers between 60-80 Work Units on hand and in progress.
I've just installed v4.35 of the CC on my two boxes, and by the look of the new auto re-schedule to deadline features introduced, it is becoming more imperative that Einstein get their "fudge factor" more accurate. As I said before, I have four projects running on the 1900+. If E@H continues to run on such short deadlines with inaccurate completion times then I can see it ending up in such a situation that the CC will bump E@H up the queue in order that it makes the deadline to the detrement of the other three projects running on that machine.
I understand that longer deadlines are undesirable to the project, but surely E@H can do something about the accuracy of the time it takes to crunch a WU. In the meantime, I've taken my cache down from 3 to 1.5 days in hopes that it will ease the crunch slightly. In the long term this is undesirable for me, as I have two boxes on the same prefs settings, one with a much faster CPU than the other (Athlon64 FX53 2400+ as opposed to an AthlonXP 1900+). In the long term it might pay dividends to split the two boxes to different profiles, I just wish that BOINC could store all that stuff locally! Well... That's for another post. (See my configurator article for my views on this.
> I've just installed v4.35 of the CC on my two boxes....
> I have four projects running on the 1900+....
> In the meantime, I've taken my cache down from 3 to 1.5 days....
I'm interested in your experiences with the above because I'm still running 4.19 and only one project (E@H) on multiple boxes using an interval of 0.2 days. Here are some questions I'd be interested in hearing your response to:-
1. Do you think 4.35 handles scheduling of work any better than earlier versions?
2. Any particular differences you have noticed?
3. How many E@H work units did you have on hand when the interval was 3 days?
4. Has that number reduced at all yet? (probably too early to say at the moment)
5. Do you have any finished & uploaded results which still show as "ready to report"?
I know from bitter experience that earlier versions like the one I'm running will actually leave finished results sitting "ready to report" for quite a while when a cache is being "run down" like you are doing. I ended up losing eight "ready to report" results when there was a power glitch whilst I was away for a week. When I got back and restarted the box, they were all still sitting there but had expired in the meantime.
> > I've just installed v4.35 of the CC on my two boxes....
> > I have four projects running on the 1900+....
> > In the meantime, I've taken my cache down from 3 to 1.5 days....
>
> I'm interested in your experiences with the above because I'm still running
> 4.19 and only one project (E@H) on multiple boxes using an interval of 0.2
> days. Here are some questions I'd be interested in hearing your response
> to:-
>
> 1. Do you think 4.35 handles scheduling of work any better than earlier
> versions?
> 2. Any particular differences you have noticed?
> 3. How many E@H work units did you have on hand when the interval was 3 days?
> 4. Has that number reduced at all yet? (probably too early to say at the
> moment)
> 5. Do you have any finished & uploaded results which still show as "ready
> to report"?
>
> I know from bitter experience that earlier versions like the one I'm running
> will actually leave finished results sitting "ready to report" for quite a
> while when a cache is being "run down" like you are doing. I ended up losing
> eight "ready to report" results when there was a power glitch whilst I was
> away for a week. When I got back and restarted the box, they were all still
> sitting there but had expired in the meantime.
>
What I'm on about is that v4.35 seems to give the project who's deadline is closest priority which, don't get me wrong is a good idea, in my opinion, they should have implemented it this way from the start. The issue here, is with the short deadlines in combination with this feature is meaning that E@H seems to be getting an unfair priority on machines that I have set up to do 4 projects each at 100%, eg... 25% per project.
It's early days yet, as I only upgraded last night, maybe I'm just panicking for no reason. I'll just have to see as the new CC irons out the cache.
To answer your questions...
1. Not sure yet, waiting to see how it deals with my cache and adjustments made last night.
2. Bucket loads of new features including the ability to suspend individual projects which helps me fight the deadline battle amongst other things and a HUGELY improved UI.
3. On both the 1900+ and the Athlon64 I had two or three in the clip and one in the barrel as it were with a three day queue. Depending on when I checked.
4. Yeah... Too early to say.
5. No... I check each machine manually at night forcing them to report any finished work. The 1900+ stays on 24/7 anyhow with a 24/7 DSL line via a local LAN, so it can report as and when. The 64 is forced to report before I shutdown at night for the same reason.
OK, thanks very much for that. I'm going to upgrade from 4.19 and looks like 4.35 might be a good place to jump to. Sounds all good so far. Please keep us posted, thanks.
Once the deadline pressure is gone the client will go back to the time slicing. The BOINC client did run the earliest deadline first to begin with. A combination of real and percieved problems with that mode and the huge workunits at CPDN caused the change to timeslicing.
The client is less likely to attempt to download work from a project after it has been in deadline mode. So it should even out in the long run even though E@H is likely to get extra time when there is work on the client.
The 4.35 version is more likely to have ready to report work sitting on the client. This is because it does not always try to get more work when work is finished.
OK... Thanks Paul.
)
OK... Thanks Paul.
I just remembered when I had
)
I just remembered when I had SETI@Home running on both my new computer and the Pentium II. I went to the message board at SETI@Home, and asked everyone if there was a point to running it on the old computer because the new one processed so many more work units in less time. Everyone replied saying I should run it on both computers because every little amount of processing helps the project. I thought that was good advice. Why doesn't Einstein@Home recognize that? I'm sure the data in the database can't take up that much space if they found a good way to organize it. Think about it, they could probably find a way to keep all of this data in a text file. Text files take up very little space. I tested this myself, and you can have 1,389,343 characters of text in a file that takes up the same amount of space as the default desktop background image of Windows XP. That image is only about 1.37 MB. With today's hard disks, I don't think space should be much of a problem.
> ... I'm sure the data in
)
> ... I'm sure the data in the database can't take up that much
> space if they found a good way to organize it. Think about it, they could
> probably find a way to keep all of this data in a text file. Text files take
> up very little space. I tested this myself, and you can have 1,389,343
> characters of text in a file that takes up the same amount of space as the
> default desktop background image of Windows XP. That image is only about 1.37
> MB. With today's hard disks, I don't think space should be much of a problem.
The issue, for good or ill, is that BOINC is a system. And an integral part of that system is the database and its defined structure. If Einstein@Home were to try to change that component they may as well have started their own custom project.
Also, at this point, Einstein@Home is hosting the entire BOINC project on one server because that is all they have. So, that compounds the need for speed.
So, if you wish to use that older P II on projects use it on SETI@Home where the deadline is longer and the Work Unit processing time is shorter. You could also go to Predictor@Home though they too have a 7 day deadline.
I agree, deadlines are
)
I agree, deadlines are important to any project. Having everything tied down to one back-end server can't help matters, but there's not much they can do about that.
What still does worry me though, is the accuracy of the estimated time it takes to complete a WU. Currently each WU on the 1900+ that I previously mentioned is taking 3 - 4 hrs longer than estimated. Is there any way the Einstein team could make this "fudging" any more accurate?
> What still does worry me
)
> What still does worry me though, is the accuracy of the estimated time it
> takes to complete a WU. Currently each WU on the 1900+ that I previously
> mentioned is taking 3 - 4 hrs longer than estimated. Is there any way the
> Einstein team could make this "fudging" any more accurate?
There are a number of efforts underway to improve many of the aspects of scheduling work and ensuring it is done on time. When we will see that in production is anyone's guess.
For now, our best defense is to not have too large of a queue of work. I have mine set to 0.5 and have for all 7 of my computers between 60-80 Work Units on hand and in progress.
I've just installed v4.35 of
)
I've just installed v4.35 of the CC on my two boxes, and by the look of the new auto re-schedule to deadline features introduced, it is becoming more imperative that Einstein get their "fudge factor" more accurate. As I said before, I have four projects running on the 1900+. If E@H continues to run on such short deadlines with inaccurate completion times then I can see it ending up in such a situation that the CC will bump E@H up the queue in order that it makes the deadline to the detrement of the other three projects running on that machine.
I understand that longer deadlines are undesirable to the project, but surely E@H can do something about the accuracy of the time it takes to crunch a WU. In the meantime, I've taken my cache down from 3 to 1.5 days in hopes that it will ease the crunch slightly. In the long term this is undesirable for me, as I have two boxes on the same prefs settings, one with a much faster CPU than the other (Athlon64 FX53 2400+ as opposed to an AthlonXP 1900+). In the long term it might pay dividends to split the two boxes to different profiles, I just wish that BOINC could store all that stuff locally! Well... That's for another post. (See my configurator article for my views on this.
> I've just installed v4.35
)
> I've just installed v4.35 of the CC on my two boxes....
> I have four projects running on the 1900+....
> In the meantime, I've taken my cache down from 3 to 1.5 days....
I'm interested in your experiences with the above because I'm still running 4.19 and only one project (E@H) on multiple boxes using an interval of 0.2 days. Here are some questions I'd be interested in hearing your response to:-
1. Do you think 4.35 handles scheduling of work any better than earlier versions?
2. Any particular differences you have noticed?
3. How many E@H work units did you have on hand when the interval was 3 days?
4. Has that number reduced at all yet? (probably too early to say at the moment)
5. Do you have any finished & uploaded results which still show as "ready to report"?
I know from bitter experience that earlier versions like the one I'm running will actually leave finished results sitting "ready to report" for quite a while when a cache is being "run down" like you are doing. I ended up losing eight "ready to report" results when there was a power glitch whilst I was away for a week. When I got back and restarted the box, they were all still sitting there but had expired in the meantime.
Cheers,
Gary.
> > I've just installed v4.35
)
> > I've just installed v4.35 of the CC on my two boxes....
> > I have four projects running on the 1900+....
> > In the meantime, I've taken my cache down from 3 to 1.5 days....
>
> I'm interested in your experiences with the above because I'm still running
> 4.19 and only one project (E@H) on multiple boxes using an interval of 0.2
> days. Here are some questions I'd be interested in hearing your response
> to:-
>
> 1. Do you think 4.35 handles scheduling of work any better than earlier
> versions?
> 2. Any particular differences you have noticed?
> 3. How many E@H work units did you have on hand when the interval was 3 days?
> 4. Has that number reduced at all yet? (probably too early to say at the
> moment)
> 5. Do you have any finished & uploaded results which still show as "ready
> to report"?
>
> I know from bitter experience that earlier versions like the one I'm running
> will actually leave finished results sitting "ready to report" for quite a
> while when a cache is being "run down" like you are doing. I ended up losing
> eight "ready to report" results when there was a power glitch whilst I was
> away for a week. When I got back and restarted the box, they were all still
> sitting there but had expired in the meantime.
>
What I'm on about is that v4.35 seems to give the project who's deadline is closest priority which, don't get me wrong is a good idea, in my opinion, they should have implemented it this way from the start. The issue here, is with the short deadlines in combination with this feature is meaning that E@H seems to be getting an unfair priority on machines that I have set up to do 4 projects each at 100%, eg... 25% per project.
It's early days yet, as I only upgraded last night, maybe I'm just panicking for no reason. I'll just have to see as the new CC irons out the cache.
To answer your questions...
1. Not sure yet, waiting to see how it deals with my cache and adjustments made last night.
2. Bucket loads of new features including the ability to suspend individual projects which helps me fight the deadline battle amongst other things and a HUGELY improved UI.
3. On both the 1900+ and the Athlon64 I had two or three in the clip and one in the barrel as it were with a three day queue. Depending on when I checked.
4. Yeah... Too early to say.
5. No... I check each machine manually at night forcing them to report any finished work. The 1900+ stays on 24/7 anyhow with a 24/7 DSL line via a local LAN, so it can report as and when. The 64 is forced to report before I shutdown at night for the same reason.
> To answer your
)
> To answer your questions...
>
OK, thanks very much for that. I'm going to upgrade from 4.19 and looks like 4.35 might be a good place to jump to. Sounds all good so far. Please keep us posted, thanks.
Cheers,
Gary.
Some 4.35 answers for
)
Some 4.35 answers for all.
Once the deadline pressure is gone the client will go back to the time slicing. The BOINC client did run the earliest deadline first to begin with. A combination of real and percieved problems with that mode and the huge workunits at CPDN caused the change to timeslicing.
The client is less likely to attempt to download work from a project after it has been in deadline mode. So it should even out in the long run even though E@H is likely to get extra time when there is work on the client.
The 4.35 version is more likely to have ready to report work sitting on the client. This is because it does not always try to get more work when work is finished.
BOINC WIKI
BOINCing since 2002/12/8