Well my uploads just cleared again and I'm back up on the limits.

Cheers.

Well my uploads just cleared again and I'm back up on the limits.

Cheers.

A few retries & the uploads cleared, but the most common response to a request for work is "No tasks sent". Every now & then some get allocated, but probably 75% of the requests at the moment result in "No tasks sent" responses.


EDIT- just looked at the network graphs & there's a big surge in outbound & inbound traffic. Things might be coming back to life...
Uploads appear to be going back under their own steam, although it is taking 10-20 seconds for them to actually start transferring data once the clock starts.

---

Grant
Darwin NT

As I write this 90,000 results have been returned and incoming traffic is up to just over 27 MB per second. My upload queue cleared an hour or so ago.

Out of interest how many results are stored in a row in the database? I am just wondering how many rows are been taken up by result waiting for DB purging there are currently 1,606,679 results waiting to be deleted and the work unit waiting purging is 779,696

---

Well my uploads just cleared again and I'm back up on the limits.

Cheers.

A few retries & the uploads cleared, but the most common response to a request for work is "No tasks sent". Every now & then some get allocated, but probably 75% of the requests at the moment result in "No tasks sent" responses.


EDIT- just looked at the network graphs & there's a big surge in outbound & inbound traffic. Things might be coming back to life...
Uploads appear to be going back under their own steam, although it is taking 10-20 seconds for them to actually start transferring data once the clock starts.

Yeah we'll just have to wait and see how it goes, though Einstein has been helpful to keep my main rigs' GPU's active the last few days while trying to get to get my SETI cache back up.

Cheers.

Aparently UL are working now (still no AP work avaiable). As usual we will never know what happenig. Sometimes i think, takes only few seconds to write a note about the outages, maybe just to keep the curious updated.

---

As I write this 90,000 results have been returned and incoming traffic is up to just over 27 MB per second. My upload queue cleared an hour or so ago.

Out of interest how many results are stored in a row in the database? I am just wondering how many rows are been taken up by result waiting for DB purging there are currently 1,606,679 results waiting to be deleted and the work unit waiting purging is 779,696

As I recall it is one entry per row. Which was the reason limits were needed. It was taking to long to scan the table with "Results out in the field" I believe.

---

