Some good news in general. With some extreme debugging by Jeff and the rare manual-reading by me we got fastCGI working for both the scheduler CGI and the file upload handler under linux/apache2. On hindsight not terribly difficult but it wasn't very easy to track down the issues given fastCGI's penchant for overloading FILE streams and whatnot. The servers were going up and down this afternoon as we were employing the new executables and working out the configuration kinks.

The results were vast and immediate, which then caused us to quickly hit our next (and possibly final) bottleneck: the rate at which we can create new work. As it stands now the splitters (which create the work) can only run on Solaris machines, three of which we recently retired (koloth, kryten, and galileo). We have every possible Solaris box we have working on this now including three not-so-hefty desktop systems (milkyway, glenn, and kang). We could put some effort into making a linux version of splitter, but I don't think we'll bother for several reasons including: 1. we are sending out workunits faster than we get raw data from the telescope (we always claimed that this would be our "ceiling" and wouldn't put any effort into making work beyond this rate if we don't have the resources), and 2. we are quite close to running out of classic work that is of any scientific use. Any programming effort should pour into the new multibeam splitter, and I sure hope we finish that real soon.

- Matt

---

-- BOINC/SETI@home network/web/science/development person
-- "Any idiot can have a good idea. What is hard is to do it." - Jeanne-Claude

Some good news in general. With some extreme debugging by Jeff and the rare manual-reading by me we got fastCGI working for both the scheduler CGI and the file upload handler under linux/apache2. On hindsight not terribly difficult but it wasn't very easy to track down the issues given fastCGI's penchant for overloading FILE streams and whatnot. The servers were going up and down this afternoon as we were employing the new executables and working out the configuration kinks.

The results were vast and immediate, which then caused us to quickly hit our next (and possibly final) bottleneck: the rate at which we can create new work. As it stands now the splitters (which create the work) can only run on Solaris machines, three of which we recently retired (koloth, kryten, and galileo). We have every possible Solaris box we have working on this now including three not-so-hefty desktop systems (milkyway, glenn, and kang). We could put some effort into making a linux version of splitter, but I don't think we'll bother for several reasons including: 1. we are sending out workunits faster than we get raw data from the telescope (we always claimed that this would be our "ceiling" and wouldn't put any effort into making work beyond this rate if we don't have the resources), and 2. we are quite close to running out of classic work that is of any scientific use. Any programming effort should pour into the new multibeam splitter, and I sure hope we finish that real soon.

- Matt

Great news. Does this mean the anonymous_platform issue is resolved?

---

The timeout problem is not solved. It causes large numbers of ghosts.

I just got 12 new ones.

---

very good news, but we have some Problems

HTTP internal server error

HTTP internal server error

i have 3 Hosts here and all have the same problem....

all using pure Seti clients, no optimized...

i think that Problem was cleared out

...

Greetings from Germany NRW
Ulli

We're still having a different problem than reported earlier in the thread - I have a completed WU that starts to upload, gets to 98.85%, then stalls.
This is on a cable modem, no optimized app, client 5.8.16.

Just tried it 1445 PDT...

---

.

Hello, from Albany, CA!...

ghosts has always been there it is just now more in the public if they are not too manny it is acceptable

Mat
I am sure alot of us would like to see an "result download rate"
This can be dirived from the rate teady to send is falling

Ex
RCR=result creation rate
RDR=result download rate
if ready to send is standing still then RDR = RCR
If ready to send is increasing by 1 result a second then RDR=RCR-1
If ready to send is decreasing by 1 result a second then RDR=RCR+1
u can use avarages this dont have to be perfect

---

ghosts has always been there it is just now more in the public if they are not too manny it is acceptable

True but as far as I know the 5 minute timeout problem is from the last few days.

---

Just twiddled the timeouts - maybe that'll fix the ghost workunit/result issue.

- Matt

---

-- BOINC/SETI@home network/web/science/development person
-- "Any idiot can have a good idea. What is hard is to do it." - Jeanne-Claude

Just twiddled the timeouts - maybe that'll fix the ghost workunit/result issue.

- Matt

Matt...

Uploads are impossible at the moment. Might want to check to see if there's anything wrong other than extra traffic...

Brian

Just twiddled the timeouts - maybe that'll fix the ghost workunit/result issue.

- Matt

Matt...

Uploads are impossible at the moment. Might want to check to see if there's anything wrong other than extra traffic...

Brian

I guess I just needed to post something here, because right after I did, the upload I had worked... Now it is just "No work from project", which I would guess is probably either legit or slow feeder...

