I thought a bit more about this suppression of pending jobs (workunits). There are two possible problems when you know if there is a wingman or not.
The first is if you know there will be no wingman you can manipulate the result on your computer and potentially harm the project by sending in falsified scientific results.
If you have a trustworthy machine, any task ending in _0 almost certainly has no wingman. The server trusts you, so it won't generate _1. A task with _1 means that someone else needed a trusted wingman for verification, and you're it. So you probably already know this information. In any case, as I recall, anything remotely exciting is reanalyzed independently by the Einstein people and should also show up weaker in adjacent workunits. So this could potentially add a bit of extra computational load for project headquarters, but it shouldn't actually contaminate the science. And any computational cost is balanced off by a near-doubling of the project's overall speed if most hosts are trustworthy.
Quote:
The other one is when you have tasks that have a wingman and tasks that don't you might be inclined to abort or starve the ones with a wingmen because you are in a race with another team and want Credit as quick as possible.
Probably already happens when people see slow wingmen. It adds some server load, but probably doesn't waste hosts' computational time, because there's little sense in aborting something that's already started. It's long been possible to check whether a wingman is slow, and it looks like now you can still tell whether there's a wingman. This behaviour would be annoying, but hopefully rare, and hiding the details won't stop it anyway. If repeated aborts can make a host less trustworthy, then there would even be a strong disincentive. But I don't know if that's possible.
Quote:
For now we are going to leave it as it is. I'll bring this to the attention of the FGRPB1 scientists and they can discuss if this might have an impact on their scientific results.
I though about all that a few days, something kept bugging me but I was in a pain to remember exactly what.
There is no real interest (from me anyway) to see who has done the crunching of any WU already validated. Not even a desire to know who I am waiting for, so the validation pending ones. However, the initial post started from observing the work in progress and then it makes sense (maybe also to me only): I usually look in the morning and sometimes notice that I got a new task as wingman, because (a) prior one(s) failed to meet the deadline. The tasks suffixed _2 or higher. Although I have only a really small cache of half a day maximum, quite often, when I look, the reason why I got one does not exist anymore at that point: the prior crunching partner managed to get his job reported only slightly after the 14 days, before my computer even started crunching again... At that point, I abort it, it serves no purpose anymore and is a waste of time and money, I then prefer to favour a fresh WU.
So here is the bottleneck: when not seeing anymore, there´s no opportunity to abort redundant ones either. I hate such a thing, but I realise that is personal and probably peanuts overall. Only a few are reading here, the overwhelming majority of crunchers is possibly not even looking at progress all that often.
I discussed this with the scientists and we decided to leave it as is because of the potential scientific impact.
We do not necessarily fear the injection of falsified detections but rather the absence of them. This indeed contaminates science.
Quote:
If you have a trustworthy machine, any task ending in _0 almost certainly has no wingman. The server trusts you, so it won't generate _1.
This may be true after some time when you see that the majority of your tasks has no wingman but we also make sure to check those trusted hosts from time to time and force a wingman on a trusted host to see if we can still trust it. So seeing a _0 at the end of the task name is not an indicator that there is no _1 task.
Quote:
Although I have only a really small cache of half a day maximum, quite often, when I look, the reason why I got one does not exist anymore at that point: the prior crunching partner managed to get his job reported only slightly after the 14 days, before my computer even started crunching again... At that point, I abort it, it serves no purpose anymore and is a waste of time and money, I then prefer to favour a fresh WU.
With adaptive replication the amount of redundant tasks should drop a little bit as a trustworthy host usually has a good turnaround time. I understand your intention but as you yourself stated this is not done by many volunteers. There once was an effort for a better prediction of turnaround time before sending tasks but it made no difference in the end. So we appreciate your efforts but won't change the workunit info page.
On another note we had the best day for FGRPB1 on Sunday with roughly 50k workunits finished while the previous maximum was only 30k on March 9th. So for us adaptive replication looks great from a throughput perspective.
Just thought I´d mention full data for these applications being visible once again, meaning showing all work units here also, like it was before, wingman (if available) done or not. I really prefer it this way, hope I won´t be punished for sending the signal.
Overall, I like what I see, although it takes me some time to find my way around. Congrats on that!
RE: I thought a bit more
)
If you have a trustworthy machine, any task ending in _0 almost certainly has no wingman. The server trusts you, so it won't generate _1. A task with _1 means that someone else needed a trusted wingman for verification, and you're it. So you probably already know this information. In any case, as I recall, anything remotely exciting is reanalyzed independently by the Einstein people and should also show up weaker in adjacent workunits. So this could potentially add a bit of extra computational load for project headquarters, but it shouldn't actually contaminate the science. And any computational cost is balanced off by a near-doubling of the project's overall speed if most hosts are trustworthy.
Probably already happens when people see slow wingmen. It adds some server load, but probably doesn't waste hosts' computational time, because there's little sense in aborting something that's already started. It's long been possible to check whether a wingman is slow, and it looks like now you can still tell whether there's a wingman. This behaviour would be annoying, but hopefully rare, and hiding the details won't stop it anyway. If repeated aborts can make a host less trustworthy, then there would even be a strong disincentive. But I don't know if that's possible.
I though about all that a few
)
I though about all that a few days, something kept bugging me but I was in a pain to remember exactly what.
There is no real interest (from me anyway) to see who has done the crunching of any WU already validated. Not even a desire to know who I am waiting for, so the validation pending ones. However, the initial post started from observing the work in progress and then it makes sense (maybe also to me only): I usually look in the morning and sometimes notice that I got a new task as wingman, because (a) prior one(s) failed to meet the deadline. The tasks suffixed _2 or higher. Although I have only a really small cache of half a day maximum, quite often, when I look, the reason why I got one does not exist anymore at that point: the prior crunching partner managed to get his job reported only slightly after the 14 days, before my computer even started crunching again... At that point, I abort it, it serves no purpose anymore and is a waste of time and money, I then prefer to favour a fresh WU.
So here is the bottleneck: when not seeing anymore, there´s no opportunity to abort redundant ones either. I hate such a thing, but I realise that is personal and probably peanuts overall. Only a few are reading here, the overwhelming majority of crunchers is possibly not even looking at progress all that often.
I discussed this with the
)
I discussed this with the scientists and we decided to leave it as is because of the potential scientific impact.
We do not necessarily fear the injection of falsified detections but rather the absence of them. This indeed contaminates science.
This may be true after some time when you see that the majority of your tasks has no wingman but we also make sure to check those trusted hosts from time to time and force a wingman on a trusted host to see if we can still trust it. So seeing a _0 at the end of the task name is not an indicator that there is no _1 task.
With adaptive replication the amount of redundant tasks should drop a little bit as a trustworthy host usually has a good turnaround time. I understand your intention but as you yourself stated this is not done by many volunteers. There once was an effort for a better prediction of turnaround time before sending tasks but it made no difference in the end. So we appreciate your efforts but won't change the workunit info page.
On another note we had the best day for FGRPB1 on Sunday with roughly 50k workunits finished while the previous maximum was only 30k on March 9th. So for us adaptive replication looks great from a throughput perspective.
Just thought I´d mention full
)
Just thought I´d mention full data for these applications being visible once again, meaning showing all work units here also, like it was before, wingman (if available) done or not. I really prefer it this way, hope I won´t be punished for sending the signal.
Overall, I like what I see, although it takes me some time to find my way around. Congrats on that!