Date: Sat, 8 Jun 1996 02:58:16 -0600 (MDT) From: Dave Andersen <angio@aros.net> To: michaelh@cet.co.jp (Michael Hancock) Cc: hackers@freebsd.org Subject: Re: Testing DE driver Message-ID: <199606080858.CAA31722@terra.aros.net> In-Reply-To: <Pine.SV4.3.93.960608120006.15180A-100000@parkplace.cet.co.jp> from "Michael Hancock" at Jun 8, 96 12:04:20 pm
next in thread | previous in thread | raw e-mail | index | archive | help
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'."
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199606080858.CAA31722>