Really?? All the v0.03 I ran completed without errors.
I completed all 30 of the 0.03 without error on an i7-4770 running Ubuntu 16.04. Also I completed 4 of the 0.03 and another 4 of the 0.02 on an i7-4771 running Windows 7 64-bit. They look OK to me too.
The 0.03 app versions were a little bit faster (10-15%), but out in the field these had horrible failure rates (70-99%), so I had to retract these.
Really?? All the v0.03 I ran completed without errors. Any ideas as to what was causing the errors?
I am still investigating. I enabled the less problematic Windows and Linux app versions again; for OSX now there is a "Betat test" version 0.04. It seems like on Linux only the version linked with (g)libc 2.15 was causing trouble.
The 0.03 app versions were a little bit faster (10-15%), but out in the field these had horrible failure rates (70-99%), so I had to retract these.
Really?? All the v0.03 I ran completed without errors. Any ideas as to what was causing the errors?
I am still investigating. I enabled the less problematic Windows and Linux app versions again; for OSX now there is a "Betat test" version 0.04. It seems like on Linux only the version linked with (g)libc 2.15 was causing trouble.
No errors on any version so far.
archae86 wrote:
Minimum quorum:1
Initial replication:1
Max # of error/total/success tasks:20, 20, 20
So no quorum partners (aka wingmen) seems to be the intent.
Tasks are 'Completed, waiting for validation' and are now quorom = 2. At least for my v0.03 and v0.02
Maybe they checked a task and it doesn't show any computer assigned to the task. Not even your own or that it's sent out to someone else. The ones I have verified show both computers listed. For Gamma-ray pulsar binary search #1 on GPUs it shows your own task and the wingman you're waiting for.
Gamma-ray pulsar binary search #1 on GPUs - I completed it and waiting on wingman.
So no quorum partners (aka wingmen) seems to be the intent.
That does not seem to be a good idea to me. A false positive would be verified by the project so no harm but a positive missed in error will never be known. A wingman would reduce that possibility.
That does not seem to be a good idea to me. A false positive would be verified by the project so no harm but a positive missed in error will never be known. A wingman would reduce that possibility.
They haven't found any thus far. It might be a better use of their resources to search as much as possible in the hope of finding something. If they ensure that they don't miss anything, it comes at a price: they can search only half as fast.
I suppose it depends on how much data they have now, and how much they anticipate coming in. The newer data will be from the more sensitive searches too, which will enhance the possibility of finding something. Therefore, they may want to get through the present data as fast as possible. That would be my thinking at any rate.
Indeed for the current (test/tuning) run we use BOINC's "adaptive replication" (as we have been for FGRP5 for a long time). This results in a "replication ratio" of 115-130% (instead of the previous 200), which gains us ~80% of computing power compared to previous runs. Over time our validators have become pretty good at finding errors even in single results. Additionally our workunits unavoidably overlap in parameter space, such that a "signal" would likely show up in multiple workunits, and the loss (i.e. false negative) of one wouldn't hurt that much.
Richie_9 wrote:mmonnin
)
The 0.03 app versions were a little bit faster (10-15%), but out in the field these had horrible failure rates (70-99%), so I had to retract these.
BM
Bernd Machenschalk
)
Really?? All the v0.03 I ran completed without errors. Any ideas as to what was causing the errors?
Zalster wrote:Really?? All
)
I completed all 30 of the 0.03 without error on an i7-4770 running Ubuntu 16.04. Also I completed 4 of the 0.03 and another 4 of the 0.02 on an i7-4771 running Windows 7 64-bit. They look OK to me too.
Am I missing something? I
)
Am I missing something? I can't find a wingman for these tasks.
Minimum quorum:1 Initial
)
Zalster wrote:Bernd
)
I am still investigating. I enabled the less problematic Windows and Linux app versions again; for OSX now there is a "Betat test" version 0.04. It seems like on Linux only the version linked with (g)libc 2.15 was causing trouble.
BM
Bernd Machenschalk
)
No errors on any version so far.
Tasks are 'Completed, waiting for validation' and are now quorom = 2. At least for my v0.03 and v0.02
Maybe they checked a task and it doesn't show any computer assigned to the task. Not even your own or that it's sent out to someone else. The ones I have verified show both computers listed. For Gamma-ray pulsar binary search #1 on GPUs it shows your own task and the wingman you're waiting for.
Gamma-ray pulsar binary search #1 on GPUs - I completed it and waiting on wingman.
https://einsteinathome.org/workunit/338760117
Continuous Gravitational Wave search O2 All-Sky Tuning - Atm it shows no computer, not even my own although I've already completed it.
https://einsteinathome.org/workunit/339008009
archae86 wrote:Minimum
)
That does not seem to be a good idea to me. A false positive would be verified by the project so no harm but a positive missed in error will never be known. A wingman would reduce that possibility.
Betreger wrote:That does not
)
They haven't found any thus far. It might be a better use of their resources to search as much as possible in the hope of finding something. If they ensure that they don't miss anything, it comes at a price: they can search only half as fast.
I suppose it depends on how much data they have now, and how much they anticipate coming in. The newer data will be from the more sensitive searches too, which will enhance the possibility of finding something. Therefore, they may want to get through the present data as fast as possible. That would be my thinking at any rate.
Indeed for the current
)
Indeed for the current (test/tuning) run we use BOINC's "adaptive replication" (as we have been for FGRP5 for a long time). This results in a "replication ratio" of 115-130% (instead of the previous 200), which gains us ~80% of computing power compared to previous runs. Over time our validators have become pretty good at finding errors even in single results. Additionally our workunits unavoidably overlap in parameter space, such that a "signal" would likely show up in multiple workunits, and the loss (i.e. false negative) of one wouldn't hurt that much.
BM