Right. Which means there is never any way to carry more than 2.5 days worth of work, if you happen go be unlucky enough to have the short WUs in your queue. Not nearly enough when a project has frequent downtime. It would be better to have all WUs set with a deadline no shorter than about 14 days, even if they are small/fast WU.

I thought the max was 10 days, has it changed to 14? Thanks.

---

Right. Which means there is never any way to carry more than 2.5 days worth of work, if you happen go be unlucky enough to have the short WUs in your queue. Not nearly enough when a project has frequent downtime. It would be better to have all WUs set with a deadline no shorter than about 14 days, even if they are small/fast WU.

I thought the max was 10 days, has it changed to 14? Thanks.

Not sure I understand your question. The max "connect" time is 10 days. But I am not talking about that.

I am suggesting that the min deadline for a WU should be no smaller than 14 days.

This would allow people to use the full range of values for "connect". Currently, with deadlines as short as 4 days, setting the connect to anything larger than about a day will cause BOINC to go into panic mode. And the queue will never get bigger than a couple of days worth of work.

---

Dublin, California
Team: SETI.USA

Right. Which means there is never any way to carry more than 2.5 days worth of work, if you happen go be unlucky enough to have the short WUs in your queue. Not nearly enough when a project has frequent downtime. It would be better to have all WUs set with a deadline no shorter than about 14 days, even if they are small/fast WU.

I thought the max was 10 days, has it changed to 14? Thanks.

Not sure I understand your question. The max "connect" time is 10 days. But I am not talking about that.

I am suggesting that the min deadline for a WU should be no smaller than 14 days.

This would allow people to use the full range of values for "connect". Currently, with deadlines as short as 4 days, setting the connect to anything larger than about a day will cause BOINC to go into panic mode. And the queue will never get bigger than a couple of days worth of work.

I haven't tried it, mainly because with running three projects, I've never run out of work. But I would think, gradually your cache of units would increase to approximately your requirement, although I doubt wether it will let you have a full 10 days worth.

You are also in danger of upsetting the people who like instant gratification. They will say these short units only take 15 mins, why do I have to wait 10 days for this "******" to return them.

Andy

Not sure I understand your question. The max "connect" time is 10 days. But I am not talking about that.

I am suggesting that the min deadline for a WU should be no smaller than 14 days.

This would allow people to use the full range of values for "connect". Currently, with deadlines as short as 4 days, setting the connect to anything larger than about a day will cause BOINC to go into panic mode. And the queue will never get bigger than a couple of days worth of work.

I haven't tried it, mainly because with running three projects, I've never run out of work. But I would think, gradually your cache of units would increase to approximately your requirement, although I doubt wether it will let you have a full 10 days worth.

Nope. Per JM7:

"Computation deadline = report deadline - ( connect every X + switch
projects every X, + 1 day).

If a task cannot be completed within 90% of the time between now and the
computation deadline it is in deadline trouble. S@H has tasks that have
about a 4 day deadline. 4 - (2 + 1 + .05) = 0.95 days. If the time
before getting started + the time to compute > 0.95 days, the task is in
deadline trouble."

So long as you have any WUs with a deadline less than 10 days, and a connect setting of 10 days, it will remain in panic mode.

---

Dublin, California
Team: SETI.USA

As SETI is still taking in finished units, the deadline issue is a non issue. When units are sent out there will be appropriate deadlines based on past practice. (IMHO)

[snip]

There is still a deadline issue - it is currently very hard to report completed WU's, as the scheduler is dealing with huge numbers of "ronco boxes" ("set and forget") whose owners don't know of the work blackout. The boxes are bugging the scheduler for work, which makes a "reporting xx completed WUs" scheduler request time-out about 50-90% of the time. Even a simple "update my stats" scheduler request seldom goes thru...

Thanks for bringing this up again. I thought about replying to the "rose-colored" viewpoint that there isn't any issue, but chose not to...

It appears that some people just don't seem to understand that there are results out there that can pass and are passing deadlines and the hosts in question may not have been able to report due to an inability to timely connect and report...

Hi!

I'm waiting for the new server to show up as everybody else, as my computers are beginning to run out of work - but I'll live through this.

Would it be possible to make a backup of the database distributable as well as the WU's?
I wouldn't mind setting aside a few gigabytes to store a part of the database, if it could help the project.

A.

---

Right. Which means there is never any way to carry more than 2.5 days worth of work, if you happen go be unlucky enough to have the short WUs in your queue. Not nearly enough when a project has frequent downtime. It would be better to have all WUs set with a deadline no shorter than about 14 days, even if they are small/fast WU.

I thought the max was 10 days, has it changed to 14? Thanks.

Not sure I understand your question. The max "connect" time is 10 days. But I am not talking about that.

I am suggesting that the min deadline for a WU should be no smaller than 14 days.

