[mirror-admin] Slow syncing?

[Stephen John Smoogen]

On Mon, Jan 11, 2010 at 3:46 AM, J.H. <warthog9 at kernel.org> wrote:
> Marek,
>
> You are correct I'm measuring the complete time from start to finish.
> That said the data is still valid, the time it takes to generate the
> file list should be relatively uniform across runs (not perfectly I'll
> admit but close enough for my purposes).  That said I don't use the
> start time / duration in my graphs for anything other than when the
> process started / ended.
>
> The transfer speed is used from the values rsync gives back, or in the
> case below: 28379.86 bytes/sec, so those should be accurate.  A sync
> that does nothing is still going to transfer very little and it's
> internal measurements are far more accurate / useful for graphing
> purposes than anything else I have.
>
> Bonus, since 'null' runs are so small in comparison to a real update
> they more or less are going to get drowned out in the graphs by the
> larger more obvious syncs, which given the graphs I've already sent are
> very obviously faster at least for me.
>

What I am wondering if there is some sort of upstream bandwidth
shaping we are running into which rewards small file transfers but
hurts long/large transfers.

Could some other people please use John's script to see if they get
better results on small transfers versus long ones? And John could you
check for say something larger to see if you get a consistent speed
for DVD that matches other people. If not then we need to go over the
routing differences between one side and another to see who the
culprit might be.

-- 
Stephen J Smoogen.

Ah, but a man's reach should exceed his grasp. Or what's a heaven for?
-- Robert Browning

--