Interrupt latency

105 views
Skip to first unread message

kvleonhardt

unread,
Jun 7, 2012, 3:20:49 AM6/7/12
to minix3
Hi

I have just measured the interrupt latency on a AMD Geode MX 500 MHz
embedded computer with Minix 3.1.8 kernel.

35us!!!!! That is 17500 clock cycles.

I am using hardware interrupt 12 for the test, so it is with low
priority, but the latency is constant, and does not vary more than +/-
1 us. Later I will use hardware interrupt 5, 6 or 7. But that will
probably not make any significant difference

I have in the time of writing not investigated what the kernel are
using the time for.

Does anyone have any experience with this?

BR
kvleonhardt

pikpik

unread,
Jun 13, 2012, 1:13:05 PM6/13/12
to minix3
Hi,

On Jun 7, 3:20 am, kvleonhardt wrote:

> I have just measured the interrupt latency on a AMD Geode MX 500 MHz
> embedded computer with Minix 3.1.8 kernel.
>
> 35us!!!!! That is 17500 clock cycles.

Is that good or bad? I would assume that 17500 clock cycles is a long
time.

> I am using hardware interrupt 12 for the test, so it is with low
> priority, but the latency is constant, and does not vary more than +/-
> 1 us. Later I will use hardware interrupt 5, 6 or 7. But that will
> probably not make any significant difference
>
> I have in the time of writing not investigated what the kernel are
> using the time for.
>
> Does anyone have any experience with this?

I don't have any experience with it, but I thinks it's very
interesting.

Thank you,
pikpik

Colin Fowler

unread,
Jun 13, 2012, 4:53:42 PM6/13/12
to min...@googlegroups.com
It really depends on what you want to do with your system. Real-time
systems type stuff is not going to be happy at all with 17,500 cycles
latency. On the other hand, for general desktop use it's fine. For
general server stuff it's fine too.

kvleonhardt, did you make sure to disable as many other drivers as
possible? The network card driver is an obvious one. Don't forget many
drivers will disable interrupts for various part of their low level code
( and obviously in the ISR) so some of the lantency could be caused by
that. Of course with such little variance that might not be a major factor.

I'd guess most of the latency is caused by the message overhead to the
user-space driver and the context switch.

Again it really boils down to what you want to do with your Minix
system. For audio
or video processing that latency would be well below the human perceptual
threshold.

Colin
> --
> You received this message because you are subscribed to the Google Groups "minix3" group.
> To post to this group, send email to min...@googlegroups.com.
> To unsubscribe from this group, send email to minix3+un...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/minix3?hl=en.
>

kvleonhardt

unread,
Jun 19, 2012, 3:17:08 AM6/19/12
to min...@googlegroups.com
Hi,

All measurement are done with no other hardware. Therefore only the system timer is hardware interrupting.  Agree, it must be the messaging that consumes all the time. Not good for a real time OS.

I have measured the interrupt latency with DOS. In real mode the latency is apx 4 us, and in protected mode apx 5 us.

So no Minix this time, I keep DOS one more decade. :-)

kvleonhardt

Andy Kosela

unread,
Jun 19, 2012, 4:01:49 AM6/19/12
to min...@googlegroups.com
This is interesting. Are you able to do the same measurements using
FreeBSD and NetBSD?

--Andy

Pablo Pessolani

unread,
Jun 19, 2012, 9:58:01 AM6/19/12
to min...@googlegroups.com
Some years ago (2005) , I wrote MINIX4RT (Minix for RealTime) based on MINIX 2.0.2
 
I used a IBM Model 370C Notebook, Intel® DX4 75MHz for the performance tests.
The timer was set at 1000 Hz and each column represent a different kind of load generated by a user space program. 
The  IRQ 7- paralllel port was used for the tests.
 
Software interrupts are equivalent to Linux. (not running at interrupt time)

Interrupt Service Time of Software Interrupts for 1000 [Hz]

Delay [ns]

DKTLoad

HDLoad

