If one of the objectives of this schedling code is to insure that the client always has something to do, it fails to do so for me.
I added the Einstein project to a couple of my cpus because of the frequent down times of the SETI project. I would often run out of work during these down periods.
I've been unable to download SETI WU since Thusday or so. By Sat I had finished all the SETI and Einstein WUs.
Under this condition the scheduler code still would not download a Einstein WU. I assume it's because of the reasons given here. If I understand the explanation correctly, it's won't download anything until SETI resumes downloading and I can process SETI WUs again.
If one of the objectives of this schedling code is to insure that the client always has something to do, it fails to do so for me.
I added the Einstein project to a couple of my cpus because of the frequent down times of the SETI project. I would often run out of work during these down periods.
I've been unable to download SETI WU since Thusday or so. By Sat I had finished all the SETI and Einstein WUs.
Under this condition the scheduler code still would not download a Einstein WU. I assume it's because of the reasons given here. If I understand the explanation correctly, it's won't download anything until SETI resumes downloading and I can process SETI WUs again.
So my client sits idle.
Which host are you talking about? They all show at least one "in progress" WU.
If one of the objectives of this schedling code is to insure that the client always has something to do, it fails to do so for me.
I added the Einstein project to a couple of my cpus because of the frequent down times of the SETI project. I would often run out of work during these down periods.
I've been unable to download SETI WU since Thusday or so. By Sat I had finished all the SETI and Einstein WUs.
Under this condition the scheduler code still would not download a Einstein WU. I assume it's because of the reasons given here. If I understand the explanation correctly, it's won't download anything until SETI resumes downloading and I can process SETI WUs again.
So my client sits idle.
Which host are you talking about? They all show at least one "in progress" WU.
I reset the Einstein project on each cpu this morning. Prior to that they were idle.
If one of the objectives of this schedling code is to insure that the client always has something to do, it fails to do so for me.
I added the Einstein project to a couple of my cpus because of the frequent down times of the SETI project. I would often run out of work during these down periods.
I've been unable to download SETI WU since Thusday or so. By Sat I had finished all the SETI and Einstein WUs.
Under this condition the scheduler code still would not download a Einstein WU. I assume it's because of the reasons given here. If I understand the explanation correctly, it's won't download anything until SETI resumes downloading and I can process SETI WUs again.
So my client sits idle.
Which host are you talking about? They all show at least one "in progress" WU.
I reset the Einstein project on each cpu this morning. Prior to that they were idle.
This is what I've been saying, If I set my connect time to less than 2 or 3 days I run out of work if Seti goes down, Einstein has a problem for Dialup users. Until I went to 4.45 I did not have a problem, I never ran out of work. The old sharing was fine, each project took it's turn!!!!!!!!!!!!!
If one of the objectives of this schedling code is to insure that the client always has something to do, it fails to do so for me.
I added the Einstein project to a couple of my cpus because of the frequent down times of the SETI project. I would often run out of work during these down periods.
I've been unable to download SETI WU since Thusday or so. By Sat I had finished all the SETI and Einstein WUs.
Under this condition the scheduler code still would not download a Einstein WU. I assume it's because of the reasons given here. If I understand the explanation correctly, it's won't download anything until SETI resumes downloading and I can process SETI WUs again.
So my client sits idle.
Which host are you talking about? They all show at least one "in progress" WU.
Please see host 385757 (Linda), it's currently sitting idle. As I understand this "problem" it will stay idle until Seti resumes downloading or I reset it.
Please see host 385757 (Linda), it's currently sitting idle. As I understand this "problem" it will stay idle until Seti resumes downloading or I reset it.
If S@H is stalled downloading, then you should try an anonymous proxy to unstick it.
Please see host 385757 (Linda), it's currently sitting idle. As I understand this "problem" it will stay idle until Seti resumes downloading or I reset it.
If S@H is stalled downloading, then you should try an anonymous proxy to unstick it.
John, whats going on there that anonymous proxies are needed?
Please see host 385757 (Linda), it's currently sitting idle. As I understand this "problem" it will stay idle until Seti resumes downloading or I reset it.
If S@H is stalled downloading, then you should try an anonymous proxy to unstick it.
John, whats going on there that anonymous proxies are needed?
Walt
I have no idea what the actual problem is, but for some people an outside proxy (can be either anonymous or transparent, just has to be somewhere other than your ISP is neessecary to get through to the UL/DL server at S@H (and AFAIK noplace else).
Please see host 385757 (Linda), it's currently sitting idle. As I understand this "problem" it will stay idle until Seti resumes downloading or I reset it.
If S@H is stalled downloading, then you should try an anonymous proxy to unstick it.
John, whats going on there that anonymous proxies are needed?
Walt
I have no idea what the actual problem is, but for some people an outside proxy (can be either anonymous or transparent, just has to be somewhere other than your ISP is neessecary to get through to the UL/DL server at S@H (and AFAIK noplace else).
My network here (roughly 100 miles from Berkeley) couldn't get thru until just a little while ago. Same with my servers on a completely separate network in the midwest (roughly 100 miles from UWM).
Magically, after their "weekly outage" everything works. I wonder if someone loaded old config data in one of the routers on Saturday and then loaded the correct ones today. [EDIT] And/or ran with old DNS config - they did make changes to that stuff recently[/edit]
Please see host 385757 (Linda), it's currently sitting idle. As I understand this "problem" it will stay idle until Seti resumes downloading or I reset it.
If S@H is stalled downloading, then you should try an anonymous proxy to unstick it.
John, whats going on there that anonymous proxies are needed?
Walt
I have no idea what the actual problem is, but for some people an outside proxy (can be either anonymous or transparent, just has to be somewhere other than your ISP is neessecary to get through to the UL/DL server at S@H (and AFAIK noplace else).
My network here (roughly 100 miles from Berkeley) couldn't get thru until just a little while ago. Same with my servers on a completely separate network in the midwest (roughly 100 miles from UWM).
Magically, after their "weekly outage" everything works. I wonder if someone loaded old config data in one of the routers on Saturday and then loaded the correct ones today. [EDIT] And/or ran with old DNS config - they did make changes to that stuff recently[/edit]
There is news at the S@H site that they found a configuration error on one of the Cogent facing servers. Fixing that seems to have fixed the problem.
If one of the objectives of
)
If one of the objectives of this schedling code is to insure that the client always has something to do, it fails to do so for me.
I added the Einstein project to a couple of my cpus because of the frequent down times of the SETI project. I would often run out of work during these down periods.
I've been unable to download SETI WU since Thusday or so. By Sat I had finished all the SETI and Einstein WUs.
Under this condition the scheduler code still would not download a Einstein WU. I assume it's because of the reasons given here. If I understand the explanation correctly, it's won't download anything until SETI resumes downloading and I can process SETI WUs again.
So my client sits idle.
RE: If one of the
)
Which host are you talking about? They all show at least one "in progress" WU.
RE: RE: RE: If one of
)
I reset the Einstein project on each cpu this morning. Prior to that they were idle.
RE: RE: RE: RE: If
)
This is what I've been saying, If I set my connect time to less than 2 or 3 days I run out of work if Seti goes down, Einstein has a problem for Dialup users. Until I went to 4.45 I did not have a problem, I never ran out of work. The old sharing was fine, each project took it's turn!!!!!!!!!!!!!
RE: RE: If one of the
)
Please see host 385757 (Linda), it's currently sitting idle. As I understand this "problem" it will stay idle until Seti resumes downloading or I reset it.
RE: Please see host 385757
)
If S@H is stalled downloading, then you should try an anonymous proxy to unstick it.
BOINC WIKI
RE: RE: Please see host
)
John, whats going on there that anonymous proxies are needed?
Walt
RE: RE: RE: Please see
)
I have no idea what the actual problem is, but for some people an outside proxy (can be either anonymous or transparent, just has to be somewhere other than your ISP is neessecary to get through to the UL/DL server at S@H (and AFAIK noplace else).
BOINC WIKI
RE: RE: RE: RE: Pleas
)
My network here (roughly 100 miles from Berkeley) couldn't get thru until just a little while ago. Same with my servers on a completely separate network in the midwest (roughly 100 miles from UWM).
Magically, after their "weekly outage" everything works. I wonder if someone loaded old config data in one of the routers on Saturday and then loaded the correct ones today. [EDIT] And/or ran with old DNS config - they did make changes to that stuff recently[/edit]
RE: RE: RE: RE: Quote
)
There is news at the S@H site that they found a configuration error on one of the Cogent facing servers. Fixing that seems to have fixed the problem.
BOINC WIKI