This thread has some discussion about macintosh machines. However the version they were talking about was 3.24 not 3.26. So whatever was happening in .24 may have not been fixed in .26 when it comes to mac's.

I can confirm that 3.26 has the same mac slowdown issue that 3.24 does.

We have some leads now on the issue, so <deity of your choice (or absence thereof)> willing, we may be able to correct things by the next release, though no promises.

The Result Graphs on the website is NOT WORKING...

Hi Mike,

To which graph are you referring?

As reported widely, the Mac OSX versions of 3.24 and 3.26 are showing extremely poor performance, which is reflected in abnormally low "granted credit" scores compared to all previous versions. The Granted Credit is ~4 -5 times lower than the "Claimed Credit" now! Clearly, version 3.26 did not fix the problem introduced by 3.24. At first, I thought this might be a glitch in the scoring system, but after analyzing the result reports, I no longer think that is the case. I have a 21000-second time preference set and usually a large number of decoys are attempted and finish within the time window on my 3.2 GHz Mac Pro. Many of my results have only one decoy attempt now, so the low granted credit is probably correct.

However, that implies that a serious bug was introduced in v3.24. Is this is receiving priority attention by the Rosetta programmers? Not only is the calculation efficiency dramatically reduced, but I worry that the technical accuracy of the results may be poor, also. As a Mac OSX developer, I know there have been lots of changes in Xcode recently and thus more opportunities for code to break that used to work fine previously.

---

The Result Graphs on the website is NOT WORKING...

Hi Mike,

To which graph are you referring?

Hey, sorry for blowing a fuse there... It is the results and data plots from active workunits

Thanks
Mike

this task died at just under 2hrs due to no heartbeat.

CASP9_fb_benchmark_hybridization_run54_T0532_0_C1_SAVE_ALL_OUT_IGNORE_THE_REST_47951_293_0

All the usual unpacking and checking went ok
then this:
Setting database description ...
Setting up checkpointing ...
Setting up graphics native ...
BOINC:: Worker startup.
Starting watchdog...
Watchdog active.
# cpu_run_time_pref: 28800
No heartbeat from core client for 30 sec - exiting

I have noticed that the tasks are requiring about 1/2 Gig of memory to run.
I never noticed this before.

---

What you do today you will have to live with tonight

Rosetta Mini 3.26
rb_04_20_30733_61889__round2_t000__0_C1_SAVE_ALL_OUT_IGNORE_THE_REST_48383_2236

Now using 713 KB and has used as much as 963 KB.

Can you give users the option of limiting the number of such
memory-hungry workunits that can be on one of their computers
at any one time? Or would you prefer to recompile them to
run in 64-bit mode instead of 32-bit mode so that, under
64-bit versions of Windows, the workunits can run without any
additional memory being used for the SysWOW64 software
needed to run 32-bit workunits under 64-bit versions of
Windows? Note that you choose the second option, you may
need to ask the BOINC developers to make it possible to set
a lower limit for memory used by all 32-bit workunits than for
the total memory used by all workunits, or if they prefer,
insure that every 32-bit workunit gets a separate 4 GB of
32-bit memoryspace. I've found that my computer tends to slow
down user response quite a bit as the total memory used by
32-bit workunits and other 32-bit programs approaches 3.5 GB,
as I'd expect if all 32-bit programs must fit within a single
4 GB memoryspace. The computer has a total of 8 GB of memory.

robertmiles means "MB" not "KB".

Just a suggestion that may improve your memory usage in the meantime, consider turning off hyperthreading if you have it active. It causes twice as many threads to run, and try to utilize twice as much memory, but doesn't generally yield twice the processing (especially if there is contention for memory, such as you describe for the <4GB space). I'm sure every processor is different. But in years past, with fairly lengthy review of credit per second averages, it has been observed that contention for floating point operations between the 2 hyperthreaded WUs roughly equaled any benefits of running in two threads.

It could be that they've beefed up the floating point processing to be useful to twice as many threads simultaneously, so you'd want to watch your RAC over time to see if change to hyperthreading setting is helping or not. But that's a tough one because of specific variations in any given work unit. So, on the other hand, watch for result after a few days, don't panic at a variation any sooner then that.

I'm sure many would be curious to hear your findings.

---

Rosetta Moderator: Mod.Sense

robertmiles means "MB" not "KB".

Just a suggestion that may improve your memory usage in the meantime, consider turning off hyperthreading if you have it active. It causes twice as many threads to run, and try to utilize twice as much memory, but doesn't generally yield twice the processing (especially if there is contention for memory, such as you describe for the <4GB space). I'm sure every processor is different. But in years past, with fairly lengthy review of credit per second averages, it has been observed that contention for floating point operations between the 2 hyperthreaded WUs roughly equaled any benefits of running in two threads.

The computer with the problems doesn't use hyperthreading within BOINC, and I already have BOINC using one less than the number of cores available.

I do have another computer that does use hyperthreading, but does not have this problem. It uses 64-bit Windows 7 Professional and has 16 GB, but is currently using only 3.85 GB. Could that mean that its version of Windows is better at running large numbera of 32-bit programs at once? I may have to watch it to see if it ever goes above 4 GB for all 32-bit programs.

The first computer still has some programs that just aren't ready for installing Windows 7.

The Result Graphs on the website is NOT WORKING...

Hi Mike,

To which graph are you referring?

Hey, sorry for blowing a fuse there... It is the results and data plots from active workunits

Thanks
Mike

??? BUMP

The Result Graphs on the website is NOT WORKING...

It is the results and data plots from active workunits

It looks like the server side system that handles it is fundamentally broken (resource issues), and would take a non-trivial amount of effort to fix. Unfortunately, the "fix" we're probably going to implement is to remove that feature/link altogether. Sorry about that.

The Result Graphs on the website is NOT WORKING...

It is the results and data plots from active workunits

It looks like the server side system that handles it is fundamentally broken (resource issues), and would take a non-trivial amount of effort to fix. Unfortunately, the "fix" we're probably going to implement is to remove that feature/link altogether. Sorry about that.

When you take the fun out of doing a project, you lose customers quickly

I know I'm going on this bumping thread thing again.

The not funny part is that it's not working again.

The funny part is that I did a Google search for the problem as usual, came across this thread, and only after reading the whole thing did I realize that I was actually the poster.

Oh.. PS sorry for blowing a fuse yet again in that last post a few years ago. I have learned to be less bitter since.. Although fixing this feature would really make it fun ;).