Why are the claimed credit scores much lower per machine now compared to before the big crash?

They're sending out many shorter (smaller) workunits, that's why you're getting less credits than usually. Although, I wouldn't say they're much lower (45-55 credits), and for example in my case, it's about a 1:1 ratio of "normal length" (67.xx credits) and shorter WUs.

You say their smaller WU.s but if thats the case why are they still taking as long to process as the WU.s before the outage in my case for a WU of say 2hrs getting 67credits before but now only getting say 27credits?

Why are the claimed credit scores much lower per machine now compared to before the big crash?

They're sending out many shorter (smaller) workunits, that's why you're getting less credits than usually. Although, I wouldn't say they're much lower (45-55 credits), and for example in my case, it's about a 1:1 ratio of "normal length" (67.xx credits) and shorter WUs.

You say their smaller WU.s but if thats the case why are they still taking as long to process as the WU.s before the outage in my case for a WU of say 2hrs getting 67credits before but now only getting say 27credits?

That's normal for the low credit WUs. On my quad rig, a 'normal' 67 pointer will crunch in about 52 minutes, but the low credit or noisy WUs will usually take 40-45 minutes to crunch. Almost as much time, but much lower credit.

---

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

Has anyone else noticed a reduction in their cache? I had mine set to 4.5 days on "Computer is connected to the Internet about every" x.x "days", and (after noticing that I wasn't getting my usual quota of work!) found that I'd been reset to 0.1 days! That isn't how often I connect to the net, (I'm on dial-up) and I need a larger cache than that, as I run a dual-core AMD Opteron...

If this is related to the splitter's woes, please tell me...

---

.

Hello, from Albany, CA!...

Has anyone else noticed a reduction in their cache? I had mine set to 4.5 days on "Computer is connected to the Internet about every" x.x "days", and (after noticing that I wasn't getting my usual quota of work!) found that I'd been reset to 0.1 days! That isn't how often I connect to the net, (I'm on dial-up) and I need a larger cache than that, as I run a dual-core AMD Opteron...

If this is related to the splitter's woes, please tell me...

Did you notice that the general preferences has changed?
There's now two settings:

Computer is connected to the Internet about every
(Leave blank or 0 if always connected.
BOINC will try to maintain at least this much work.)

And:

Maintain enough work for an additional
(Requires 5.10+ client.)

My cache setting (i think) was on the second one, & i wasn't
getting a lot of work, (i think i still had Astropulse stuff to report on Beta)
i've moved it to the first one & i think it's a bit better now, try it,
It might be better.

Claggy.

---

Different path, different "optimium."

Error rates now are much much better than 1 in 30,000, maybe this was the case using a modem, but who still uses modems now? :-)
Anyway, this can be dealt with using adaptive MTU, and/or using recoverable ECC which can recover a packet from one or maybe two bit errors like audio CDs do.
I'm sure there's room in TCP to be able to handle these...

I chose an error rate of 1 in 30,000 bits because every 64k packet would likely have two errors in it. It is an example of how a pretty low error rate (0.03%) can be pretty awful as packet size gets larger.

When we're talking about TCP, one thing that comes along with that is that the checksum on the packet has to be right, or the packet has to be retried. If there is a one bit error, that changes the checksum.

It is possible to do ECC, or even tolerate some errors, but not using TCP. You have to run UDP if you want to do that -- and layer your own error detection and/or error correction on top of that.

There is also nothing in the IP protocol that says we can't develop new protocols. Most of the time, when we say TCP/IP, we really mean the whole IP suite, and sometimes we really mean TCP running over IP. There is UDP/IP, and ICMP/IP, and GRE/IP and a few others.

---

Has anyone else noticed a reduction in their cache? I had mine set to 4.5 days on "Computer is connected to the Internet about every" x.x "days", and (after noticing that I wasn't getting my usual quota of work!) found that I'd been reset to 0.1 days! That isn't how often I connect to the net, (I'm on dial-up) and I need a larger cache than that, as I run a dual-core AMD Opteron...

