I have a few large uploads that seem to not be able to upload. in both cases it is the large _9 file that will not go through. each time it tries, it gets a "transient http error" and then immediately backs off.

there is no problem connecting to the project, and more tasks will download, and the smaller tasks upload just fine.

is there a problem on the project side that's preventing the large files from uploading? do you have a limit in place? the affected are 509.74MB and 512.24MB respectively.

---

just finished another task on the same system, _9 file size is 491MB, and uploaded just fine, while attempting the trouble files >500MB at the same time still returned the transient http error.

definitely seems to be some kind of file size limit on the project side.

would be great to get this looked at so I can report these results and not waste ~30+hours of crunch time.

---

We've been round this cycle before - quite recently, in fact.

The limit is set in the task specification sent by the project, and applied by the client:

<file>
<name>e3s506_e1s419p0f1179-ADRIA_New_KIXcMyb_HIP_AdaptiveBandit-1-2-RND7999_2_9</name>
<nbytes>0.000000</nbytes>
<max_nbytes>1024000000.000000</max_nbytes>
<status>0</status>
<upload_url>https://www.gpugrid.net/PS3GRID_cgi/file_upload_handler</upload_url>
</file>

That's a limit set in bytes, not MiB - it's smaller than it looks.

Maybe you got an old resend, with the previous 512000000 limit still in place? You can fix that yourself, if you spot it before the task finishes. Stop the client - making sure you know which task was running on which card. Edit client_state.xml to give yourself enough headroom, and start the client again.

no, this is quite different. I've very familiar with the old issue, this is new.

the problem before was related to the file size limit in the client_state file. when this was exceeded, it caused a straight up computation error when attempting to upload. that is NOT happening here. the file upload attempts, and the project responds with a "transient http error" as reported by BOINC. and the file stays stuck in the transfers indefinitely. I've checked the client state already and confirmed that these files are listed with a max upload limit of <max_nbytes>1024000000.000000</max_nbytes>

Sun 04 Jul 2021 05:33:12 PM EDT | GPUGRID | Temporarily failed upload of e5s86_e1s499p0f1068-ADRIA_New_KIXcMyb_HIP_AdaptiveBandit-1-2-RND5913_5_9: transient HTTP error

this is why I suggest that there may be some max file size limit on the project side that is rejecting the transfer.

---

