My uploads are building up again =(

Same here. Frustrating.

Edit: Maybe suddenly cleared up? Nice.

Still having a box with 240+ WUs that cannot upload. :(

The 100 GB limit is -

If you DO NOT check the "Use no more than XXXX GB" box, the default value is 100 GB.

In other words, checking the box with a value of 100 GB is the same as not checking it at all.

When I learnt of this limit, I just set it to 1000G in the preferences and controlled disk usage through 'the use no more than xG' or 'eave at least yG free'. The preferences clearly state that the lowest of the 3 limits will be used.

"If you don't install the 32-bit libraries your tasks will eventually keep crashing, and hence your device will get jailed. "

Unfortunately I don't think that is the case - though I stand to be corrected.

It depends on what sort of work you're being offered to crunch.

If it's UK Met office 'Hadley' tasks, they'll always fail.
If it's the newer IFS tasks, thy're not guaranteed to be successful - but it won't be for a lack of 32-bit libraries.

Thank you Richard, that is a very useful clarification.

It's actually even simpler in Linux. Stop the client, mv the whole directory to the new location, create a symlink pointing to the new location with the name of previous directory and then start the client. The client will continue to operate on the old directory name except that's now just a link to the new directory. (Of course you can go the other route of changing boinc client config to use new directory name, similar to the Windows setup you described, but involves config editing. )

I've just tried that, and it didn't work. My problem is that neither SuperUser nor BOINC can follow the symlink to the new drive after reboot: if the logged-in user (me) mounts the drive manually, it works for SuperUser, but not BOINC.

All the gory details are in my 'Help requested thread' in the Linux area - it would be much appreciated if you could take a look and suggest what I might be doing wrong.

@wujj123456 - problem solved, no need to follow up. But for the record - you also have to add the new disk to fstab, and if using UUIDs, use the UUID of the formatted partition, not the UUID of the underlying hardware.

All my uploads had cleared up. Jippiee =D

@wujj123456 - problem solved, no need to follow up. But for the record - you also have to add the new disk to fstab, and if using UUIDs, use the UUID of the formatted partition, not the UUID of the underlying hardware

Congrats! Yeah, mounting on boot and sometimes permission could be a problem when migrating to a new disk and glad you sorted it out.

Finally cleared all of my backlog. Got decent speed for the past 24 hours, especially during the last 12 hours that maxed out my upload link. Yay!

Finally cleared all of my backlog. Got decent speed for the past 24 hours, especially during the last 12 hours that maxed out my upload link. Yay!

36 hours of unattended crunching with a limit of two tasks running at once has left me with about 300 files to upload. I think this is just my slow connection which can just cope with two of the standard uploads but starts falling behind every time a 122.zip which is almost twice the size comes up. I have suspended crunching till things clear a bit.

Here we go again:
21 Jan 2023 17:43 UTC Error reported by file upload server: can't write file oifs_43r3_ps_[…].zip: No space left on server

Just had 3 uploads fail at 100% with same message
"No space left on server"

Just had 3 uploads fail at 100% with same message
"No space left on server"

Me too, but 8 having trouble. All 8 are 100% uploaded, but most recent Event Log messages ...

Edit 1: They have all gone through now. It actually reloaded each one again.

Sat 21 Jan 2023 01:20:32 PM EST | climateprediction.net | Started upload of oifs_43r3_ps_0973_2009050100_123_978_12195617_0_r724200919_36.zip
Sat 21 Jan 2023 01:20:36 PM EST | climateprediction.net | [error] Error reported by file upload server: can't write file oifs_43r3_ps_0973_2009050100_123_978_12195617_0_r724200919_36.zip: No space left on server
Sat 21 Jan 2023 01:20:36 PM EST | climateprediction.net | Temporarily failed upload of oifs_43r3_ps_0973_2009050100_123_978_12195617_0_r724200919_36.zip: transient upload error
Sat 21 Jan 2023 01:20:36 PM EST | climateprediction.net | Backing off 00:02:33 on upload of oifs_43r3_ps_0973_2009050100_123_978_12195617_0_r724200919_36.zip

---

What's annoying is that my boxes are still sending upload traffic, it seems - the upload runs, and then fails at the end.

Oh well. Suspend network traffic and crunch on (or finish WUs and put the CPUs to something else - it's time for a maintenance cycle on my boxes). Not like this is new to any of us.

Wasn't the upload rate supposed to be monitored and below the offload rate, so this wouldn't happen again? Seems like the sort of thing one would set to page the admin at 10% free space or such...

I've been playing with some GCP "Spot" instances (like preemptible, but won't power off automatically at 24h, especially if they're small) to add some cycles, and the AMD boxes are churning along hard. I suppose I'll shut those off, they're not exactly long on disk space. :/

The occasional one gets through:

21/01/2023 18:23:12 | climateprediction.net | Finished upload of oifs_43r3_ps_0802_1993050100_123_962_12179446_0_r599420434_12.zip

I think it must be that the transfer to backing storage is still running, but too slowly - compared to the rate of incoming uploads, at any rate.

It is in YoYo miode, I guess one could say..

Another bunch uploaded to 100% but failed. Massaging the Retry button got them to all go up, but ..
Now I just have three more. 8-(

---

Perhaps it's casual weekend crunchers turning on their computers and finally started to offload their backlog after three weeks. Hopefully the transfer process can eventually win out...

I've been playing with some GCP "Spot" instances (like preemptible, but won't power off automatically at 24h, especially if they're small) to add some cycles, and the AMD boxes are churning along hard. I suppose I'll shut those off, they're not exactly long on disk space. :/

Curious what's your $ per WU. I've also recently checked EC2, GCP or Azure and they all have that nice catch of bandwidth cost. Their bandwidth costs around $0.08-0.1 per GB and that would mean around $0.15 - $0.2 per WU. That alone already exceeds cost per WU for whatever I can get with my own equipment, electricity and home network. Azure covers first 100GB and others' free usage is negligible.

I honestly wonder if I missed some great deals hidden in their pages of pages of pricing list. Would be nice to cross check. Otherwise, until the bandwidth to compute ratio significantly drops, OpenIFS probably makes no sense in major cloud vendors.

Perhaps it's casual weekend crunchers turning on their computers and finally started to offload their backlog after three weeks. Hopefully the transfer process can eventually win out...

I suppose so.

I run my machines 24/7 and take them down at most once a week for updates. The little Windows 10 box has not run any CPDN in a very long time. My big RHEL8.7 box has been running 5 Oifs jobs at a time for quite a while. Over the last few days, it was having no trouble uploading the "trickles." But today it has most recently gotten up to 13 trickles behind. Right now it is four behind with a 9-minute backoff.

Average upload rate 	3840.21 KB/sec
Average download rate 	5713.52 KB/sec
Average turnaround time 2.64 days

---