Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 9 Jun 2000 14:24:13 +0200
From:      Gerhard Sittig <Gerhard.Sittig@gmx.net>
To:        stable@FreeBSD.ORG
Subject:   Re: changes in dd?
Message-ID:  <20000609142413.Q9883@speedy.gsinet>
In-Reply-To: <200006081940.PAA00971@misha.privatelabs.com>; from mi@privatelabs.com on Thu, Jun 08, 2000 at 03:40:41PM -0400
References:  <20000608194615.N9883@speedy.gsinet> <200006081940.PAA00971@misha.privatelabs.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Jun 08, 2000 at 15:40 -0400, mi@privatelabs.com wrote:
> On  8 Jun, Gerhard Sittig wrote:
> > On Wed, Jun 07, 2000 at 17:08 -0400, Mikhail Teterin wrote:
> > > 
> > > My command line is:
> > > 	ssh -o'Compression no' -e none -c blowfish <server> \
> > > 		dd ibs=1 count=<size> of=/dev/null < /kernel.GENERIC
> > 
> > Look at what you do here:  You shuffle *many* tiny packets
> > around each of them being *one* byte long. This will result
> > in a _very_ tight loop eating time without any making sense.
> 
> I  understand, but  why  am  I seeing  different  behavior on
> different machines? Why  does not April 19  -stable care and
> still  shows the same speed, but the June 2 -stable cares and
> demostrates terrible performance drop?

Look at what the loop body does:  Climb down and up the whole
function stack for every single byte -- from the app (dd) down to
the disk driver, everytime passing the syscall gate (which seems
to be expensive due to protection level and context switches) and
parameter passing and checking and all the like.  And you fetch
every single byte from the file in its own cycle.

Maybe one of the passed interfaces has some additional check or a
slightly different path of program flow.  Keeping the huge(?)
number of cycles in mind, this _can_ result in significant
decrease of performance.  But that's just speculation from my
side.  Additional parameters (which now have to get passed, too)
can have a similar effect.  Or passing parameters by value
instead of just referencing their location.  Or maybe you even
have the same or a similar codebase for both -STABLE machines but
used different compiler switches?  Or do they have different CPUs
/ RAMs / disks / you name it, which will result in different
behaviour in this strange situation (say whatever you like, but
reading a stream byte by byte is broken app desing in the first
place and not what underlying drivers get optimized for:).

> > How about doing this with _one_ block  of the size you want?
> > I.e. what stops you from swapping the count and bs
> > parameters?
> 
> That's a good idea, thanks! How come I did not think of it
> myself :) ?  Of course, now I already wrote my own program :(

Maybe you were aware of the downside I didn't mention explicitly? :)

When you need both of "count" and "skip" things get trickier.  If
there's a big common denominator of the two values you're lucky
and can use this as the bs parameter.  If the values differ
greatly you might tend to do something along these lines:

  dd if=$SOURCE bs=$SKIPLEN skip=1 | \
  dd of=$DEST   bs=$CUTLEN count=1

Cutting bs down to low values and putting "real" numbers in the
"skip" and "count" parameters will have a similar effect to what
you experienced.


But I guess we're getting OT here for -stable purposes.


virtually yours   82D1 9B9C 01DC 4FB4 D7B4  61BE 3F49 4F77 72DE DA76
Gerhard Sittig   true | mail -s "get gpg key" Gerhard.Sittig@gmx.net
-- 
     If you don't understand or are scared by any of the above
             ask your parents or an adult to help you.


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-stable" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20000609142413.Q9883>