Regarding your final comment, whereas the development on the simple GUI, the Account Manager System, and new features for specific projects are worthy efforts, IMHO they are "fluff" when it leads to skipping a maintenance update for longstanding issues on the current production version which have a major negative impact to BOINC overall every time a project (especially SAH) goes down for 24 hours.
Here, here. I have exactly the same grouse with the lack of a maintenance release to sort out the 'work fetch' disregarding project resource shares when the queue's empty.
It's also a problem when the issue which this outage has highlighted, violates the basic principle of BOINC: "Don't micromanage". The problems which have been raised on the boards - few, and politely - all seem to be solved by advice to click the update button.
I've been monitoring the progress graphs:
which show what a deleterious and longlasting effect even quite a brief total shutdown can have on a project. Anybody planning a new BOINC project take note, and plan your server provision accordingly!
[Edit - to cure thread stretching, and also to add that I wish my pending credit hadn't gone up to over 1,000. Maybe it'll all validate in one go when those crunchers come back from their 168 hour holiday...]
...[Edit - to cure thread stretching, and also to add that I wish my pending credit hadn't gone up to over 1,000. Maybe it'll all validate in one go when those crunchers come back from their 168 hour holiday...]
LOL, Maybe I have a few of them. I only carry 3 days worth though, but my "sleepers" should be back in the game around 8 or 9 PM US EST.
Of course, that assumes mine don't blocked out by hoards of other hosts coming back online at the same time and starting it all over again. ;-)
I am now approaching the 1000 pending credit mark and have credit pending since the 6th of December.
One of the computers I am waiting for 739159 with an avg. turnaround time of 3.1 days, has 73 WUs, sent out between the 5th to 7th, outstanding which is ok. The problem is it has not reported a WU since 4th of December.
Another one 703423 has 254 WUs sent out on the 10th and 11th. The 143 WUs for the 11th will however take nearly 2 days and the outstanding from the 10th will take 1.5 days to complete. Although it reports each day, it seems as if also receives each day. It is the same as mine - AMD64 X2 4400+. My turnaround time is 0.14days as opposed to 0.49 days on this computer and I recieve about 50 WUs per day. We both run WinXP SP2 as well.
Something starnge that I noticed is that the Measured floating point speed for my computer is 2013.35 opposed to 3573.65 for this one and the Measured integer speed for mine is 1960.71 as opposed to 11652.25 for this one. A 600% difference. How is this possible while it is crunching the same seconds per WU? Is there any effect because of this?
I also notice the max WU of 72 per cpu will mean I can receive over 2 day's worth of crunching on one day. Can this happen every day and if so, when will the WUs complete?
I also think, if a host do not hoard WUs, it will not find itself in this situation and affect maybe many more other hosts when it cannot complete WUs within a day or should we all increase our caches?
I am now approaching the 1000 pending credit mark and have credit pending since the 6th of December.
One of the computers I am waiting for 739159 with an avg. turnaround time of 3.1 days, has 73 WUs, sent out between the 5th to 7th, outstanding which is ok. The problem is it has not reported a WU since 4th of December.
Another one 703423 has 254 WUs sent out on the 10th and 11th. The 143 WUs for the 11th will however take nearly 2 days and the outstanding from the 10th will take 1.5 days to complete. Although it reports each day, it seems as if also receives each day. It is the same as mine - AMD64 X2 4400+. My turnaround time is 0.14days as opposed to 0.49 days on this computer and I recieve about 50 WUs per day. We both run WinXP SP2 as well.
Something starnge that I noticed is that the Measured floating point speed for my computer is 2013.35 opposed to 3573.65 for this one and the Measured integer speed for mine is 1960.71 as opposed to 11652.25 for this one. A 600% difference. How is this possible while it is crunching the same seconds per WU? Is there any effect because of this?
I also notice the max WU of 72 per cpu will mean I can receive over 2 day's worth of crunching on one day. Can this happen every day and if so, when will the WUs complete?
I also think, if a host do not hoard WUs, it will not find itself in this situation and affect maybe many more other hosts when it cannot complete WUs within a day or should we all increase our caches?
Different opp systems yeild a different bench result for similar CPUs, make sure you are comparing a system that uses the same opp sys as yours.
Something starnge that I noticed is that the Measured floating point speed for my computer is 2013.35 opposed to 3573.65 for this one and the Measured integer speed for mine is 1960.71 as opposed to 11652.25 for this one. A 600% difference. How is this possible while it is crunching the same seconds per WU? Is there any effect because of this?
That machine is running Crunch3r's BOINC v5.5.0
Crunch3r (and some other optimisers) fiddles with the benchmarks to try and normalise credit claims on projects where credit is based on the old benchmark*time system. Here on Einstein, credits are calculated centrally so there's no point.
Basically, those benchmarks are fiction. Ignore them.
If you are noticing more machines not returning work, it's because of the outage. Many machines went on a 1 week hiatus and will not be returning their work, and reporting back until later this week, if people do not have the ability to hand reset the counter by hitting update.
Well as others have said already- don't rely on the benchmarks too much, especially when people use optimized apps or you try to compare boxes with different OSs. After installing Linux on my laptop the average WU completion time went down around 5% (which is no wonder really, Linux is just a bit gentler on a poor little Celeron's resources) while my benchmarks got absolutely pathetic (I'm benchmarking at around 50-60% of what I used to have running Win XP). So, in general, WU completion times are a better way of getting a rough guesstimate as long as one differs between short and long WUs. The WUs are a bit different in size but similar enough to give at least an overview.
Of course, the recent outage also tends to mix the statistics up a bit. I also noticed that I seem to have more pending credit than usually.
If you are noticing more machines not returning work, it's because of the outage. Many machines went on a 1 week hiatus and will not be returning their work, and reporting back until later this week, if people do not have the ability to hand reset the counter by hitting update.
Well, I see some machines that went on hiatus are starting to return work, although others are still sleeping. The week has past and they should have started by now.
Can't E@H send out requests to get the ones on hiatus active again?
Theoretically they could, but as a practical matter they can't for 2 main reasons:
1.) The default for all three types of installation does not allow remote control of BOINC. The project can relay preferences changes, but only after the host has initiated contact.
2.) If your running a 5.x client and remote RPC is enabled, they would have no way of knowing what the BOINC access password is.
RE: Regarding your final
)
Here, here. I have exactly the same grouse with the lack of a maintenance release to sort out the 'work fetch' disregarding project resource shares when the queue's empty.
It's also a problem when the issue which this outage has highlighted, violates the basic principle of BOINC: "Don't micromanage". The problems which have been raised on the boards - few, and politely - all seem to be solved by advice to click the update button.
I've been monitoring the progress graphs:
which show what a deleterious and longlasting effect even quite a brief total shutdown can have on a project. Anybody planning a new BOINC project take note, and plan your server provision accordingly!
[Edit - to cure thread stretching, and also to add that I wish my pending credit hadn't gone up to over 1,000. Maybe it'll all validate in one go when those crunchers come back from their 168 hour holiday...]
RE: ...[Edit - to cure
)
LOL, Maybe I have a few of them. I only carry 3 days worth though, but my "sleepers" should be back in the game around 8 or 9 PM US EST.
Of course, that assumes mine don't blocked out by hoards of other hosts coming back online at the same time and starting it all over again. ;-)
Alinator
I am now approaching the 1000
)
I am now approaching the 1000 pending credit mark and have credit pending since the 6th of December.
One of the computers I am waiting for 739159 with an avg. turnaround time of 3.1 days, has 73 WUs, sent out between the 5th to 7th, outstanding which is ok. The problem is it has not reported a WU since 4th of December.
Another one 703423 has 254 WUs sent out on the 10th and 11th. The 143 WUs for the 11th will however take nearly 2 days and the outstanding from the 10th will take 1.5 days to complete. Although it reports each day, it seems as if also receives each day. It is the same as mine - AMD64 X2 4400+. My turnaround time is 0.14days as opposed to 0.49 days on this computer and I recieve about 50 WUs per day. We both run WinXP SP2 as well.
Something starnge that I noticed is that the Measured floating point speed for my computer is 2013.35 opposed to 3573.65 for this one and the Measured integer speed for mine is 1960.71 as opposed to 11652.25 for this one. A 600% difference. How is this possible while it is crunching the same seconds per WU? Is there any effect because of this?
I also notice the max WU of 72 per cpu will mean I can receive over 2 day's worth of crunching on one day. Can this happen every day and if so, when will the WUs complete?
I also think, if a host do not hoard WUs, it will not find itself in this situation and affect maybe many more other hosts when it cannot complete WUs within a day or should we all increase our caches?
RE: I am now approaching
)
Different opp systems yeild a different bench result for similar CPUs, make sure you are comparing a system that uses the same opp sys as yours.
RE: Something starnge that
)
That machine is running Crunch3r's BOINC v5.5.0
Crunch3r (and some other optimisers) fiddles with the benchmarks to try and normalise credit claims on projects where credit is based on the old benchmark*time system. Here on Einstein, credits are calculated centrally so there's no point.
Basically, those benchmarks are fiction. Ignore them.
If you are noticing more
)
If you are noticing more machines not returning work, it's because of the outage. Many machines went on a 1 week hiatus and will not be returning their work, and reporting back until later this week, if people do not have the ability to hand reset the counter by hitting update.
Well as others have said
)
Well as others have said already- don't rely on the benchmarks too much, especially when people use optimized apps or you try to compare boxes with different OSs. After installing Linux on my laptop the average WU completion time went down around 5% (which is no wonder really, Linux is just a bit gentler on a poor little Celeron's resources) while my benchmarks got absolutely pathetic (I'm benchmarking at around 50-60% of what I used to have running Win XP). So, in general, WU completion times are a better way of getting a rough guesstimate as long as one differs between short and long WUs. The WUs are a bit different in size but similar enough to give at least an overview.
Of course, the recent outage also tends to mix the statistics up a bit. I also noticed that I seem to have more pending credit than usually.
RE: If you are noticing
)
Well, I see some machines that went on hiatus are starting to return work, although others are still sleeping. The week has past and they should have started by now.
Can't E@H send out requests to get the ones on hiatus active again?
Theoretically they could, but
)
Theoretically they could, but as a practical matter they can't for 2 main reasons:
1.) The default for all three types of installation does not allow remote control of BOINC. The project can relay preferences changes, but only after the host has initiated contact.
2.) If your running a 5.x client and remote RPC is enabled, they would have no way of knowing what the BOINC access password is.
HTH,
Alinator
Ok, understood. Thanks.
)
Ok, understood. Thanks.