OK, different. You should be able to see the actual size of the file in question using 'properties' in your equivalent of File Browser, or CLI equivalent. Post that where Toni can see it. It may be quickest for him to compress the file (if it isn't already) - that should buy some time until the next bout of inflation.

Edit - I have two tasks due to upload overnight (UK time). I'll watch out for them in ten hours or so, when I get up.

Edit 2 - you can usually get more detail on "transient http error" by setting the 'http debug' Event Log flag - including the exact wording of the response from the file upload handler.

e5s86_e1s499p0f1068-ADRIA_New_KIXcMyb_HIP_AdaptiveBandit-1-2-RND5913_5_9:
BOINC reported file size: 515.24 MB
Linux reported file size: 540.3 MB

e5s136_e3s165p0f813-ADRIA_New_KIXcMyb_HIP_AdaptiveBandit-1-2-RND0460_5_9
BOINC reported file size: 509.74 MB
Linux reported file size: 534.5 MB

likely differences in the way it's calculated.

I don't think you'll see an issue unless the _9 file ends up being >500MB as reported by BOINC. I had several tasks ~490MB go through fine.

---

set the http_debug flag but good god it spams so many messages to the log that it nearly brings boincmgr to it's knees on a fast system.

looks like my hypothesis was correct. server side limit rejecting the transfer because it's too big.

Sun 04 Jul 2021 06:20:46 PM EDT | GPUGRID | [http] [ID#90] Received header from server: HTTP/1.1 413 Request Entity Too Large
Sun 04 Jul 2021 06:20:46 PM EDT | GPUGRID | [http] [ID#90] Received header from server: Date: Sun, 04 Jul 2021 22:20:46 GMT
Sun 04 Jul 2021 06:20:46 PM EDT | GPUGRID | [http] [ID#90] Received header from server: Server: Apache/2.4.6 (CentOS) OpenSSL/1.0.1e-fips mod_auth_gssapi/1.3.1 mod_auth_kerb/5.4 mod_fcgid/2.3.9 PHP/5.4.16 mod_wsgi/3.4 Python/2.7.5
Sun 04 Jul 2021 06:20:46 PM EDT | GPUGRID | [http] [ID#90] Received header from server: Connection: close
Sun 04 Jul 2021 06:20:46 PM EDT | GPUGRID | [http] [ID#90] Received header from server: Content-Type: text/html; charset=iso-8859-1
Sun 04 Jul 2021 06:20:46 PM EDT | GPUGRID | [http] [ID#90] Received header from server:
Sun 04 Jul 2021 06:20:46 PM EDT | GPUGRID | [http] [ID#90] Info:  GnuTLS recv error (-110): The TLS connection was non-properly terminated.
Sun 04 Jul 2021 06:20:46 PM EDT | GPUGRID | [http] [ID#90] Info:  Closing connection 96
Sun 04 Jul 2021 06:20:46 PM EDT | GPUGRID | [http] HTTP error: Failure when receiving data from the peer
Sun 04 Jul 2021 06:20:47 PM EDT |  | Project communication failed: attempting access to reference site
Sun 04 Jul 2021 06:20:47 PM EDT |  | [http] HTTP_OP::init_get(): https://www.google.com/
Sun 04 Jul 2021 06:20:47 PM EDT | GPUGRID | Temporarily failed upload of e5s136_e3s165p0f813-ADRIA_New_KIXcMyb_HIP_AdaptiveBandit-1-2-RND0460_5_9: transient HTTP error
Sun 04 Jul 2021 06:20:47 PM EDT | GPUGRID | Backing off 04:20:04 on upload of e5s136_e3s165p0f813-ADRIA_New_KIXcMyb_HIP_AdaptiveBandit-1-2-RND0460_5_9

---

Thanks for the analysis. It looks like you have uncovered an undocumented limitation! :(

likely differences in the way it's calculated.

Yes, some tools count 1,000 bytes at a time, others count 1,024 bytes - the difference get bigger as the sizes get bigger.

I don't think you'll see an issue unless the _9 file ends up being >500MB as reported by BOINC. I had several tasks ~490MB go through fine.

Yes, both mine uploaded and validated while I slept.

Received header from server: HTTP/1.1 413 Request Entity Too Large

But it looks like you've caught the problem before I could run another test.

With http_debug, I usually wait until there's just one file waiting to upload. Set the flag, retry the upload, unset the flag - then go and examine the entrails in the log. Gets confusing if there are multiple interleaved transfers.

definitely seems to be some kind of file size limit on the project side.

As an emergency bypass, you could try to open your /etc/boinc-client/cc_config.xml file as Administrator, and edit in <options> section the line

<http_1_0>0</http_1_0>

to

<http_1_0>1</http_1_0>

Re-read config files in BOINC Manager and retry the upload.
Whether it works or not, return cc_config.xml to original values and post your experiences, please.

definitely seems to be some kind of file size limit on the project side.

As an emergency bypass, you could try to open your /etc/boinc-client/cc_config.xml file as Administrator, and edit in <options> section the line

<http_1_0>0</http_1_0>

to

<http_1_0>1</http_1_0>

Re-read config files in BOINC Manager and retry the upload.
Whether it works or not, return cc_config.xml to original values and post your experiences, please.

didn't work unfortunately. same error.

---

Then, on server side there is the same size limitation or worse for HTTP V1.0 than for HTTP V1.1.
No more ideas than waiting for the problem to be addresed from server side...

I appreciate the effort :)

But Toni is aware of the problem so hopefully he or someone else at the project can find the setting that needs adjustment and make the change.

---

I offered him some documentation covering Apache and Nginx - looked easy enough...

Not sure if they manage their own server or rely on their institution's tech support team.

Should be solved.

I offered him some documentation covering Apache and Nginx - looked easy enough...

Not sure if they manage their own server or rely on their institution's tech support team.

I don't think i got the memo...

Should be solved.

my two stuck files still won't upload. getting the same error. what did you set the limit to?

---

I offered him some documentation covering Apache and Nginx - looked easy enough...

Not sure if they manage their own server or rely on their institution's tech support team.

I don't think i got the memo...

In your news thread - "What Is a 413 Request Entity Too Large Error & How to Fix It"

https://blog.hubspot.com/website/413-request-entity-too-large

I got four new tasks on Monday, created and issued around 10:00 UTC. Three finished overnight, and the fourth is uploading as I type.

The troublesome _9 file is shown as 524608164 bytes - 524.6 MB according to Linux (1000 convention), 500.31 MB according to BOINC (1024 convention). So in the danger zone, either way. But it's uploaded and reported - I think we're out of the woods on this one.

Just for fun, I tried gzip on the file: the resulting 'compressed' file was 524.7 MB - slightly bigger. So nothing to be gained there - we're already as efficient as we could hope.

What was the size in MB shown on the upload page?

My 2 trouble files still won’t upload, despite Toni claiming that it has been fixed.

---