ARM64 Headless test build

Hello everyone!

We are excited to announce that we’ve come up with an ARM64 test build for you to try here:

ARM Headless test build 32-bit

ARM Headless test build 64-bit

RPM ARM64 Headless test build
Fedora 30
Fedora 31

Please do note that this is for server/headless set-ups.

Let us know what you think!

2 Likes

I just tried to install this on my Raspberry Pi (running a 64-bit Debian derivative), and the linked file appears to be 32-bit, not 64-bit.

Hi @necopinus :slight_smile: We’ll release a 64-bit soon! Many thanks for the feedback.

Apologies about that. Links updated! :slight_smile:

1 Like

I installed the ARM64 binary on a Raspberry Pi 4B and am currently performing a first sync. It will take a couple of days before everything is downloaded, so I’ll report back then.

So far, the only problem I’ve seen is that I’m experiencing an intermittent crash when running insync-headless status; it is almost identical to the issue reported here:

The only difference is that the line number for cli.py is 365 for me, rather than 362 for the original poster.

Despite this error syncing appears to be running fine, at least for my Google Workspace account. I have two personal Google accounts that are being synced as well, and it’s unclear if they’re hung or not… Interestingly, I got the above crash initially, then this morning found that the status command was working but that both personal accounts showed authentication errors. I re-authenticated, and everything seemed to be fine (the personal accounts both began pulling down more data), but a few hours later both accounts appear to be stalled again and status is also crashing. That said, no new authentication errors in out.txt, so… ¯\_(ツ)_/¯

I’ll report back results once I get a full sync of everything (or at least a full sync of my Google Workspace account, since then problems with personal accounts should be more obvious).

Quick update: I’m definitely seeing some hangs as well. Most clear up in an hour or two, but folders that hang seem to get stuck indefinitely on “scanning”. Restarting might temporarily resolve the problem (not enough has been synced yet for me to do a definitive test).

Digging into the errors in out.txt reveals exactly the same API error as described here is occuring:

Going to keep on keeping on to see if I can get a full sync.

1 Like

Hey there! Thanks for the report! Can we get your logs.db so we can investigate, please?

Here’s how:

Logs submitted.

As a quick note, I’ve gotten a full sync now. I had four issues during the process (which involved pulling down ~1.3 TB of data, and then moving ~30 GB of that data to other accounts. Almost all of these issues match those described in other forum threads, and I thus don’t think they’re ARM64-specific.

  1. Intermittent crashes of insync-headless status. These crashes only occurred during the first third of the sync process, and may be related to Insync trying to get a handle on my very large data set.

  2. A “Daily Limit for Unauthenticated Use Exceeded” error. This would cause files (and sometimes entire folders) to hang for minutes (files) to hours (folders). However, Insync always eventually recovered.

  3. Possibly related to the above, at some point during the initial sync every account that I added eventually took one error that caused insync-headless error list to prompt me to “log in again”. However, after indicating that I wanted to log in again, Insync then continued normally. Both consumer accounts took this error relatively early in the sync process, but my Workspace account took it somewhere after the half-way mark. Genuinely not sure what to make of this.

  4. Finally, towards the end of the process where I was re-arranging (and thus uploading) ~30 GB of data, Insync began taking a different rate limit error. This error didn’t clear up when I just let Insync run overnight (no back-off?), but taking the suggestion from the linked thread to just turn off Insync for an hour and then start it back up again worked around the issue.

That all sounds like a lot, but every single one of these issues could be worked around, and most of them have occurred in non-ARM64 builds… So at least in my testing this build seems good.

Thank you for your team’s work with this — having an ARM64 build of insync-headless will make my life a lot easier. I hope that it continues to get support and development!

2 Likes

Hi @necopinus,

I truly appreciate your detailed walkthrough! I’ve also received your logs and responded to that email :slight_smile:

One last note…

I have an older x86_64 laptop running an Ubuntu derivative that I don’t use that much anymore (I mostly keep it around for when I need to access a Windows VM). After getting everything synced up on my Raspberry Pi 4B with the ARM64 build from this thread, I decided that to install Insync on that box too just to have some data redundancy.

My initial sync using the Raspberry Pi 4B took ~3 days, which is about the same time it takes to pull all of my data down using rclone. So I was expecting similar performance on the old laptop. But to my surprise, the speed of the Insync x86_64 desktop client was ~10x faster than on the Raspberry Pi 4B (or rclone) on the same network connection! (So, what took ~3 days on the Pi finished overnight on my old laptop.)

So this is an unexpected point of feedback — there’s something about the ARM64 headless build of Insync that makes it much slower than the equivalent x86_64 desktop build. This may be related to some of the hangs I noted in my previous post, or might have something to do with the fact that the Pi has 4 cores and my old laptop has 8 cores.

Again, the sync ultimately finished successfully on both systems, so the build here works. But a ~10x speed difference is surprising.

1 Like

Hey! That’s definitely an interesting result and I’d like to thank you for sharing your experience on both machines. I’ll send this over to our engineers so we can investigate the sync performance further!

Hey @necopinus - upon checking it seems to stem from the difference wit the number of cores. It’s doubled in the 2nd machine, so it’s expected to be faster - combo of better RAM + CPU speed :slight_smile:

That makes sense. There definitely is a performance difference between the two machines, but normally I don’t find it that noticeable. But a small difference x alarge amount of time is more noticeable than a small difference x a small amount of time, so that makes sense.

Thank you all again for an ARM64 build!

1 Like

Thank you for your continued trust and support in our product, @necopinus! :slight_smile: