I have two S5R2 WUs (one completing today, one on Friday) for which wingmen have not yet been assigned. These are 34750712 and 34756166 and were downloaded on 9/20 and 9/21 respectively.
A reasonable shutdown of the R2 phase should call for all of the R2 work to be assigned (even returned units) before additional R3 work was downloaded. Clearly, this is not happening.
What should I expect in terms of the validation of these two units?
Cheers,
Ron
Copyright © 2024 Einstein@Home. All rights reserved.
Why no wingmen
)
Actually it's smarter to have a transition where for a short time both runs exist in parallel. The reason is that every piece of work requires several megabytes of raw data to crunch on (the l1_* and h1_* files you'll find in the BOINC subfolder for Einstein@Home). It would really discourage people if they had to download that much data with every single new piece of work. Luckily, the tasks to be computed can be sorted into several "bins" that require the same raw-data.
So instead, you download new raw data and the server will give you preferably work that matches this raw-data and can be crunched without an additional download (as long as there is work in this "bin").
If you want to start distributing S5R3 work only after all S5R2 work was distributed, you would have to force many more downloads for the participants as work from some "bins" will be in greater supply than other, and you have to force PCs to load raw-data from new bins.
Don't worry, there are still enough PCs out there that crunch for S5R2 (most of my PCS, for example). You will get a wingman soon.
CU
Bikeman
Bikeman, Your postings are
)
Bikeman,
Your postings are usually very helpful -- but I think that you have skimmed my message a little too quickly. I do NOT feel that I will get a wingman soon since that has not yet occured in five days. Note -- I only have a moderate speed system her (AMD X2 3800) yet I will be returning a completed result within the hour for which a wingman has not yet been assigned.
Yes, it is quite reasonable to run both phases at the same time, but I don't share your view that it is reasonable for my results to hang in pending limbo because a quorum has not even been attempted.
Cheers,
Ron
I think higher pendings are
)
I think higher pendings are rather normal in the transition phase. Mine are going up aswell.
I think higher pendings are
)
I think higher pendings are rather normal in the transition phase. Mine are going up aswell.
No problem with higher pendings -- I currently have pendings equal to 11 days of RAC and will, in a matter of minutes, have a full 14 days.
My concern is that there may be a systemic problem during the transition when a quorum is not even assigned. I learned some months ago to simply wait for wingmen to return their results -- it always happened eventually. However, I have not previously seen a situation where a wingman doesn't even exist after five days. And, I am reasonably certain that no amount of patience will get a second result in for validation when a second computer has not even been assigned.
Who knows, perhaps I will be assigned as my own wingman when my next request for new work goes in. At least I run a stodgy standard computer with very little else running except BOINC and a browser, so my results should be as clean as the data permits -- and I have been processing these data files for the better part of a month.
Cheers,
Ron
PS -- got to 14 days as I was typing.
RE: I think higher pendings
)
Ron,
a single user is NEVER assigned a WU as its own quorum partner.
As Annika mentioned, during transition the number of users which have the same dataset as you is decreasing so you have to wait longer.
At the end of the S4* run, Bernd modified the sheduler parameters to speed up the finishing of the run and the remaining WUs were sent to 10 users.
The WUs will get assigned to a second user, and you will finally get your credits.
Edit: my pending credit is currently 18,389.16
Udo
RE: I think higher pendings
)
Both of those WUs were intially issued to a system that returned 63 compute errors in three days. This means that there are 63 results that have to be
reissued. It doesn't surprise me that it takes a while for somebody to pick up all of them.
a single user is NEVER
)
a single user is NEVER assigned a WU as its own quorum partner.
Sorry -- I was trying to make a joke and obviously failed.
As Annika mentioned, during transition the number of users which have the same dataset as you is decreasing so you have to wait longer.
This does not seem logical to me -- the number of users with a given data set should be fairly constant until the server has a reason to delete and replace it -- in other words, until there are no more results to be computed from it. Clearly, that is not the case here.
At the end of the S4* run, Bernd modified the sheduler parameters to speed up the finishing of the run and the remaining WUs were sent to 10 users.
The WUs will get assigned to a second user, and you will finally get your credits.
Thanks for the assurances -- my perspective is only since June.
Cheers,
Ron
I guess what's concerning you
)
I guess what's concerning you is the fact that you never saw a situation where a result wasn't even (re-)sent at the time the first wingman completed the result.
Believe me, this has happened before. There's a statistic on the the status page that shows the age of the oldest unsent result. Before the transition, it usually showed something around 7 days and now is a bit above. So there have 'always' been results that waited around 7 days for being (re-)sent, enough for most PCs to complete a S5R2 unit.
I hope this will convince you there's nothing to worry about.
CU
Bikeman
Thanks Bikeman, No, I have
)
Thanks Bikeman,
No, I have not seen such slow reissues before.
Cheers,
Ron
I have the opposite problem.
)
I have the opposite problem. I don't know why I am crunching this wu when the two others have completed and been awarded credit. I've had this chap running for 50+ hours now? It is 97% complete.
Wave upon wave of demented avengers march cheerfully out of obscurity into the dream.