On Mon 28-Nov-2016 9:20 AM, Neelesh Vemula wrote:
Queries:
1) I have found the sample benchmark numbers for seL4 IPC from http://l4hq.org/docs/performance.php. Since I am running on Armv7 Cortex A9 , the time for one half way trip is 316 ns. Is this measured from system call to system call or from process to process?
It's measured as the time from user level to user level, i.e. just the mode switch and kernel execution component of performing an IPC
2) I am trying to compare the performance on FreeRTOS and Linux, is there any such comparison on where seL4 stands?
Each of these three systems is vastly different and are very hard to make comparisons between. The question is, what performance are you caring about? If you want the fastest cross address space IPC then the answer is seL4, since Linux has much more expensive IPC primitives and FreeRTOS does not have multiple address spaces. But you probably wouldn't build a system on Linux whose performance was dependent on the performance of IPC.

Whilst this was done in the context of multicore, we have shown that you can build systems on seL4 that have equivalent or better performance to a similar Linux system (see the results section of http://ts.data61.csiro.au/publications/nictaabstracts/8768.pdf).

That said you would expect FreeRTOS to be the 'fastest' of the three options as it has neither mode switches to invoke kernel functions, nor address space switches. But obviously you are sacrificing a great deal of security and protection in the process.
3) Does the IPC time vary with the different api of ReplyRecv, Reply, seL4_NBRecv? I have this question because I am seeing that Reply is taking about twice the amount of clock cycles compared to Recv.
The largest differences will be with seL4_Call and seL4_ReplyRecv, which have a dedicated fastpath that, if the conditions are met, will yield an IPC that is 2-4x faster than the 'slowpath'. Different invocations will definitely take different amounts of time, although 2x slower for Recv is a bit surprising, are you certain that there is actually a message waiting on the endpoint/notification?

In terms of my application, I am majorly looking at measuring one whole cycle which includes:

1) 1st Process sends message to 2nd Process
2) 2nd Process Reads from AXI device space
3) 2nd Process replies with Reply and waits for another command from 1st process
4) 1st process sends another message to 2nd Process
5) 2nd Process writes to the hardware
6) Time from step 1 to step 5 is measured.


Results for this on 
seL4 :  3180 clock cycles
FreeRTOS: 2414 clock cycles

I am sure there is possibility of unnecessary overheads involved in my measurement, but I expected seL4 to be faster. Can someone help me in this regard.
FreeRTOS does not use protected/kernel mode, nor does it switch address spaces, rather everything (user processes and system services) run in a single address space. As mentioned earlier this will always give the best performance, but you sacrifice any kind of isolation or security.

Adrian