Interesting. I hadn't the slightest clue that Rosetta was causing the issues I was experiencing... severe WMC + ffdshow lag, general system slowness, etc.

BTW, I run quite a few science apps in BOINC, so nailing down a system issue to a particular one is rather tough.

---

I do a lot of video editing and my linear editing programs were moving at a snails pace compared to normal

Was that with the 5.12 application? Or the 5.13 that was just released to correct the new memory contention problems?

---

Add this signature to your EMail:
Running Microsoft's "System Idle Process" will never help cure cancer, AIDS nor Alzheimer's. But running Rosetta@home just might!
https://boinc.bakerlab.org/rosetta/

Hi all: We just released 5.13, after testing on ralph today. Please continue to post here if you see any remaining issues.

Congrats for your immediate action.
All my machines works with 5.13 and everything seems to be normal.

Thank you very much.

---

A64 3500@2727MHz - A64 3200@2400MHz - P4 3.0 northy@3.6MHz
Sempron 2600+@2100MHz - Celeron 2.8 northy @3.6MHz
P4 2.4@2.8MHz - Celeron 2.66@3.0MHz - AthlonXP 2000+@1866MHz

Closing the door long after the horse has bolted, but hopefully the following information is consistant with the believed cause of the 5.12 PF bug.

I have a HT P4 here still grinding away on 5.12 WU's Right now, it's crunching on two of them:

1. JUMP_ALLBARCODES_ANTIPARALLEL_1tul__SAVE_ALL_OUT_491_11226_0 WSS: 67.7 megs, Vmem size: 148.8 megs, PF's pretty much zero.

2. HOMO_7486_h003_1_LOOPRLX_IGNORE_THE_REST_7486h003_dec297_1.pdb_497_7_0 WSS: 195 megs, Vmem size: 402.6 megs, PF's 1.8 million and growing at a scary rate of knots.

Hope this helps.

-- Edit --

Needless to say, I'll be watching my systems like a hawk as the 5.13 WU come on line. Since this is not a drop dead showstopper for me, I'll let the 5.12's clear from the cache in their own good time.

---

Hi all: thanks very much for the info on page faults. I can see the high PF rate on my Windows system too especially when I turn on/off graphics a few times. We'll look into whether these are soft or hard page faults... and also whether we can free virtual mem completely when graphics are off.

This might be what is going on with page faults. The ordinary hard page fault is the one you get when the page needed is in virtual memory - that's the common understanding of what a page fault is. There is another kind - it is what is probably happening in rosetta - see the following:

____________________
http://blogs.msdn.com/greggm/archive/2004/01/21/61237.aspx

Soft faults are relatively inexpensive. These occur when a process tries to access the virtual address, and the operating system can satisfy the request without reading in the page from disk. This can happen with pages that the program wants to be zero (called �demand zero� pages), when a page is written to for the first time (�copy on write� pages) or if the page is already in memory somewhere else. The last situation occurs if a file is memory mapped into multiple processes or into multiple locations of the same process, and one of the other file references has already caused the data to be in physical memory.
____________________________


I also believe that the slowdowns have their origin in a bug in the MS Directx SDK. I've experienced similar effects as long as 2 years ago in other applications not related to Boinc whose only common component was the DirectX SDK. I do not have much experience with the DirectX SDK and have never been able to find out if that was actually the problem - it's just a hunch.

---

I HAVE TRIED TWICE NOW AND BOTH FAILED. SO I AM OUT OF THIS PROJECT SORRY GUYS

---