{"title":"Linux SCHED DEADLINE vs. MARTOP-EDF","authors":"A. Stahlhofen, Dieter Zöbel","doi":"10.1109/EUC.2015.28","DOIUrl":null,"url":null,"abstract":"The theoretical background of real-time scheduling has been studied intensively by researchers in this community. A myriad of scheduling policies and sophisticated variations are principally available to be implemented at an operating system level or a middleware level. However, the number of implementations is far behind the number of publications and in the majority of cases they never reach a status beyond prototypes. This is a pitiful situation given that today there is a generation of processor boards waiting for adventurous developers to design and program time-critical embedded applications. The paragon here may be seen in the Raspberry Pi board, but several others also belong to this category (e.g. Cubietruck, Banana Pi). Offering a ready-to-use real-time programming framework is a basic concern of the MARTOP (Mapping real-time to POSIX) project. In order to address a broad range of platforms the approach is independent of a particular operating system only relying on POSIX as intermediate API. As there is another prominent approach to increase the availability of real-time scheduling we are going to compare both with each other. The already prominent one is the EDF-implementation for Linux called SCHED_DEADLINE which is part of the Linux standard kernel since version 3.14. The application scopes of both approaches are completely different. So, MARTOP principally allows any scheduling strategy and several fixed priority scheduling strategies are already available. However, the exciting is that both meet at the EDF-implementation and will be compared not only under the aspect of performance, but equally respecting overhead and robustness.","PeriodicalId":299207,"journal":{"name":"2015 IEEE 13th International Conference on Embedded and Ubiquitous Computing","volume":"15 1","pages":"0"},"PeriodicalIF":0.0000,"publicationDate":"2015-10-21","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":"1","resultStr":null,"platform":"Semanticscholar","paperid":null,"PeriodicalName":"2015 IEEE 13th International Conference on Embedded and Ubiquitous Computing","FirstCategoryId":"1085","ListUrlMain":"https://doi.org/10.1109/EUC.2015.28","RegionNum":0,"RegionCategory":null,"ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":null,"EPubDate":"","PubModel":"","JCR":"","JCRName":"","Score":null,"Total":0}
引用次数: 1
Abstract
The theoretical background of real-time scheduling has been studied intensively by researchers in this community. A myriad of scheduling policies and sophisticated variations are principally available to be implemented at an operating system level or a middleware level. However, the number of implementations is far behind the number of publications and in the majority of cases they never reach a status beyond prototypes. This is a pitiful situation given that today there is a generation of processor boards waiting for adventurous developers to design and program time-critical embedded applications. The paragon here may be seen in the Raspberry Pi board, but several others also belong to this category (e.g. Cubietruck, Banana Pi). Offering a ready-to-use real-time programming framework is a basic concern of the MARTOP (Mapping real-time to POSIX) project. In order to address a broad range of platforms the approach is independent of a particular operating system only relying on POSIX as intermediate API. As there is another prominent approach to increase the availability of real-time scheduling we are going to compare both with each other. The already prominent one is the EDF-implementation for Linux called SCHED_DEADLINE which is part of the Linux standard kernel since version 3.14. The application scopes of both approaches are completely different. So, MARTOP principally allows any scheduling strategy and several fixed priority scheduling strategies are already available. However, the exciting is that both meet at the EDF-implementation and will be compared not only under the aspect of performance, but equally respecting overhead and robustness.