Language Selection

English French German Italian Portuguese Spanish

today's howtos and programming bits

Filed under
Development
HowTos
  • How to install the Writefull editor on Linux
  • Linux Find If Processor (CPU) is 64 bit / 32 bit [long mode ~ lm]
  • How to Install and Configure latest version of Ansible on Ubuntu Linux
  • How To Create a Database on InfluxDB 1.7 & 2.0
  • Step-by-Step Execution and Examples

    Last week I finished writing all the new examples for the ROCS, together with a little description of each commented in the beginning of the code

  • Applying C - Deadline Scheduling

    For real time tasks FIFO scheduling is appropriate. However, if you are using a modern version of Linux there’s a better choice. Earliest Deadline Scheduling (EDS) is new recently introduced (Kernel 3.14) Linux scheduling policy. Due to its recent introduction and because it isn’t a POSIX scheduling method, it isn't widely used, but it does have many good properties for realtime tasks.

    A SCHED_DEADLINE thread is associated with three parameters – runtime, period and deadline. The thread will receive runtime nanoseconds of execution every period nanoseconds and deadline specifies in nanoseconds how delayed into the period the allocation can be. If a thread takes longer than its runtime period the operating system suspends it and restarts it at its next activation period.

    It is also useful to know that in this case sched_yield suspends the thread until its next time period starts. This means you can give time back to the system if you have overestimated how long a task should take.

    Notice that times are specified in nano seconds (ns) but micro seconds (us) are more reasonable for describing how long a real world task is likely to take.

    For example, if runtime is 10 us, period 100 us and deadline 20 us you can be sure that the thread will get 10 us every 100us and the maximum delay from the start of the 100 us period is 20 us. If the thread is, say, setting a hardware line high at the start of the 10us and low at the end, the pulses will be 10us wide and repeat every 100us, but with a jitter of 20 us from the start of the 100us period, i.e. a pulse could be up to 20us late. This only works if the system isn’t overloaded and there are enough CPUs to satisfy all of the demands. As long as the system isn’t overloaded then the scheduling algorithm is proven to meet the specifications of period and deadline.

More in Tux Machines

Type Title Author Replies Last Postsort icon
Story Android Leftovers Rianne Schestowitz 23/09/2019 - 12:19am
Story Building A Linux HTPC / Storage Server With The SilverStone CS381 Rianne Schestowitz 23/09/2019 - 12:09am
Story Intel Icelake Thunderbolt Support, Stratix10 Additions & Other Material Hits Linux 5.4 Roy Schestowitz 22/09/2019 - 8:38pm
Story Python Programming Leftovers Roy Schestowitz 22/09/2019 - 8:35pm
Story Geary 3.34 Debuts with Deeper GNOME Contacts Integration, Other Changes Roy Schestowitz 22/09/2019 - 8:32pm
Story today's howtos Roy Schestowitz 22/09/2019 - 8:28pm
Story Stallman Under Fire for Views on Epstein Roy Schestowitz 59 22/09/2019 - 8:24pm
Story Best free Linux firewalls of 2019: go beyond Iptables for desktops and servers Roy Schestowitz 22/09/2019 - 8:19pm
Story GNU Parallel 20190922 ('Stallman') released Roy Schestowitz 22/09/2019 - 8:07pm
Story Top 20 Best NodeJs Frameworks For Developers in 2019 Roy Schestowitz 22/09/2019 - 7:58pm