genivi-ipc@lists.genivi.org

Development list for inter process communication (IPC) related topics

View all threads

recap on ipc-quartztime

AW
Andreas.Warnke@elektrobit.com
Wed, Jan 4, 2017 8:31 AM

Hello and a happy new year to you ipc-interested,

Three years ago, I started developing a shared-memory based IPC - because my subjective perception was that many todays message-based IPC systems take more CPU-performance than necessary.

I'd like to share some of my lessons learned since that time (please feel free to discuss and respond):

Pro:

I still believe that the way how ipc-quartztime is implemented (shared memory, signals, mutexes) is one of the fastest possible concepts and that also security can be partly addressed by limiting the read/write access (via MMU) to the shared memory pages.

2014 my impression was, that performance is the most critical thing of an IPC: You can reduce startup-times, hardware-costs, latencies; improve user-experience.

New insights are the weights and importance of other quality criteria:

Scalability: The concept could be extended to cross hypervisor-boundaries - but never to cross multiple network nodes.
Security: Authentication and Authorization(Access Control) becomes more and more important, separating security-zones, etc.
Safety: Mechanisms as dual-data-paths, freedom-from-interference, E2E protection, time-measurements.
Availability: Redundancy
Interoperability: In automotive, there often are several communication frameworks being used in parallel
Fault-tolerance and Recoverability: The more complexity is added to a system, the more likely it is that the system enters an unforeseen state.

It is interesting to experience how one's scope broadens: while I was more focused on infotainment 3 years ago, more in-vehicle functions showed up in my field-of-vision in the last years. It's like a zoom-out ;-) - You may know this feeling?

Maybe you could take something from above points,
In any case I wish you all the best for 2017!

Andreas

For the interested: Link to ipc-quartztime:
http://andreaswarnke.de/ipc-quartztime/html/index.html

--
Andreas Warnke
Dipl-Inform., Systems Engineering and Validation Dept.

EB - Driving the Future of Software
Phone: 09131 7701 6274
Fax: 09131 7701 6333
andreas.warnke@elektrobit.commailto:andreas.warnke@elektrobit.com
https://www.elektrobit.com/
PGP-Key: https://securemail.elektrobit.com/
Elektrobit Automotive GmbH, Am Wolfsmantel 46, 91058 Erlangen, Germany
Managing Directors Alexander Kocher, Gregor Zink
Register Court Fürth HRB 4886

Hello and a happy new year to you ipc-interested, Three years ago, I started developing a shared-memory based IPC - because my subjective perception was that many todays message-based IPC systems take more CPU-performance than necessary. I'd like to share some of my lessons learned since that time (please feel free to discuss and respond): Pro: I still believe that the way how ipc-quartztime is implemented (shared memory, signals, mutexes) is one of the fastest possible concepts and that also security can be partly addressed by limiting the read/write access (via MMU) to the shared memory pages. 2014 my impression was, that performance is the most critical thing of an IPC: You can reduce startup-times, hardware-costs, latencies; improve user-experience. New insights are the weights and importance of other quality criteria: Scalability: The concept could be extended to cross hypervisor-boundaries - but never to cross multiple network nodes. Security: Authentication and Authorization(Access Control) becomes more and more important, separating security-zones, etc. Safety: Mechanisms as dual-data-paths, freedom-from-interference, E2E protection, time-measurements. Availability: Redundancy Interoperability: In automotive, there often are several communication frameworks being used in parallel Fault-tolerance and Recoverability: The more complexity is added to a system, the more likely it is that the system enters an unforeseen state. It is interesting to experience how one's scope broadens: while I was more focused on infotainment 3 years ago, more in-vehicle functions showed up in my field-of-vision in the last years. It's like a zoom-out ;-) - You may know this feeling? Maybe you could take something from above points, In any case I wish you all the best for 2017! Andreas For the interested: Link to ipc-quartztime: http://andreaswarnke.de/ipc-quartztime/html/index.html -- Andreas Warnke Dipl-Inform., Systems Engineering and Validation Dept. EB - Driving the Future of Software Phone: 09131 7701 6274 Fax: 09131 7701 6333 andreas.warnke@elektrobit.com<mailto:andreas.warnke@elektrobit.com> https://www.elektrobit.com/ PGP-Key: https://securemail.elektrobit.com/ Elektrobit Automotive GmbH, Am Wolfsmantel 46, 91058 Erlangen, Germany Managing Directors Alexander Kocher, Gregor Zink Register Court Fürth HRB 4886
AG
Andersson, Gunnar
Wed, Feb 1, 2017 3:46 PM

