NDK2.0 real-time scheduling policies question.

Hi Anatoly,

The NDK scheduling is done using priority levels.  When an "NDK Task" is created (it is really a BIOS TSK) it is set to one of the priorities that the NDK net scheduler knows about: low, normal, high and kernel level.  Each of these can be configured to have a different value (defaults are 3, 5, 7 and 9, respectively).

When the NDK scheduler runs, all scheduling is made with respect to these priority levels that it knows about.  Kernel level priority is special, in that only one network task that has kernel level priority can be scheduled to run at a time (by the NDK's net scheduler).

So what happens if your app has a non-network related task with a higher priority than kernel level? Say priority 10?  It can/will pre-empt the NDK task running at kernel level and this is what it's supposed to do.  The NDK's net scheduler is designed to keep all of the network tasks properly synchronized but at the same time without interfering with other non-network related tasks.

For more information, please refer to the NDK User's Guide (spraa523_ug.pdf)

Thanks,

Steve

• As far as I understood from the user guide, it is recommended to set the priority of the Net Scheduler to low, and the mode to interrupt mode, for real-time purposes in the application. Am I right? 

• Another thing, is that of the reason that TCP/IP stack works synchronously, with the acks being sent for each predefined amount of data(TCP Receive Window), so the NDK is designed in such a way, that the network tasks is blocked, pending on acknowledge receive event from the low level driver. Am I right?

How can I promise the Network task, that transmits data, to be blocked for more segments of time, in order to give my application tasks more time for execution, but stiil run eventually?

Anatoly.

Anatoly,

Anatoly Odler said:

As far as I understood from the user guide, it is recommended to set the priority of the Net Scheduler to low, and the mode to interrupt mode, for real-time purposes in the application. Am I right?

Yes, this sounds like the scenario that best fits your application.

Anatoly Odler said:

The problem I have is that if the network scheduler is in low priority, the network task never runs if it is supposed to transmit data (send()), it just never gets the network event.

If you are making a call to send() (for TCP) but are not seeing anything actually sent out on the wire, it could be due to the TCP buffer size.  When you call send, the data you pass to it is copied into the socket buffer for that socket.  Then depending on the protocol it will actually send the data after some certain buffering criteria has been met.  For TCP, it waits until the TCP send buffer has been filled before actually creating the packet and pushing it out.

The default size of this buffer is 8k.  So, once 8k worth of data has been written, it creates the packet and pushes it out.

How much data are you trying to send when you don't see anything happening?  I suspect the send buffer hasn't been filled up yet.

Anatoly Odler said:

How can I promise the Network task, that transmits data, to be blocked for more segments of time, in order to give my application tasks more time for execution, but stiil run eventually?

First thing that comes to mind is to sleep the task in between data sends.  This would have a throttling effect and the sleeps should allow your time critical tasks to run more.  You could tune the amount of data sent in between sleeps along with the sleep times until you achieve the desired effect.

Steve

Steven Connell said:

If you are making a call to send() (for TCP) but are not seeing anything actually sent out on the wire, it could be due to the TCP buffer size.  When you call send, the data you pass to it is copied into the socket buffer for that socket.  Then depending on the protocol it will actually send the data after some certain buffering criteria has been met.  For TCP, it waits until the TCP send buffer has been filled before actually creating the packet and pushing it out.

• The problem is , that in low priority level for Net Schedular, and an interrupt mode for it, my transmit task never runs.

I tried to tune the priorities of the transmit task and a worker task (app task), but nothing matters.

• When you say the packed the TCP task waits until the TCP send buffer has been filled, do you the filling the packet is done by software (the same transmit task), or it is done by hardware, or by some another internal task the NDK creates?

• If the protocol is TCP, does the transmit task pend on an internal semaphore, which is signaled from the HAL, only when an acknowledge for the recently sent packet is received?