11.07.2024 08:12:13 | Einstein@Home | General prefs: from Einstein@Home (last modified ---)
Get this info in Boinc 8.0.2.
Prefs are reported permanently after this info is reported.
This is probably the case for every client. After the scheduler request, the prefs are returned, since no timestamp was kept for when they were last changed. So every scheduler request returns the prefs again. This exact line is then reported. Completely normal, I would say. Looking back to the beginning of my logfile, it has been like this since at least the end of June.
11.07.2024 08:12:13 | Einstein@Home | General prefs: from Einstein@Home (last modified ---)
Get this info in Boinc 8.0.2.
Prefs are reported permanently after this info is reported.
This is probably the case for every client. After the scheduler request, the prefs are returned, since no timestamp was kept for when they were last changed. So every scheduler request returns the prefs again. This exact line is then reported. Completely normal, I would say. Looking back to the beginning of my logfile, it has been like this since at least the end of June.
I actually saw this "spamming" on one of my systems at WCG when it migrated from client 7.20.5 to 7.24.1; however, I got a bit confused because another migrated client didn't show the same behaviour. Naturally, that sent me into the client code to see what might have changed...
Below is a quote from my notes -- I'd also link to my posts about it over at WCG, but their web site appears to be down at the moment so I can't get the URL :-)...
... if the client is in a non-default venue and a global preferences section appears in a scheduler reply it looks for its venue and if it finds it it stops scanning the preferences once it reaches the end of the venue data (which is a perfectly reasonable performance tweak!) This assumes that all the venue-independent items in the global preferences block appear before the venue blocks, which seems to be how a standard BOINC server (e.g.TN-Grid) does it. The bad news is that WCG puts out the modified date AFTER the end of the venue stuff, so the client never sees it -- OOPS!
I wrote it up and posted it in the WCG forums. And I've got systems that need a non-default venue getting their "global preferences" from TN-Grid so that the spamming doesn't happen if running a 7.24.x client.
The code in earlier clients had the same "issue" (and reported the non-existent time!) but didn't write the spam :-) -- that was the key code change...
Getting [changed] global preferences from an older server version results in a global preferences section whose first entry is for mod_time and which ends straight after the last closing venue tag. Getting global preferences from WCG put several values between the list of venues and the end of global preferences, (including mod_time and run_gpu_if_user_active...)
I'm guessing that might also be the issue here. I'm not sure whether that discrepancy constitutes a server bug or a client bug :-)
Yep, that's indeed correct. Once again people get hit by BOINC's homegrown XML "parser". It expects the preferences to be in the following order:
generic global preferences
0-3 venues
As soon as there's any venue in the preferences, there must not be anything following it since the processing will stop at the end of the (current) venue, no matter what.
Again, this is off-topic here but we're going to look into this separately to ensure our user records comply with this, one way or another.
Yep, that's indeed correct. Once again people get hit by BOINC's homegrown XML "parser". It expects the preferences to be in the following order:
generic global preferences
0-3 venues
As soon as there's any venue in the preferences, there must not be anything following it since the processing will stop at the end of the (current) venue, no matter what.
Again, this is off-topic here but we're going to look into this separately to ensure our user records comply with this, one way or another.
Cheers
And I thought it was just me. LOL Good to know, I'm sure I won't be the only one watching.
Thanks for the report. Should
)
Thanks for the report. Should be fixed now.
BM
11.07.2024 08:12:13 |
)
11.07.2024 08:12:13 | Einstein@Home | General prefs: from Einstein@Home (last modified ---)
Get this info in Boinc 8.0.2.
Prefs are reported permanently after this info is reported.
Hi Meaex, I don't follow.
)
Hi Meaex,
I don't follow. Can you please elaborate?
Thanks
Einstein@Home Project
maeax schrieb:11.07.2024
)
This is probably the case for every client. After the scheduler request, the prefs are returned, since no timestamp was kept for when they were last changed. So every scheduler request returns the prefs again. This exact line is then reported. Completely normal, I would say. Looking back to the beginning of my logfile, it has been like this since at least the end of June.
Thanks. Yes, that should be
)
Thanks. Yes, that should be independent of the DB migration but we should look into this (again).
Cheers
Einstein@Home Project
Bernd Machenschalk
)
still no stats export as of this morning.
_________________________________________________________________________
Ian&Steve C. wrote:Bernd
)
Oh, there was an old instance of the stats dump program hanging. Fixed. Thanks for keeping an eye!
BM
Scrooge McDuck wrote:maeax
)
I actually saw this "spamming" on one of my systems at WCG when it migrated from client 7.20.5 to 7.24.1; however, I got a bit confused because another migrated client didn't show the same behaviour. Naturally, that sent me into the client code to see what might have changed...
Below is a quote from my notes -- I'd also link to my posts about it over at WCG, but their web site appears to be down at the moment so I can't get the URL :-)...
The code in earlier clients had the same "issue" (and reported the non-existent time!) but didn't write the spam :-) -- that was the key code change...
Getting [changed] global preferences from an older server version results in a global preferences section whose first entry is for mod_time and which ends straight after the last closing venue tag. Getting global preferences from WCG put several values between the list of venues and the end of global preferences, (including mod_time and run_gpu_if_user_active...)
I'm guessing that might also be the issue here. I'm not sure whether that discrepancy constitutes a server bug or a client bug :-)
Hope this might help.
Cheers - Al
Yep, that's indeed correct.
)
Yep, that's indeed correct. Once again people get hit by BOINC's homegrown XML "parser". It expects the preferences to be in the following order:
As soon as there's any venue in the preferences, there must not be anything following it since the processing will stop at the end of the (current) venue, no matter what.
Again, this is off-topic here but we're going to look into this separately to ensure our user records comply with this, one way or another.
Cheers
Einstein@Home Project
Oliver Behnke wrote: Yep,
)
And I thought it was just me. LOL Good to know, I'm sure I won't be the only one watching.
Proud member of the Old Farts Association