Gary, there is a new option in Einstein account preferences for the new run.
On my account this is default set to off. Users may need to turn it on to receive results for the new run.
I looked into my account and the option is set to get the new S6 tasks, but it is also disabled so I can´t opt out. On the one host I got the new task I just reseted the project after I finished the S5 tasks.
I looked into my account and the option is set to get the new S6 tasks, but it is also disabled so I can´t opt out.
In my Einstein@home preferences "Gravitational Wave S6 GC search" is set to "no" and disabled. So, I can't select it there, but I got a task (and data) for einstein_S6Bucket_1.01_windows_intelx86__SSE2.exe nonetheless.
Gruß,
Gundolf
Computer sind nicht alles im Leben. (Kleiner Scherz)
Gary, there is a new option in Einstein account preferences for the new run.
On my account this is default set to off. Users may need to turn it on to receive results for the new run.
I looked into my account and the option is set to get the new S6 tasks, but it is also disabled so I can´t opt out. On the one host I got the new task I just reseted the project after I finished the S5 tasks.
This is strange mine is set to off but your right it is also disabled so I can not change it.
Looks like the admins need to take a look at that.
Gary, there is a new option in Einstein account preferences for the new run.
On my account this is default set to off. Users may need to turn it on to receive results for the new run.
I looked into my account and the option is set to get the new S6 tasks, but it is also disabled so I can´t opt out. On the one host I got the new task I just reseted the project after I finished the S5 tasks.
This is strange mine is set to off but your right it is also disabled so I can not change it.
Looks like the admins need to take a look at that.
I had one venue with a restricted selection: for that venue (only) the new S6 option appeared as disabled/unchecked. For venues with 'all applications' selected, the new option is displaying a checkmark, as you'd expect.
When I changed one of the other options in my selective venue, the checkmark appeared in the S6 box. That's one way of tidying things up.
Host 831490 has now returned some S6 work, showing some 20% reduction in time taken. (but nearly the same credit awarded)
When I changed one of the other options in my selective venue, the checkmark appeared in the S6 box. That's one way of tidying things up.
Thanks, this works for turning S6 on but the checkbox is still disabled.
For anyone who wants to turn it off there is no option available.
So still some admin action needed to enable free use of the checkbox.
I'd expect the S6 checkbox being checked (S6 processing enabled) and changing of it being disabled (greyed out). Everything else would be a surprise to me.
In any case the current "locality" scheduler that is used for GW Applications such as S5GC1HF and S6Bucket has a bug that leads to this setting being ignored anyway for these applications.
S5GC1HF was the first GW run where we enabled the opt-out because of the data volume (download, disk space, RAM usage) involved. We didn't notice that this didn't work at all until we revisited the scheduler code a couple of days ago.
We are re-designing and (partly) re-writing the locality scheduler code anyway, but this will take some time. For the time being, opting out of S6Bucket is only possible by using anonymous platform (app_info.xml).
S6Bucket should have way lower requirements than S5GC1HF had, so I hope this is not too much of a problem.
I'd expect the S6 checkbox being checked (S6 processing enabled) and changing of it being disabled (greyed out). Everything else would be a surprise to me.
BM
Bernd, I had BRP unchecked and S5GC1HF checked. When S6Bucket was added it was unchecked. After the tip from Richard I changed BRP to checked and saved that setting this also changed S6Bucket to checked. Then I changed BRP back to unchecked and after saving S6Bucket stayed checked. So it looks like there is something wrong with the original adding of the S6Bucket option if one of the other options was unchecked.
I was a bit surprised not to see a bigger number of new run tasks sent out. Too many hosts still able to access old run tasks for the frequency they already have on board, I guess.
My boxes (set not to do any BRP tasks) are still walking up the frequency ranges. So far at least the mass creation of primary tasks has lowered my total bandwidth consumption to roughly 3/4ths it's baseline level because I can often grab large numbers of tasks at the same frequency levels, although it's gotten somewhat jumpier since my main box is encountering occasional holes in the frequency range. I didn't think to install monitoring software on my secondary box in advance of the wind down, but it's managed to find a private frequency range and has gobbled a 4 day cache of work without needing to change frequencies at all.
At some point primary task depletion will get high enough this'll probably change; but since my ISP doesn't have a cap I'm just measuring actual results instead of fiddling with anything.
Rather anti-climatic on my end. All of my boxes kept getting primary tasks until full depletion and then switched over to s6. I haven't taken any resends since then. One of my boxes used an extra 1.5days bandwidth during the period, the second about 2-3 days less bandwidth than normal (because with full WU generation it wasn't inching up the frequency ladder as often).
It's possible the resend issue is generating extra traffic at the E@H server level; but it's not visible on the client side. The problem with the client never going back for additional tasks on a previous frequency after the scheduler generates more OTOH is wasting a lot of bandwidth as my minimum traffic days during the run down were about 10% of my normal load.
RE: Gary, there is a new
)
I looked into my account and the option is set to get the new S6 tasks, but it is also disabled so I can´t opt out. On the one host I got the new task I just reseted the project after I finished the S5 tasks.
RE: I looked into my
)
In my Einstein@home preferences "Gravitational Wave S6 GC search" is set to "no" and disabled. So, I can't select it there, but I got a task (and data) for einstein_S6Bucket_1.01_windows_intelx86__SSE2.exe nonetheless.
Gruß,
Gundolf
Computer sind nicht alles im Leben. (Kleiner Scherz)
RE: RE: Gary, there is a
)
This is strange mine is set to off but your right it is also disabled so I can not change it.
Looks like the admins need to take a look at that.
RE: RE: RE: Gary, there
)
I had one venue with a restricted selection: for that venue (only) the new S6 option appeared as disabled/unchecked. For venues with 'all applications' selected, the new option is displaying a checkmark, as you'd expect.
When I changed one of the other options in my selective venue, the checkmark appeared in the S6 box. That's one way of tidying things up.
Host 831490 has now returned some S6 work, showing some 20% reduction in time taken. (but nearly the same credit awarded)
RE: When I changed one of
)
Thanks, this works for turning S6 on but the checkbox is still disabled.
For anyone who wants to turn it off there is no option available.
So still some admin action needed to enable free use of the checkbox.
I'd expect the S6 checkbox
)
I'd expect the S6 checkbox being checked (S6 processing enabled) and changing of it being disabled (greyed out). Everything else would be a surprise to me.
In any case the current "locality" scheduler that is used for GW Applications such as S5GC1HF and S6Bucket has a bug that leads to this setting being ignored anyway for these applications.
S5GC1HF was the first GW run where we enabled the opt-out because of the data volume (download, disk space, RAM usage) involved. We didn't notice that this didn't work at all until we revisited the scheduler code a couple of days ago.
We are re-designing and (partly) re-writing the locality scheduler code anyway, but this will take some time. For the time being, opting out of S6Bucket is only possible by using anonymous platform (app_info.xml).
S6Bucket should have way lower requirements than S5GC1HF had, so I hope this is not too much of a problem.
BM
BM
RE: I'd expect the S6
)
Bernd, I had BRP unchecked and S5GC1HF checked. When S6Bucket was added it was unchecked. After the tip from Richard I changed BRP to checked and saved that setting this also changed S6Bucket to checked. Then I changed BRP back to unchecked and after saving S6Bucket stayed checked. So it looks like there is something wrong with the original adding of the S6Bucket option if one of the other options was unchecked.
RE: I was a bit surprised
)
My boxes (set not to do any BRP tasks) are still walking up the frequency ranges. So far at least the mass creation of primary tasks has lowered my total bandwidth consumption to roughly 3/4ths it's baseline level because I can often grab large numbers of tasks at the same frequency levels, although it's gotten somewhat jumpier since my main box is encountering occasional holes in the frequency range. I didn't think to install monitoring software on my secondary box in advance of the wind down, but it's managed to find a private frequency range and has gobbled a 4 day cache of work without needing to change frequencies at all.
At some point primary task depletion will get high enough this'll probably change; but since my ISP doesn't have a cap I'm just measuring actual results instead of fiddling with anything.
How is the cleanup coming? I
)
How is the cleanup coming? I still have S5 work for 5 days on two host.
Rather anti-climatic on my
)
Rather anti-climatic on my end. All of my boxes kept getting primary tasks until full depletion and then switched over to s6. I haven't taken any resends since then. One of my boxes used an extra 1.5days bandwidth during the period, the second about 2-3 days less bandwidth than normal (because with full WU generation it wasn't inching up the frequency ladder as often).
It's possible the resend issue is generating extra traffic at the E@H server level; but it's not visible on the client side. The problem with the client never going back for additional tasks on a previous frequency after the scheduler generates more OTOH is wasting a lot of bandwidth as my minimum traffic days during the run down were about 10% of my normal load.