pCloud drought

pCloud has been unreachable with RISC OS 5.29 and 5.28 for a while now, it errors with “Not logged on”. The login details are correct and did work. The CloudFS module is up to date at 0.33.

There is no problem logging in on the Mac.

No problem here – using ARMX6 RISC OS version 5.29 (02 Nov 2020)

Thanks. I had a feeling this is a just me thing!

“Not logged on”

Do you have a password set on the RISC OS machine, and if so, could it have gone missing? I have, and get this error if I attempt to launch pCloud without entering the password.

The password is present and seen to correct correct in the Mounts file. The login email address is also correct. The same user and password are just fine on the Mac.

Obviously the fix is to set the server to PCloud EU rather that just PCloud. Equally obviously it is a hard space between PCloud and EU. Obviously the Omni front end cannot handle the hard space so it must be entered directly into the Mounts file.

I now have two working pCloud accounts and they keep working over a reboot.

What is going on?

set the server to PCloud EU rather that just PCloud

Hmmm. ‘PCloud’ works just fine here on a Pi4 (RO 5.29 [04-Nov-21]/CloudFS 0.33/OmniClient 2.32).

@ David Pitt

JFYI: pCloud Module 0.33 works totally fine here with RO 5.28 and OmniClient 2.32 (16-Mar-2020)

I am using PCloud (not PCloud EU).

The mystery is partly solved. In pCloud’s user account settings the data server location, EU or US, can be chosen. Both my accounts are set to EU. The old account, which had worked with PCloud, must have migrated to EU when that server was introduced. The new account created yesterday defaulted to EU. Both accounts now require 16.99GBP to move server location.

Both accounts now require 16.99GBP to move server location.

Hmm, a regime that understands privacy versus one that doesn’t. Why would you not want to have an EU server?

Things are getting interesting. Two countries have now ruled that using Google Analytics on a site breaches the GDPR. One should not consider the US to be friendly when it comes to data.
https://www.theregister.com/2022/01/13/google_analytics_gdpr/
https://www.theregister.com/2022/02/10/google_analytics_gdpr_breach/

Why would you not want to have an EU server?

Because it’s on the other side of the world and TCP is slow over long distances.

Hey, you did ask :)

And another shout out for Iris, it can log in to pCloud’s web interface.

Note that in here in the UK pcloud.com lands on the eu site.

Because it’s on the other side of the world and TCP is slow over long distances.

I think there ought to be an available server set in FourEx (The Last Continent)

I note that there are a few here using pCloud. How do you rate the speed? I use it on a Titanium but it is incredibly slow. I have just uploaded a directory of files (admittedly there is a good proportion of small files), total size around 2.5MB. The upload took about half an hour. It seems to take as long to read the files in to memory as to actually send them. TaskUsage shows the filer action window using 100% cpu, and the Titanium is essentially unusable for any other task while the upload is proceding. Broadband here is FTTC at 40Mb/s, and uploading files to my web server via FTP flies.

I am wondering whether there is something odd about my system, or whether this pedestrian speed is normal. I am on v. 0.33 of pCloud and an early Feb version of RISC OS 5.29.

@ Chris

How do you rate the speed?

Very very slow, I just use it for testing purposes, to make sure my software works fine with it, for instance people can add objects from pCloud to the LaunchPad and just making sure everything works with that. Other apps can use it to sync-up entities across geo-separated RISC OS deployment instances etc, so very very small message files.

How do you rate the speed?

It’s a bit rubbish on the RPi400. But it is also rubbish on the iMac so it’s not CloudFS thing AFAICS.

OK guys, thanks. I have only used it very occasionally to check it was still working, but have never used it in anger. At least it is not my system at fault.

How do you rate the speed?

It seeems really quite slow using RISC OS:-
using ARMX6 and 5MB text file:-
upload to cloud 35 seconds
download to ARMX6 24 seconds

The slow speed has not much to do with pCloud as On a Mac M1 transfer up and down for the same 5MB file is sub 1 second.
It is more to do with the machine/os capabilities – see the following table of download and upload speeds.
The measurements were made using www.broadbandspeedtest.org.

               down/Mbps  up/Mbps
mac M1  mac os      70       18
pi400   Pi OS       42       18
pi3B+   Pi OS       52       18
armx6   RISC OS      5        5
pi4     RISC OS     13       12

