<?xml version="1.0" encoding="utf-8"?>
<feed xml:lang="en" xmlns="http://www.w3.org/2005/Atom"><title>Recent posts to Tickrate of 50 microsec causing schedular to go to nanosleep</title><link href="https://forge.codesys.com/forge/talk/Engineering/thread/a8804bf228/" rel="alternate"/><link href="https://forge.codesys.com/forge/talk/Engineering/thread/a8804bf228/feed.atom" rel="self"/><id>https://forge.codesys.com/forge/talk/Engineering/thread/a8804bf228/</id><updated>2020-02-27T14:09:07.938000Z</updated><subtitle>Recent posts to Tickrate of 50 microsec causing schedular to go to nanosleep</subtitle><entry><title>Tickrate of 50 microsec causing schedular to go to nanosleep</title><link href="https://forge.codesys.com/forge/talk/Engineering/thread/a8804bf228/?limit=25#1ba8" rel="alternate"/><published>2020-02-27T14:09:07.938000Z</published><updated>2020-02-27T14:09:07.938000Z</updated><author><name>praveena</name><uri>https://forge.codesys.com/u/praveena/</uri></author><id>https://forge.codesys.comcde1b8ab881049c33452c308be224c8b3250bbd9</id><summary type="html">&lt;div class="markdown_content"&gt;&lt;p&gt;We have PPC machine and use QNX 6.5.0 with CODESYS 3.5 patch 4.We have a system tickrate of 50 microseconds.&lt;/p&gt;
&lt;ol&gt;
&lt;li&gt;
&lt;p&gt;Can CODESYS 3.5  patch 4 run  on such a tickrate?&lt;/p&gt;
&lt;/li&gt;
&lt;li&gt;
&lt;p&gt;It is also observed that  in a normal system  kernel trace , 9  tasks are running under Codesys  process  .Three  of them follow FIFO Scheduling and others follow Round robin. the " schedule(PID 4)”  task of  150f priority  goes regularly into nanosleep, then becomes ready, runs  and then goes to nanosleep again . The   task(PID 7)  with 23f priority is blocked on semaphore  and decrements the semaphore once the scheduler increments the semaphore, and then becomes ready to run.  It then runs before getting blocked on a semaphore again. this cycle continues.&lt;/p&gt;
&lt;/li&gt;
&lt;li&gt;In a Unhealthy system it has been observed that schedule(4) task goes into nanosleep state and does not come out of it. The task(7) is also continuously blocked on a  semaphore.&lt;br/&gt;
Thus the system behaves in an unstable manner.&lt;/li&gt;
&lt;/ol&gt;
&lt;p&gt;&lt;strong&gt;Is the above phenomenon due to a low tick rate.&lt;/strong&gt;&lt;/p&gt;&lt;/div&gt;</summary></entry></feed>