If this is related to the splitter's woes, please tell me...

There are a lot of the 4 day deadline WUs being sent out. If your machine gets any of those, and if you have your "connect" setting larger than about 1, BOINC will go into panic mode and not download any more until all short WUs have been completed. Then it will download more, probably get some more short WUs, and go back into panic mode. Lather rinse repeat.

To see the largest connect setting you can use without causing panic mode, look at the chart on this page:

http://boinc-wiki.ath.cx/index.php?title=Work_Buffer

If you want a larger queue, then upgrade to 5.9.*, set your "connect" to .5 days, and your "additional" to 4. Warning: using "additional" may cause some WUs to be returned after the deadline...but I haven't had that happen yet. I use .1, and 5.

---

Dublin, California
Team: SETI.USA

Has anyone else noticed a reduction in their cache? I had mine set to 4.5 days on "Computer is connected to the Internet about every" x.x "days", and (after noticing that I wasn't getting my usual quota of work!) found that I'd been reset to 0.1 days! That isn't how often I connect to the net, (I'm on dial-up) and I need a larger cache than that, as I run a dual-core AMD Opteron...

If this is related to the splitter's woes, please tell me...

Did you notice that the general preferences has changed?
There's now two settings:

Computer is connected to the Internet about every
(Leave blank or 0 if always connected.
BOINC will try to maintain at least this much work.)

And:

Maintain enough work for an additional
(Requires 5.10+ client.)

My cache setting (I think) was on the second one, & I wasn't
getting a lot of work, (I think I still had Astropulse stuff to report on Beta)
I've moved it to the first one & I think it's a bit better now, try it,
It might be better.

Claggy.

Mine was on the first, and I re-set it to 4.5 (and got a lot more work)... I think it got reset when the team added the second line...

"requires 5.10+"? even boinc alpha is only on 5.9!(.12) So far, there isn't a 5.10 client...

---

.

Hello, from Albany, CA!...

Has anyone else noticed a reduction in their cache? I had mine set to 4.5 days on "Computer is connected to the Internet about every" x.x "days", and (after noticing that I wasn't getting my usual quota of work!) found that I'd been reset to 0.1 days! That isn't how often I connect to the net, (I'm on dial-up) and I need a larger cache than that, as I run a dual-core AMD Opteron...

If this is related to the splitter's woes, please tell me...

Did you notice that the general preferences has changed?
There's now two settings:

Computer is connected to the Internet about every
(Leave blank or 0 if always connected.
BOINC will try to maintain at least this much work.)

And:

Maintain enough work for an additional
(Requires 5.10+ client.)

My cache setting (I think) was on the second one, & I wasn't
getting a lot of work, (I think I still had Astropulse stuff to report on Beta)
I've moved it to the first one & I think it's a bit better now, try it,
It might be better.

Claggy.

Mine was on the first, and I re-set it to 4.5 (and got a lot more work)... I think it got reset when the team added the second line...

"requires 5.10+"? even boinc alpha is only on 5.9!(.12) So far, there isn't a 5.10 client...

It was explained to me that the 5.9XX client is the same as 5.10xx, but it is in beta or pre-release status. It will be renumbered 5.10xx when it is considered stable enough to become the general release. So it seems that the 'additional' cache setting may be active in the 5.9.12 currently in testing.

---

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

Has anyone else noticed a reduction in their cache? I had mine set to 4.5 days on "Computer is connected to the Internet about every" x.x "days", and (after noticing that I wasn't getting my usual quota of work!) found that I'd been reset to 0.1 days! That isn't how often I connect to the net, (I'm on dial-up) and I need a larger cache than that, as I run a dual-core AMD Opteron...

If this is related to the splitter's woes, please tell me...

There are a lot of the 4 day deadline WUs being sent out. If your machine gets any of those, and if you have your "connect" setting larger than about 1, BOINC will go into panic mode and not download any more until all short WUs have been completed. Then it will download more, probably get some more short WUs, and go back into panic mode. Lather rinse repeat.

