From owner-freebsd-stable Fri Jun 9 6:19:12 2000 Delivered-To: freebsd-stable@freebsd.org Received: from mail.gmx.net (pop.gmx.net [194.221.183.20]) by hub.freebsd.org (Postfix) with SMTP id 3CC5437C444 for ; Fri, 9 Jun 2000 06:19:03 -0700 (PDT) (envelope-from Gerhard.Sittig@gmx.net) Received: (qmail 11292 invoked by uid 0); 9 Jun 2000 13:19:01 -0000 Received: from p3ee0b2fa.dip.t-dialin.net (HELO speedy.gsinet) (62.224.178.250) by mail06.rzmi.gmx.net with SMTP; 9 Jun 2000 13:19:01 -0000 Received: (from sittig@localhost) by speedy.gsinet (8.8.8/8.8.8) id OAA22280 for stable@FreeBSD.ORG; Fri, 9 Jun 2000 14:24:13 +0200 Date: Fri, 9 Jun 2000 14:24:13 +0200 From: Gerhard Sittig To: stable@FreeBSD.ORG Subject: Re: changes in dd? Message-ID: <20000609142413.Q9883@speedy.gsinet> Mail-Followup-To: stable@FreeBSD.ORG References: <20000608194615.N9883@speedy.gsinet> <200006081940.PAA00971@misha.privatelabs.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <200006081940.PAA00971@misha.privatelabs.com>; from mi@privatelabs.com on Thu, Jun 08, 2000 at 03:40:41PM -0400 Organization: System Defenestrators Inc. Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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 \ > > > dd ibs=1 count= 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