From: isw on
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
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
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
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
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