Yes...but why did you say 'Burma'?

Who did?

Well all I can say if anyone is still having problems ATM then its your bad lack. :D

My 3 have been going through the cycles without any problems the last few days and still maintaining their caches after they were all drained last week for updating.

Cheers.

---

Doesn't look like the replica is gaining any ground. Still just over 200,000 seconds behind.

Matt is right.. there's something fishy going on there. There's no reason on a hardware level that the replica can't keep up.

---

Linux laptop:
record uptime: 1511d 20h 19m (ended due to the power brick giving-up)

http://setiathome.berkeley.edu/workunit.php?wuid=753788639

The 1st not, so a 3rd WU was sent out.
But in the meantime the 1st result came (2 Jul 2011 - 6:11:09 UTC)

You are right. I did misinterprid.

But mine should not have started on July 8, it should have been deleted before my machine startedto crunch this one, for there were already two retults validated.

The second host already reported late.
Deadline was 27 june so it was sent to third host.
But the second returned before you did and got credits already.

It could srill be you get credits for it.

Look again. ;-)

The 2nd result came in time.

Name ap_02ap11ae_B4_P0_00026_20110601_16835.wu_0
Arbeitspaket 753788639
Erstellt 2 Jun 2011 | 0:29:01 UTC
Gesendet 2 Jun 2011 | 4:26:56 UTC
Empfangen 2 Jul 2011 | 6:11:09 UTC
Serverstatus Abgeschloßen
Resultat Erfolgreich
Clientstatus Fertig
Endstatus 0 (0x0)
Computer ID 5541162
Ablaufdatum 27 Jun 2011 | 4:26:56 UTC

The first both WUs had the deadline 27 Jun 2011 - 4:26:56 UTC.

If I follow the URL the upper (I said 1st) result came:
ap_02ap11ae_B4_P0_00026_20110601_16835.wu_0
2 Jul 2011 - 6:11:09 UTC
..the middle result (I said 2nd) came:
ap_02ap11ae_B4_P0_00026_20110601_16835.wu_1
13 Jun 2011 - 17:24:07 UTC

So the 2nd WU/result came in time.

I count the WU/results because of the end of the name, this is the same as from up to down in the overview.

You count in the order in which the results was sent back.

;-)


- Best regards! - Sutaru Tsureku, team seti.international founder. - Optimize your PC for higher RAC. - SETI@home needs your help. -

---

Doesn't look like the replica is gaining any ground. Still just over 200,000 seconds behind.

Matt is right.. there's something fishy going on there. There's no reason on a hardware level that the replica can't keep up.

Not really fishy... the MB assimilartors are catching up pretty good, that's additional load on the database. We have now reached the point, when assimilated results are purged from database at the speed they were assimilated, and that was faster than usual, i.e. without backlog of over 1000000. And than for the last few hours we were returning around 80000 results per hour. So already the fact, that it's not falling more behind like it did sometimes in the past under even less heavy load is IMO a good thing.

---

Welcome back!

Meowza!

---

"Freedom is just Chaos, with better lighting." Alan Dean Foster

Phew! Was really getting worried this time wb all :-)

---

Ok, where did everybody go? And why wasn't I invited? :-)

---

PROUD MEMBER OF Team Starfire World BOINC

Checking my bp...should be getting back to normal now....Lt

I almost panicked.

---

Goodbye Seti Classic

I didn't panic---quite.
I was a bit worried though. It's not often the server crashes take the forums down with them.

---

"Freedom is just Chaos, with better lighting." Alan Dean Foster

And, Hmmmmmmmm.....
They're splitting AP work again.
Hopefully that's a sign some progress has been made on the AP issues, and not just an oversight when bringing the servers back online.

---

"Freedom is just Chaos, with better lighting." Alan Dean Foster

And, Hmmmmmmmm.....
They're splitting AP work again.
Hopefully that's a sign some progress has been made on the AP issues, and not just an oversight when bringing the servers back online.

Yeah, now if they could just do something with those 69k+ workunits awaiting validation we might get somewhere.

---

PROUD MEMBER OF Team Starfire World BOINC

One of the download servers appears to still be down.
Most of my downloads time out as soon as they start.

---

Grant
Darwin NT

Yes...but why did you say 'Burma'?

I panicked.

---

Yes...but why did you say 'Burma'?

I panicked.

[BSM Williams voice on]
I will not have panicking in my jungle!
[BSM Williams voice off]

"Shoulders back, lovely boy".

---

That was a bit of a panicky moment there lads. But a stiff upper lip, and a cup of tea, helped in the meantime :).

Well, it is gaining ground, but slowly. On 8 Jul 2011, 22:21:59 UTC it was 71 hours behind, now it is something like 59 hours behind.

