High latency on Zigbee router

RE: High latency on Zigbee router

Edvin — Fri, 25 Mar 2022 08:23:13 GMT

Hello,

After talking with our Zigbee team, and they said that you should indeed not use the zb_buf_get_out_delayed_func(). You should rather use zb_buf_get_out_delayed(). They said that it should reduce the delay.

The reason for the delay in the first place is that whenever the Zboss stack decides that it has nothing to do, it may suspend itself for a given amount of time. Using the ZBOSS API doesn't directly resume the ZBOSS thread. If I understood them correctly, using zb_buf_get_out_delayed() (instead of zb_buf_get_out_delayed_func()) will still be thread safe, as the _func() variant also is), but it should also resume/wake up the ZBOSS thread, which should significantly improve the latency.

Note that at times of high ZBOSS activity, you still may see some delay.

They also mentioned that because of what that is explained above, a zigbee application may actually run slower when there is less traffic (less events to wake up the ZBOSS stack).

BR,

Edvin

RE: High latency on Zigbee router

mytzyiay — Wed, 23 Mar 2022 22:10:14 GMT

Are the samples wrong to be calling zb_buf_get_out_delayed_func() from outside the Zigbee thread?

RE: High latency on Zigbee router

Edvin — Wed, 23 Mar 2022 21:34:41 GMT

Hello,

Sorry for the late reply. I also handle the other ticket that you have ongoing. I see that it is the same application, and seeing as you sort of figured this out, is this subject still something you need us to look into?

BR,

Edvin

RE: High latency on Zigbee router

mytzyiay — Tue, 22 Mar 2022 04:52:54 GMT

BTW, I did see in https://developer.nordicsemi.com/nRF_Connect_SDK/doc/zboss/3.5.2.0/zigbee_prog_principles.html

> Except for the scheduler API, the Zigbee stack API is not thread-safe. This means that calls to the Zigbee API must be invoked through scheduler callbacks or from the same thread that runs the scheduler loop. In NCS, the scheduler API is overloaded by functions that make it interrupt- and thread-safe. These functions can be found in nrf/subsys/zigbee/osif/zb_nrf_platform.h.

which suggests that maybe I shouldn't be trying to allocate ZB bufs from the main app thread.

But I see zb_buf_get_out_delayed_ext() being called from e.g. non-Zigbee worker threads in light_switch's button_handler(), and even in the timer callback light_switch_button_handler(), so I assumed it was safe to do. Is that correct?

If I change my code to do this, the latency problem vanishes:

static void tock_cb2(zb_uint8_t bufid)
{
 LOG_INF("tock %lld", k_uptime_get());
 if (bufid)
 zb_buf_free(bufid);
}

static void tock_cb1(zb_uint8_t bufid)
{
 zb_buf_get_out_delayed_func(tock_cb2);
}

/* at the end of main() */
 while (1) {
 LOG_INF("tick %lld", k_uptime_get());
 zb_ret_t error_code = ZB_SCHEDULE_APP_CALLBACK(tock_cb1, 0);
 if (error_code != RET_OK)
 LOG_ERR("error %d", error_code);
 k_sleep(K_SECONDS(2));
 }