...
Observation: the backlog of results 'ready to send' ran out, for both MB and AP, around 10:00 UTC, or a few minutes before. There's still a trickle, but effectively no new downloads will have been added to the download server queue since then.

The download pipe remained saturated at 93 Mbit/sec until about 10:50 UTC, the best part of an hour later. That gives us some idea of the relative speeds of the various project components: I think we need to use the remaining time before the new servers arrive to work out some way of helping the scheduler request/reply messages get through (and hence avoid creating a new set of ghosts), while Oscar and friend keep the pipe full.

The 1148513 MB and 26888 AP in "ready to send" at the start plus about 12000 MB and 5000 AP reissues created during the saturation period would have taken nearly 19 hours of download with an actual throughput of 90 Mbps. I suspect ghost creation of 100000 or more.

With the queues drained as much as possible by other means, I hope the staff will try <resend_lost_results>1</resend_lost_results> in the project config.xml at least for short periods. Bursts of activity caused by that should be tolerable, and go a long way toward having the server "in progress" actually match what is on participants' hosts. This being Friday, I expect whoever is in the lab has other plans, but maybe next week?

Joe

I was surprised that the query loading on Jocelyn showed no sign of abating when the backlog of work available for allocation ran dry - with downloads a mere 20% of what they were this morning, what are all those other queries?

I was surprised that the query loading on Jocelyn showed no sign of abating when the backlog of work available for allocation ran dry - with downloads a mere 20% of what they were this morning, what are all those other queries?

The one item of information that I have not seen is "When will the new servers arrive?" I understand that the PO has been placed, but there has been no mention of an arrival date or an estimated "On Line" date. Thanks,
Dave
____________
David Moritz

The one item of information that I have not seen is "When will the new servers arrive?" I understand that the PO has been placed, but there has been no mention of an arrival date or an estimated "On Line" date. Thanks,
Dave

Expect the online date to be at least 4 weeks from now. Installing, config, and burn in will take lots and lots of time.

The one item of information that I have not seen is "When will the new servers arrive?" I understand that the PO has been placed, but there has been no mention of an arrival date or an estimated "On Line" date. Thanks,
Dave

Someone has about 1.5 million WU's looking at server, Must be very slow returning, I run out and my pc is slow

Or they are only able to compute for a few hours a day, or they've had PC problems.
Or seti has been "sidelined" by other BOINC projects which give shorter turnaround times - one of my crunchers still has a couple of SETI WU to run, but is quite happy crunching the milkyway at high priority because that project's WU only have a few days turnaround compared to SETI's weeks.
____________
Bob Smith
Member of Seti PIPPS (Pluto is a Planet Protest Society)
Somewhere in the (un)known Universe?

Just an idea for possibly speeding up the database size reduction: How about distributing more copies of pending results already before they expire? That way the project could utilize some of its current massive overcapacity to add redundancy and thus accelerate the decline in "Results returned and awaiting validation".

Normally the resending of timed-out WUs works in a fairly stretched-out way (timewise). This gives the best resource utilization when the project is up and running - we only resend results that really have timed out and need to be resent.

But these weeks, with capacity to burn, I guess a more parallel work-mode might come in handy. If one or two extra results were distributed already today, and returned tomorrow, then that old result that was sent out in October and times out next week will no longer need to be resent (and thus kept active), because the WU will already have the required quorum of two results and can be finalized.
____________

But these weeks, with capacity to burn, I guess a more parallel work-mode might come in handy. If one or two extra results were distributed already today, and returned tomorrow, then that old result that was sent out in October and times out next week will no longer need to be resent (and thus kept active), because the WU will already have the required quorum of two results and can be finalized.

This would speed up things a bit but not entirely. WU can not be finalized until quorum has been met and results have been validated and all outstanding WUs have either been reported or timed out. If WUs get re-issued prior to expiration of existing results, WUs would still need to live until all remaining results of same WU expire. But not longer as hopefully there would already be a quorum created by faster crunchers.
____________Metod ...

Just a query - while we're waiting for the new servers, how about Beta granting credit for returned WU's? I returned 85 when Beta finally came up, and received another 40 or so from the built-up un-crunched queue - I've been steadily returning those as they've crunched, but my Beta stats line is flat since sometime in September! Or would this be too much on the substitute database server??
____________
.

Just a query - while we're waiting for the new servers, how about Beta granting credit for returned WU's? I returned 85 when Beta finally came up, and received another 40 or so from the built-up un-crunched queue - I've been steadily returning those as they've crunched, but my Beta stats line is flat since sometime in September! Or would this be too much on the substitute database server??

Now that you mention it, I've crunched a few hundred MB WU's and got some new work, afew days ago, too.
But haven't seen any credit update, since 2 month's.
Well with the weekend ahead, it'll be monday or later ;-)

My Beta stats line is flat since sometime in September! Or would this be too much on the substitute database server??

Beta validators are off at Beta there are 43,610 waiting validation as of 13 Nov 2010 4:48:08 UTC. data-driven web pages & vote_monitor are the only things running
____________Live in NZ y not join Smile City?