Hi Andreas

Sent: den 4 januari 2017 09:31

Hello and a happy new year to you ipc-interested,

Three years ago, I started developing a shared-memory based IPC - because my subjective perception was that many todays message-based IPC systems take more CPU-performance than necessary.

I'd like to share some of my lessons learned since that time (please feel free to discuss and respond):

If no one answered on this, let me just acknowledge that I did see and read it with
interest.

I think continued work on IPC abstraction and APIs could bring things like this into
wider interest and then some might actually try and use it.

Without it, it becomes too specific a technology for most people to adopt
(because it's not widely used yet - a chicken and egg problem, but clearly it's not
known in the FOSS community at large and I imagine people are waiting for
things like kdbus->bus1 etc...)

A code generator from Franca, or a Common-API (C or C++) backend
(lower part of the libraries) that attaches to this would be interesting...
In the second approach, possibly it's just a library and no need for a new code
generator at all.

Best Regards

  • Gunnar

-----Original Message-----
From: genivi-ipc [mailto:genivi-ipc-bounces@mailman1.genivi.org] On Behalf Of Andreas.Warnke@elektrobit.com
Sent: den 4 januari 2017 09:31
To: genivi-ipc@lists.genivi.org; Andreas.Binner@elektrobit.com
Subject: [Genivi-ipc] recap on ipc-quartztime

Hello and a happy new year to you ipc-interested,

Three years ago, I started developing a shared-memory based IPC - because my subjective perception was that many todays message-based IPC systems take more CPU-performance than necessary.

I'd like to share some of my lessons learned since that time (please feel free to discuss and respond):

Pro:

I still believe that the way how ipc-quartztime is implemented (shared memory, signals, mutexes) is one of the fastest possible concepts and that also security can be partly addressed by limiting the read/write access (via MMU) to the shared memory pages.

2014 my impression was, that performance is the most critical thing of an IPC: You can reduce startup-times, hardware-costs, latencies; improve user-experience.

New insights are the weights and importance of other quality criteria:

Scalability: The concept could be extended to cross hypervisor-boundaries - but never to cross multiple network nodes.
Security: Authentication and Authorization(Access Control) becomes more and more important, separating security-zones, etc.
Safety: Mechanisms as dual-data-paths, freedom-from-interference, E2E protection, time-measurements.
Availability: Redundancy
Interoperability: In automotive, there often are several communication frameworks being used in parallel
Fault-tolerance and Recoverability: The more complexity is added to a system, the more likely it is that the system enters an unforeseen state.

It is interesting to experience how one's scope broadens: while I was more focused on infotainment 3 years ago, more in-vehicle functions showed up in my field-of-vision in the last years. It's like a zoom-out ;-) - You may know this feeling?

Maybe you could take something from above points,
In any case I wish you all the best for 2017!

Andreas

For the interested: Link to ipc-quartztime:
http://andreaswarnke.de/ipc-quartztime/html/index.html

--
Andreas Warnke
Dipl-Inform., Systems Engineering and Validation Dept.

EB - Driving the Future of Software
Phone: 09131 7701 6274
Fax: 09131 7701 6333
andreas.warnke@elektrobit.commailto:andreas.warnke@elektrobit.com
https://www.elektrobit.com/
PGP-Key: https://securemail.elektrobit.com/
Elektrobit Automotive GmbH, Am Wolfsmantel 46, 91058 Erlangen, Germany
Managing Directors Alexander Kocher, Gregor Zink
Register Court Fürth HRB 4886