Uploads go to 100%, and *then* they fail... After the network traffic is complete.

---

Just twiddled the timeouts - maybe that'll fix the ghost workunit/result issue.

- Matt

I just got a WU on my FreeBSD box (with a app_info.xml) so that appears to work now :)

---

Thanks for the update and all the hard work, Matt!

---

Join The Assimilators

Free Internet Radio! "The Assimilators" Browser Toolbar!

Some good news in general. With some extreme debugging by Jeff and the rare manual-reading by me we got fastCGI working for both the scheduler CGI and the file upload handler under linux/apache2. On hindsight not terribly difficult but it wasn't very easy to track down the issues given fastCGI's penchant for overloading FILE streams and whatnot. The servers were going up and down this afternoon as we were employing the new executables and working out the configuration kinks.

The results were vast and immediate, which then caused us to quickly hit our next (and possibly final) bottleneck: the rate at which we can create new work. As it stands now the splitters (which create the work) can only run on Solaris machines, three of which we recently retired (koloth, kryten, and galileo). We have every possible Solaris box we have working on this now including three not-so-hefty desktop systems (milkyway, glenn, and kang). We could put some effort into making a linux version of splitter, but I don't think we'll bother for several reasons including: 1. we are sending out workunits faster than we get raw data from the telescope (we always claimed that this would be our "ceiling" and wouldn't put any effort into making work beyond this rate if we don't have the resources), and 2. we are quite close to running out of classic work that is of any scientific use. Any programming effort should pour into the new multibeam splitter, and I sure hope we finish that real soon.

- Matt

. . . keep up the good work Matt (and that goes without sayin' - the rest @

Berkeley too . . .)

---

BOINC Wiki . . .

Science Status Page . . .

Hi,

Thanks for your hard work at the Lab ;)

Just managed to download new work with optimized apps (app_info.xml) without renaming it.
So apperently it works ;-)

BTW: It loosks as it was the "too short timings" that cause the trouble for the opimized apps as they need sligtly longer time to connect/comunicate than the ordinary stock apss.

Kiva

---

Greetings from Norway

Crunch3er & AK-V8 Inside

Just twiddled the timeouts - maybe that'll fix the ghost workunit/result issue.

- Matt

Uploads now are running with no problems.
What I see is that communicating with the scheduler is still difficult
and I get error messages after 300 secs from initial reporting request.

errors are:

24.05.2007 07:46:23||Project communication failed: attempting access to reference site
24.05.2007 07:46:24||Access to reference site succeeded - project servers may be temporarily down.

or

24.05.2007 07:37:51||Access to reference site succeeded - project servers may be temporarily down.
24.05.2007 07:37:51|SETI@home|Scheduler request failed: failed sending data to the peer

(theese are messages received some minute ago ... my time is UTC+2)

In theese hosts I don't have any app_info file and
in this moment I can't say anything about my far
hosts that are still using app_info.
If I'll see them working, I'll tell you.

Bye,
Franz

---

Thank you for the news update. All you guys are doing a great job.

Is there any way for us to know if the project is offline vs out of work?

---

It's not too many computers, it's a lack of circuit breakers for this room. But we can fix it :)

Is there any way for us to know if the project is offline vs out of work?

Check the Server Status page.

---

Grant
Darwin NT

The results were vast and immediate, which then caused us to quickly hit our next (and possibly final) bottleneck: the rate at which we can create new work. As it stands now the splitters (which create the work) can only run on Solaris machines, three of which we recently retired (koloth, kryten, and galileo). We have every possible Solaris box we have working on this now including three not-so-hefty desktop systems (milkyway, glenn, and kang). We could put some effort into making a linux version of splitter, but I don't think we'll bother for several reasons including: 1. we are sending out workunits faster than we get raw data from the telescope (we always claimed that this would be our "ceiling" and wouldn't put any effort into making work beyond this rate if we don't have the resources), and 2. we are quite close to running out of classic work that is of any scientific use. Any programming effort should pour into the new multibeam splitter, and I sure hope we finish that real soon.

Matt

Im somwhat confused.

As far as i understand the multibeam reciever will increase the amount of data to be recorded at the radio telescope (7 recievers 2 polarasition = 14 chanels).
As you say yourself there is still work going on on the multibeam splitter.

But would more data not require more tapes so more splitters.
Then you would probbably also need the linux machines.

Or have i missed somthing

Greetings from the netherlands

---