[quote][quote]that was sorted late last year

I am running 6.10.58 on all 8 rigs, and I seem to recall that everything worked out OK the last time we had an outage of this magnitude.

I am on 6.10.58 so will hold off upgrading, will see how it goes.

Kevin

---

Kevin

I'm thinking that was back around 6.10.47 plus something was tweaked server side a year ago. Sorry I don't remember much more and don't have any records.

Any ideas as to how much longer this outage is going to last? No updates on the technical new thread. I still have work for another day or so.
______________

My guess is right before they take it down for the Tuesday 3 day outage.
But I'm an optimist. OTOH, when and if I run out of Seti work, I still have
Milkyway, Einstein, Rosetta, Docking, Enigma, and others to crunch.

I'm guessing sometime Monday work-hours UT-0800.

...No updates on the technical new thread...

Message 1075931 - Posted: 10 Feb 2011 | 22:13:48 UTC:

Meanwhile, we'll be off for the foreseeable future. Like at least until next week, I imagine. Bummer.

Looks like an (actual) update to me. ;-)

Gruß,
Gundolf

My guess is well after the coming Tuesday outage. They will not get it up on Monday, that I'm sure about. On Tuesday is outage day, so Tuesday is not the day. With some luck it will happen of Wednesday, but even that is doubtful. I even doubt it will happen at all the coming week.

Don't be surprised if it doesn't happen until earliest Monday Jan 21. It may even take longer, yeah much much longer.....

Edit: It may even be so, that it doesn't happen at all, ever again.....

