Date: Sat, 1 Aug 1998 06:10:43 -0400 (EDT) From: Peter Dufault <dufault@hda.com> To: mike@smith.net.au (Mike Smith) Cc: chanders@timing.com, freebsd-hackers@FreeBSD.ORG Subject: Re: Using FreeBSD for data acquisition? (long) Message-ID: <199808011010.GAA13588@hda.hda.com> In-Reply-To: <199807312055.NAA00498@dingo.cdrom.com> from Mike Smith at "Jul 31, 98 01:55:30 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
> > At the end of the message is histogram data for a test run of about > > 15 hours. I plot the data with gnuplot, using a logscale for y. > > Note that the longest read is 480 (480/500 = .960 seconds). Note > > that the most common read is 50 (50/500 = .100 seconds). > > This would tend to indicate a possible problem with the interaction > between your interrupt handler and the read handler, but it's > impossible to tell without seeing the code. .1 seconds is the round robin scheduling interval. It appears the wakeup from the driver isn't preempting the current process, but waiting until the next roundrobin call. As far as I can tell, wakeup should preempt it. We do large continuous data collection on FreeBSD. However, we don't try to meet any latency requirements - the data is time stamped by the different pieces of hardware and we just don't lose any of it. It is difficult to guarantee response in FreeBSD without: 1. Having a way to know you missed your deadline, either in hardware or using the CPU time stamps, for debugging your system and testing new releases; 2. Doing your latency critical work in the kernel. You still have to keep an eye out for misbehaving device drivers turning off interrupts, etc. Peter -- Peter Dufault (dufault@hda.com) Realtime development, Machine control, HD Associates, Inc. Safety critical systems, Agency approval To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199808011010.GAA13588>