System Tick Speed.

[phomann]

Hi Mark,

The example application uses a system tick of 50mS. It is my understanding that this should cause tasks to run 20 times per second. I tried halving this expecting the  watchdog task to toggle the LED at twice the speed, yet it seems to toggle slower.
When I changed the tick time to 10ms, the led toggled even slower. Am I missing something? 

Also, is it correct that with a tick of 50ms, the fastest a task can run is 200 times a second. In order to get decent response times over Ethernet. I want to set the tick time to 1ms, is this possible?

cheers,

Peter.

[mark]

Hi Peter

>> I tried halving this expecting the watchdog task to toggle the LED at twice the speed, yet it seems to toggle slower.
Changing the TICK value will not cause any periodic tasks (like the watchdog) to run at different rates. Their times are defined as:
(DELAY_LIMIT)( 0.2 * SEC )
where SEC is ( 1000 / TICK_RESOLUTION )
and #define TICK_RESOLUTION      50 // demo value

If you halve TICK_RESOLUTION to 25 it means that the TICK interrupt is occurring faster but SEC will now be double the value and so the value for (DELAY_LIMIT)( 0.2 * SEC ) will also have been automatically adjusted to remain at 0.2 seconds.

>>When I changed the tick time to 10ms, the led toggled even slower.
The only way that I can explain this is if there is something wrong with the calculation used to set the SYSTICK - I will try to reproduce this and report back later.

>>Also, is it correct that with a tick of 50ms, the fastest a task can run is 200 times a second. In order to get decent response times over Ethernet. I want to set the tick time to 1ms, is this possible?

The TICK defines the resolution of software timers (eg. if TICK is 50ms ,setting a SW mono-stable to fire after 65ms or 80ms will result in both cases in 50ms due to the fact that this is the absolute resolution). By setting the TICK to 10ms it would be possible to set 60ms and 70ms software mono-stable timers since the TICK resolution will be able to distinguish.

The TICK doesn't have any influence on the reaction of the Ethernet. If an Ethernet frame is received, its interrupt will immediately wake up the Ethernet task to initiate processing - there is no TICK involved and so increasing its speed to 1ms will not change anything. The effect of faster TICK than necessary is that the CPU has to handle more TICK interrupts and so the rule is to set the TICK as high as possible, still allowing the timer resolution for the most critical timer task. If you don't really need to have any better timer resolution that 1s there is no reason why the TICK needs to be as fast as 50ms... However be careful with the maximum value used (see config.h where there is a note about the maximum possible TICK value for the particular processor / HW-timer used).

Also note that, should the system require just one or two high accuracy timers, it may be best to configure HW timers specifically for the task since these will enable very high resolution without needing to increase the TICK frequency.

Regards

Mark

[mark]

Hi Peter

I have performed the following test on an LM3S8962 evaluation board.

1. Original demo project with #define TICK_RESOLUTION      50
The LED blink period was 200ms on/ 200ms off

2. #define TICK_RESOLUTION      10
The LED blink period was 200ms on/ 200ms off

3. #define TICK_RESOLUTION      1
The LED blink period was 200ms on/ 200ms off

Therefore I couldn't see any change in the repetition rate due to changes in the TICK. This is how it should be.
Can you possibly explain your observations due to another influence?

Regards

Mark

[phomann]

Hi Mark,

I am only using the simulator at this stage. If I change the tick resolution to 5, the pin on port F simulator display toggles about once every 3 secs.

As to my other question regarding the scheduling of task. When a tcp/ip message comes in, an interrupt sends an event to the tcp/ip task? This task is then schedules to run, and will be run as soon as all the tasks before it in the task list that are ready to be run have been run?

Are the tasks waiting to be run, run in the order that they are in the task list. or the order that they changed to the ready to run state?

Cheers,

Peter.

[phomann]

Hi Mark,

I looked at the uTaskerSchedule function and answered my own question. So, worst case is when a task has just yeilded control and an event for it is posted, it will have to now wait for all other tasks (that can run) to be run before it can process the event. Is that correct?

Cheers,


Peter.

[mark]

Hi peter

