I see that your system has in the mean time uploaded & reported the old work and gotten new work.
So then an explanation, as the whole problem is a combination of things here at Einstein. That the scheduler reply does not fit in the XML buffer in the BOINC client can be caused by:
1. The number of data files required by the current work units.
2. The number of available download mirrors, where these data files can be gotten from.
3. The length of the download URLs.
Bernd has for the moment reduced the amount of download mirrors from 4 to 3 on the S6CasA application. Not just to be able to cater you, but it's very probable that you weren't the only one with this problem. The rest with the problem either didn't notice, or they are still looking (elsewhere) for a solution.
One of the other things that the developers here will look into is the reduction of the length of the download URLs, as when you have to load less characters, there's less possibility that you overload the XML buffer.
May this happen again in the future, there is something you can try to do, and that is to reduce the amount of work you ask for, or (temporarily) switch science applications and set Gravitational Wave S6 Directed Search to No in the project preferences.
Thank you, this makes perfect sense. I recently changed my profile to download 2 days worth of work instead of .25, since this particular host has 16 processors + GPU it had a lot of files to download.
Thank you, I'll wait for
)
Thank you, I'll wait for further updates.
I see that your system has in
)
I see that your system has in the mean time uploaded & reported the old work and gotten new work.
So then an explanation, as the whole problem is a combination of things here at Einstein. That the scheduler reply does not fit in the XML buffer in the BOINC client can be caused by:
1. The number of data files required by the current work units.
2. The number of available download mirrors, where these data files can be gotten from.
3. The length of the download URLs.
Bernd has for the moment reduced the amount of download mirrors from 4 to 3 on the S6CasA application. Not just to be able to cater you, but it's very probable that you weren't the only one with this problem. The rest with the problem either didn't notice, or they are still looking (elsewhere) for a solution.
One of the other things that the developers here will look into is the reduction of the length of the download URLs, as when you have to load less characters, there's less possibility that you overload the XML buffer.
May this happen again in the future, there is something you can try to do, and that is to reduce the amount of work you ask for, or (temporarily) switch science applications and set Gravitational Wave S6 Directed Search to No in the project preferences.
To be precise, we still have
)
To be precise, we still have five download mirrors operational, but every client will just get communicated the three nearest to its own timezone.
BM
BM
Thank you, this makes perfect
)
Thank you, this makes perfect sense. I recently changed my profile to download 2 days worth of work instead of .25, since this particular host has 16 processors + GPU it had a lot of files to download.