CPULoad

NOLoad

Average

38319

44443

39652

35986

Standard Deviation

6865

7523

2582

6534

Minimum

30688

30848

35712

30688

Maximum

62304

59584

51008

87264


Event driven interrupts are installed as Interrupt handlers.

Interrupt Service Time of Event-Driven Interrupts for 1000 [Hz]

Delay [ns]

DKTLoad

HDLoad

CPULoad

NOLoad

Average

31092

33790

33506

29895

Standard Deviation

10294

10445

9100

10284

Minimum

21824

22144

23232

22144

Maximum

69664

90912

92896

86464

 
Now, there is a RT version of MINIX3
Try with it.
PAP
 
 
2012/6/19 Andy Kosela <ako...@andykosela.com>
--
You received this message because you are subscribed to the Google Groups "minix3" group.

Yana

unread,
Jun 21, 2012, 5:00:01 AM6/21/12
to min...@googlegroups.com
Hello,

2012/6/19 kvleonhardt <kvleo...@gmail.com>:
> So no Minix this time, I keep DOS one more decade. :-)

For example, there are the following approaches about customizing
interrupt latency of MINIX.

* context switch

Interrupt latency about process without paging seems to become smaller
than interrupt latency about process with paging.

* message passing

Interrupt latency about message buffer which uses registers seems to
become smaller than interrupt latency about message buffer which uses
memories.

* mixed system

Formerly I patched minix_R3.2.0-116fcea.iso.bz2 for ARM, MIPS and GXemul.
http://groups.google.com/group/minix3/browse_thread/thread/1bbbc6efa5771c82

And I used MINIX with YanaKernel0 on the following computer system.
+ processor (GXemul(testarm,testmips))
+ YanaKernel0
+ MINIX kernel(and tasks) which depended on YanaKernel0
+ MINIX processes

About MINIX with YanaKernel0, YanaKernel0 handles exceptions and
interrupts directly, MINIX kernel is executed as a task of
YanaKernel0.

Interrupt latency about task of YanaKernel0 seems to become smaller
than interrupt latency about process of MINIX.

Thanks,

Yana

Niek Linnenbank

unread,
Jun 21, 2012, 5:24:00 AM6/21/12
to min...@googlegroups.com
Hello  Yana,
 
I'm interested to hear more about the YanaKernel0 you are talking about.
What kind of system is it, exactly? I've looked at the yana.jp homepage,
but I couldn't find any (english) documentation on the system.
Thanks,
 
Niek
--
You received this message because you are subscribed to the Google Groups "minix3" group.
To post to this group, send email to min...@googlegroups.com.
To unsubscribe from this group, send email to minix3+un...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/minix3?hl=en.




--
Niek Linnenbank

WWW: http://www.nieklinnenbank.nl/
BLOG: http://nieklinnenbank.wordpress.com/
FUN:    http://www.FreeNOS.org/

Yana

unread,
Jun 23, 2012, 11:00:02 PM6/23/12
to min...@googlegroups.com
Hello,

2012/6/21 Niek Linnenbank <nieklin...@gmail.com>:
> I'm interested to hear more about the YanaKernel0 you are talking about.
> What kind of system is it, exactly? I've looked at the yana.jp homepage,
> but I couldn't find any (english) documentation on the system.

Thank you for being interested in YanaKernel0 and "yana.jp".

There is not English documentation, but the following link may help
understanding.
http://groups.google.com/group/minix3/browse_thread/thread/b37eb23f02b65bb0

I introduce YanaKernel0A in C with reference to MINIX 3.2.0.

Keywords of YanaKernel0 are simple, resource limited, and hardware
implementable.

I implemented YanaKernel0A in C language (and assembly language).

I want to implement YanaKernel0 by hardware, but not yet.
And I want to use task which was implemented by hardware.

* execution

About YanaKernel0, processor executes kernel or task.
YanaKernel0A in C is executed on ARM and MIPS.

