We had some trouble with BRP4 workunit generation earlier today. The problem has been solved. It will take a few hours to build a buffer of unsent tasks, though. Currently all generated tasks are immediately sucked up by hungry clients.
BM
Edit: Sorry, the problem is only partially solved so far. We are still working on it.
Einstein@home seems hugely popular. Why not give people a heads-up the few times there are problems with the equipment . . . . would save some of us a lot of trouble shooting time. Thanks.
The download server has been working ok this weekend. We did have a problem with generating workunits for BRP4 (the other searches being unaffected). This problem has been solved for now, we are generating and sending out BRP4 work again.
The workunit generation for BRP4 is a chain of various software running on a couple of machines. So far it did work well and reliable since end of September. The reboot of one of the machines on Friday morning then lead to a chain of oddities and errors that resulted in no work being generated anymore.
A couple of errors in that chain still need some investigation in order to prevent this from happening again, but we won't do it today. It's advent weekend after all, and most of the people involved (Ben, Carsten, Oliver, me) spend these days with their families.
Would it be an idea to have the FGRP work coming from a different download server? That could then free up some bandwidth, relieve the BRP download server of some load and remove the double point of failure (ie 2 download servers).
The network / server load from FGRP1 is negligible. There is a single large file that should be downloaded only once per host for all workunits, the actual data files are just a few kB, and should also be used for many tasks.
What would make more sense would be to have two download servers for BRP4, each one fed by a single workunit generator. But currently we don't need that.
We are currently investigating different ways to encode (effectively compress) the BRP4 timeseries data, such that we need to ship fewer bytes per task. This should help both server and clients.
We had some trouble with BRP4
)
We had some trouble with BRP4 workunit generation earlier today. The problem has been solved. It will take a few hours to build a buffer of unsent tasks, though. Currently all generated tasks are immediately sucked up by hungry clients.
BM
Edit: Sorry, the problem is only partially solved so far. We are still working on it.
BM
Einstein@home seems hugely
)
Einstein@home seems hugely popular. Why not give people a heads-up the few times there are problems with the equipment . . . . would save some of us a lot of trouble shooting time. Thanks.
Is this project taking the
)
Is this project taking the same cosmic path as seti@home?
Is this the distributed computing example of another black hole ?
What a joke,
Justin Uva Donator
Seems the server thinks he
)
Seems the server thinks he has weekends OFF, i think NOT sir!
To bad no CUDA Work.
The point of this projects is realistic, so it's always better.
Indeed, If only there were
)
Indeed,
If only there were realistic work units to crunch ;-)
The download server has been
)
The download server has been working ok this weekend. We did have a problem with generating workunits for BRP4 (the other searches being unaffected). This problem has been solved for now, we are generating and sending out BRP4 work again.
The workunit generation for BRP4 is a chain of various software running on a couple of machines. So far it did work well and reliable since end of September. The reboot of one of the machines on Friday morning then lead to a chain of oddities and errors that resulted in no work being generated anymore.
A couple of errors in that chain still need some investigation in order to prevent this from happening again, but we won't do it today. It's advent weekend after all, and most of the people involved (Ben, Carsten, Oliver, me) spend these days with their families.
BM
BM
Thanks very much for the
)
Thanks very much for the update.
Well, at least some of us understand that the occasional hardware issue has to be accepted gracefully. Thanks to all of you for your hard work.
Would it be an idea to have
)
Would it be an idea to have the FGRP work coming from a different download server? That could then free up some bandwidth, relieve the BRP download server of some load and remove the double point of failure (ie 2 download servers).
BOINC blog
The network / server load
)
The network / server load from FGRP1 is negligible. There is a single large file that should be downloaded only once per host for all workunits, the actual data files are just a few kB, and should also be used for many tasks.
What would make more sense would be to have two download servers for BRP4, each one fed by a single workunit generator. But currently we don't need that.
We are currently investigating different ways to encode (effectively compress) the BRP4 timeseries data, such that we need to ship fewer bytes per task. This should help both server and clients.
BM
BM