Real Time response/latency question

Real Time response/latency question

[Graham Stoney]

Hi folks,

I'm looking at software architecture questions, and wondering how much
application domain work I can move out of driver land and into user space,
hence the following question: Can anyone give me a rough idea of the maximum
latency in user space I could expect on an 860T based system with multiple
threads, where only one thread has SCHED_RR realtime scheduling priority?

Thanks,
Graham

PS: If you're in Sydney Australia and you're interested in an Embedded Linux
job doing 860/855T stuff, please let me know.

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Real Time response/latency question

[Dan Malek]

Graham Stoney wrote:
> 
> Hi folks,
> 
> I'm looking at software architecture questions, and wondering how much
> application domain work I can move out of driver land and into user space,

I believe this is a good programming practice, and in many
cases I don't even write a driver when the application is
allowed to run with root privilege.

> .... Can anyone give me a rough idea of the maximum
> latency in user space I could expect on an 860T based system with multiple
> threads, where only one thread has SCHED_RR realtime scheduling priority?


You can't answer this question due to the design and implementation
of the kernel.  Most "real-time" systems can't either once you
throw protocol stacks, file systems, disk drives, and other
external devices or distributed services into the feature mix.

I have successfully written applications that required
sub-millisecond latency.  You just have to be careful about
other applications in the system, and remember that you can't
preempt the kernel.

If you have hard real-time requirements, check into the RT-Linux
features.  These are starting to mature, and can make scheduling
guarantees within the confined real-time domain.


	-- Dan

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Real Time response/latency question

[Claude Robitaille]

On Tue, 30 Nov 1999, Dan Malek wrote:

> 
> Graham Stoney wrote:
> > 
> > Hi folks,
> > 
> > I'm looking at software architecture questions, and wondering how much
> > application domain work I can move out of driver land and into user space,
> 
> I believe this is a good programming practice, and in many
> cases I don't even write a driver when the application is
> allowed to run with root privilege.
I have not looked yet into this section of my own project but I'll have to
eventually so I have a question: how about interrupt? I guess a very
simple driver which kicks some userland waiting thread is good enough in
most cases. Or is there a way to register some userland code?

Claude


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Real Time response/latency question

[Dan Malek]

Claude Robitaille wrote:

> .... so I have a question: how about interrupt? I guess a very
> simple driver which kicks some userland waiting thread is good enough in
> most cases. Or is there a way to register some userland code?

Interrupts are the reason to write the driver.  The open()/close()
can perform some hardware initialization and shutdown to enable
and disable the interrupt source.  The interrupt handler may
need to do something to remove the pending interrupt, and then
I usually use select() for the user thread synchronization.

The difficulty registering some user function as the interrupt
handler is it must run with interrupts disabled.....there are
a number of complexities associated with allowing this to
occur.  The reason for interrupts disabled is that the handler
must do something to remove the interrupt state before you can
enable interrupts again.


	-- Dan

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Real Time response/latency question

[Marcus Sundberg]

Dan Malek <dan@netx4.com> writes:

> Graham Stoney wrote:
> > .... Can anyone give me a rough idea of the maximum latency in user
> >space I could expect on an 860T based system with multiple threads,
> >where only one thread has SCHED_RR realtime scheduling priority?
> 
> 
> You can't answer this question due to the design and implementation of
> the kernel.  Most "real-time" systems can't either once you throw
> protocol stacks, file systems, disk drives, and other external devices
> or distributed services into the feature mix.
> 
> I have successfully written applications that required sub-millisecond
> latency.  You just have to be careful about other applications in the
> system, and remember that you can't preempt the kernel.

Ingo molnars lowlatency patch (http://www.redhat.com/~mingo/lowlatency-2.2.13-A1)
(adapted to PPC ofcourse) in combination with POSIX realtime scheduling
can actually do great things for you. (Not hard realtime ofcourse
but very good "normal-case" latency even under high load)

However, if you use a serial console - don't even think about doing
anything remotely realtime without the following patch. Without it
the 8xx serial driver can busy-wait up to 25ms(!!!) (assuming 9600
bits/s) when it prints a newline.

Index: n_tty.c
===================================================================
RCS file: /swb/cvs_repository/linux/drivers/char/n_tty.c,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 n_tty.c
--- n_tty.c	1999/07/07 13:57:03	1.1.1.1
+++ n_tty.c	1999/11/30 20:17:16
@@ -144,11 +144,13 @@
 			if (O_ONLCR(tty)) {
 				if (space < 2)
 					return -1;
-				tty->driver.put_char(tty, '\r');
+				tty->driver.write(tty, 0, "\r\n", 2);
 				tty->column = 0;
+			} else {
+				tty->driver.put_char(tty, c);
 			}
 			tty->canon_column = tty->column;
-			break;
+			return 0;
 		case '\r':
 			if (O_ONOCR(tty) && tty->column == 0)
 				return 0;


//Marcus
-- 
-------------------------------+------------------------------------
        Marcus Sundberg        | http://www.stacken.kth.se/~mackan/
 Royal Institute of Technology |       Phone: +46 707 295404
       Stockholm, Sweden       |   E-Mail: mackan@stacken.kth.se

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/