The alpha builds (numbered 5.9.x) for testing for the 5.10.x release line have been started.

If you are running it, the best thing you can do is post to the alpha email list. But you can also use this thread and Jord and I will pass along bug reports to the developers if need be (that is if they haven't already been posted to the list).

---

Kathryn :o)

I've noted the following :

The Linux V5.9.3 seems to benchmark quite inconsistently.

All my 5.9.3 equipped Systems will change Benchmark results at every benchmark with far higher variation than any other Version I've seen so far (upto 10% variation)

For me, this large variation affects Integer Benchmarks only.
In comparison, the Float bench remains very consistent, well within 0.1%.

(all measured repeatedly on dedicated Systems with no other relevant CPU usage besides BOINC itself)

---

I've noted the following :

The Linux V5.9.3 seems to benchmark quite inconsistently.

All my 5.9.3 equipped Systems will change Benchmark results at every benchmark with far higher variation than any other Version I've seen so far (upto 10% variation)

For me, this large variation affects Integer Benchmarks only.
In comparison, the Float bench remains very consistent, well within 0.1%.

(all measured repeatedly on dedicated Systems with no other relevant CPU usage besides BOINC itself)

Are they dual or single core systems? With or without HT?

---

Kathryn :o)

Are they dual or single core systems? With or without HT?

Almost all of them are Dual Core (Athlon64 X2, x86_64 Fedora Core 4/5/6 Installations)

---

Are they dual or single core systems? With or without HT?

Almost all of them are Dual Core (Athlon64 X2, x86_64 Fedora Core 4/5/6 Installations)

There's a bug someplace in the benchmarks with the dual cores. I see it consistently on my Pent D. I think Tony (Astro) was collecting data on it over at Seti a number of alpha versions back.

---

Kathryn :o)

I have a problem with the 5.9.3 on AMD's X2 and Intels Dual Core. When I use in the german windows version under XP on the folder "Aufgaben" (Tasks) the columns for sort, the Boinc manager hangs and must be ended by taskmanager. This problem not exist on singel core machines.

I'm here right for error description for alpha versions? Or is there another thread or mailings list for feedback available?

---

There is anywhere one bug more ...

I also found something else, possibly quite a big bug :

On all 5.9.3 (Linux) Systems, the Work Buffer kept by the Clients far exceeds the desired Setting. (I have no 5.9.3 Windows Clients running for comparison)

Since a few days, I have "Connect to Network every x days" reduced from 1 to 0.5 days.

All remaining 5.8.15 and 5.8.16 Clients worked down their caches immediately and show a perfect ~12hrs of Work Buffer, while all 5.9.3 Clients vary from 36 upto 62 (!) hours.

I first noted the oversized local Caches as the first Clients ran into "x Deadline misses" on MalariaControl with its typical shorter deadlines when I still had the setting to 1 day (the reason I cut it in half).
At that time, the 5.9.3 clients indicated a Work Buffer of upto 120hrs.

Looking at the amount of Work actually kept on the Clients, it appears as the Clients indeed fully overload on Work, compared to the much lower desired setting.
It's only thanks to the highly varying actual runtimes (often much shorter) of MalariaControl, that the Clients don't miss the deadlines completely.

The large variation between work buffers kept on the 5.9.3 Clients is not transparent to me, as all relevant Parameters (CPU efficiency, active fraction, on fraction etc.) are almost identical on all affected machines - they're on 24/7 @ 99.x% efficiency anyway with about no downtimes, no exception.

Only good news is, that the 5.9.3 still reacts proportionally to the desired setting... it just remains too large by a factor of 3x to 6x.

---

I also found something else, possibly quite a big bug :

On all 5.9.3 (Linux) Systems, the Work Buffer kept by the Clients far exceeds the desired Setting. (I have no 5.9.3 Windows Clients running for comparison)

Since a few days, I have "Connect to Network every x days" reduced from 1 to 0.5 days.

All remaining 5.8.15 and 5.8.16 Clients worked down their caches immediately and show a perfect ~12hrs of Work Buffer, while all 5.9.3 Clients vary from 36 upto 62 (!) hours.

I first noted the oversized local Caches as the first Clients ran into "x Deadline misses" on MalariaControl with its typical shorter deadlines when I still had the setting to 1 day (the reason I cut it in half).
At that time, the 5.9.3 clients indicated a Work Buffer of upto 120hrs.

Looking at the amount of Work actually kept on the Clients, it appears as the Clients indeed fully overload on Work, compared to the much lower desired setting.
It's only thanks to the highly varying actual runtimes (often much shorter) of MalariaControl, that the Clients don't miss the deadlines completely.

The large variation between work buffers kept on the 5.9.3 Clients is not transparent to me, as all relevant Parameters (CPU efficiency, active fraction, on fraction etc.) are almost identical on all affected machines - they're on 24/7 @ 99.x% efficiency anyway with about no downtimes, no exception.

Only good news is, that the 5.9.3 still reacts proportionally to the desired setting... it just remains too large by a factor of 3x to 6x.

