Hi, I don't think increase the HZ would improve the latency performance significantly in your case.
The standard way to decrease the latency for embedded system is using a real-time kernel running alongside with uClinux and keeping the real-time task inside the real-time kernel. Not too sure if that already supported in the NIOS uClinux. In my experience there is no easy way to reduce the latency significantly in uClinux, you need analysis which routine is the bottleneck and tackle that part. Does NIOS have SRAM? Try to put the critical routine executed from SRAM. If it is IRQ handler (TOP half) too slow or the bottom half too slow (tasklets or workqueues), then you need figure out how to cheat (bypassing) the kernel scheduler for your need. Try to reduce the number of system calls (including gettimeofday kind of calls) because each will cause the kernel reschedule your user space process (if you are not using FIFO or RR priority process). Does NIOS has spare timer? Try to use the timer in the kernel space to analysis the timing as mentioned above and report back the result to proc file system, or use the spare I/O pins to report the timing and use the CRO to look at it. Again it require many tweaks and tricks. If you have enough time to play with it, it would be quite rewarding to do so in the end of day. Good luck Xin Xie > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:uclinux-dev- > [EMAIL PROTECTED] On Behalf Of Grant Edwards > Sent: Friday, 21 November 2008 6:48 AM > To: [email protected] > Subject: [uClinux-dev] Re: Methods to reduce latency? > > On 2008-11-20, Dave Meador <[EMAIL PROTECTED]> wrote: > > > Darn, that would have been too easy. > > Sometimes the easy solution works. > > >> Does the tick size matter? It's set to 10ms right now, so I > >> guess I'll try changing it to 1ms to see what happens. > > > > Its worth a try, but be careful because reducing tick size can > > have the adverse side effect of increasing context switch > > overhead. > > If the system is designed correctly, it should make much > different. The time-critical stuff would all be configured to > use the real-time/FIFO scheduler, so context switches wouldn't > be driven by the system tick. But, the FIFO scheduler doesn't > appear to work, so context-switch overhead will be impacted. > > > Reducing the tick size too much could cause more work for the > > processor in task switching rather than doing actual process > > work and thus degrading your performance. > > All tasks except the idle task should be blocked until they > have work to do and then should run until they block again. > > But, it turns out to be moot. The kernel hangs when HZ is 1000 > and resets immediately when HZ is 250 or 300. It could be that > the system tick timer isn't configurable and is hard-wired to > generate a 100Hz interrupt. > > -- > Grant Edwards grante Yow! ... I see > TOILET > at SEATS ... > visi.com > > _______________________________________________ > uClinux-dev mailing list > [email protected] > http://mailman.uclinux.org/mailman/listinfo/uclinux-dev > This message was resent by [email protected] > To unsubscribe see: > http://mailman.uclinux.org/mailman/options/uclinux-dev _______________________________________________ uClinux-dev mailing list [email protected] http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by [email protected] To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