When using the simulator the times do tend to be a bit longer when using low TICK values. I sometimes do the following when the accuracy on the target is important - usually when simulating a high resolution is not paramount:
#ifdef _WINDOWS
    #define TICK_RESOLUTION      50                // good value for simulation
#else
    #define TICK_RESOLUTION      1                  // higher resolution for the target
#endif

The simulation accuracy depends on which Windows version is being used since the timer function using older operating systems has a limited resolution - I think that it is about 45ms or so. Newer Windows operating systems do better.

It all boils down to the accuracy of the following timeout in WinSimMain.cpp
        Sleep(TICK_RESOLUTION);                                          // we sleep to simulate the basic tick operation

My Vista based laptop simulates quite well with 10ms TICK (only very slightly slower toggling, which you don't really notice) but with 1ms it does get quite a bit slower...


The time taken for a task to service an event does indeed depend on the present position of the scheduler in its task list. The worst case is when all other tasks have the chance to run. Generally the system is fully event driven and tasks only do something when events occur, so usually the reaction time is quiet fast, wherever the present position is. The worst case can be calculated assuming all other tasks have first to treat their worst-case events.

Regards

Mark

[phomann]

Hi Mark,

Thanks for that. I'll do what you suggest regarding the Timer Tick definition.

Cheers,

Peter.

[aloft]

I'm seeing some weird issues when trying to reduce my power consumption.  I've defined the SUPPORT_LOW_POWER variable and I expected that setting TICK_RESOLUTION to something higher like 200 would increase the efficiency.  200 does increase the efficiency, but it doesn't work.  I've tried other values and they aren't working like I'd expect.
50 (default) = 93mA
200            = 71mA (but doesn't connect - no Ethernet LEDs even).
100            = 90mA (but doesn't connect - no Ethernet LEDs even)
250            = 112mA (but doesn't connect - no Ethernet LEDs even)

I must have some dependency on the TICK_RESOLUTION.  Any idea what I'm missing?  I'm probably overlooking something obvious.

Thanks,

TW

[mark]

Hi TW

I think that I can explain this. It is due to the task configuration:

If you look in the task configuration table (in TaskConfig.h) you will see entries like:
  { "ARP",       fnTaskArp,      MEDIUM_QUE, (DELAY_LIMIT)(0.05 * SEC), 0, UTASKER_STOP},
  { "Eth",       fnTaskEthernet, (HEADER_LENGTH * 12),  (DELAY_LIMIT)(0.05 * SEC), 0, UTASKER_STOP},
and
  { "app",       fnApplication,  MEDIUM_QUE,  (DELAY_LIMIT)(0.10 * SEC), 0, UTASKER_STOP},
   etc.

These tasks are started with a delay.
The problem is that if you increase TICK to above 50ms it will cause some values to become zero:
 (DELAY_LIMIT)(0.05 * SEC) == 0.05 * ( 1000 / TICK_RESOLUTION ) == 0.5
This requires half a TICK and DELAY_LIMIT is an integer value, which rounds down to 0. The task(s) will never start and so you will have no Ethernet - for example.

Note that when using routines like uTaskerMono() it is not that serious since the routine will interpret a zero value as a single TICK - it will thus at least get a delay, although rounded up in this case. In the task table, the compiler decides and so if a delay is rounded down to zero it can not be caught. This means that when increasing TICK_RESOLUTION also the possible impact on the task configuration (as well as the general resolution of the SW timers in the project) need to be considered.

In your case (when you want to use quite large values), a simple ways around this is to declare the start up delays directly in TICKs rather than in SEC.
The start up time will be a bit slower but the system will still be started in an ordered manor with no risk of difficulties when TICK_RESOLUTION is further increased.

  { "ARP",       fnTaskArp,      MEDIUM_QUE, 1, 0, UTASKER_STOP},                  // delays specified in TICKs
  { "Eth",       fnTaskEthernet, (HEADER_LENGTH * 12),  1, 0, UTASKER_STOP},
  { "app",       fnApplication,  MEDIUM_QUE, 2, 0, UTASKER_STOP},
etc.

Regards

Mark

[aloft]

Hi Mark. 

Thanks for the quick reply.  Yes, that was the problem.

Thanks!!

TW