At the same time that the WU rate started falling there was a large spike in the error rate. It's possible the project was put on hold while staff tries to determine if there was a bad data problem.
OTOH, if you look at the coverage maps for BRP5 and BRP6; the latter has a scattering of beams in areas where the former had holes. It could be that the remaining beams were just shifted over to BRP6, causing BRP5 to end a bit earlier than expected.
BRP5 is actually finished (apart from the one unfinished WU and the one task in progress); what appears as "remaining" beams is actually an accounting problem that occurred in pre-processing.
At the same time that the WU rate started falling there was a large spike in the error rate.
If you are referring to the detailed rate plots: invalid results, client errors etc. are shown as "% of valid". So if the the number of daily canonical/valid results drops by itself (because of running out of work), the rate shown of errors etc. will raise up even if the numbers of returned errors stay the same or drop. It's just a matter of reporting delay that for the duration of the deadline (14d) the number of errors drops slower than the number of "valids".
Finshing BRP5
)
At the same time that the WU rate started falling there was a large spike in the error rate. It's possible the project was put on hold while staff tries to determine if there was a bad data problem.
OTOH, if you look at the coverage maps for BRP5 and BRP6; the latter has a scattering of beams in areas where the former had holes. It could be that the remaining beams were just shifted over to BRP6, causing BRP5 to end a bit earlier than expected.
BRP5 is actually finished
)
BRP5 is actually finished (apart from the one unfinished WU and the one task in progress); what appears as "remaining" beams is actually an accounting problem that occurred in pre-processing.
BM
BM
RE: At the same time that
)
If you are referring to the detailed rate plots: invalid results, client errors etc. are shown as "% of valid". So if the the number of daily canonical/valid results drops by itself (because of running out of work), the rate shown of errors etc. will raise up even if the numbers of returned errors stay the same or drop. It's just a matter of reporting delay that for the duration of the deadline (14d) the number of errors drops slower than the number of "valids".
BM
BM
That's what I was referring
)
That's what I was referring to; why weren't the hosts returning errors running out at the same rate as those doing good work.