Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Dropbox will kill your insane MacBook Air 2013 battery

blog.nicoschuele.com

Post reply on HN
Print view View original

101–110 of 111 posts

Re: Dropbox will kill your insane MacBook Air 2013 battery

#102

Post by streeter »

Terretta wrote: post #70
wslh wrote: post #65

Earlier quoted context omitted.

So, we need a per application battery usage indicator? Surely this application exists.

It's in beta, coming this fall: Mavericks. The new battery indicator on the menu bar identifies apps that consume the most energy, and Activity Monitor now details energy consumption per process. First in list of features: https://developer.apple.com/osx/whats-new/

Anyone running Mavericks seen what it says for Dropbox? I've seen reports for Chrome and Safari, but not Dropbox yet.

Re: Dropbox will kill your insane MacBook Air 2013 battery

#103

Post by waterhouse »

"I just have to change my habit of having it constantly on while working. Turn Dropbox on and sync before starting to work and then turn it off."

Hohoho. Allow me to suggest a solution. Suppose that you would be ok with having Dropbox sync files every five minutes. Let's suppose that 10 seconds is usually more than enough to do whatever syncing is necessary. Well, then:

  $ while :; do killall -STOP Dropbox; sleep 300; killall -CONT Dropbox; sleep 10; done
I do things like this to throttle the CPU usage and, in some cases, the power consumption of applications that really don't need what they're using. This really should be a feature provided by the operating system, but in the meantime, I resort to ridiculous hacks of this sort. (Note that, if you ^C the above loop, Dropbox will likely be still STOPped and you'll have to CONT it again. It is possible to write a more sophisticated program to address this problem.)

Re: Dropbox will kill your insane MacBook Air 2013 battery

#104

Post by tluyben2 »

tommorris wrote: post #85
tluyben2 wrote: post #7

Earlier quoted context omitted.

You can also, what I did, switch dropbox off and switch it on only when you are connected to power for a sync. It's not ideal, but it works. I don't see how dropbox could do better though. If you do it manually to your NAS, you basically do the same as switching dropbox on/off or dropbox in a cronjob. Anything monitoring your file system and synching up with many small files will incur load like this.

I use ControlPlane - http://www.controlplaneapp.com/ - which monitors your "context" (like location etc.) and lets you trigger events on context change. Just added some rules so that Dropbox quits when I'm in my "mobile" context, but reopens when I am in my "home" or "office" contexts. Will see whether it works on my commute later.

Nice! Thanks for that tip.

Re: Dropbox will kill your insane MacBook Air 2013 battery

#105

Post by tommorris »

tluyben2 wrote: post #104
tommorris wrote: post #85

Earlier quoted context omitted.

I use ControlPlane - http://www.controlplaneapp.com/ - which monitors your "context" (like location etc.) and lets you trigger events on context change. Just added some rules so that Dropbox quits when I'm in my "mobile" context, but reopens when I am in my "home" or "office" contexts. Will see whether it works on my commute later.

Nice! Thanks for that tip.

And I'll note that after my commute home, I do seem to have a bit more battery life than usual. So that's a win.

Re: Dropbox will kill your insane MacBook Air 2013 battery

#106

Post by aidos »

Osmium wrote: post #77
aidos wrote: post #54

Earlier quoted context omitted.

Dropbox has its own process though, doesn't it? dbfseventsd. sudo fs_usage -w I've been watching it recently and it seems to touch files that it shouldn't need to. I need to do more investigation. I uninstalled backblaze recently because I discovered that it manually scans the whole filesystem _all the time_.

Thanks for the Backblaze info! That's really good to know. Do you know if CrashPlan is any saner? Resource usage was a big factor when deciding between the two, and I want to know if I've made the right choice :)

I haven't used CrashPlan so I can't really say, sorry. I've moved to Arq now which has been working very well for me but it's OSX only.

Re: Dropbox will kill your insane MacBook Air 2013 battery

#107

Post by Osmium »

aidos wrote: post #106
Osmium wrote: post #77

Earlier quoted context omitted.

Thanks for the Backblaze info! That's really good to know. Do you know if CrashPlan is any saner? Resource usage was a big factor when deciding between the two, and I want to know if I've made the right choice :)

I haven't used CrashPlan so I can't really say, sorry. I've moved to Arq now which has been working very well for me but it's OSX only.

Thanks for the reply -- I've looked at Arq before too. I find it interesting Arq (S3) is a third the price of Tarsnap (S3).

Out of interest, if you don't mind me asking, how large is your backup, and do you use S3 or Glacier backend?

Re: Dropbox will kill your insane MacBook Air 2013 battery

#108

Post by nitrogen »

mikevm wrote: post #95
nitrogen wrote: post #67

Earlier quoted context omitted.

Your files may have changed between logins (multi-user system, multi-OS system, etc.).

In that case, you can look at the modified date first. Better than re-calculating hashes. I guess the methods I propose will not guarantee proper syncing if for some reason a file has changed but the metadata hasn't...

A hashing/checksumming filesystem would make it possible to determine whether a file's contents have changed without reading the file. The burden of computing the checksum is then shifted to writing, which in theory occurs once per sync in the case of Dropbox. This burden is merely computational, rather than a complete disk I/O burden imposed by hashing the file when Dropbox restarts.

Re: Dropbox will kill your insane MacBook Air 2013 battery

#109

Post by aidos »

Osmium wrote: post #107
aidos wrote: post #106

Earlier quoted context omitted.

I haven't used CrashPlan so I can't really say, sorry. I've moved to Arq now which has been working very well for me but it's OSX only.

Thanks for the reply -- I've looked at Arq before too. I find it interesting Arq (S3) is a third the price of Tarsnap (S3). Out of interest, if you don't mind me asking, how large is your backup, and do you use S3 or Glacier backend?

Interesting question - I hadn't gotten around to checking the numbers yet myself. So,

  Indexes are stored in S3, data is on Glacier
  ~450GB of data stored
  316,189 Requests to upload it all (main cost)
  $17.39 to upload it all
  $5.09 to store it last month (but upload was incomplete)
  Expect closer to $6-$7 to store it this month
  ~$120 to restore it all (that was a back of the napkin figure before I started)
Arq has a number of good things to recommend it. The creator lurks around here, which is always nice to know. The design is very sensible - it's basically a git index on S3 with the data blobs in Glacier. The storage format is open and documented. All the data is encrypted using your own key locally and then pushed to your own AWS account. It works out really cheap if you use Glacier (only planning on restoring in catastrophic circumstances).

It all just works. The interface is easy and intuitive. I pushed my data to the EU region since it's closer. The more I think about it the happier I am with my choice at the moment. Even if I changed my mind and stopped using it - it's nice knowing that for a few dollars a month I have a huge snapshot of my data in a reasonable format in my AWS account.

Post reply on HN