Despite the slow speed on RISC OS, pCloud is an essential file transfer tool for me as it is the only technology that works across all machines/os combinations.

The slow speed has not much to do with pCloud as On a Mac M1 transfer up and down for the same 5MB file is sub 1 second.

I’m sure that I’ve recently seen words to the effect that the rapid up/download speeds on other platforms is an artifact of the caching. The actual speeds are much slower.

I can’t remember where I saw it or who the authority was (“is” unless he (or she) has even more recently popped their clogs). Sorry to be so vague but that seems to be my par for the course these days.

But it (pCloud uploading) is also rubbish on the iMac

Today that story needs adjustment. Uploads to pCloud from the iMac are off like a rocket, near instantaneous.

Upload rates for a single 10MB file are 3Mb/s on the Titanium and 4Mb/s on the RPi400. FilerAction is up at to 100% cpu.

the rapid up/download speeds on other platforms is an artifact of the caching.

The source of this information was probably Robert Sprowson , or Vince Hudd. We discussed this at a recent MUG meeting. The belief expressed was that Mac and probably Windows and Linux pCloud clients sync the cloud files to local storage. With the result that it is near impossible to make meaningful speed tests with pCloud downloads.
However, the Broadband speed tests in the above post tell their own story.

The source of this information was probably Robert Sprowson , or Vince Hudd. We discussed this at a recent MUG meeting.

Ah yes. Now that you mention it, I remember. I can’t claim my age is the culprit as you’re older than me. :-(

However, the Broadband speed tests in the above post tell their own story.

They certainly do. Like you, I still value pCloud and use it a lot.

Obviously the fix is to set the server to PCloud EU rather that just PCloud.

Since (roughly) Feb 2021 there has been an option to have your data hosted in datacentres in the EU or the US, which for some people is significant given the introduction of GDPR. Accounts can be migrated from one to the other for a fee. Any new accounts will select the closest based on your IP address at the time of creation, though this can be overridden by just changing the Data region drop down menu.

The only practical difference for CloudFS is needing to remember to enter the different datacentre name into OmniClient. Unfortunately there’s no API to query which datacentre a user is on for obvious paradoxical reasons (you’d need to be logged on to make the API call), the Mac/Windows clients probably just try both and see which works!

The slow speed has not much to do with pCloud as On a Mac M1 transfer up and down for the same 5MB file is sub 1 second.
It is more to do with the machine/os capabilities – see the following table of download and upload speeds.

It’s important to mention that with RISC OS the files are transferred as you watch them go in the Filer Action window. The Mac/Windows clients temporarily cache the file locally then send it in the background – John R’s figures illustrate this in action because his broadband speed test shows ~18Mb/s uplink speed, yet an observation that a 5MB (40Mb) file takes less than 1s to send. That would be impossible at 18Mb/s.

Today that story needs adjustment. Uploads to pCloud from the iMac are off like a rocket, near instantaneous.
Upload rates for a single 10MB file are 3Mb/s on the Titanium and 4Mb/s on the RPi400. FilerAction is up at to 100% cpu.

The extra dimension with differences at time of day is usually down to traffic shaping by the ISP. Often they’ll claim no throttling occurs, but in reality file sharing (such as Dropbox and pCloud) often are 2nd class citizens during busy periods when more realtime traffic like a Netflix movie would get a faster route.

And lastly there’s positive feedback built into Filer Action. When it notices the data rate is below <some threshold> it will reduce the chunk size it copies in order to keep the desktop responsive. One thing anyone who remembers using Econet will tell you is sending lots of small packets is slower than sending 1 big packet (100 x OS_BGET versus 1 x OS_GBPB of 100 bytes), so while reducing the chunk size helps with floppy discs, it actually makes things worse here.

With a good broadband connection you’d expect to get around 500kB/s, and that’s improving with each new version as more cunning is applied to dodge the lack of reentrant file operations. However, the more local the storage (cache > RAM > HDD > NAS > cloud) the faster you’ll be, but that’s missing the real utility of a cloud filing system.

yet an observation that a 5MB (40Mb) file

That’s just a calculation of the data content in bits – you missed the packet headers.
For rough calculations, I tend to work on a basis that 5MB data is 50Mb transmitted (i.e. x10)

When it notices the data rate is below it will reduce the chunk size it copies in order to keep the desktop responsive.

On multicore machines, I’m sure there could be general improvement if the transfer was handled by a different core than the desktop etc