configTICK_RATE_HZ scales application speed?

danielgraham2 wrote on Monday, August 20, 2018:

I have following (strange?) behaviour:
when I change the configTICK_RATE_HZ value, my application speed scales with the factor i changed the value with.

Example: I have a webserver that can up/download a file.
My configTICK_RATE_HZ is 250 Hz. Here the upload takes 1 Minute.
When I change the configTICK_RATE_HZ to 1000 the upload only takes 25 seconds…

When I understood the configTICK_RATE_HZ value properly, this should not be. The value should only control the granularity of the time I can measure with freeRTOS and the frequency the tasks are evaluated for selection, but should not have any impact to the speed the application runs with.

I checked the obvious error: vTaskDelay(Until) is only used with pdMS_TO_TICKS macro.

I am using FreeRTOS 9 with the Microchip Harmony Framework on a PIC32MZ2048EFM144.

Can someone confirm that this behaviour is not right?

1 Like

richarddamon wrote on Monday, August 20, 2018:

A couple errors can cause this sort of issue. One is that if the port doesn’t actually change the tick rate when you change the define, then timeouts will be incorrect. One quick test is to implement the tick-hook and have it toggle a bit and see that the tick rate is right and changes.

A second type of error that can do this is if some ISR that you depend on doesn’t test the wasWoken flag and force a reschedule, in which case the task that should have been activated by the ISR waits till the next tick interrupt.

rtel wrote on Monday, August 20, 2018:

In addition to Richard D’s answer:

  1. ALL block times should use the pdMS_TO_TICKS() macro to ensure
    block times scale automatically to the correct value whenever. You only
    mention vTaskDelay(), but block times are used in a lot more places than

  2. Ideally your entire application should be event driven - that is -
    never have an arbitrary delay when waiting for an external event
    [ideally] and instead have the event unblock a task.

Given the two above, changing configTICK_RATE_HZ should only change the
granularity and accuracy of block times, and not change the execution
speed of the application. Conclusion is, there is something in your
code, or the harmony code, that is doing something contrary to the above.

danielgraham2 wrote on Tuesday, August 21, 2018:

OK, thank you both for the clarification and the hints.
I will investigate - something is not right.