- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.Link Copied
5 Replies
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
--- 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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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]- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Oh and I forgot, for the other runs, instead of measuring T0 each time, increase the value by 500ms
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
Reply
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page