Rosetta is wasting CPU time on tasks involving gzip files. I have 7-Zip installed on my PC and it does work, although I've never had any need to use it for GZIP files.
Q1: Why does the task details on these errors show that credit was granted? My results page never shows any credits granted for tasks ending in errors.
Q2: Is there a fix for these errors? I could be running something else instead of Rosetta with very few tasks ending in an error or invalid validate state instead. I don't care about accumulating credits to impress anyone with but I do care about wasting my CPU time on tasks that consistently end up with the same error (involving gzip files)
I can post more details/info on my PC, BOINC/Rosetta configuration and/or error messages if needed, I've tried researching this myself & still can't discover what the problem is with GZIP files so I'm unsure what details or info are essential here.
Thanks in advance for any help or clues.

My PC info:
6/25/2014 9:10:45 PM | | Starting BOINC client version 7.2.42 for windows_x86_64
6/25/2014 9:10:45 PM | | log flags: file_xfer, sched_ops, task
6/25/2014 9:10:45 PM | | Libraries: libcurl/7.25.0 OpenSSL/1.0.1 zlib/1.2.6
6/25/2014 9:10:45 PM | | Data directory: C:ProgramDataBOINC
6/25/2014 9:10:45 PM | | Running under account Yaweh
6/25/2014 9:10:45 PM | | CAL: ATI GPU 0: AMD Radeon HD 6570/6670/7570/7670 series (Turks) (CAL version 1.4.1848, 1024MB, 991MB available, 1248 GFLOPS peak)
6/25/2014 9:10:45 PM | | OpenCL: AMD/ATI GPU 0: AMD Radeon HD 6570/6670/7570/7670 series (Turks) (driver version 1445.5 (VM), device version OpenCL 1.2 AMD-APP (1445.5), 1024MB, 991MB available, 1248 GFLOPS peak)
6/25/2014 9:10:45 PM | | OpenCL CPU: AMD FX(tm)-4300 Quad-Core Processor (OpenCL driver vendor: Advanced Micro Devices, Inc., driver version 1445.5 (sse2,avx,fma4), device version OpenCL 1.2 AMD-APP (1445.5))
6/25/2014 9:10:45 PM | | Host name: HAL-9000
6/25/2014 9:10:45 PM | | Processor: 4 AuthenticAMD AMD FX(tm)-4300 Quad-Core Processor [Family 21 Model 2 Stepping 0]
6/25/2014 9:10:45 PM | | Processor features: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 htt pni ssse3 fma cx16 sse4_1 sse4_2 popcnt aes syscall nx lm svm sse4a osvw ibs xop skinit wdt lwp fma4 tce tbm topx page1gb rdtscp
6/25/2014 9:10:45 PM | | OS: Microsoft Windows 7: Ultimate x64 Edition, Service Pack 1, (06.01.7601.00)
6/25/2014 9:10:45 PM | | Memory: 7.90 GB physical, 15.81 GB virtual
6/25/2014 9:10:45 PM | | Disk: 398.07 GB total, 281.29 GB free
6/25/2014 9:10:45 PM | | Local time is UTC -7 hours

A typical "problem task" - almost all of which have this error in common "attempt to create gzip file failed"

Task ID 669582044
Name benchmark_0014_alex_metric_58c8eb0a169e5c49e1cef5331416f2432f6d8260_ploops_32_input_0002_no_lig_fragments_contact_opt_iteration_1_dbe4269ef4fb4de99e2f824cdcbaf1c6_fold_SAVE_ALL_OUT_170252_2287_1
Workunit 607401441
Created 23 Jun 2014 6:29:16 UTC
Sent 23 Jun 2014 6:37:42 UTC
Received 25 Jun 2014 16:30:45 UTC
Server state Over
Outcome Client error
Client state Compute error
Exit status 0 (0x0)
Computer ID 1651978
Report deadline 3 Jul 2014 6:37:42 UTC
CPU time 10494.31
stderr out
(I omitted lots of entries here, but can post them if need be)]
WARNING! attempt to create gzipped file ../../projects/boinc.bakerlab.org_rosetta/benchmark_0014_alex_metric_58c8eb0a169e5c49e1cef5331416f2432f6d8260_ploops_32_input_0002_no_lig_fragments_contact_opt_iteration_1_dbe4269ef4fb4de99e2f824cdcbaf1c6_fold_SAVE_ALL_OUT_170252_2287_1_0 failed.
======================================================
DONE :: 1 starting structures 10494.3 cpu seconds
This process generated 11 decoys from 11 attempts
======================================================
BOINC :: WS_max 5.23223e+008
BOINC :: Watchdog shutting down...
BOINC :: BOINC support services shutting down cleanly ...
called boinc_finish
</stderr_txt>
<message>
upload failure: <file_xfer_error> <file_name>benchmark_0014_alex_metric_58c8eb0a169e5c49e1cef5331416f2432f6d8260_ploops_32_input_0002_no_lig_fragments_contact_opt_iteration_1_dbe4269ef4fb4de99e2f824cdcbaf1c6_fold_SAVE_ALL_OUT_170252_2287_1_0</file_name>
<error_code>-161 (not found)</error_code>
</file_xfer_error>
</message> ]]>
Validate state Invalid
Claimed credit 75.4130190048912
Granted credit 75.4130190048912
application version 3.52

---

CIAO Auf Wiederesehen ALOHA Saludos SHALOM Sayonara ADIEU Arrivederci G'DAY!

Q1: Why does the task details on these errors show that credit was granted? My results page never shows any credits granted for tasks ending in errors.

Credit is granted for errored tasks in the belief that failures can help the scientists improve their work (bugs can be fixed and imprecise formulae can be refined). Hoewver BOINC's normal credit systems can't handle awarding credit for errors, so a separate script is run each night to award credit.

Mod.Sense wrote:

The granting of credit for errors is done daily, and when it occurs, the credit is NOT shown on the list of WUs

As Mod.Sense said recently in another thread, the credit does not show up in the work unit page. However looking at your recent work, the amount of credit claimed and granted on failed tasks are shown in the task page.

Q2: Is there a fix for these errors? I could be running something else instead of Rosetta with very few tasks ending in an error or invalid validate state instead. I don't care about accumulating credits to impress anyone with but I do care about wasting my CPU time on tasks that consistently end up with the same error (involving gzip files)

Errors happen from time to time in experimental science. Looking at your recent work you have had 5 failed tasks in the last 48, so you are still pushing through a lot of completed results. The scientists may also be able to retrieve some completed work from your errored tasks (in addition to the error report helping them make improvements).

If you want to help the scientists further you can report your errors in the bug report thread for the current version of the software (Minirosetta 3.52 at the moment). That will hopefully speed up the process of them tracking down the problems and also highlight if there any common issues appearing.

Looking at the 3.52 thread there is at least one other recent report of gzip file problems so it is probably a software or task glitch rather than a fault on your end.