Windows Port simulation speed

Kernel
1

Hi !

I’m experimenting with the windows MSVC_MINGW port.

After some doing some measurements, I’m realizing that my scheduler ticks are twice as slow as expected, i.e. 1ms is actually 2ms.

Here’s an example where a single task is schedule to be executed every 1000ms:

volatile int i = 0;

static void hello_task(void *pvParameters) {
  (void)pvParameters;

  TickType_t xLastWakeTime = xTaskGetTickCount();
  for (;;) {
    TracyCZone(ctx, 1); // Tracing utility
    {
      printf("%d\n", xTaskGetTickCount());
    }
    TracyCZoneEnd(ctx);

    vTaskDelayUntil(&xLastWakeTime, pdMS_TO_TICKS(1000));
  }
}

`FreeRTOSConfig.h` is configured so 1000 tick is 1000 ms

#define configTICK_RATE_HZ                      ( ( TickType_t ) 1000 )

Here’s the console (as you can see, the task is executed every 1000ms)

image
image427×162 3.45 KB

Here’s my trace measurement (as you can see, the task is executed every 2000ms)

image
image938×401 45.9 KB

I was expecting the windows scheduler behavior to be a bit off, but the fact that it’s almost exactly twice as slow is suspicious to me.

My questions:

What could cause this difference? Do you have an idea on how to fix it?

As a follow-up, can we speed things up? My desktop is so much more powerful than a 32bit mcu, it would be convenient to run my simulation 100x faster than my actual code.

Thanks!

2

One reason may be load on your machine. Check the CPU usage. Regarding speeding it by 100x, I am not aware of any such option. You may consider checking QEmu also.

3

When I work with the WinSim release, I always use #define configTICK_RATE_HZ 100just to increase the performance.

That is also a test to make sure that the functions pdMS_TO_TICKS() and pdTICKS_TO_MS() are being called where applicable.

@fz-gabriel

Q: could you put the tickrate on 100 Hz and report what delays you measure? About 10 or 19 ms?

There is a wonderful thing about WinSim (the MSVC_MINGW port):
The duration of a clock tich can not be guaranteed because the FreeRTOS task is competing with other tasks/threads in a core, and the Windows scheduler is not particularly real-time.

And the good thing: we used the WinSim port very often for testing and debugging real-time issues: the flow of the program is exactly the same as it is on any other “real hardware” platform. Those tests often had multiple tasks running on the same priority level, in an attempt to trigger race conditions.

Often these macros were defined:

#define configUSE_PREEMPTION 1
#define configUSE_TIME_SLICING 1