Another new one to test.

REMINDER TO ALL ALPHA TESTERS:
It's far easier for us to fix problems if you send message logs with the appropriate flags set. The main flags are:

<cpu_sched_debug>: problems involving the choice of applications to run.
<work_fetch_debug>: problems involving work fetch (which projects are asked for work, and how much).
<rr_simulation>: problems involving jobs being run in high-priority mode.

Use these flags from the cc_config.xml file.

Report any problems you get with it to the Alpha email list. This list needs registration.

The offical change log:

- WINSETUP: Remove the 'SeDebugPrivilege' prev from the list of privs the installer sets for the BOINC client itself.

- MGR: Change the shortcut key for switching to the simple view.

- client: If an administrator has deployed proxy settings at runtime or during a VPN connection allow the client to read the new proxy configuration from the registry.

- MGR: Add View menu with Cmd+Shift+A to Mac Simple GUI for disabled users because Mac manager cannot eliminate menu bar or detect active screen reader. On Windows, manager prevents switch to Simple GUI if screen reader is active.

- WININSTALL: Abort install if Win9x detected

This is likely to become the official version next week unless "showstopper" bugs are found.

---

BOINC blog

Now its the "official" version. From the BOINC Alpha email list...

We are pleased to announce that 6.10 is now ready for public use.

This release of BOINC contains the following enhancements:

1. Support for ATI GPUs

2. Support for detecting proxy configurations within companies

3. Improvements to the CPU/GPU scheduler

4. A new default screen saver

I would like to thanks everybody who has used a pre-release version of 6.10 over the last couple of months, for providing feedback and helping us make the BOINC system even better.

Release Notes: Release_Notes

System Requirements: System_Requirements

Download: Download

----- Rom

BOINC Development Team

---

BOINC blog

I wonder if there is any chance to change the view "style" of credits? I mean - instead of 1234567 to show 1,234,567? it's way better visible :-)

---

Mark,

And one more thing. Recently I've got problem with RAM and took out 2 of 3 sticks from my rig and also I have to reduce timing from 7-7-7-24 to 9-9-9-30. I made CPU benchmarking and I was really surprised that the values it gives are pretty much the same. But in fact it takes 3h20m for a WU in POEM instead of 2h10m.

So, if there is any chance to make this benchmark more realistic?

---

Mark,

And one more thing. Recently I've got problem with RAM and took out 2 of 3 sticks from my rig and also I have to reduce timing from 7-7-7-24 to 9-9-9-30. I made CPU benchmarking and I was really surprised that the values it gives are pretty much the same. But in fact it takes 3h20m for a WU in POEM instead of 2h10m.

So, if there is any chance to make this benchmark more realistic?

Benchmarks are un-good for any number of reasons not the least of which you just demonstrated. Especially with today's systems the benchmark is likely to be run completely out of cache and even likely to be fully held in L1 cache no less ...

There have been complaints about this since BOINC Beta and solutions proposed ... there is even a new credit system being proposed by UCB though it is not fully developed yet and has a number of holes not the least of which is that it concentrates on single precision floating point as the be-all and end-all of the values that have to be tracked ... even when we have one project that is almost exclusively double precision and others that are pretty much integer based (meaning performance numbers of single precision systems are not relevant to the performance of that project's applications).

Mark,

And one more thing. Recently I've got problem with RAM and took out 2 of 3 sticks from my rig and also I have to reduce timing from 7-7-7-24 to 9-9-9-30. I made CPU benchmarking and I was really surprised that the values it gives are pretty much the same. But in fact it takes 3h20m for a WU in POEM instead of 2h10m.

So, if there is any chance to make this benchmark more realistic?

There was a bit of debate about using real wu as a basis for benchmaking, but then a number of the projects have different types of work.

The benchmark is used primarily to work out how quick your machine is so it can estimate how long work will take. Its then adjusted by the DCF value which is kept per project on your PC. Unfortunately there is only one DCF value per project. It doesn't differentiate between cpu and gpu or different apps within a project (eg seti has multibeam and astropulse which take totally different times).

In your case the DCF should have adjusted by now to give a reasonable estimate of how long the work will take. It however has to complete some work units 1st to be able to adjust it.

Its not my call as to adjusting the benchmark. Really it doesn't matter what number it comes up with, because once the machine has done some work the DCF will have adjusted anyway.

---

BOINC blog

Thx guys for your answers :-)

So in fact i should not pay too much attention on these values and i should use so-called "usual" benchmarks to estimate how fast my rig is. clear, no question.

There ia another... hmm... request. If there is any chance to make BOINC save WUs before closing? Coz right now it loosing 2-3% of each WU. Yep, I put "30 secs" in web, but the story is there...

---

Thx guys for your answers :-)

So in fact i should not pay too much attention on these values and i should use so-called "usual" benchmarks to estimate how fast my rig is. clear, no question.

There ia another... hmm... request. If there is any chance to make BOINC save WUs before closing? Coz right now it loosing 2-3% of each WU. Yep, I put "30 secs" in web, but the story is there...

You are welcome for the answers ...