genivi-ipc mailing list
genivi-ipc@mailman1.genivi.org
http://lists.genivi.org/cgi-bin/mailman/listinfo/genivi-ipc

Hi Andreas Sent: den 4 januari 2017 09:31 > Hello and a happy new year to you ipc-interested, > > Three years ago, I started developing a shared-memory based IPC - because my subjective perception was that many todays message-based IPC systems take more CPU-performance than necessary. > > I'd like to share some of my lessons learned since that time (please feel free to discuss and respond): If no one answered on this, let me just acknowledge that I did see and read it with interest. I think continued work on IPC abstraction and APIs could bring things like this into wider interest and then some might actually try and use it. Without it, it becomes too specific a technology for most people to adopt (because it's not widely used yet - a chicken and egg problem, but clearly it's not known in the FOSS community at large and I imagine people are waiting for things like kdbus->bus1 etc...) A code generator from Franca, or a Common-API (C or C++) backend (lower part of the libraries) that attaches to this would be interesting... In the second approach, possibly it's just a library and no need for a new code generator at all. Best Regards - Gunnar -----Original Message----- From: genivi-ipc [mailto:genivi-ipc-bounces@mailman1.genivi.org] On Behalf Of Andreas.Warnke@elektrobit.com Sent: den 4 januari 2017 09:31 To: genivi-ipc@lists.genivi.org; Andreas.Binner@elektrobit.com Subject: [Genivi-ipc] recap on ipc-quartztime Hello and a happy new year to you ipc-interested, Three years ago, I started developing a shared-memory based IPC - because my subjective perception was that many todays message-based IPC systems take more CPU-performance than necessary. I'd like to share some of my lessons learned since that time (please feel free to discuss and respond): Pro: I still believe that the way how ipc-quartztime is implemented (shared memory, signals, mutexes) is one of the fastest possible concepts and that also security can be partly addressed by limiting the read/write access (via MMU) to the shared memory pages. 2014 my impression was, that performance is the most critical thing of an IPC: You can reduce startup-times, hardware-costs, latencies; improve user-experience. New insights are the weights and importance of other quality criteria: Scalability: The concept could be extended to cross hypervisor-boundaries - but never to cross multiple network nodes. Security: Authentication and Authorization(Access Control) becomes more and more important, separating security-zones, etc. Safety: Mechanisms as dual-data-paths, freedom-from-interference, E2E protection, time-measurements. Availability: Redundancy Interoperability: In automotive, there often are several communication frameworks being used in parallel Fault-tolerance and Recoverability: The more complexity is added to a system, the more likely it is that the system enters an unforeseen state. It is interesting to experience how one's scope broadens: while I was more focused on infotainment 3 years ago, more in-vehicle functions showed up in my field-of-vision in the last years. It's like a zoom-out ;-) - You may know this feeling? Maybe you could take something from above points, In any case I wish you all the best for 2017! Andreas For the interested: Link to ipc-quartztime: http://andreaswarnke.de/ipc-quartztime/html/index.html -- Andreas Warnke Dipl-Inform., Systems Engineering and Validation Dept. EB - Driving the Future of Software Phone: 09131 7701 6274 Fax: 09131 7701 6333 andreas.warnke@elektrobit.com<mailto:andreas.warnke@elektrobit.com> https://www.elektrobit.com/ PGP-Key: https://securemail.elektrobit.com/ Elektrobit Automotive GmbH, Am Wolfsmantel 46, 91058 Erlangen, Germany Managing Directors Alexander Kocher, Gregor Zink Register Court Fürth HRB 4886 _______________________________________________ genivi-ipc mailing list genivi-ipc@mailman1.genivi.org http://lists.genivi.org/cgi-bin/mailman/listinfo/genivi-ipc