... I have no clue how the credit works under this system. ...

But you're an admin! *just kidding*

... Maybe it just needs some damping. ...

Is this on the 'to do list'?

------------------------------------------

Just curious.

The stock V6.91 and r246 opt. app of S@h v7 work well (at least for Windows).
What's now?
How long it will last that S@h v7 will be released at S@h (MAIN)?
Is somewhere a roadmap?


- Best regards! - Sutaru Tsureku, team seti.international founder. - Optimize your PC for higher RAC (@ SETI@home). - SETI@home needs your help. -

---

How long it will last that S@h v7 will be released at S@h (MAIN)?

I guess as usual.
As soon all versions produce less than 5% - 10% errors.

---

With each crime and every kindness we birth our future.

While 6.91 has been running since the 6th April I do not think I have had a failded WU niether have many been validated, so to say its working fine on a host basis yes?? But overall??

As for r246 available from the 27th April?? no local failed WU'S but also no validated WU's as the validator has been off line since the 27th April I would hope some time yet. Before its ready.

What is the rush to go over to main. Lets prove they work over here or (Or face the continual whinging that they were not tested enough over here.)

Michael.

Even if my PCs made 1,015,000+ Cr. to now here at S@h BETA, they test the first time a new app.
So they don't have experiences.
They are just curious about how the procedure is (e.g. roadmap) and how long a new app is tested before release (at MAIN).

;-)


- Best regards! - Sutaru Tsureku, team seti.international founder. - Optimize your PC for higher RAC (@ SETI@home). - SETI@home needs your help. -

---

Query: I have a V7 6.91 WU that has run 76+ hours, where a normal WU for that computer runs in the 10 hour range. Is this normal?

WU = 07mr11ah.3292.24198.206158430212.14.224_1

Computer: AMD athlon 3000+, 1.5 Gb, non CUDA-capable GPU
OS: Windoze XP Pro x64
Boinc: 6.10.58

Currently reading 76:52:49 with 6:57:01 to go...

---

Maybe it's a BUG of the app on AMD CPUs..

Message 40448 here in this thread.

What do the progress, at which value currently?
AFAIK, if the elapsed time increase, but the progress stay at 0 % then it's the BUG.

BTW.
I didn't found this PC (CPU) in your hosts list.


- Best regards! - Sutaru Tsureku, team seti.international founder. - Optimize your PC for higher RAC (@ SETI@home). - SETI@home needs your help. -

---

Since i switched to setiathome v7 v6.93 i686 for linux the day after it was released, this host got higher number (3 out of the last 20) of results validated inconclusive versus different windows hosts.

Anyone else can confirm my observation ?

---

_\|/_
U r s

I´m not sure it has something to do with Linux app Urs.
I also found some inconclusives on my host after replica catched up.
Even with GPU app.
Some results are identical, some have higher autocorr count.

---

With each crime and every kindness we birth our future.

I've also had a few inconclusive across my different hosts:

T8100:

http://setiweb.ssl.berkeley.edu/beta/workunit.php?wuid=3328814 Stock windows 6.91 against Stock windows 6.91

http://setiweb.ssl.berkeley.edu/beta/workunit.php?wuid=3339945 Stock windows 6.91 against Stock Apple 6.92

E8500:

http://setiweb.ssl.berkeley.edu/beta/workunit.php?wuid=3364934 Optimised CPU build 246 against Stock windows 6.91

http://setiweb.ssl.berkeley.edu/beta/workunit.php?wuid=3355019 Optimised CPU build 246 against Stock windows 6.91

There are a few others, but they are eithier against build 228 (which didn't save the autocorrection correctly) or against dodgy hosts,

Claggy

Thanks for having a look. Was just wondering, because there was only 1 per 100 wus validated inconclusive before (with 64bit linux seti v7) on my host, which seemed acceptable to me.

Maybe its wait and see if there shows up a certain accumulation of inconclusives.

---

_\|/_
U r s

Good evening Claggy Urs.

How far do you want to go back with inconclusive. I have listed all my latest since running r246.

wuid=5338048 ATI v7 anon CPU
wuid=3357942 v6.92 v7 anon CPU
wuid=3357924 v6.91 v7 anon CPU
wuid=3346743 v6.91 v7 anonCPU
wuid=3341169 v6.91 v6.91

Completed, validation inconclusive. Reported before.

wuid=3341157
wuid=3341156
wuid=3341140

Michael

Joe,

Pepo wrote:

Josef W. Segur wrote:

I spent most of my day making test builds, here's a quick summary of my conclusions:

The DCT in FFTW is real to real, but as noted in the documentation:

In the current version of FFTW, all r2r transforms except for the halfcomplex type are computed via pre- or post-processing of halfcomplex transforms, and they are therefore not as fast as they could be. Since most other general DCT/DST codes employ a similar algorithm, however, FFTW’s implementation should provide at least competitive performance.

In order to do that pre- and post-processing, it temporarily allocates memory, probably the same size as the real array. 128K 4 byte floats is 128 4K pages, so the 519336 Autocorrelations done could cause 66475008 page faults.

Yes, this was the last question for today I was thinking of during the evening and night: I've mentioned noticing that the process very frequently allocates and deallocated pretty large chunks of memory (around 1/2 MB) and its Working Set and Private Bytes always change accordingly. My thought was that as the memory area always gets off the process' working set (to the Standby List?), taking it back to process' working set has always to cause some (at least soft) page faults (depending on whether enough free RAM is available for the process).

Your assumed number of page faults nicely compares to my observation of approx. 67 620 000 PFs :-)

