Date: Fri, 05 Jun 1998 06:41:49 -0700 From: "Richard S. Straka" <straka@home.com> To: Bruce Evans <bde@zeta.org.au>, current@FreeBSD.ORG Subject: Re: strange behavior with signal latencies Message-ID: <3577F59D.983C4EE4@home.com> References: <199806042229.IAA23654@godzilla.zeta.org.au>
next in thread | previous in thread | raw e-mail | index | archive | help
Bruce Evans wrote: > >In looking at the results, I noticed that that the current box exhibited > >a 2300 microsecond additional delay every 10th signal or at 100ms > >intervals. Also, occationally a signal is missed. I have also noticed > >recently using top and systat that current has been consuming between > >1.6% and 3.1% of my P133 in interrupt handling. This seems to > >correspond to the latancy I am seeing with the signal test code. I > >changed the quantum interval using sysctl to 20 ticks. This had no > >effect, the 2300 microsecond latency still appeared at 10Hz. > > > >The results with 2.2.6R on the 486-100 box showed no signs of the > >latency and appeared to always reliably wakeup on every signal. Also, > >when the machine is completely idle, the interrupt load is 0.0%, > >occationally jumping to 0.4% when the disks sync. > > The results show no signs of latency with -current on a P5/133 here. > > This should be relatively easy to debug - just find whatever is causing > the abnormal interrupt load. I suspect it is an interrupt handler looping. > > Bruce It turned out to be the de driver. I am currently using two of these cards in a firewall/natd configuration. Thanks for the help. BTW, these latancy times really go out the window (10+ms ) when the system is loaded with disk writing or network activity. I have performed similar tests on an Ultra 30 box running Solaris 2.6. Even under extreme loading, the latencies stay below 1ms (its no VxWorks, but it ain't bad for soft realtime). It appears that Solaris does very little work in hardware interrupts, defering work to preemtable kernel threads which are under control of the scheduler. They offer a realtime scheduling class which has higher priority than their system scheduling class. The amount of work we currently do in FreeBSD in hardware and software interrupts coupled with the non-preemtable nature of kernel activity precludes us from doing even soft realtime work. Regards, Richard Straka straka@home.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3577F59D.983C4EE4>