But overall, in general, if you're doing a fair bit of work everyday, the RAC should be an upward trend ? :-)

It should trend gradually upwards, towards something close to your daily work rate. But we usually reckon it takes a month to six weeks to get there.

I've only been a member 2 days ...it should all be recent :-D lol

Thank you guys :-)

Your RAC won't level out for 2-3 months yet.

Cheers.

I notice some work pending validation has been sent to computers that've never done any work :P I'm guessing that I'll have to wait until the deadline expires before it is sent to someone else, or would that lose the work ? sorry for another question :-)

Yes it'll be sent out again to someone else and you'll just have to wait for the credit.

Cheers.

Yes it'll be sent out again to someone else and you'll just have to wait for the credit.

Cheers.

Thanks Wiggo :-)

As far as I can remember, ntpckr isn't running because when it does, it brings the DB crying to its knees and basically the entire project comes to a screeching halt. The queries that are involved require a lot of I/O (I don't recall if hardware or software... both of which the DB still currently has some issues with, which is the reason for the server-side "tasks in progress" limits).

I, among others, have suggested taking one of the weekly DB backups and putting that backup on an isolated machine and let ntpckr chew on that for a few months to get caught up. Then update that DB with a recent backup and let ntpckr chew through the new data for a while until it gets caught-up again. Maybe do that one more time, and then it should be able to run live in "near real time" as it has in its name.

That's my understanding on that, at least.

---

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

As far as I can remember, ntpckr isn't running because when it does, it brings the DB crying to its knees and basically the entire project comes to a screeching halt. The queries that are involved require a lot of I/O (I don't recall if hardware or software... both of which the DB still currently has some issues with, which is the reason for the server-side "tasks in progress" limits).

I, among others, have suggested taking one of the weekly DB backups and putting that backup on an isolated machine and let ntpckr chew on that for a few months to get caught up. Then update that DB with a recent backup and let ntpckr chew through the new data for a while until it gets caught-up again. Maybe do that one more time, and then it should be able to run live in "near real time" as it has in its name.

That's my understanding on that, at least.

Can't be quite right. The ntpckr will be chewing over the science database - every result ever received - which is HUGE.

The weekly backups - and the server "tasks in progress" limits - are for the BOINC database, which is for the fast-moving transactional stuff. Everything of interest is dropped from that after 24 hours - after having been assimilated into the science database, of course.

I think it was mostly the sheer size of the science database which stalled the ntpckr when they tried it - you simply need something with the resources of Google to access and process that much data in real time.

As far as I can remember, ntpckr isn't running because when it does, it brings the DB crying to its knees and basically the entire project comes to a screeching halt. The queries that are involved require a lot of I/O (I don't recall if hardware or software... both of which the DB still currently has some issues with, which is the reason for the server-side "tasks in progress" limits).

I, among others, have suggested taking one of the weekly DB backups and putting that backup on an isolated machine and let ntpckr chew on that for a few months to get caught up. Then update that DB with a recent backup and let ntpckr chew through the new data for a while until it gets caught-up again. Maybe do that one more time, and then it should be able to run live in "near real time" as it has in its name.

That's my understanding on that, at least.

Can't be quite right. The ntpckr will be chewing over the science database - every result ever received - which is HUGE.

The weekly backups - and the server "tasks in progress" limits - are for the BOINC database, which is for the fast-moving transactional stuff. Everything of interest is dropped from that after 24 hours - after having been assimilated into the science database, of course.

I think it was mostly the sheer size of the science database which stalled the ntpckr when they tried it - you simply need something with the resources of Google to access and process that much data in real time.

Ah. Okay. I guess I had some misinterpretations somewhere along the line.

In any case, If they're working on some DB stuff such as breaking it up into tables, why couldn't ntpckr just deal with one single table at a time and then make a list of things it finds interesting, and then when the next table is loaded, continue adding to the list of interesting things, and so on. Once it has chewed through everything, go through the list and make comparisons and consolidate the list a bit and there's your list of interesting things to look at more-closely.

But the second part of my aforementioned idea still works.. once the backlog has been analyzed, it should be able to keep up in near real time. I wouldn't think that it would have to completely start over with every new result that comes in. So.. the hurdle at the moment for ntpckr is chewing through the backlog.

---

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