I don't really care about pending credits (or credits anywa), however, the very existence and length of this thread indicates that many people DO care and do not feel comfortable with a large backlog of pending credits (for whatever reasons).
CU
Bikeman
I don't really care that much about a huge backlog of pending credits, but at the same time, wouldn't it make more sense for the project to minimize the number of pending credits? If the same WU is sent to two different machines now, they'll both report back relatively quickly and that WU can be considered finished. If they're sent out months apart from each other, then it's not until the second computer has finished that we know if there's a problem with the results (and therefore can send out the WU to a third host).
BUT if the Project has a lot of older pc's crunching for it, your idea could eliminate some of them. That is also a balancing act for the Project.
The project had a 14-day deadline in the past. I advocated for an increase to 21 days, but the project felt that 18 was best suited for their needs given the increased processing time with S5R3 and with the level of complaints. The mistake I think you're making is believing that I'm advocating a super-short deadline. You mention 1 day. Others either earlier in this thread or in another mentioned 7 days. I'm mentioning returning it to the original amount of 14 days because the performance of the application has increased, and by more than the amount of the increase in days (as a percentage).
I don't really care about pending credits (or credits anywa), however, the very existence and length of this thread indicates that many people DO care and do not feel comfortable with a large backlog of pending credits (for whatever reasons).
CU
Bikeman
I don't really care that much about a huge backlog of pending credits, but at the same time, wouldn't it make more sense for the project to minimize the number of pending credits? If the same WU is sent to two different machines now, they'll both report back relatively quickly and that WU can be considered finished. If they're sent out months apart from each other, then it's not until the second computer has finished that we know if there's a problem with the results (and therefore can send out the WU to a third host).
A while back over at Seti they instituted a system where any unit that was being resent was sent to a machine that statistically was returning units in 1 day or less. It worked pretty well.
A while back over at Seti they instituted a system where any unit that was being resent was sent to a machine that statistically was returning units in 1 day or less. It worked pretty well.
When was that? I haven't seen any sign of it in the two years I've been running Seti BOINC.
A while back over at Seti they instituted a system where any unit that was being resent was sent to a machine that statistically was returning units in 1 day or less. It worked pretty well.
When was that? I haven't seen any sign of it in the two years I've been running Seti BOINC.
I haven't crunched for Seti in almost 3 years so can't say exactly, but it was working before I left. It was in its infancy and there were bugs to be worked out, but it was working. Rom and Dr. A were even talking of putting it into Boinc itself, not just Seti.
A while back over at Seti they instituted a system where any unit that was being resent was sent to a machine that statistically was returning units in 1 day or less. It worked pretty well.
When was that? I haven't seen any sign of it in the two years I've been running Seti BOINC.
I haven't crunched for Seti in almost 3 years so can't say exactly, but it was working before I left. It was in its infancy and there were bugs to be worked out, but it was working. Rom and Dr. A were even talking of putting it into Boinc itself, not just Seti.
Hmmm...
Are you sure you aren't thinking about ghost resends? This is enabled here on EAH currently, and they tried it on SAH, but had to disable it due to it bringing the BOINC database and other backend processes to their knees as the amount outstanding work in the field increased.
What I do recall was some discussion of having deadline time out resends getting put into the feeder queue at the top rather that the bottom. IIRC it's a FIFO by default, so currently a resend would get plugged in at the bottom of the list and have to work its way to the top before getting sent.
A while back over at Seti they instituted a system where any unit that was being resent was sent to a machine that statistically was returning units in 1 day or less. It worked pretty well.
When was that? I haven't seen any sign of it in the two years I've been running Seti BOINC.
I haven't crunched for Seti in almost 3 years so can't say exactly, but it was working before I left. It was in its infancy and there were bugs to be worked out, but it was working. Rom and Dr. A were even talking of putting it into Boinc itself, not just Seti.
Hmmm...
Are you sure you aren't thinking about ghost resends? This is enabled here on EAH currently, and they tried it on SAH, but had to disable it due to it bringing the BOINC database and other backend processes to their knees as the amount outstanding work in the field increased.
What I do recall was some discussion of having deadline time out resends getting put into the feeder queue at the top rather that the bottom. IIRC it's a FIFO by default, so currently a resend would get plugged in at the bottom of the list and have to work its way to the top before getting sent.
Alinator
I don't know what that means, sorry...What I am talking about is since Seti used to use a minimum quorum of 3 returns before credit could be granted, Rom and Dr. A were setting up Seti to re-issue a unit to a faster pc if any one of the first three didn't finish on time or had an error crunching. This made the granting of credits faster and fewer people were waiting FOREVER for their credits. They did this by re-sending the unit to a pc that was returning units within 24 hours normally. I, and many others, got many of these over my time there, the deadline was short, usually 24 to 48 hours, and since I had some fast pc's it was doable.
Einstein could do the same thing, re-issue units with a shorter deadline to machines that are retuning units within 24 to 48 hours, and clear its own cache of pending credits quicker, if they so chose. This would be a change to the current way of doing things, but since they are picking machines that are probably Einstein only, it wouldn't make much difference, except to those waiting for their credits to be granted. People crunching several projects could get into long term debt issues if they sent these units to just anyone though.
...
Einstein could do the same thing, re-issue units with a shorter deadline to machines that are retuning units within 24 to 48 hours, and clear its own cache of pending credits quicker, if they so chose...
While now the scheduler has to wait for a machine (for days sometimes) that has the "right" dataset, then it would have to wait for a machine with the right dataset and the desired turnaround time. I don't think that would be really faster.
Gruß,
Gundolf
Computer sind nicht alles im Leben. (Kleiner Scherz)
...
Einstein could do the same thing, re-issue units with a shorter deadline to machines that are retuning units within 24 to 48 hours, and clear its own cache of pending credits quicker, if they so chose...
While now the scheduler has to wait for a machine (for days sometimes) that has the "right" dataset, then it would have to wait for a machine with the right dataset and the desired turnaround time. I don't think that would be really faster.
RE: I don't really care
)
I don't really care that much about a huge backlog of pending credits, but at the same time, wouldn't it make more sense for the project to minimize the number of pending credits? If the same WU is sent to two different machines now, they'll both report back relatively quickly and that WU can be considered finished. If they're sent out months apart from each other, then it's not until the second computer has finished that we know if there's a problem with the results (and therefore can send out the WU to a third host).
RE: BUT if the Project has
)
The project had a 14-day deadline in the past. I advocated for an increase to 21 days, but the project felt that 18 was best suited for their needs given the increased processing time with S5R3 and with the level of complaints. The mistake I think you're making is believing that I'm advocating a super-short deadline. You mention 1 day. Others either earlier in this thread or in another mentioned 7 days. I'm mentioning returning it to the original amount of 14 days because the performance of the application has increased, and by more than the amount of the increase in days (as a percentage).
Anyway, just a thought...
RE: RE: I don't really
)
A while back over at Seti they instituted a system where any unit that was being resent was sent to a machine that statistically was returning units in 1 day or less. It worked pretty well.
RE: A while back over at
)
When was that? I haven't seen any sign of it in the two years I've been running Seti BOINC.
RE: RE: A while back over
)
I haven't crunched for Seti in almost 3 years so can't say exactly, but it was working before I left. It was in its infancy and there were bugs to be worked out, but it was working. Rom and Dr. A were even talking of putting it into Boinc itself, not just Seti.
RE: RE: RE: A while
)
Hmmm...
Are you sure you aren't thinking about ghost resends? This is enabled here on EAH currently, and they tried it on SAH, but had to disable it due to it bringing the BOINC database and other backend processes to their knees as the amount outstanding work in the field increased.
What I do recall was some discussion of having deadline time out resends getting put into the feeder queue at the top rather that the bottom. IIRC it's a FIFO by default, so currently a resend would get plugged in at the bottom of the list and have to work its way to the top before getting sent.
Alinator
RE: RE: RE: RE: A
)
I don't know what that means, sorry...What I am talking about is since Seti used to use a minimum quorum of 3 returns before credit could be granted, Rom and Dr. A were setting up Seti to re-issue a unit to a faster pc if any one of the first three didn't finish on time or had an error crunching. This made the granting of credits faster and fewer people were waiting FOREVER for their credits. They did this by re-sending the unit to a pc that was returning units within 24 hours normally. I, and many others, got many of these over my time there, the deadline was short, usually 24 to 48 hours, and since I had some fast pc's it was doable.
Einstein could do the same thing, re-issue units with a shorter deadline to machines that are retuning units within 24 to 48 hours, and clear its own cache of pending credits quicker, if they so chose. This would be a change to the current way of doing things, but since they are picking machines that are probably Einstein only, it wouldn't make much difference, except to those waiting for their credits to be granted. People crunching several projects could get into long term debt issues if they sent these units to just anyone though.
RE: ... Einstein could do
)
While now the scheduler has to wait for a machine (for days sometimes) that has the "right" dataset, then it would have to wait for a machine with the right dataset and the desired turnaround time. I don't think that would be really faster.
Gruß,
Gundolf
Computer sind nicht alles im Leben. (Kleiner Scherz)
RE: RE: ... Einstein
)
Under that scenario, no it would not be faster!