Forum Discussion

Altera_Forum's avatar
Altera_Forum
Icon for Honored Contributor rankHonored Contributor
12 years ago

Tasks priorities in NicheStack

Hi there,

I have a problem with task priorities using the NicheStack.

My app task has priority 4 and the TCP tasks start at priority 5. The app task is basically a for(;;) loop which writes a value to a output pin and sleeps during 500 ms and so on. This works like a charm when no net traffic is present (the TCPs task has no workload), the app task sleeps exactly 500 ms.

But when we add net traffic it seems that the TCP tasks (with lower priority) consume too many CPU time and the app task (the higher priority task) frequency is not 500 ms anymore, it increases to 1000 ms or more.

My question is:

Is it not supposed that the uCOSII scheduler should give CPU to the higher priority task as soon it is ready to execute? Maybe there is so many interruptions that overkill the OS?

Any help will be appreciated.

5 Replies

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    12 years ago

    Does your higher priority task use any network API function? (either receive or send)

    How did you implement the 500ms pause?

    You are right that the higher priority task should be the one running even if there is a high IP load, but the interruptions always have a higher priority.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    12 years ago

    --- Quote Start ---

    Does your higher priority task use any network API function? (either receive or send)

    --- Quote End ---

    No, I don't use any network function.

    --- Quote Start ---

    How did you implement the 500ms pause?

    --- Quote End ---

    I call OSTimeDly() function.

    --- Quote Start ---

    You are right that the higher priority task should be the one running even if there is a high IP load, but the interruptions always have a higher priority.

    --- Quote End ---

    I'm using the SMSC MAC, maybe building the driver to polling mode would be the solution, what do you think?

    Thanks.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    12 years ago

    IIRC the interrupt routines in the TSE driver don't use that much CPU, but yes you could try polling instead and see if it changes anything. As long as you don't have a high network traffic, it should be ok.

    Are you using a constant delay in OSTimeDly()? If yes you could use an alternative method:[list][*]ask for the local time when your function starts executing (T0)[*] when it is finished, ask for the time again (T1)[*]call OSTimeDly() with a dynamic delay, 500ms-(T1-T0)[/list]
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    12 years ago

    Oh and I forgot, for the other runs, instead of measuring T0 each time, increase the value by 500ms

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    12 years ago

    I have switched the driver to polling mode and NOW the high priority task works as expected.

    I forgot to tell before :( but I've used the TfGen app to generate traffic to the board, from 1000 to 10000 kbps.

    But there are some problems, sometimes (when TfGen is running) the execution stops with a dtrap(), exactly in the ip_reassm() function, inside the "if (!ahole)" condition; sometimes (when is connected to a local net and the TFGen is not running) the ping don't work. I'm using version 2 of the NicheStack.

    You've given a clue, the current driver is the SMSC but exchanging it to the TSE driver maybe worths a try.

    Thanks.