I saw a bunch of these went out today.

Even more intense than the D3RBandit units. Runtime/Computation of these new units looks to be about 20% longer.

~12hrs for an RTX 2080 Ti (225W, 1780MHz)
~15-16hrs for an RTX 2080 (185W, 1850MHz)
~20hrs for an RTX 2070 (150W, 1780MHz)
~31hrs for a GTX1660 Super (125W, 1900MHz)
____________

Huston, we have a problem.

My first round of tasks ran to completion, but all hit a computation error right after hitting 100%

<error_code>-131 (file size too big)</error_code>

Well that sucks. I got a bunch of them also. I have about an hour to go on one of them to see if it too bombs out with too big an upload.

Yes, the same problem of file upload too big error.

My first round of tasks ran to completion, but all hit a computation error right after hitting 100%

<error_code>-131 (file size too big)</error_code>

I expect everyone's will fail the same. This is a project-side issue.

That process sounds right. I've been trying to catch a resend myself, but with no success so far (most of the fun seems to have happened overnight, UK time, when I had work fetch suspended).

Two additional points:
1) Usually, GPUGrid tasks produce multiple upload files, though I can't speak for this particular batch until I catch one. I was hoping to report on which particular file was over-size, and by how much the allowed/actual sizes differed. That would help Toni and/or Adria.
2) Depending on how you have BOINC installed, stopping the BOINC client service should be an easy way of ceasing all activity in an orderly fashion, in preparation for the edit.

Am I late to the party? Had my computer running with the gpugrid project attached but didn't get anything. Checked the logs as well, it just keeps saying project has not tasks available.

My first round of tasks ran to completion, but all hit a computation error right after hitting 100%

<error_code>-131 (file size too big)</error_code>

I expect everyone's will fail the same. This is a project-side issue.

Thank you very much for sharing this issue.
In a flash:
I have several of these tasks currently running at my hosts.
The first in finishing is running at a GTX 1660 Ti GPU under Linux OS.
https://www.gpugrid.net/result.php?resultid=32622893
- I've stopped BOINC activity at BOINC Manager.
- I've killed all BOINC processes.
- I've edited as administrator the file \var\lib\boinc-client\client_state.xml
- I've edited all the instances (21) for the mentioned task of <max_nbytes> parameter, adding a leading 10 to the existing value.
- I've restarted boinc-client service, and activity at BOINC Manager.
This task is estimating to finish in about 10 hours. Then I'll report if this bypass has worked.

I was able to edit one task on the host with homogeneous cards. But won't bother with the tasks running on non-homogeneous hosts as they will likely error out from restarting on a different card anyway.

the trouble file seems to be the one labelled "_9". that file is like 475MB and takes several minutes to upload. not sure if any others are over their limits, since each upload file has it's own size limit and they are not all the same.

the trouble file seems to be the one labelled "_9". that file is like 475MB and takes several minutes to upload. not sure if any others are over their limits, since each upload file has it's own size limit and they are not all the same.

I've just picked up a couple of these tasks. The _9 file seems to have a <max_bytes> of 512,000,000. That should be just enough, even though the binary equivalent is 488.28 MB. I'll bump it for safety, and try and catch the exact size when it uploads.

The tasks I've got are freshly created, at 15:42 UTC this afternoon - not resends. They may have made a fresh batch with the problem fixed.

My _9 file currently uploading is 478MB.

I forgot to note down what it was default before I edited it.

My _9 file currently uploading is 478MB.

I forgot to note down what it was default before I edited it.

I suspended BOINC network activity a while before my previously mentioned task finished.

-1) The workaround succeeded for me too. It finished in a valid result after a total processing time of 102996 seconds.

-2) Regarding the generated output files, I took a screenshot that looks as follows:

WHAT a WASTE!
upload failure: <file_xfer_error>
<file_name>e1s8_I3-ADRIA_KIXcMyb_HIP_bandit-0-2-RND3309_0_9</file_name>
<error_code>-131 (file size too big)</error_code>
after running for 118,437 sec = 39.9 HOURS on my GTX 1660 Ti.
Come on, people get with it, Please!

I generally prefer donating my PC power to GpuGrid: you guys publish papers, you do real science to benefit people (so I assume).

BUT, I am not willing to waste either my PC & GPU, nor my power bill.
I am signing OFF this project for a while.
Besides, as these are simulation runs, GPUGRID can set the time to run pretty closely by specifying the number of simulation replications.
For weeks now, my 1660 Ti had been consistently just missing the 24Hr completion mark.
Other GPU projects give double or even ten times the credit per time unit.
LLP, 6-sigma healthcare
____________
LLP, PhD, Prof. Engr.
I think => I THINK I am.
My thinking is not the source of my being, nor does it prove my existence to you.
The Living Word of God
World Youth Day