To see the largest connect setting you can use without causing panic mode, look at the chart on this page:

http://boinc-wiki.ath.cx/index.php?title=Work_Buffer

If you want a larger queue, then upgrade to 5.9.*, set your "connect" to .5 days, and your "additional" to 4. Warning: using "additional" may cause some WUs to be returned after the deadline...but I haven't had that happen yet. I use .1, and 5.

You do realize that the 5.9.xx clients are still being tested? The recommended version of BOINC is still 5.8.16, AFAIK.

Yes, I'm aware of the "wide AR WU" problem - that hasn't changed since before the blackout - and doesn't explain why my cache setting would be changed without my knowledge. The better solution to the "wide AR WU" problem is to set the minimum deadline for them to something just beyond the EDF BOINC setting, which has to be done by the SETI staff. EDF (see next) I can deal with... (right now I'm in EDF for some long-running Einstein WU's)

(that's "Earliest Deadline First", which seems to be the preffered terminology for what you termed "panic mode".)

---

.

Hello, from Albany, CA!...

Has anyone else noticed a reduction in their cache? I had mine set to 4.5 days on "Computer is connected to the Internet about every" x.x "days", and (after noticing that I wasn't getting my usual quota of work!) found that I'd been reset to 0.1 days! That isn't how often I connect to the net, (I'm on dial-up) and I need a larger cache than that, as I run a dual-core AMD Opteron...

If this is related to the splitter's woes, please tell me...

Did you notice that the general preferences has changed?
There's now two settings:

Computer is connected to the Internet about every
(Leave blank or 0 if always connected.
BOINC will try to maintain at least this much work.)

And:

Maintain enough work for an additional
(Requires 5.10+ client.)

My cache setting (I think) was on the second one, & I wasn't
getting a lot of work, (I think I still had Astropulse stuff to report on Beta)
I've moved it to the first one & I think it's a bit better now, try it,
It might be better.

Claggy.

Mine was on the first, and I re-set it to 4.5 (and got a lot more work)... I think it got reset when the team added the second line...

"requires 5.10+"? even boinc alpha is only on 5.9!(.12) So far, there isn't a 5.10 client...

It was explained to me that the 5.9XX client is the same as 5.10xx, but it is in beta or pre-release status. It will be renumbered 5.10xx when it is considered stable enough to become the general release. So it seems that the 'additional' cache setting may be active in the 5.9.12 currently in testing.

Oh... The only place I have a 5.9 client (.10) is on the Win XP Pro x64 version that I dual-boot to, and the only project I run there is CDPN, where you only get WU's to equal your "cpu"'s (I'm running two WUs, as I have a dual-core...)

---

.

Hello, from Albany, CA!...

I chose an error rate of 1 in 30,000 bits because every 64k packet would likely have two errors in it. It is an example of how a pretty low error rate (0.03%) can be pretty awful as packet size gets larger.

0.03% would actually be a very high error rate for most transports. As a comparison, typical gigabit Ethernet bit error rates are between 1 in ten billion and 1 in a hundred billion bits.

...typical gigabit Ethernet bit error rates are between 1 in ten billion and 1 in a hundred billion bits.

doesn't sound like much at first does it. But that's approximately 1 bit error every 10 to 100 seconds at full capacity isn't it? One wonders what that does to a large database query...

---

"Living by the wisdom of computer science doesn't sound so bad after all. And unlike most advice, it's backed up by proofs." -- Algorithms to live by: The computer science of human decisions.

Well,

all my hosts can now up- and download as well as report, all pretty quickly. I haven't seen a scheduler request fail in a while since the recent network tweaks.

Work on Main has been steadily available, and is starting to flow on Beta as well. So thanks for getting the good ship SETI@Home back on an even keel!

Regards,
Simon.

OT: Jason, have you been taken by the Cylons? ;o) Reminds me, I should watch S3 of BS:G...

---

Donate to SETI@Home via PayPal!

Optimized SETI@Home apps + Information

...
OT: Jason, have you been taken by the Cylons? ;o) Reminds me, I should watch S3 of BS:G...

