From owner-freebsd-hackers Sat Jun 8 01:58:24 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id BAA16297 for hackers-outgoing; Sat, 8 Jun 1996 01:58:24 -0700 (PDT) Received: from mailhub.aros.net (mailhub.aros.net [205.164.111.17]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id BAA16280 for ; Sat, 8 Jun 1996 01:58:20 -0700 (PDT) Received: from terra.aros.net (terra.aros.net [205.164.111.10]) by mailhub.aros.net (8.7.5/Unknown) with ESMTP id DAA03287; Sat, 8 Jun 1996 03:34:08 -0600 (MDT) Received: (from angio@localhost) by terra.aros.net (8.7.5/8.6.12) id CAA31722; Sat, 8 Jun 1996 02:58:17 -0600 From: Dave Andersen Message-Id: <199606080858.CAA31722@terra.aros.net> Subject: Re: Testing DE driver To: michaelh@cet.co.jp (Michael Hancock) Date: Sat, 8 Jun 1996 02:58:16 -0600 (MDT) Cc: hackers@freebsd.org In-Reply-To: from "Michael Hancock" at Jun 8, 96 12:04:20 pm X-Mailer: ELM [version 2.4 PL25 PGP2] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk You may wish to try tcpblast - it does basically what it sounds like. :-) It's in the packages collection in benchmarking/tcpblast-1.0.tgz. TCPblast is limited to 9999 blocks of 1024 bytes. So set it up in a loop: while 1 tcpblast destination 9999 end This _will_ work out your network interface, and even more, your network. If you can't afford to have a saturated network while you're doing this -- well, don't. :) The only problem about this is that it uses constant-sized blocks with identical content. You could also try running several concurrent ping -f's over the network with different pad bytes in each ping. Or, combine that with the tcpblast loop. :) -Dave Andersen Lo and behold, Michael Hancock once said: > > I'm testing Matt Thomas' experimental DE driver. Well sort of. What > would be a good way to stress test this driver? All I've done so far with > the driver was a few large sup sessions and running NetScape. > > Also, how do I check to see if there are any ipintrq drops? > > -mh > > On Mon, 3 Jun 1996, Matt Thomas wrote: > > > > > I modified my new/normal if_de.c driver to do something > > quite different from most network drivers. > > > > This driver will defer processing of interrupts to a > > netisr routine. Actually the acknowledges an interrupt, > > and disables interrupts for the device, and waits for > > a software interrupt to acutally service the interrupt. > > > > Thus hardly any of the driver runs splimp and most runs > > at splnet. > > > > This also results in pratically no drops at the protocol > > layer (ie. ipintrq). With a small change to ether_input > > and ip_input, one could even bypass ipintrq and have > > much fairer input processing (reduce queueing delays and > > effects considerably). > > > > If you are in an environment where you are getting > > ipintrq drops with the de driver, I'd be very curious > > to see what results you get from this driver. > > > > Send me mail if you are interested... > > > > (Anything after 2.1.0-RELEASE should work fine included > > 2.2-current). > > > > -- > > Matt Thomas Internet: matt@3am-software.com > > 3am Software Foundry WWW URL: http://www.3am-software.com/bio/matt.html > > Westford, MA Disclaimer: I disavow all knowledge of this message > > > > > > -- > michaelh@cet.co.jp http://www.cet.co.jp > CET Inc., Daiichi Kasuya BLDG 8F 2-5-12, Higashi Shinbashi, Minato-ku, > Tokyo 105 Japan Tel: +81-3-3437-1761 Fax: +81-3-3437-1766 > -- angio@aros.net Complete virtual hosting and business-oriented system administration Internet services. (WWW, FTP, email) http://www.aros.net/ http://www.aros.net/about/virtual "There are only two industries that refer to thier customers as 'users'."