New tasks have already been reconfigured with a larger file size limit and are being distributed.

They compute and report fine.

For weeks now, my 1660 Ti had been consistently just missing the 24Hr completion mark.

new tasks failing again, even with the higher limt: https://www.gpugrid.net/result.php?resultid=32625435

needs to be higher than 512000000 still
____________

My last *_0_9 file size was 509240934 bytes.
Possibly 512000000 is set too tight for certain tasks.

I guess that something is going on for a definitive solution to lately problems.
I had 5 ADRIA tasks left in process.
They all were canceled by server between 15:53 and 16:36 UTC on 18/06/2021.
149,56 wasted processing hours altogether.
I had applied <max_nbytes> parameter workaround to every of them, but this is something that the server couldn't know...

I applied the fix to all my personal systems also, and you're right, the project couldnt know who did or didn't apply the fix manually. I'm sure there were many more people that didnt fix and would have errored out. While it's unfortunate that some processing time was wasted, I think they made the right call to just cancel them all.
____________

Cancelled tasks here also. I had edited them to survive. Moot now but at least some of them hadn't started yet so no crunching time lost.

New tasks have just started to flow.
I've replenished my buffer: 7 tasks , one for each of my working GPUs.
New New:

...
<name>e3s358_e1s419p0f996-ADRIA_New_KIXcMyb_HIP_AdaptiveBandit-0-2-RND5689_0_9</name>
<nbytes>0.000000</nbytes>
<max_nbytes>1024000000.000000</max_nbytes>
...

New tasks have just started to flow.
I've replenished my buffer: 7 tasks , one for each of my working GPUs.
New New:

...
<name>e3s358_e1s419p0f996-ADRIA_New_KIXcMyb_HIP_AdaptiveBandit-0-2-RND5689_0_9</name>
<nbytes>0.000000</nbytes>
<max_nbytes>1024000000.000000</max_nbytes>
...

seeing nearly all of these tasks instant failing the past 2 days. not sure what's up. there is no verbose error message associated with them. just...fail.

http://www.gpugrid.net/result.php?resultid=32628049

<message>
process exited with code 195 (0xc3, -61)</message>
<stderr_txt>
05:41:09 (894336): wrapper (7.7.26016): starting
05:41:09 (894336): wrapper (7.7.26016): starting
05:41:09 (894336): wrapper: running acemd3 (--boinc input --device 3)
05:41:10 (894336): acemd3 exited; CPU time 0.002381
05:41:10 (894336): app exit status: 0x1
05:41:10 (894336): called boinc_finish(195)

seeing nearly all of these tasks instant failing the past 2 days...

I thought it was me as I got one and the resend hadn't error'd out yet. Good to know.

They're trying again. I got e3s197_e1s419p0f951-ADRIA_New_KIXcMyb_HIP_AdaptiveBandit-1-2-RND9332_0 - newly created this morning - but sadly it failed after 3 seconds.

stderr says 'EXIT_CHILD_FAILED', but no hint of what the actual failure was. We couldn't have a licensing problem again, could we? I've preserved the job specification, but it's unlikely to reveal anything - I'll check it.

i usually see a few _0's roll through every day. all instant fail for the past several days. I sent a message to Toni, but did see any resolution yet.
____________

I couldn't get anything out of the captured work spec - the wrapper rather gets in the way of decoding it. Next time, I'll try capturing the files as well, and running them in terminal - that worked for WCG.

Every of 7 tasks received at my Linux hosts today, all of them starting with "e4s...", have failed after a few seconds past.
Every resends have continued to fail at other varied Linux hosts... until they have been catched by some Windows non-Ampere-GPU hosts.
May be there is some kind of issue regarding Linux application / license (?)

I don’t think it’s a licensing issue. The apps were recreated with an updated license last October, about 9 months ago. Both Windows and Linux were created at the same time, presumably with the same licensing period.
____________

but you're right that it does appear to be a problem with Linux computers. maybe some parameter isnt set right for the Linux app? i see some successful runs on Windows machines.
____________

May be there is some kind of issue regarding Linux application / license (?)

I've received this e3s203_e1s419p0f906-ADRIA_New_KIXcMyb_HIP_AdaptiveBandit-1-2-RND8149_1 task at the Windows host, and it has been running for more than one hour by now.
The computer is the same, the only difference is in Operating System entered.
I think I'll let this task to run to its completion, to check whether it succeeds.
About 44 more hours left, estimated for this GTX 1650 SUPER GPU...

I sent another message to Toni about the issue of Linux tasks. Hopefully a quick resolution.
____________

I sent another message to Toni about the issue of Linux tasks. Hopefully a quick resolution.