I have a Windows 5.9.3 and a Windows 5.8.16.....nearly identical configurations. The work buffer is virtually the same.

I have a Linux 5.9.3 and a Windows 5.8.16.....nearly identical configurations. The work buffer on the Linux 5.9.3 is double the Windows 5.8.16.

---

Read that an additional setting was in the works meant to have been part of a final 5.8 release.... 1 for buffer size and 1 for the connect.... is that kicking in?

All my 5.8.16, 5.8.17 and 5.9.3s are configured with the same cc_config.xml:
<save_stats_days>10</save_stats_days>
<work_request_factor>1</work_request_factor>

---

Read that an additional setting was in the works meant to have been part of a final 5.8 release.... 1 for buffer size and 1 for the connect.... is that kicking in?

All my 5.8.16, 5.8.17 and 5.9.3s are configured with the same cc_config.xml:
<save_stats_days>10</save_stats_days>
<work_request_factor>1</work_request_factor>

Can you report this to the mailing list?

---

Kathryn :o)

Read that an additional setting was in the works meant to have been part of a final 5.8 release.... 1 for buffer size and 1 for the connect.... is that kicking in?

All my 5.8.16, 5.8.17 and 5.9.3s are configured with the same cc_config.xml:
<save_stats_days>10</save_stats_days>
<work_request_factor>1</work_request_factor>

Can you report this to the mailing list?

What is the purpose of this thread, if not to report 5.9.x problems?

---

Read that an additional setting was in the works meant to have been part of a final 5.8 release.... 1 for buffer size and 1 for the connect.... is that kicking in?

All my 5.8.16, 5.8.17 and 5.9.3s are configured with the same cc_config.xml:
<save_stats_days>10</save_stats_days>
<work_request_factor>1</work_request_factor>

Can you report this to the mailing list?

What is the purpose of this thread, if not to report 5.9.x problems?

I have submitted it to the list, but it will be infinitely more easy to debug if you are able to participate in that discussion. Else, Jord or I act as intermediaries between the list and you. We can't see what you're seeing. We don't have access to your install of BOINC. We don't know anything about your set-up. Basically, you have the information and we don't.

---

Kathryn :o)

I've checked all available Mailing Lists and found no such thing as "boinc_Bugreports : For people testing pre-release BOINC Versions"

None of the existing List Descriptions match the profile of Bug Reporting outside Code-Level (Developers only).

---

For the two of you with cache size problems, what project are you getting your general preferences from?

On the latest version of the server software, there's a new field

Cache enough work for an additional
(maximum 10 days; requires 5.10+ client)

By default, it's set to 1 day (and I've reported this on the mailing list).

Seti and BOINC Alpha are the only two project that currently have this deployed.

---

Kathryn :o)

For the two of you with cache size problems, what project are you getting your general preferences from?

On the latest version of the server software, there's a new field

Cache enough work for an additional
(maximum 10 days; requires 5.10+ client)

By default, it's set to 1 day (and I've reported this on the mailing list).

Seti and BOINC Alpha are the only two project that currently have this deployed.

I maintain my preferences on Docking@Home.

---

My latest Prefs are from MalariaControl.

(and as I said, there is no specific Alpha Mailing List in the Link you provided - which is a collection of other BOINC Development related Mailing Lists - , I think we keep missing each other here ;) ... Which of the 8 available Mailing Lists contained in the Page you linked do you mean? Could it be I'm missing Details on that Page simply because I'm not registered to any Mailing lists yet?)

---

My latest Prefs are from MalariaControl.

(and as I said, there is no specific Alpha Mailing List in the Link you provided - which is a collection of other BOINC Development related Mailing Lists - , I think we keep missing each other here ;) ... Which of the 8 available Mailing Lists contained in the Page you linked do you mean? )

Thanks for the info.

And I'll change that link to point directly to the alpha list sign up. I swear the alpha list used to be on that page. Because that's where I would have signed up for it ages ago.

http://www.ssl.berkeley.edu/mailman/listinfo/boinc_alpha


By the way, ignore everything I said in the above discussion. When I'm actually coherent, I'll correct it.

---

Kathryn :o)

Ah, that looks better... I regged up, let's see how it works out from there on :)

-- edit --

Wow, using that Mailing list will take a while getting used to. I had hoped for something more like a Messageboard *ugh*

---

I have checked the adjustment under preferences, network usage, additional work buffer and have the following result.

QMC has downloaded 32 workunits with 11:09 hours after I change from 0.00 to 0.01 additional work. This was the second test with the same adjustment. When my PC has downloaded so much workunits, he don't change from project to project after one hour (as configured), he is now working in once over 4 hours on the same project (QMC).

OS: Windows XP 32bit
HW: AMD64bit X2 4200
BOINC: 5.9.3

---

There is anywhere one bug more ...

Ah, that looks better... I regged up, let's see how it works out from there on :)

-- edit --

Wow, using that Mailing list will take a while getting used to. I had hoped for something more like a Messageboard *ugh*

I'm with you. I don't even have email configured on every computer I sit at during the day........I do have browsers to get to a forum.

---