From: isw on 9 Mar 2010 00:10 In article <080320101135372551%nospam(a)nospam.invalid>, nospam <nospam(a)nospam.invalid> wrote: > In article <1jf17w7.1v1q9551p0p1cqN%nospam(a)see.signature>, Richard > Maine <nospam(a)see.signature> wrote: > > > > one that the vast majority of the time everyone wants completed as quickly > > > as possible. > > > > I wouldn't argue against it being a majority, but I think the "vast" > > overstates it. I have certainly read plenty of complaints about TM > > causing annoying slowdowns in other tasks. And I've read others where > > people didn't know that TM was causing their slowdowns, but that did > > later emerge as the cause. I have definitely noticed the slowdowns > > myself - enough so that if my machine suddenly seems to slow down, > > that's one thing I imediately check for - is TM running? That's one > > reason I set my TM schedule to kick off at most every 4 hours instead of > > every hour. > > i've never noticed any slowdown at all when time machine copies files. Depends on what else you're doing. Ever try it while running some processor-intensive filters in GIMP or Photoshop, trying to get the parms juggled to your liking? That's when the lag gets really annoying; T-M can hog things for several seconds at the time. What I would expect from a well-written backup app would be that it runs fast when nobody else wants to use the machine, but graciously backs off when other apps need processor cycles. Isaac
From: nospam on 9 Mar 2010 01:08 In article <isw-E890B1.21103208032010@[216.168.3.50]>, isw <isw(a)witzend.com> wrote: > > i've never noticed any slowdown at all when time machine copies files. > > Depends on what else you're doing. Ever try it while running some > processor-intensive filters in GIMP or Photoshop, trying to get the > parms juggled to your liking? gimp is pig slow no matter what you do. time machine has kicked in when i'm compiling, using photoshop or working with video. i have yet to notice it copying, other than every now and then i notice a disk icon appear and disappear. > That's when the lag gets really annoying; > T-M can hog things for several seconds at the time. not in my experience. you might have disk issues or some other configuration problem. i once had bad blocks on a hard drive and when time machine kicked in, the machine locked up while it was retrying the blocks. the hard drive was replaced and everything was back to normal. > What I would expect from a well-written backup app would be that it runs > fast when nobody else wants to use the machine, but graciously backs off > when other apps need processor cycles. based on that, time machine would qualify as a well written backup app. it sucks for other reasons but not the ones you just listed.
From: Kevin McMurtrie on 9 Mar 2010 01:54 In article <isw-2D81AE.21044408032010@[216.168.3.50]>, isw <isw(a)witzend.com> wrote: > In article <slrnhpb7ef.gpu.g.kreme(a)cerebus.local>, > Lewis <g.kreme(a)gmail.com.dontsendmecopies> wrote: > > > In message <1jf17w7.1v1q9551p0p1cqN%nospam(a)see.signature> > > Richard <nospam(a)see.signature> wrote: > > > Lewis <g.kreme(a)gmail.com.dontsendmecopies> wrote: > > > > >> And how do you propose to throttle the file copying when it's a backup > > >> as opposed to any other time? > > > > > It is common enough with other kinds of backup software. My mozy remote > > > backup has an option to throttle the bandwidth it uses. > > > > Bandwidth != writing to disk > > > > > It even allows > > > you to specify time periods when the throttling applies. I've seen other > > > utilities with simillar things. Sure, they are most commonly throttling > > > to avoid hogging your internet connection instead of anything local, but > > > I see no essential difference in principle, or likely in implementation. > > > > Well, it's nice thet you don't see any difference. I'm sure it must be > > trivial. WHy don't you just whip up a version of Time Machine that > > behaves the way you want it to? > > > > Simply put, it is not at *ALL* the same. > > > > Hint: When I tried out Crashplan writing to another disk hogged the > > entire machine. > > > > > Apple doesn't happen to do that with TM at the moment, but I'd be > > > surprised if there were any fundamental reason why they couldn't. > > > > Prepare to be surprised, if you ever decide to actually learn anything > > about disk IO. > > > > > And I would question the "vast" in > > > > >> one that the vast majority of the time everyone wants completed as > > >> quickly > > >> as possible. > > > > > I wouldn't argue against it being a majority, but I think the "vast" > > > overstates it. > > > > I'll go further. I am willin to be that, to five nines, people want disk > > IO to complete as fast as possible. That is 99.999% of the time. > > You seem to be confusing "Disk IO" with the overall performance of a > backup application. > > There is no reason why it is necessary for a backup task to saturate the > disk channel continuously for a long period of time. If it writes small > chunks, with pauses between, the user will experience less lag. Simple. > > Isaac As far as I can tell, OS X has no support for I/O prioritization like it does for the CPU. An application can't do it itself either. Measuring fluctuations in latency to detect saturation, as is done for networks, would not work for a disk because of variable seek times and pre-fetching into caches. Voluntary pauses, which really kill performance, would be the only way to make it work. The problem comes down to OS X needing a major change to how it handles I/O. You can 'nice' a process to the max but it can still suck up so much I/O that nothing else runs. -- I won't see Google Groups replies because I must filter them as spam
From: nospam on 9 Mar 2010 02:41 In article <slrnhpbucg.1j9t.g.kreme(a)cerebus.local>, Lewis <g.kreme(a)gmail.com.dontsendmecopies> wrote: > As it > is, backups run in 3-5 minutes on local disk and 10-20 minutes over the > newtork, so there is plenty of time befor ethe next schduled backup. how much stuff are you changing? my backups are over a wifi network and they take about 1-2 minutes. the one that just ran took just 78 seconds, looking at the console logs.
From: Richard Maine on 9 Mar 2010 03:30
Lewis <g.kreme(a)gmail.com.dontsendmecopies> wrote: > Pointing out ignorance is not a 'personal insult'. Then I'll note that you are ignorant about what insults are. Welcome to my kill file. -- Richard Maine | Good judgment comes from experience; email: last name at domain . net | experience comes from bad judgment. domain: summertriangle | -- Mark Twain |