SETI@home classic workunits: 93,865 CPU time: 863,447 hours
Join the [url=http://tinyurl.com/8y46zvu]BP6/VP6 User Group[

Things appear normal again from BOINC clients view, no stuck up- or donwloads.
But the SSP looks ridiculous to me, as if 15 MB and 15 AP splitters are running momentary... :?

---

Aloha, Uli

As I write this 90,000 results have been returned and incoming traffic is up to just over 27 MB per second. My upload queue cleared an hour or so ago.

Out of interest how many results are stored in a row in the database? I am just wondering how many rows are been taken up by result waiting for DB purging there are currently 1,606,679 results waiting to be deleted and the work unit waiting purging is 779,696

As I recall it is one entry per row. Which was the reason limits were needed. It was taking to long to scan the table with "Results out in the field" I believe.

One entry per row is standard for any good database design. 'Result' and 'Row' are pretty much synonyms here.

Scanning won't take much time, because the key fields are indexed - and a database index search is *very* fast (that's what they're optimised for). Retrieving the rest of the record is what takes the time - especially if you have to go to a physical disk for it. I think the staff have said that it makes a huge difference when the whole database is small enough to be held completely in RAM, both tables and indexes.

As I write this 90,000 results have been returned and incoming traffic is up to just over 27 MB per second. My upload queue cleared an hour or so ago.

Out of interest how many results are stored in a row in the database? I am just wondering how many rows are been taken up by result waiting for DB purging there are currently 1,606,679 results waiting to be deleted and the work unit waiting purging is 779,696

As I recall it is one entry per row. Which was the reason limits were needed. It was taking to long to scan the table with "Results out in the field" I believe.

One entry per row is standard for any good database design. 'Result' and 'Row' are pretty much synonyms here.

Scanning won't take much time, because the key fields are indexed - and a database index search is *very* fast (that's what they're optimised for). Retrieving the rest of the record is what takes the time - especially if you have to go to a physical disk for it. I think the staff have said that it makes a huge difference when the whole database is small enough to be held completely in RAM, both tables and indexes.

Having seen many poor db implementations over the years I tend to take caution when assuming things.
In fact I have to work with a system where someone thought it would be a good idea to make a table for groups of users and then stuff all the users into each line with the group as the key. Instead of just adding a group field to the user table.

Perhaps the limit I was thinking about was just once we exceeded the RAM for the db. I did not follow this issue closely after they asked if there were db experts with idea for optimization.
I tend to just know enough to muck things up and then get them back to where they were before I touched it.

---

SETI@home classic workunits: 93,865 CPU time: 863,447 hours
Join the [url=http://tinyurl.com/8y46zvu]BP6/VP6 User Group[

As I write this 90,000 results have been returned and incoming traffic is up to just over 27 MB per second. My upload queue cleared an hour or so ago.

Out of interest how many results are stored in a row in the database? I am just wondering how many rows are been taken up by result waiting for DB purging there are currently 1,606,679 results waiting to be deleted and the work unit waiting purging is 779,696

As I recall it is one entry per row. Which was the reason limits were needed. It was taking to long to scan the table with "Results out in the field" I believe.

One entry per row is standard for any good database design. 'Result' and 'Row' are pretty much synonyms here.

Scanning won't take much time, because the key fields are indexed - and a database index search is *very* fast (that's what they're optimised for). Retrieving the rest of the record is what takes the time - especially if you have to go to a physical disk for it. I think the staff have said that it makes a huge difference when the whole database is small enough to be held completely in RAM, both tables and indexes.

Having seen many poor db implementations over the years I tend to take caution when assuming things.
In fact I have to work with a system where someone thought it would be a good idea to make a table for groups of users and then stuff all the users into each line with the group as the key. Instead of just adding a group field to the user table.

Perhaps the limit I was thinking about was just once we exceeded the RAM for the db. I did not follow this issue closely after they asked if there were db experts with idea for optimization.
I tend to just know enough to muck things up and then get them back to where they were before I touched it.

The basic design is viewable in http://boinc.berkeley.edu/trac/browser/boinc-v2/db/schema.sql, and seems to be reasonably normalised for tables like 'workunit' and 'result'. The BOINC developers do have a tendency to over-use blobs, especially for xml replacements for proper fields, but that doesn't affect our question here.

As I write this 90,000 results have been returned and incoming traffic is up to just over 27 MB per second. My upload queue cleared an hour or so ago.

Out of interest how many results are stored in a row in the database? I am just wondering how many rows are been taken up by result waiting for DB purging there are currently 1,606,679 results waiting to be deleted and the work unit waiting purging is 779,696

As I recall it is one entry per row. Which was the reason limits were needed. It was taking to long to scan the table with "Results out in the field" I believe.

One entry per row is standard for any good database design. 'Result' and 'Row' are pretty much synonyms here.

Scanning won't take much time, because the key fields are indexed - and a database index search is *very* fast (that's what they're optimised for). Retrieving the rest of the record is what takes the time - especially if you have to go to a physical disk for it. I think the staff have said that it makes a huge difference when the whole database is small enough to be held completely in RAM, both tables and indexes.

Having seen many poor db implementations over the years I tend to take caution when assuming things.
In fact I have to work with a system where someone thought it would be a good idea to make a table for groups of users and then stuff all the users into each line with the group as the key. Instead of just adding a group field to the user table.

Perhaps the limit I was thinking about was just once we exceeded the RAM for the db. I did not follow this issue closely after they asked if there were db experts with idea for optimization.
I tend to just know enough to muck things up and then get them back to where they were before I touched it.

The basic design is viewable in http://boinc.berkeley.edu/trac/browser/boinc-v2/db/schema.sql, and seems to be reasonably normalised for tables like 'workunit' and 'result'. The BOINC developers do have a tendency to over-use blobs, especially for xml replacements for proper fields, but that doesn't affect our question here.

Thanks for all the answers.

---

Weekly Maintenance is over and the AstroPulse Splitters went from Not Running to Disabled. I suppose that may be an improvement, however, my Mac can't tell any difference. Is there any hope of resurrecting the AP Splitters anytime soon?

I sure hope AP comes on line
Fully expected it back up after the outage
This is a waste of volunteers time

Michael

The AstroPulse splitters comes again online when they checked why they made so much errors.
I was in contact with Eric and he said it is/was not normal.

SETI@home never said "We will feed your PC with tasks 24/7". Or they did?

http://setiathome.berkeley.edu
.. on the left hand:
Keep your computer busy when SETI@home has no work - participate in other BOINC-based projects.


TBar, you have "good luck" that the MAC BOINC don't support the "limit of tasks in progress", so your PC can fill up more tasks than other members with other OS. And you complain nevertheless?
If you are a hardcore SETIzen, make a 2nd OS (Linux, Windows) to your HDD and use it if no AstroPulse tasks are available. Just an idea.

---

I have been checking my AP work that finally got validated today because somebody finally returned their work. It's easy to see who has been hoarding work as ALL AP work should have been returned by now from a 200 work unit limit. Any outstanding AP work has been hoarded by using various techniques discussed here. Some 56K AP work still out in the field as of now.

Much work is being re-issued because my wingman was late returning work. Great waste of resources just to build up a gigantic cache.

Take a look and take names! Perhaps Berkely will put some meaningful limits that can be enforced by them when work continues. We can always hope!

---

Boinc....Boinc....Boinc....Boinc....

I have been checking my AP work that finally got validated today because somebody finally returned their work. It's easy to see who has been hoarding work as ALL AP work should have been returned by now from a 200 work unit limit. Any outstanding AP work has been hoarded by using various techniques discussed here. Some 56K AP work still out in the field as of now.

Much work is being re-issued because my wingman was late returning work. Great waste of resources just to build up a gigantic cache.

Take a look and take names! Perhaps Berkely will put some meaningful limits that can be enforced by them when work continues. We can always hope!

NOT entirely true. NO hoarding going on here. Actually I resent the implication.

I run mostly AP with a 10 day cache. That amounts to about 20-25 tasks per machine. AP has not been down that long, my machines have about 5-6 days left.

---

Dave

The real pisser is seeing a lot of channels loaded and not knowing why work is not being sent.
We were not told until now of why this is going on
As to hoarding AP work my 200 limit is 5 minutes away from my last WU completing then the well runs dry.

I have no interest in other projects at all.
Thanks for at least telling what is wrong......

I have been checking my AP work that finally got validated today because somebody finally returned their work. It's easy to see who has been hoarding work as ALL AP work should have been returned by now from a 200 work unit limit. Any outstanding AP work has been hoarded by using various techniques discussed here. Some 56K AP work still out in the field as of now....

i blame the 56k on the slow suns of a female dog! any computer in the top 500 rigs should be excluded from the limits as they stand.

---

Now I look and see many wu with March deadlines so obviously I was wrong. I failed to realize that many are still content to work 24+ hours on one AP work unit.

And excluding the top 500 computers from the limits would just be wrong!

---

Boinc....Boinc....Boinc....Boinc....

I have been checking my AP work that finally got validated today because somebody finally returned their work. It's easy to see who has been hoarding work as ALL AP work should have been returned by now from a 200 work unit limit. Any outstanding AP work has been hoarded by using various techniques discussed here. Some 56K AP work still out in the field as of now.

Much work is being re-issued because my wingman was late returning work. Great waste of resources just to build up a gigantic cache.

Take a look and take names! Perhaps Berkely will put some meaningful limits that can be enforced by them when work continues. We can always hope!

NOT entirely true. NO hoarding going on here. Actually I resent the implication.

I run mostly AP with a 10 day cache. That amounts to about 20-25 tasks per machine. AP has not been down that long, my machines have about 5-6 days left.

Well, some of the people here are not the swiftest. Obviously they don't bother to check a thing, or even give it a thought. My Mac has been working two hosts since Jan 26th, supposedly working 2 groups of 200 is somehow much better than 1 group of 400. I guess I should have made it 3 groups of 200. It is STILL working a BETA APP in hopes a Stock Mac App will be released soon. I suppose you geniuses out there would rather see a Machine working a Beta App just quit? Heck, why not, no one needs to test any new Apps around here, they just pop outta thin air. It has quit BTW, going on a couple days now. No problem for those complainers though, if it doesn't help them then it doesn't matter. Are any of you complainers running any tests on new software out there?

There are plenty of other machines out there running a 10 day cache. I have one still working off a 10 day cache on the CPU, they aren't due until the 7th of Mar. I suppose some people can't think that far ahead though. Oh, my machine working APs on the CPU is Still running the New CUDA App on the GPUs which will eventually be released as x42. I don't remember a whole lotta people offering to test that one either...