I did suggest a change to the way BOINC handles backoffs. It seems Dr A has put it into the too hard basket. If the projects start asking for it then he may look at doing it.
Quote:
Date: Sat, 01 Oct 2011 10:37:23 -0700
From: David Anderson
Subject: Re: [boinc_dev] Suggested change to project backoffs
To:
It would be possible to do per-server backoff, but it's probably not worth the added complexity.
-- David
Quote:
Now that Einstein is getting download issues I would suggest a change to the way backoff's work.
Einstein issues different types of work from different download servers, so you get GPU work from one and CPU work from a couple of others. Seti (correct me if I am wrong) collects all type of work from all the download servers so you could get CPU or GPU work from any one of them.
I notice that in Einsteins case as the project goes into back off for GPU work it prevents me from getting CPU work, even though its from a different server. So I'd suggest that rather than backing off on a per-project basis we backoff on a per-project server URL basis (or just server URL basis). This will allow Seti work to flow even if one download server is under stress. It would also work for Einstein in that we could get CPU work when their GPU download server is stressed.. It might also mean that rather than one server getting stressed and then the others get clogged up with downloads that have gone to backoff when they didn't need to.
It's getting to the point now where I'm running out of CPU work on a couple of machines because I can't get work downloaded. Some of that work has a due date that I may not be able to meet if it isn't downloaded soon :(
There seems to be a new problem with downloading BRP4-files.
This morning I got within 3h 63 BRP4-files, but all of them became errored. Now the server says, your daily quota is reached. The modem does´nt show any mal function. CRC-Error are low, 11 within that hour, SNR and datarate ok. I never had such within the more than 6 years I´m up here. Some of the LAT files show sometimes similar problems, but not at this percentage. The last LAT-file, a few minutes ago, was ok.
Kind regards
Martin
looks like the logjam has broken. what, did SETI come back online?
Seti is still having all kinds of issues. Work only trickles out. It has had little affect on the computers that don't produce a great deal of work, but has crippled the top hosts.
It seems Dr A has had a rethink after a few more emails on the mailing list and is going to look into this.
Quote:
I did suggest a change to the way BOINC handles backoffs. It seems Dr A has put it into the too hard basket. If the projects start asking for it then he may look at doing it.
Quote:
Date: Sat, 01 Oct 2011 10:37:23 -0700
From: David Anderson
Subject: Re: [boinc_dev] Suggested change to project backoffs
To:
It would be possible to do per-server backoff, but it's probably not worth the added complexity.
-- David
Quote:
Now that Einstein is getting download issues I would suggest a change to the way backoff's work.
Einstein issues different types of work from different download servers, so you get GPU work from one and CPU work from a couple of others. Seti (correct me if I am wrong) collects all type of work from all the download servers so you could get CPU or GPU work from any one of them.
I notice that in Einsteins case as the project goes into back off for GPU work it prevents me from getting CPU work, even though its from a different server. So I'd suggest that rather than backing off on a per-project basis we backoff on a per-project server URL basis (or just server URL basis). This will allow Seti work to flow even if one download server is under stress. It would also work for Einstein in that we could get CPU work when their GPU download server is stressed.. It might also mean that rather than one server getting stressed and then the others get clogged up with downloads that have gone to backoff when they didn't need to.
Haven't noticed DownLoad trouble or no D'Load, at all.
Largest DownLoad Qeue, was SETIs. Always on the fastest rigs,
cause they need the most.
Thanks David Anderson , for the update and future plans.
Is there any other BOINC project that uses more than a single server for download? I would imagine that Einstein@home is really a special case in that respect.
I do very well understand that implementing a rather complex mechanism in the client to work around a problem of a single project that this project needs to fix anyway is considered not worth the effort.
Is there any other BOINC project that uses more than a single server for download? I would imagine that Einstein@home is really a special case in that respect.
I do very well understand that implementing a rather complex mechanism in the client to work around a problem of a single project that this project needs to fix anyway is considered not worth the effort.
BM
CPDN (Climate Prediction) uses multiple download servers, but they've taken a different approach. The client is only given one url, but for redirection or redundancy it can be of the form
- I would guess the decision as to exactly which machine handles the load is made by the php script running on the server.
SETI@home use a single download url, but round-robin DNS to distribute the load across two servers. When they need to distribute vast numbers of identical files, for example during an application roll-out, they used some form of transparent redirection to a proxy cache server, but some ISPs choked on that and prevented some clients getting the files.
I guess having multiple servers only really helps for files which can easily (and efficiently) be made available in more than one place at once - applications, and the locality data files that only Einstein uses. But the problem of the client stalling on files required for one application class, preventing the download of files for a different application within the same project, could be more general than just Einstein.
I did suggest a change to the
)
I did suggest a change to the way BOINC handles backoffs. It seems Dr A has put it into the too hard basket. If the projects start asking for it then he may look at doing it.
BOINC blog
It's getting to the point now
)
It's getting to the point now where I'm running out of CPU work on a couple of machines because I can't get work downloaded. Some of that work has a due date that I may not be able to meet if it isn't downloaded soon :(
looks like the logjam has
)
looks like the logjam has broken. what, did SETI come back online?
There seems to be a new
)
There seems to be a new problem with downloading BRP4-files.
This morning I got within 3h 63 BRP4-files, but all of them became errored. Now the server says, your daily quota is reached. The modem does´nt show any mal function. CRC-Error are low, 11 within that hour, SNR and datarate ok. I never had such within the more than 6 years I´m up here. Some of the LAT files show sometimes similar problems, but not at this percentage. The last LAT-file, a few minutes ago, was ok.
Kind regards
Martin
RE: looks like the logjam
)
Seti is still having all kinds of issues. Work only trickles out. It has had little affect on the computers that don't produce a great deal of work, but has crippled the top hosts.
Steve
Crunching as member of The GPU Users Group team.
It seems Dr A has had a
)
It seems Dr A has had a rethink after a few more emails on the mailing list and is going to look into this.
BOINC blog
Haven't noticed DownLoad
)
Haven't noticed DownLoad trouble or no D'Load, at all.
Largest DownLoad Qeue, was SETIs. Always on the fastest rigs,
cause they need the most.
Thanks David Anderson , for the update and future plans.
Is there any other BOINC
)
Is there any other BOINC project that uses more than a single server for download? I would imagine that Einstein@home is really a special case in that respect.
I do very well understand that implementing a rather complex mechanism in the client to work around a problem of a single project that this project needs to fix anyway is considered not worth the effort.
BM
BM
RE: Is there any other
)
CPDN (Climate Prediction) uses multiple download servers, but they've taken a different approach. The client is only given one url, but for redirection or redundancy it can be of the form
http://climateapps2.oucs.ox.ac.uk/cpdnboinc/download/mirror.php?file=/hadam3p_6.14_windows_intelx86.exe
- I would guess the decision as to exactly which machine handles the load is made by the php script running on the server.
SETI@home use a single download url, but round-robin DNS to distribute the load across two servers. When they need to distribute vast numbers of identical files, for example during an application roll-out, they used some form of transparent redirection to a proxy cache server, but some ISPs choked on that and prevented some clients getting the files.
I guess having multiple servers only really helps for files which can easily (and efficiently) be made available in more than one place at once - applications, and the locality data files that only Einstein uses. But the problem of the client stalling on files required for one application class, preventing the download of files for a different application within the same project, could be more general than just Einstein.