Okay, the replica is up to date.


So when is the tasks feature going to be enabled?

I think what they are trying to do is reduce the load on the Master DB as much as they can, so any features that are off are to scrape every inch of available bandwidth to keep the requests down.

---

"Only two things are infinite, the universe and human stupidity, and I'm not sure about the former." - Albert Einstein
Vextor Homepage | Vextor Blog

How does that use bandwidth?

There are alot of uploads trying to get through right now in the last hour 63,486 as shown on the Server Status page, and because these results are constantly populating the DB with new information internally the bandwidth between the servers is already maxed out. Add to this the amount of people that are looking to check they're results right now and you get a serious overload on the servers resources.
This is the impression I am getting after looking at the posts over the past weeks and what is in on the Server Status Page.

---

"Only two things are infinite, the universe and human stupidity, and I'm not sure about the former." - Albert Einstein
Vextor Homepage | Vextor Blog

So they will or will not restore that in the near future?

It will be restored ASAP. How long they stay on for is dependant on whether the old servers there can balance the load on them well enough to cope with the demand.

---

"Only two things are infinite, the universe and human stupidity, and I'm not sure about the former." - Albert Einstein
Vextor Homepage | Vextor Blog

ASAP meaning in a few minutes, hours, weeks?

The very meaning of ASAP is "as soon as possible", which doesn't have a defined time line to it.

---

Okay

Uploads do not affect the DB
Downloads are a transitioned from the Scheduler (Some+ DB, it has to recieve your sched_request_setiathome.berkeley.edu.xml and parse it against the DB then let you know what downloads to look for.)
Reported Uploads (Scheduler affects the DB, results in downloads)
Every other process listed in the Server Status Page requires DB Access.
The "Tasks list" requires Very Expensive DB Access

At this point in time with over 4.5 million WU's in the Field and the 3.2 Million Results returned. Then other things suppended to get reported results back to keep silly things like "lost credit" to a Minimum... That is ALL DB Access...

It is sorta like going down to your local Office Supply Store. Buy a Monster cutting board (the splitter) to quickly start cutting paper with a ream of sheets of red papper (MB workunits) and sheets of blue paper (AP workunits ) and chopping them according to the size the Splitter chops them. MB (Enhanced or Cuda gets chopped into 222208 pieces, AP gets chopped into 5600 pieces. For each disk image that is loaded. Then send them to ALL the Users...

With all the disk images that have been split and sent to Users there are over 4 million tiny pieces are floating around (the DB has to track them all) you have some numbers of (180000 people 380000 computers).

When they are returned they are converted to Green ones (Results) each result is reassembled to create the original red or blue page it was chopped from.

Now the servers and various processes have to sort the 7 million+ tiny pieces of paper once per second trying to reassemble everything. Then a "User" wants to come along and look at "only" their red/blue and green pieces of paper they received in the Tasks lists).

Having known the Staff for a few years know that they attempt to make "Users Things Visiable Soonest." In the Current state of sorting out what is happening Users things take a back seat (esp... IF it allows other important things to complete).

Edit: This does not mention how users with very large caches affect the whole reassembling of all this.


Regards

---

Please consider a Donation to the Seti Project.

thank you for chopping a response and settling this... keep it down; as long as it's helping the process, i don't think people should be complaining.

---

I recommend Secunia PSI: http://secunia.com/vulnerability_scanning/personal/
Go Georgia Tech.