Date: Tue, 10 Sep 1996 13:23:05 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: fwmiller@cs.UMD.EDU (Frank W. Miller) Cc: terry@lambert.org, fwmiller@cs.UMD.EDU, freebsd-hackers@FreeBSD.org Subject: Re: kernel performance Message-ID: <199609102023.NAA03450@phaeton.artisoft.com> In-Reply-To: <199609101822.OAA03213@yangtze.cs.UMD.EDU> from "Frank W. Miller" at Sep 10, 96 02:22:50 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> Statistical should be fine for my purpose. I am interested in the > performance trends for a large number of reads from disk followed by > writes to UDP. By large number, we're talking in the 10s of millions, > i. e. moving a half-hour mpeg from disk to network. > I have made some very gross measurements at the system call level. > As you might expect, the numbers indicate dramatic variance in latency > and jitter. I am seeking to breakdown these measurement further to > determine what elements of the kernel play the largest role in the > variance. [ ... ] > Fortunately, I'm working with FreeBSD and BSD/OS. :P One thing to consider is that without a cache unification, BSD/OS must call bmap() for copy address ranges for copying data to/from kernel/user space. Another thing to consider is copying the data from kernel space to user space at all. One method which should speed both of these up is to mmap() the file which you will be sending. This will save you one or two copies, depending on which OS you are running it on, since the address of the data in the mapped region can be sent down, and you will trade read+copy for a fault generated by the UDP write reference. This isn't the optimal soloution (which would be to load a system call and turn around the wire requests entirely in kernel space), but it is probably the "best fit" for a user space server. If you were using reliable stream delivery, I would suggest the "team" approach. Testing (by Ed Lane) achieved an ~3X performance improvement on GIF downloads from an HTTP server by replacing the reference with a CGI that ran "team" or "ddd" to stream the GIF data down the connection interleaving the file and network I/O. Unless you are planning on letting the client overflow (limiting factor: the client), then you may want to consider trying a reliable stream delivery mechanism. Getting data from a server to a client is Ed's specialty. 8-). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199609102023.NAA03450>