This would allow people to use the full range of values for "connect". Currently, with deadlines as short as 4 days, setting the connect to anything larger than about a day will cause BOINC to go into panic mode. And the queue will never get bigger than a couple of days worth of work.

Ah, gotcha, I was referring to backlog, not days to validate.

---

"Yeah, any 5 minute period that your computer does not reboot automatically." Ooh, don't go there. My motherboard had issues where it'd spontaneously reboot. Had to return it for warranty. This one works great. Yeah, forget about the updates. I just have the notifier let me know when there's one available. I'll let it download when I feel like it, and install it when I feel like it. No biggie for me. What I do hate is when you install them, and tell it "Reboot Later" every 5 or 10 min. the dialog box pops back up asking to reboot. And sometimes it switches the Reboot now and reboot later buttons, so if you get used to being in one spot, it tricks you into blidly hitting reboot now. Now that's a pain, cause it forces everything closed, saved or not.

Don't forget... If you hit "Reboot Later" properly too many times under XP, Windows gets annoyed at you and starts putting a time limit on how long you can take to say "Reboot Later." I think it's like 10-15 non-timed "Reboot Later"s, and then it starts putting you on like a minute timer, and if you don't see the dialog before then (say, you stepped away), it'll automatically assume you want it to reboot... I really wish the OS would mind its own business, and take the user's word that they really *DO* want to wait until later... and NOT reboot right now at an inconvenient time. I really think they should do it more like a snooze option. IE, tell it to snooze for X amount of time, THEN reboot. Specify a SPECIFIC time to reboot. Or specify "don't reboot at all until I say so gosh darn it!"

But, apparently, M$ can't engineer worth a darn. At least from a user-experience point of view, despite their assertions to the contrary.

---

If there were no time, how old would YOU be? ~Me

BOINC Seti@Home Stats:

Classic Seti@Home Stats:

After updating, disable the "Automatic Update" service (as well as BITS). No more problems...

---

After updating, disable the "Automatic Update" service (as well as BITS). No more problems...

Actually you can disable the "Automatic Update" at any time... just remember to stop by the Windows Update site appropriate to your OS about once a month and download any "security updates" (AKA: the "we made an error, and left a gaping security hole in the OS!" or the "some smart-aleck figured out a new way into our OS" patches) While you're there, also look for (and at) new drivers that M$ thinks may be appropriate. (sometimes they are, sometimes they aren't!)

---

.

Hello, from Albany, CA!...

While we are on the subject of deadlines, would it be possible for the wide AR WU's to have deadlines that don't trip the "Computer overcommited, processing earliest deadline first" - which they (before the blackout) currently do - a minimum deadline should be whatever is just short of tripping that, not 4 days!

sorry, after "edit" timer had run out...

I normally carry a 4.5 day cache - I was processing for 3 solid days into this WU blackout (or as has been noted, very dark grey-out - re-issued WU's)

---

.

Hello, from Albany, CA!...

After updating, disable the "Automatic Update" service (as well as BITS). No more problems...

Actually you can disable the "Automatic Update" at any time... just remember to stop by the Windows Update site appropriate to your OS about once a month and download any "security updates" (AKA: the "we made an error, and left a gaping security hole in the OS!" or the "some smart-aleck figured out a new way into our OS" patches) While you're there, also look for (and at) new drivers that M$ thinks may be appropriate. (sometimes they are, sometimes they aren't!)

Apart from the last sentence, my point exaclty...

---

Thanks for the continuing patience and encouraging sentiments since the science database server crashed over a week ago. Still waiting on the server replacement. I think we're all anxious for it to arrive already, but we originally expected it no earlier than late-in-the-day today.

We had the usual database backup outage, in case anybody noticed. Outside of the usual backup/compression of the BOINC database, I fixed the replica server, so that's back up and running again. I also rebooted our Network Appliance which has been complaining about "misconfigurations" as of late, but that didn't seem to help or hurt. We think a bad drive in the system is causing these errors. I then replaced a bad drive in the Snap Appliance so that's back to having two working hot spares (phew). Jeff, Eric, and I also cleaned up the lab. Entropy reigns supreme around here. The table which we sit around and eat lunch was full of miscellaneous screws, heat sinks, empty drive trays, shredded bubble wrap, etc. but not anymore.

- Matt

Hi Matt,

Please, is it possible to place a post in read only where you can write the evolution of the situation ???

Everyone write and have suggestion. Very nice. It show how many persons support you. But I am sure there are a lot of people who only are interrested about the evolution. I mean, recept, start, test, integration of the new.. I fact ONLY technical news !!!

I have not the time to read all the discussion. My team and me are only interrested about the technical situation. There are other forums to discuss !!!
I hope you will find the time to read this. and act it

We are with you and all the team

---

Please, is it possible to place a post in read only where you can write the evolution of the situation ???

You could always read his posts and ignore the rest.

---

...from wherever SUN is at...

Milky way?

:-)

---

It is SEXY to DONATE!
Skype = demiurg2