It's going painfully slow though, so something fishy is going on. Maybe all the slowness and problems we have, not only with the replica, but with many other services, is because we have so many results in the different databases now, that we are reaching the limits of what the current database software, and hardware, can handle in real time.

I know it has gained some ground, but now since I've been paying attention to it, over the past ~36 hours, it is still sitting at 211,000 seconds behind. Hasn't gained or lost any ground.

Not really fishy... the MB assimilartors are catching up pretty good, that's additional load on the database. We have now reached the point, when assimilated results are purged from database at the speed they were assimilated, and that was faster than usual, i.e. without backlog of over 1000000. And than for the last few hours we were returning around 80000 results per hour. So already the fact, that it's not falling more behind like it did sometimes in the past under even less heavy load is IMO a good thing.

I do understand there's a lot of stress on the database(s), but the replica should be able to keep up with the master. The master does most of the work, and the replica just has to copy the changes. Aside from certain things like the tasks pages usually coming from the replica rather than the master, the apparent lack of performance doesn't add up when you look at the hardware being nearly identical between the two. This implies some kind of software limitation, assuming there are no issues with the hardware.

---

Linux laptop:
record uptime: 1511d 20h 19m (ended due to the power brick giving-up)

Well, it is gaining ground, but slowly. On 8 Jul 2011, 22:21:59 UTC it was 71 hours behind, now it is something like 59 hours behind.

It's going painfully slow though, so something fishy is going on. Maybe all the slowness and problems we have, not only with the replica, but with many other services, is because we have so many results in the different databases now, that we are reaching the limits of what the current database software, and hardware, can handle in real time.

I know it has gained some ground, but now since I've been paying attention to it, over the past ~36 hours, it is still sitting at 211,000 seconds behind. Hasn't gained or lost any ground.

Not really fishy... the MB assimilartors are catching up pretty good, that's additional load on the database. We have now reached the point, when assimilated results are purged from database at the speed they were assimilated, and that was faster than usual, i.e. without backlog of over 1000000. And than for the last few hours we were returning around 80000 results per hour. So already the fact, that it's not falling more behind like it did sometimes in the past under even less heavy load is IMO a good thing.

I do understand there's a lot of stress on the database(s), but the replica should be able to keep up with the master. The master does most of the work, and the replica just has to copy the changes. Aside from certain things like the tasks pages usually coming from the replica rather than the master, the apparent lack of performance doesn't add up when you look at the hardware being nearly identical between the two. This implies some kind of software limitation, assuming there are no issues with the hardware.

Jocelyn is not almost the same spec as Carolyn. Jocelyn is a 2004-2005 model sun server Carolyn is from 2010 so 5-6 years younger with over 3X the memory of Jocelyn. I say be glad it handes even 1/4 th the amount Carolyn does. The project only has 3 modern servers Carolyn, Oscar and Synergy all the others run from3-10 years old. That is Ancient in terms of server hardware and for the most part functionally obsolescent but we keep using them in many case because we can't afford to replace them.

Edit to add Carolyn has 8 CPU cores and Jocelyn has 4 CPUs ( 4 cores one per chip). So looking at 1/2 the # cores on older slower chip architecture so don't tell me they are almost the same.

---

I guess when Jeff upgraded MySQL on Jocelyn to the latest stable version Friday he was hoping that would make a significant improvement. If the lag had kept dropping as it did for the first day it would be below 150000 seconds by now. At least there haven't been any big backsteps, and Jeff probably has additional plans if the other servers will give him time to try them.

                                                                  Joe

Jocelyn is not almost the same spec as Carolyn. Jocelyn is a 2004-2005 model sun server Carolyn is from 2010 so 5-6 years younger with over 3X the memory of Jocelyn. I say be glad it handes even 1/4 th the amount Carolyn does. The project only has 3 modern servers Carolyn, Oscar and Synergy all the others run from3-10 years old. That is Ancient in terms of server hardware and for the most part functionally obsolescent but we keep using them in many case because we can't afford to replace them.

Edit to add Carolyn has 8 CPU cores and Jocelyn has 4 CPUs ( 4 cores one per chip). So looking at 1/2 the # cores on older slower chip architecture so don't tell me they are almost the same.

My bad.. I was thinking carolyn and oscar were still operating as master and replica. I guess I didn't pay any attention to recent configurations.

In that case.. I can easily see why jocelyn can't keep up. She was the best server we had before the new ones arrived, and is why new servers were acquired.

Unrelated: [/panic] Almost ran out of "ready to start" tasks in my cache. One request granting 14 APs averted that crisis.

---

Linux laptop:
record uptime: 1511d 20h 19m (ended due to the power brick giving-up)