| Subject: Re: Comms failure. |
| From: "Book End" <book@support.com.invalid> |
| Date: 09/12/2005, 08:36 |
"Lars Bausch" <lars.bausch@dotsch.de> wrote in message
news:dnbf6k$6hg$1@windu.dotsch.de...
Book End wrote:
I haven't seen any indication that BOINC/SETI has a problem but I have 2
wu's left out of a 10 day cache, the rest are waiting to upload.
Can anyone suggest what to look for & how to resolve my crisis?
Berkeley has some problems with the servers. So up- and downloads
sometimes not be posible.
From news of the seti@home main site :
December 8, 2005
We are experiencing heavy traffic on our data server. This is currently
preventing some result uploads, but is getting better over time. More in
Technical News.
From the technical news (http://setiathome.berkeley.edu/tech_news.php) :
December 8, 2005 - 03:00 UTC
For the past few days our upload/download server has been dropping
connections, making for a frustrating experience for everybody involved.
We also had our hands full trying to complete the first stage of the
master science database merge.
Currently everybody who is requesting work can get it, thanks to splitting
the uploads and downloads onto two separate servers. This isn't reflected
yet in the server status page, and it may just be a temporary solution
until we somehow obtain a machine capable of doing both. As well, there
may be more server shuffling as Classic ramps down.
Meanwhile, we are still dropping connections on the upload server. But the
good news is that we are successfully handling about 4 result uploads for
every workunit download, which means the upload server is indeed catching
up. We're getting about 35 results a second and sending out about 8
workunits a second at the time of writing.
We hit several snags with the master science database merge and were too
far in to revert back. Since we were running low on work we went with a
backup plan - creating a third database. Since all new workunits and
results are being inserted into this third database, we can leisurely
migrate the data between the other two databases without any time
pressure. This complicates our overall merge plan a bit, but reduces a lot
of the stress in the meantime.
Thank you.