Work fetch anomaly

No, not CUDA - relax: this is a nice boring 2.0GHz P4, single core, SSE2 workhorse running BOINC v5.10.13 (as it has for years).

Just spotted this sequence of messages from yesterday:

Hi , yes that is quite optimistic and maybe 1 of the reasons, why BOINC 6.4.5. is written.
I now use it more then 1 month and it is quite realistic about the amount off work to fetch. The cache setting seems to be less influential.
Although a get quite a lot of AP WU's, it never ran out of work or gave me to much, so I won't make the deadline, or goes into High Priority Mode.

____________


Knight Who Says Ni N!, OUT numbered.................

So the SETI server thinks my humble P4 can do 5 Astropulse tasks and 4 MB tasks in 69 seconds, all on a single core shared with Einstein????? Boincview has it calculated as a more realistic 25 days. And I only asked for 1 day.

Raistmer and Jason, help! My P4 needs you....

So the SETI server thinks my humble P4 can do 5 Astropulse tasks and 4 MB tasks in 69 seconds, all on a single core shared with Einstein????? Boincview has it calculated as a more realistic 25 days. And I only asked for 1 day.

Raistmer and Jason, help! My P4 needs you....

Can you look into your client_state.xml and let us know what the duration correction factor is for SETI?

Hmmmm...

Well, the metrics look good, although I would have expected them to be a little closer to my Northie 2.66 benchmark wise.

So I'm going to have to say that since the request was appropriate for the host, the project grossly screwed up in calculating how many aggregate tasks that represented for some reason. After all, it's the one which makes that determination. ;-)

Makes a good argument for why carrying a whopping big cache can be a bad idea though. :-D

Alinator

Sorry, should have posted a link for the host: 1791152. Yep, that creation date of 26 Nov 2005 14:22:39 UTC is absolutely genuine - it was one of the first hosts I migrated from Classic, when I got the closedown circular. I actually gave it a bit of a spring-clean last weekend, upgraded the RAM from 512MB to 1GB (first hardware upgrade since I bought it), and finally got round to installing SP3 for XP. Not that that would make any difference.

So the SETI server thinks my humble P4 can do 5 Astropulse tasks and 4 MB tasks in 69 seconds, all on a single core shared with Einstein????? Boincview has it calculated as a more realistic 25 days. And I only asked for 1 day.

Raistmer and Jason, help! My P4 needs you....

Can you look into your client_state.xml and let us know what the duration correction factor is for SETI?

<time_stats>
<on_frac>0.994240</on_frac>
<connected_frac>-1.000000</connected_frac>
<active_frac>0.999917</active_frac>
<cpu_efficiency>0.919307</cpu_efficiency>
<last_update>1232056125.233749</last_update>
</time_stats>

efficiency is low because this is my BoincView logger, primary browser, email client - heavy use daily driver. All normal.

SETI DCF is 0.190565 (client_state), 0.1906 (BV) - absolutely normal (I tend to run one optimisation step beyond current release, as part of Lunatics testing program)

Einstein has 16-18 hours still to run on new S5R5, but looks normal. No extra WUs cached - I think I'd better stop work fetch on both projects while this lot work through. Einstein fetched that task lunchtime yesterday (14/01/2009 12:12:56|Einstein@Home|Requesting 11 seconds of new work), and started it lunchtime today (15/01/2009 13:28:48|Einstein@Home|Starting task h1_0589.80_S5R4__701_S5R5a_1 using einstein_S5R5 version 301) - exactly in line with my 1-day cache setting.

As you might guess, I know this system very well indeed, and I've always known what to expect from BOINC running on it. This event is outside all previous experience, and it happened while I was asleep in bed - missed all the fun, darn it!

And before anyone asks, no, it isn't running in high priority (EDF) - just quietly getting on with things, exactly as BOINC should.

Simply put, connected_frac was broken through at least 5.10.38. As far as I know, it still doesn't work.

In any event, I don't see what effect it should have for a CPU intensive project, although I would guess it would spoff a network intensive one pretty well.

Alinator

Maybe it's just me, but the "connected frac" looks really odd. Shouldn't it be between 0 and 1, not less than zero??

Maybe it's just me, but the "connected frac" looks really odd. Shouldn't it be between 0 and 1, not less than zero??

connected_frac = -1 means "I don't know how often you're connected". This AFAIK depends on how you're connected to the net, and your OS. If not mis-remembers, it's always shown only -1 for me, atleast upto v5.10.45. No idea on v6...