While testing a bit the Process Hacker, I've noticed it has a tool named WS Watch, which is able to "monitor page faults that occur in a process" and break the PFs and list their counts according to functions, where they happen.

I've let one task (a local copy of 07mr11ah.5998.19290.206158430213.14.179) completely run stand-alone through (some 15 hours on Core i3) and let the tool check the PFs just after the initial minute or so (where some initialization and so (107 900 PFs) happen). The resulting table starts with:

13 397 374, libfftw3f-3-1-1a_upx.dll!uninstall_windows_exception_handler+0x5f198
12 982 101, libfftw3f-3-1-1a_upx.dll!uninstall_windows_exception_handler+0x5f1a1
   207 641, ntdll.dll!RtlDeleteAtomFromAtomTable+0x164
     2 385, ntoskrnl.exe!wcsncpy+0x3c
       630, ntoskrnl.exe!NtNotifyChangeDirectoryFile+0xbc2
       195, Ntfs.sys+0xe46e
       174, setiathome_6.91_windows_intelx86.exe+0x3a3a
       160, libfftw3f-3-1-1a_upx.dll!fftwf_set_timelimit+0xec11
       159, ntoskrnl.exe!wcsncpy+0x16
       157, Ntfs.sys+0x87204
       137, libfftw3f-3-1-1a_upx.dll!fftwf_set_timelimit+0xcdb5
       104, ntoskrnl.exe!RtlClearBits+0x3d
        88, setiathome_6.91_windows_intelx86.exe+0x3eb7

with the remaining counts not being relevant anymore.

Maybe if I'd have used a non-UPX'ed version of the executable (but you could), the names of the functions might look different (and more relevant), also the total count of registered PFs (some 27 mil. listed in my example) does differ from the process' total PF count (67 mil.), but assigning 99% of the counted PFs to libfftw3f-3-1-1a_upx.dll does to match the whole image.

Peter

http://setiweb.ssl.berkeley.edu/beta/result.php?resultid=9435761

:)

My PIII has done it's first Wu with v6.95, it's ended up being inconclusive as it was matched to an AVX equiped i5

wuid=3438787

That i5 completed all it's 6.91 Work O.K, errored all it's 6.94 work, and most of it's 6.95 work is inconclusive.

Claggy

I had a 6.95 error just as it finished Workunit 3416960

Stderr output

<core_client_version>6.12.30</core_client_version>
<![CDATA[
<message>
The system cannot find the path specified. (0x3) - exit code 3 (0x3)
</message>
<stderr_txt>
setiathome_v7 6.95 DevC++/MinGW/g++ 4.5.2
libboinc: 6.13.0

Work Unit Info:
...............
WU true angle range is : 0.378321
Optimal function choices:
--------------------------------------------------------
name timing error
--------------------------------------------------------
v_BaseLineSmooth (no other)
v_vGetPowerSpectrumUnrolled 0.000118 0.00000
sse3_ChirpData_ak8 0.011670 0.00000
v_vTranspose4x16ntw 0.007390 0.00000
BH SSE folding 0.001141 0.00000
fftw: alloc.c:270: assertion failed: p

</stderr_txt>

I'm mentioning it because my firewall popped up with an alert at the same time that Boinc was trying to do something, I didn't take note of what it was but just permanently allowed it, and since then no problems.

I had the same problem couple month ago.
Just exclude boinc directory in your firewall.

---

With each crime and every kindness we birth our future.

@Mike, Done :)
[offtopic] I've recently changed firewalls because Vista+Firefox+Zonealarm just didn't work on my system (you should see the the complaints of them blaming each other :)) My browser internet access would just stop after a few days, Boinc could do it's stuff though, but my browsers couldn't load a page and not even be killed with process explorer etc... needing a restart to get them going again. And after trying for six months with various workarounds I gave up and switched firewalls, so far so good, I'm still getting used to the way the new one works and setting permissions. Unfortunately this may have contributed to the above task erroring out.[/offtopic]

As some people already mentioned, a VLAR can easily be done by the ATI GPU
as well. (Rev.234 for H5000 GPUs)
And I haven't seen an inconclusive as well.

As some people already mentioned, a VLAR can easily be done by the ATI GPU
as well. (Rev.234 for H5000 GPUs)
And I haven't seen an inconclusive as well.

That's r246 you're running Fred, not r234,

Your host does have inconclusives.

Claggy