I'm modified the result template to (I hope) make the FFTW wisdom file a persistent file. This may cause unexpected problems with uploads, downloads or app starts. Let me know if does.

---

I'm modified the result template to (I hope) make the FFTW wisdom file a persistent file. This may cause unexpected problems with uploads, downloads or app starts. Let me know if does.

Is that on any particular app version, or all?

Claggy

All apps. But apparently this is yet another BOINC feature that doesn't work as advertised, so I may have to undo it.

---

Getting the following error on all WU's.

<core_client_version>7.2.28</core_client_version>
<![CDATA[
<message>
upload failure: <file_xfer_error>
<file_name>wisdom.sah</file_name>
<error_code>-161</error_code>
</file_xfer_error>

</message>
]]>

---

Interesting side effect there with it bailing on Cudas as well, even though the Cuda MB builds don't use fftw or its wisdom file.

Yeah, I'm manually granting credit for these. Eventually (today, I think) these should work through the queue and we should get back to normal ones.

David is looking at the issues I'm having.

---

Not sure if it's related but I've been getting the following error this afternoon - times are UTC

04/12/2013 13:22:33 | SETI@home Beta Test | Sending scheduler request: To fetch work.
04/12/2013 13:22:33 | SETI@home Beta Test | Reporting 1 completed tasks
04/12/2013 13:22:33 | SETI@home Beta Test | Requesting new tasks for CPU
04/12/2013 13:22:35 | SETI@home Beta Test | [error] Can't parse file info in scheduler reply: unexpected XML tag or syntax
04/12/2013 13:22:35 | SETI@home Beta Test | [error] No close tag in scheduler reply

Probably is. I'll check it out.

---

All apps. But apparently this is yet another BOINC feature that doesn't work as advertised, so I may have to undo it.

Eric, wisdom file is persitent for all GPU builds and for all CPU opt build since long time ago already. Just check how it's implemented in GPU build, it has almost nothing to do with BOINC and runs on known BOINC versions just OK.

All apps. But apparently this is yet another BOINC feature that doesn't work as advertised, so I may have to undo it.

Eric, wisdom file is persitent for all GPU builds and for all CPU opt build since long time ago already. Just check how it's implemented in GPU build, it has almost nothing to do with BOINC and runs on known BOINC versions just OK.

That uses the project path as specified by BOINC in init_data.xml to facilitate file operations. Although I think that's the best way, I doubt if adding that kind of code and issuing new applications is practical at this point. Perhaps it should go on a todo list for whenever new applications are needed for other reasons.

@Eric - The reason your approach failed is that the generated_locally and upload_when_present tags were removed by changeset 8296968 in July 2011 as part of the changes to allow distributed storage. Current code only recognizes them enough to avoid an unparsed XML error.

What I think *would* work is akin to the workaround for cmdline.txt files for the OpenCL applications. The server could send out an empty file named wisdom_v7.sah or such, and the file_ref would use <open_name>wisdom.sah</open_name> so the application could read and write the file. However, that essentially relies on an undocumented feature of BOINC and it might be sensible to have David bless it.

                                                                  Joe

I ended up implementing something that's probably similar. I get the project directory from the APP_INIT_DATA structure, and opens "wisdom.sah" there, unless (at some point in the future) it gets fixed in which case it will open "wisdom.sah" through a BOINC soft link.

Didn't see Joe's message until after I posted. Insert something about thinking alike here.

---

Eric, our last findings in FFTW wisdom area that planning is redone when library detects switch from x86 to x64 build. That is, to be useful in mixed x64/x86 environment (at least under Windows) files for x86 and x64 builds should have different names (to avoid unneeded replannings).
It will be implemented for opt builds maybe worth to do the same for CPU stock too.

Thanks. I'll implement that.

---