I'm wondering, is it possible to let us keep downloading new work units to process, meanwhile holding all the completed results on our own hard disk, and waiting for the upload system to get repaired ??? I suppose most computers that are attached to BOINC are equiped with lots of free disk space, and it would be good if we can keep contributing our computing resource to this project without being blocked out in the down time of the upload system. Since we all know that the reparation is going to take a while, isn't it ?
That might not be a good idea. This would prolong the recovery of the upload server because there would be more files to upload once uploads turn on. Since letting the file system get too full caused the problem, issuing more work might generate the conditions to cause the file system to fill up and become too slow again.
We're thinking about it and might in fact do that, but:
- modern clients will stop requesting more work when too many pending uploads pile up
- the more uploads do pile up out there the higher the burden will be for the upload server when it's online again
When this upload issue is resolved will E@H be staying with the XFS filesystem or is there another option?
In the meantime I am using this downtime to update patches/fixes and shutting down units that are out of work. I will return them when we have a resolution. Sometimes you are just going to "have days like this".
- modern clients will stop requesting more work when too many pending uploads pile up
Depends how you define 'modern' - that's been in the code source for at least six years.
The worst case, as far as the filesystem is concerned, will be the Arecibo GPU tasks which need 16 separate files to be slotted into the storage index: they at least will be inhibited by "too many uploads" (though I think the count is of tasks in the uploading state, not individual upload files). It would be relatively benign to allow new allocations of Perseus Arm tasks, with a much higher ratio of compute time per file generated - and you can work out the rest for yourselves.
- modern clients will stop requesting more work when too many pending uploads pile up
Depends how you define 'modern' - that's been in the code source for at least six years.
The worst case, as far as the filesystem is concerned, will be the Arecibo GPU tasks which need 16 separate files to be slotted into the storage index: they at least will be inhibited by "too many uploads" (though I think the count is of tasks in the uploading state, not individual upload files). It would be relatively benign to allow new allocations of Perseus Arm tasks, with a much higher ratio of compute time per file generated - and you can work out the rest for yourselves.
Yeah, I vote Yes for Perseus Arm tasks!!
merle
What is freedom of expression? Without the freedom to offend, it ceases to exist.
Update: we enabled the uploads again - for testing purposes - but we couldn't yet really improve the performance. We may try a few other things but any major alternative setup like moving the entire dataset will have to wait until Monday, I'm afraid.
RE: (update: fs repair
)
Soooooo..how about a coffee break?
Just kidding!
Thanks for doing this in the weekend...!
I'm wondering, is it possible
)
I'm wondering, is it possible to let us keep downloading new work units to process, meanwhile holding all the completed results on our own hard disk, and waiting for the upload system to get repaired ??? I suppose most computers that are attached to BOINC are equiped with lots of free disk space, and it would be good if we can keep contributing our computing resource to this project without being blocked out in the down time of the upload system. Since we all know that the reparation is going to take a while, isn't it ?
That might not be a good
)
That might not be a good idea. This would prolong the recovery of the upload server because there would be more files to upload once uploads turn on. Since letting the file system get too full caused the problem, issuing more work might generate the conditions to cause the file system to fill up and become too slow again.
We're thinking about it and
)
We're thinking about it and might in fact do that, but:
- modern clients will stop requesting more work when too many pending uploads pile up
- the more uploads do pile up out there the higher the burden will be for the upload server when it's online again
We'll keep you posted,
Oliver
Einstein@Home Project
RE: Remember you have to
)
He's giving her all she's got Captain!
When this upload issue is
)
When this upload issue is resolved will E@H be staying with the XFS filesystem or is there another option?
In the meantime I am using this downtime to update patches/fixes and shutting down units that are out of work. I will return them when we have a resolution. Sometimes you are just going to "have days like this".
RE: We have a number of
)
Einstein@Home Project
RE: - modern clients will
)
Depends how you define 'modern' - that's been in the code source for at least six years.
The worst case, as far as the filesystem is concerned, will be the Arecibo GPU tasks which need 16 separate files to be slotted into the storage index: they at least will be inhibited by "too many uploads" (though I think the count is of tasks in the uploading state, not individual upload files). It would be relatively benign to allow new allocations of Perseus Arm tasks, with a much higher ratio of compute time per file generated - and you can work out the rest for yourselves.
RE: RE: - modern clients
)
Yeah, I vote Yes for Perseus Arm tasks!!
merle
What is freedom of expression? Without the freedom to offend, it ceases to exist.
— Salman Rushdie
Update: we enabled the
)
Update: we enabled the uploads again - for testing purposes - but we couldn't yet really improve the performance. We may try a few other things but any major alternative setup like moving the entire dataset will have to wait until Monday, I'm afraid.
Best,
Oliver
Einstein@Home Project