And Mark is right, idiots like me have been proposing for years that we use actual tasks for benchmarking and he is also right that different projects have different tasks which is why my proposals suggested using tasks from as many projects as is possible. This is usually misinterpreted that I am suggesting using projects like CPDN so that they can ridicule the idea. The truth is that there are many projects that have short tasks that could be used and if we did run a suite of tasks on various machines we could more properly characterize them ...

The checkpoint code only says how often BOINC will say it is Ok to checkpoint... the application is the one that actually sets the rate. It asks BOINC if it is Ok, or not, then checkpoints if it is Ok ... assuming that the BOINC API is used at all ... in any case, it is up to the project's application to checkpoint ... not sure why you are losing so much ground ...then again, why shut the system off in the first place? :)

There ia another... hmm... request. If there is any chance to make BOINC save WUs before closing? Coz right now it loosing 2-3% of each WU. Yep, I put "30 secs" in web, but the story is there...

This is where the checkpointing is handled. The science app is written by each project, it decides when its going to checkpoint if at all. Milkyway gpu tasks don't, but they only take 60 seconds.

Its a trade-off between checkpointing a lot, thus slowing down the machine and checkpointing less often with the need to redo some work when it restarts. On machines with many cores (quads or i7's) I usually put the number higher (90secs on my i7's) and if you had less cores you'd probably have it about 60 which is the default.

---

BOINC blog

Just a little clarification on the "write to disk" parameter ... it really means "use this as a multiplier per core" ... so setting 90 seconds on an i7 limits disk writing to every 720 seconds. One of the keys here is that if you tell BOINC not to write to disk it keeps stuffing intermediate results into memory, after that the OS takes over and if you don't have enough memory it writes it to the swap file (which is yes, you know it, on your disk) and when it is allowed to flush from memory to disk it ends up reading from the swap file and writing to the real disk location. I mention this for crunchers who are running kind of tight on memory because setting this parameter for too long could actually slow you down.

---

Thanks - Steve

Just a little clarification on the "write to disk" parameter ... it really means "use this as a multiplier per core" ... so setting 90 seconds on an i7 limits disk writing to every 720 seconds. One of the keys here is that if you tell BOINC not to write to disk it keeps stuffing intermediate results into memory, after that the OS takes over and if you don't have enough memory it writes it to the swap file (which is yes, you know it, on your disk) and when it is allowed to flush from memory to disk it ends up reading from the swap file and writing to the real disk location. I mention this for crunchers who are running kind of tight on memory because setting this parameter for too long could actually slow you down.

Depends on BOINC version. From the 6.10.14 change log...

- client: don't multiply checkpoint interval (i.e., "disk interval" pref) by # processors.

- actually, make it "Tasks checkpoint to disk at most every ..." and change it in the advanced prefs dialog too

---

BOINC blog

Its been superceeded. See seperate message thread for BOINC 6.10.18 details.

---

BOINC blog

Depends on BOINC version. From the 6.10.14 change log...

- client: don't multiply checkpoint interval (i.e., "disk interval" pref) by # processors.

- actually, make it "Tasks checkpoint to disk at most every ..." and change it in the advanced prefs dialog too

Which is likely a move in the wrong direction in that systems are getting "wider" all the time and on wider systems with so many tasks "in-flight" the disk activity goes through the roof ... one of the reasons for the multiplier in the first place.

If I read the rumors right the i9 is about the corner and it will be at least a 12 CPU chip ... add in even just a pair of GTX295 cards and you are at 16 tasks running ...

Paul D. Buck

the idea of such benchmark is to check how hardware changes effects on BOINC. Sure, I can start any other benchmark to check, but the truth is that synthetic results are too far from "real life".

In my understanding it should work like this: it's necessary to have very short "benchmark WUs" for at least major projects and give a choice of these "benchmark WUs" OR check what project this user running and start that WU which suits better.

As advantage of this approach:
- we can test real productivity of the hatdware in terms of real project
- we can test not CPU only but GPU also.

But I'm sure if it's easy or not to program this and where to take these "benchmark WUs" (from the projects?)

Anyway it's just my personal ideas how to make this benchmark real, otherwise (sorry to say) thet are pretty much useless.

---

the idea of such benchmark is to check how hardware changes effects on BOINC. Sure, I can start any other benchmark to check, but the truth is that synthetic results are too far from "real life".

In my understanding it should work like this: it's necessary to have very short "benchmark WUs" for at least major projects and give a choice of these "benchmark WUs" OR check what project this user running and start that WU which suits better.

Which has long been my assertion. We need to benchmark with actual tasks...

For just as long UCB has been rejecting this concept along with a host of others ...

the idea of such benchmark is to check how hardware changes effects on BOINC. Sure, I can start any other benchmark to check, but the truth is that synthetic results are too far from "real life".

In my understanding it should work like this: it's necessary to have very short "benchmark WUs" for at least major projects and give a choice of these "benchmark WUs" OR check what project this user running and start that WU which suits better.

Which has long been my assertion. We need to benchmark with actual tasks...

For just as long UCB has been rejecting this concept along with a host of others ...

that's really pity... in my understanding this is not right and these benchmarks are meaningless at al...

---