Camaban

Pi is 100mbit. Not a bottleneck here, just being precise Watch htop on each one and C&P your results.

Not a bad idea. He should be able to do the same to you quite easily. Australian upload sucks, download is..,.. Liveable (Although living in Cambridge, UK, it'll be hard to come down from 120/12Mbps completely fibre for about $50 a month. There's something about downloading at 15MBps that's just.... Awesome...)

Really does, doesn't it? Then again, the only unusual thing you're getting is the HDD space. I've been using them for I think about a month and they've been brilliant. A couple of teething troubles, but nothing remotely deal-breaking.

Get a Los Angeles VPS with an Asian-optimised IP address. (As well as another one in another area... You really do NOT want to re-upload your entire backups if something goes wrong... I'd uploaded 700GB last month overall thanks to a kernel bug) I had friends back home (Brisbane) test it and they were getting about 200ms. The link would have gone via Sydney. As for actual transfer speed (which would be what you're actually interested in) I doubt the link to the server will be your bottleneck. Australian net sucks. Although if you're one of the lucky few who are on the NBN I'd be interested in hearing how it goes.

And, seriously, two in separate locations for $14 It's very affordable.

THat one has been very good for me. I will say take two though. I had some obscenely bad luck which resulted in my VM hitting a kernel bug. Uploading 330GB once is bad. Uploading it twice is just rude.

It is available for Android.

You might think that's your problem, but it isn't. The real problem is Sauron appearing and forging the rings... Don't want that guy coming near your home, and family, let alone your NAS.

Might like to have a read through here: http://httpd.apache.org/docs/2.2/mod/mod_proxy.html

Check your RAM usage. That thing only has 128MB. It *should* be enough, but depending on what else is happening it might not.

in the meantime, could try using links. Might work.

This would be nice. I use an automation program to start on boot, but it's a hack. >>What about syncing Contacts and Calendar to Android?<< This is mainly concerned with file sync at the moment. Plus, there are generally so many ways to get contacts and calendar on/off Android/whatever else that more is superfluous. If you can get it into a file though, you can sync it.

As a general thing, would it be too difficult to get it to display if there's nothing new to sync? I mean, it does 3/4 of the time, but there's something about seeing an upload queue that says 300GB that makes you panic until you double check everything and find that it's just false. :-) Attached what I'm referring to. As far as I'm aware, all these syncs are complete.

Mine is a Windows box that I'm fairly sure was doing a one way transfer. And the transfer window does display the filename. Should be able to search for it. Can't be too many files with the same name (You'd hope)

When I think that, I had something marginally similar to this on two occasions. Please note for both of these that I run Cygwin, it's always possible that I had manipulated my files in an unapproved manner. First was a case of no read/write permissions on those files. Second was a case of the date stamp being corrupt.

... 16MB of RAM? Possibly, but you're basically asking for more than an order of magnitude memory reduction... Keep in mind that not only does that 16MB need to run BTSync, it needs to run your NAS. In this case, I'd say your best bet might be to invest in a Pi and have it handle BTSync over a mapped network share.

Regarding updating to the latest version, it's worth mentioning that I'm running two backup VPS's with 512MB RAM each. On each of these VPS's is 249,025 files taking up 334 GB Largest single share is 300GB Just checked one of the servers (Ubuntu), and it's using 384MB of RAM and about 20-30% CPU (Single core VM) CentOS box is using roughly the same amount of resources. These figures include what the OS itself requires to run a fairly minimal install. Running version 1.1.26 and I can't find much cause for complaint. If you're running 1.0.X however, then it was truly awful when it came to resource usage. I was using my full RAM capacity plus 500MB-1GB of swap space.

Logical date format. IE: YYYY-MM-DD instead of the frankly strange American MM-DD-YYYY

So when you delete it on linux and modify it on Windows, it doesn't get re-uploaded?

It's known. I wouldn't say it's intended so much as it's an alpha, and IIRC, that's on the to-do list.

If it hasn't been suggested, allow for a custom image or something like that. I say this as I reindex a 300GB share I'd deleted on the wrong machine :S

So, basically you're saying that you're sending 98GB of data within 15 minutes. Which means that you're transferring at an average slowest-case speed of 112mBps between everything and everywhere, I'd wonder if maybe your switch isn't quite up to the task. As GreatMarko says, try limiting your speeds and see what happens. A small reduction in speed can make for a dramatic improvement in bandwidth. I haven't actually seen this behaviour on a switch before. At least, I've never seen a switch manage to accept enough punishment to destroy latency (not counting an ethernet over power bridge which decided it did not agree with my usenet habits) but it certainly seems feasible.

I think he's asking why it wasn't re-uploaded. Which I doubt there's an answer except "Don't delete it" - The program will probably assume you deleted it for a reason, and want it gone.

Next question is how frequently are these files altered? If they're not altered frequently, then the only painful bit is likely to be the initial sync. If the initial sync were taking a bit long, you could rsync first, then share and future updates should be synced as they're made.

Just a coincidence from the looks of it.