All Running sweet here. Glad they seemed to have cracked a few errors, Well Done Blokes :D and keep pedalling :D [ I tried a speedguide.net TCPOptimiser thingy the other day, for MTU to setiathome servers my cablemodem wants the full 1500, to which it was set happily]

LOL, Here in Oz BSG only just finished first season (& first rerun) on cable. Adama is full of lead :O didn't see that one coming

---

"Living by the wisdom of computer science doesn't sound so bad after all. And unlike most advice, it's backed up by proofs." -- Algorithms to live by: The computer science of human decisions.

Why are the claimed credit scores much lower per machine now compared to before the big crash?

They're sending out many shorter (smaller) workunits, that's why you're getting less credits than usually. Although, I wouldn't say they're much lower (45-55 credits), and for example in my case, it's about a 1:1 ratio of "normal length" (67.xx credits) and shorter WUs.

You say their smaller WU.s but if thats the case why are they still taking as long to process as the WU.s before the outage in my case for a WU of say 2hrs getting 67credits before but now only getting say 27credits?

That's normal for the low credit WUs. On my quad rig, a 'normal' 67 pointer will crunch in about 52 minutes, but the low credit or noisy WUs will usually take 40-45 minutes to crunch. Almost as much time, but much lower credit.

Didn`t realise there was any difference in the WU.s other than the size.Thanks for the answer,its the aliens that matter anyway.

You do realize that the 5.9.xx clients are still being tested? The recommended version of BOINC is still 5.8.16, AFAIK.

Of course. It says so in BIG RED LETTERS right there on the download page.

The better solution to the "wide AR WU" problem is to set the minimum deadline for them to something just beyond the EDF BOINC setting, which has to be done by the SETI staff. EDF (see next) I can deal with... (right now I'm in EDF for some long-running Einstein WU's)

Yep. I have said in the past that the minimum deadline should be 14 days. But until the projects does the right thing, this is the only way to work around it.

(that's "Earliest Deadline First", which seems to be the preffered terminology for what you termed "panic mode".)

Yeah, but I like "panic mode". It's much more descriptive, obvious even, and doesn't need to be explained over and over again.

---

Dublin, California
Team: SETI.USA

Yep. I have said in the past that the minimum deadline should be 14 days.

Why?
Shorter deadlines for shorter Work Units makes sense (or longer deadlines for Longer Work Units), especially for those that go into melt down if they do get their credit within a few minutes of claiming.

---

Grant
Darwin NT

I chose an error rate of 1 in 30,000 bits because every 64k packet would likely have two errors in it. It is an example of how a pretty low error rate (0.03%) can be pretty awful as packet size gets larger.

0.03% would actually be a very high error rate for most transports. As a comparison, typical gigabit Ethernet bit error rates are between 1 in ten billion and 1 in a hundred billion bits.

Over what distance, and through how many devices?

---

Yep. I have said in the past that the minimum deadline should be 14 days.

Why?
Shorter deadlines for shorter Work Units makes sense (or longer deadlines for Longer Work Units), especially for those that go into melt down if they do get their credit within a few minutes of claiming.

Because deadlines and connection intervals interact. If you set "connect every 10 days" and you get some 4 day WUs, you won't cache 10 days worth.

---

Yep. I have said in the past that the minimum deadline should be 14 days.

Why?
Shorter deadlines for shorter Work Units makes sense (or longer deadlines for Longer Work Units), especially for those that go into melt down if they do get their credit within a few minutes of claiming.

This is why: http://setiathome.berkeley.edu/forum_thread.php?id=39753&nowrap=true#576678

More specifically, the minimum deadline for any project should be 10 days + the shortest WU deadline length.

---

Dublin, California
Team: SETI.USA