About MINIX, processor executes kernel(and tasks) or process.
MINIX 3.2.0 is executed on x86.

* exception and interrupt

About YanaKernel0A in C, kernel handles exceptions like
YK0A_PROCEDURE_FORWARD (task passing), and task can manage task which
caused exception.
kernel handles interrupts like YK0A_PROCEDURE_BIT_FLAG, and task can
synchronize with interrupt.

About MINIX 3.2.0, kernel handles exceptions as pagefault, panic,
signal and the others, and process can not manage process which caused
exception.
kernel handles interrupts (except clock) as message passing, and
process can synchronize with interrupt.

* resource

About YanaKernel0, inside of kernel uses only the following resources.
+ processor
+ memory
+ interrupt controller (in the case of ARM)

Using disassembler, I checked stack size of kernel.
> | ARM | 48 bytes | CC="arm-elf-gcc -O2" make |
> | MIPS | 8 bytes | CC="mips-elf-gcc -O2" make |

YanaKernel0 may support real-time system, but I do not check
worst-case execution time of kernel.

MINIX kernel uses the following resources, but YanaKernel0 kernel does
not use it.
+ FPU
+ MMU
+ clock
+ serial (for debug)

* memory

About YanaKernel0, inside of kernel accesses only memories of kernel.

MINIX kernel accesses memories of process, but YanaKernel0 kernel does
not access memories of task.

For example, there is computer system with the following memories.
+ internal memories which are exceptionless and waitless
+ external memories which are exceptionable and waitable

About YanaKernel0, if kernel is allocated internal memories, memory
accesses of kernel are exceptionless and waitless even if task is
allocated external memories.

About MINIX, if process is allocated external memories, memory
accesses of kernel are exceptionable and waitable even if kernel is
allocated internal memories.

* message buffer

About sample echo2 of YanaKernel0A in C, server(task1) communicates
with client(task2) by message buffer which uses registers of task.
Kernel copy (or swap) register which is not related to memory
management about YK0A_PROCEDURE_GET_CONTEXT (or
YK0A_PROCEDURE_SET_CONTEXT).

About MINIX, server communicates with client by message buffer which
uses memories of process.
Kernel copy memories which is related to memory management about
message passing.

For example, the following process is finished normally about MINIX
3.1.3a (segmented virtual memory), and is not finished normally about
MINIX 3.2.0 (paged virtual memory).
> #include <minix/type.h>
> #include <stdio.h>
> #include <stdlib.h>
> #include <unistd.h>
> #include <minix/callnr.h>
> #include <minix/com.h>
> #include <minix/ipc.h>
> message m;
> int main(int argc, char *argv[]) {
> m.m1_i1 = -1;
> m.m1_i2 = 0;
> m.m_type = GETPROCNR;
> if (fork() == -1) { /* demand paging */
> return EXIT_FAILURE;
> }
> if (sendrec(PM_PROC_NR, &m) != 0) {
> return EXIT_FAILURE;
> }
> if (m.m_type < 0) {
> return EXIT_FAILURE;
> }
> printf("getprocnr %d\n", m.m1_i1);
> return EXIT_SUCCESS;
> }

* interrupt latency

Formerly I patched minix_R3.2.0-116fcea.iso.bz2 for ARM, MIPS and GXemul.
http://groups.google.com/group/minix3/browse_thread/thread/1bbbc6efa5771c82

About MINIX with YanaKernel0, YanaKernel0 kernel handles exceptions
and interrupts directly, MINIX kernel is executed as a task of
YanaKernel0.

About MINIX without YanaKernel0, MINIX kernel handles exceptions and
interrupts directly, YanaKernel0 kernel is not executed.

Interrupt latency about task of YanaKernel0 seems to become smaller
than interrupt latency about process of MINIX without YanaKernel0.
And interrupt latency about process of MINIX without YanaKernel0 is
smaller than interrupt latency about process of MINIX with
YanaKernel0.

Thanks,

Yana
Reply all
Reply to author
Forward
0 new messages