Monday 21 Jan is a Federal Holiday here in the US (President's Day), so they probably won't work that day, either. So if we are not fixed and back up by Friday 18th, hope for Tuesday 22nd or Wednesday 23rd.

But sooner or later, Matt & company WILL succeed in getting everything back online, at least for a day or two (or more). (8{)

---

Donald
Infernal Optimist / Submariner, retired

that was sorted late last year
I am running 6.10.58 on all 8 rigs, and I seem to recall that everything worked out OK the last time we had an outage of this magnitude.

I am on 6.10.58 so will hold off upgrading, will see how it goes.

Kevin

IIRC, Vyper was the first that drew more attention to this question and the issue is resolved thanks to Jord and Dr D.A. His rig was running 6.10.56 back then, as it is running now. Check... Manually uploading client_state.xml to s@h

---

Who the hell is General Failure and why is he reading my harddisk?¿

I wanted to give a valentine's day gift to my crunchers by showering them with lots of work units. Alas, that wont happen.
______________

IIRC, Vyper was the first that drew more attention to this question and the issue is resolved thanks to Jord and Dr D.A. His rig was running 6.10.56 back then, as it is running now. Check... Manually uploading client_state.xml to s@h

That takes us to changeset [trac]changeset:22389[/trac], which only affected the server code:

scheduler: fix crashing bug when client reports a large # (1000+) of results (256KB not enough for query in this case)

That happened round about client v6.11.8, so if nobody has suffered the problem since then - without upgrading - I think we can take it that a client upgrade won't be needed this time either.

that was sorted late last year
I am running 6.10.58 on all 8 rigs, and I seem to recall that everything worked out OK the last time we had an outage of this magnitude.

I am on 6.10.58 so will hold off upgrading, will see how it goes.

Kevin

IIRC, Vyper was the first that drew more attention to this question and the issue is resolved thanks to Jord and Dr D.A. His rig was running 6.10.56 back then, as it is running now. Check... Manually uploading client_state.xml to s@h

Thanks. I looked for that thread for a while, but did not locate it.
I am not sure what version of Boinc I was running at the time, but everything was handled without manual intervention on my part.

---

"Time is simply the mechanism that keeps everything from happening all at once."

Don't be surprised if it doesn't happen until earliest Monday Jan 21. It may even take longer, yeah much much longer.....
/quote]

[quote]Monday 21 Jan is a Federal Holiday here in the US (President's Day), so they probably won't work that day, either. So if we are not fixed and back up by Friday 18th, hope for Tuesday 22nd or Wednesday 23rd.

I hope you both mean February 21st.

---

Don't be surprised if it doesn't happen until earliest Monday Jan 21. It may even take longer, yeah much much longer.....
/quote]

[quote]Monday 21 Jan is a Federal Holiday here in the US (President's Day), so they probably won't work that day, either. So if we are not fixed and back up by Friday 18th, hope for Tuesday 22nd or Wednesday 23rd.

I hope you both mean February 21st.

Could do with it earlier than that, got a bunch of shorties just before this started, 17/02/2011 is the earliest, some are done and some are still in my download queue, would be a shame to see them go to waste.

Kevin

---

Kevin

IIRC, Vyper was the first that drew more attention to this question and the issue is resolved thanks to Jord and Dr D.A. His rig was running 6.10.56 back then, as it is running now. Check... Manually uploading client_state.xml to s@h

That takes us to changeset [trac]changeset:22389[/trac], which only affected the server code:

scheduler: fix crashing bug when client reports a large # (1000+) of results (256KB not enough for query in this case)

That happened round about client v6.11.8, so if nobody has suffered the problem since then - without upgrading - I think we can take it that a client upgrade won't be needed this time either.

And if you scroll down to the last post, you'll find out, that there was also a client change in v6.12.2, which made it possible to limit the # of completed tasks reported per RPC. However, it seems that this change is mostly intended for those who get problems caused by slow internet connection.

---

IIRC, Vyper was the first that drew more attention to this question and the issue is resolved thanks to Jord and Dr D.A. His rig was running 6.10.56 back then, as it is running now. Check... Manually uploading client_state.xml to s@h

That takes us to changeset [trac]changeset:22389[/trac], which only affected the server code:

scheduler: fix crashing bug when client reports a large # (1000+) of results (256KB not enough for query in this case)

That happened round about client v6.11.8, so if nobody has suffered the problem since then - without upgrading - I think we can take it that a client upgrade won't be needed this time either.

And if you scroll down to the last post, you'll find out, that there was also a client change in v6.12.2, which made it possible to limit the # of completed tasks reported per RPC. However, it seems that this change is mostly intended for those who get problems caused by slow internet connection.

Josef Segur reported problems with the way that was originally coded in changeset [trac]changeset:22467[/trac]. I rather doubt that anyone has tested it to destruction yet....

Corrections were made (22500, 22503, 22505.....), but if anyone has the courage, and the reportable task list, to test, I'm sure that would be appreciated. ;)

IIRC, Vyper was the first that drew more attention to this question and the issue is resolved thanks to Jord and Dr D.A. His rig was running 6.10.56 back then, as it is running now. Check... Manually uploading client_state.xml to s@h

That takes us to changeset [trac]changeset:22389[/trac], which only affected the server code:

scheduler: fix crashing bug when client reports a large # (1000+) of results (256KB not enough for query in this case)

That happened round about client v6.11.8, so if nobody has suffered the problem since then - without upgrading - I think we can take it that a client upgrade won't be needed this time either.

And if you scroll down to the last post, you'll find out, that there was also a client change in v6.12.2, which made it possible to limit the # of completed tasks reported per RPC. However, it seems that this change is mostly intended for those who get problems caused by slow internet connection.

Josef Segur reported problems with the way that was originally coded in changeset [trac]changeset:22467[/trac]. I rather doubt that anyone has tested it to destruction yet....

Corrections were made (22500, 22503, 22505.....), but if anyone has the courage, and the reportable task list, to test, I'm sure that would be appreciated. ;)

Right now, the Frozen 920 has 3,149 results it would like to report.

---

"Time is simply the mechanism that keeps everything from happening all at once."

Since the server side "fix" [22389] and any subsequent tweaks i have on several occasions due to outages or network issues, my end, reported well above a 1000 results in one go

usually in the 1-3k range, without any problem

basically it takes the first 1000 results and leaves the remainder for reporting next time etc - still has to upload the whole file though

this is on hosts with the 6.10.58 client

i dont think i am alone in this as Mark and anybody in the top 100+ will probably have used this feature a time or two already even if they have not seen it happen

as i was lucky(?) enough to have a full cache just prior to this outage i will be reporting just under 4000 tasks as an when we get going again - although i intend to leave it a day or so before i report after we come back up to ease the strain in a small way

the newer client may well have extra features to control this which is good as it probably will stress the servers less if we can limit the number reported in one go

---

Tim

Just for to tell..

The 1.000 results split was on the server. No specially BOINC needed. It can be on/off, depend of the S@h crew. I don't know if this is now on.

I had always probs to report > ~ 1.000 results.

I was in contact with Dr. Anderson and he asked Rom to add <max_tasks_reported>N</max_tasks_reported> to the client (cc_config.xml).

I updated today to the last DEV-V6.12.14 of BOINC (because my 940 BE + 4x GTX260 have thousands of results ULed) and it work fine. But to now no well S@h scheduler contact.. ;-)

---

It would be nice to be able to tell a Fermi card to run 2 or 3 WU's per gpu while having an older card do 1 WU per gpu at a time.

---

Savoir-Faire is everywhere!
The T1 Trust, T1 Class 4-4-4-4 #5550, America's First HST

Don't be surprised if it doesn't happen until earliest Monday Jan 21. It may even take longer, yeah much much longer.....

Monday 21 Jan is a Federal Holiday here in the US (President's Day), so they probably won't work that day, either. So if we are not fixed and back up by Friday 18th, hope for Tuesday 22nd or Wednesday 23rd.

I hope you both mean February 21st.

Yes, arkayn, you are correct, as usual. Hadn't had my 2nd cup of coffee yet.

---

Donald
Infernal Optimist / Submariner, retired