ZigBee throughtput test

[Nicolas Kauffmann]

Hi,

I would like to test the ZigBee throughput like the examples ("ATT_MTU Throughput Example" for BLE and "Thread Throughput Measurement Application").

I'm not familiar with ZigBee (I read about it but I'm still learning). I started from the example (Zigbee Light Control with touchlink commissioning). I don't know if it's a good idea.

I implemented a function to send data with the API described in the documentation (zb_zcl_start_command_header, zb_zcl_finish_and_send_packet).

And as a first test, I call periodically ZB_GET_OUT_BUF_DELAYED and it works but, if I send at a too short period (ex: 500ms), the target blocks for a while then receives then it blocks and again and again...

When I say it blocks, it means that I don't get any trace from zcl_device_cb (callback for handling ZCL commands).

Is my method good or am I mistaken ?  Do I need to implement my own cluster ?

Best Regards,

Nicolas

[Jørgen Holmefjord]

Hi,

I got some help with this from one of our Zigbee developers. We have created an example that you can use for testing throughput.

There is at least one issue in your code, you should not use "ZB_APS_ADDR_MODE_16_GROUP_ENDP_NOT_PRESENT". Groupcast is actually a broadcast and is limited. There is a special table to keep track of broadcast messages, because those packets are just retransmitted by every node couple of times. All nodes try to keep track of which messages they've already transmitted, so they do not cause a broadcast storm.

A couple of things you should consider when measuring throughput:

1. You should not use broadcast transmission to measure throughput (groupcast).
2. It is worth having a second device that will accept those "custom" commands to avoid traffic containing error messages.
3. Going from light sample example with coordinator may be easier (there is an explicit place where you read light bulb's address). Although to avoid going through coordinator to the second node it is worth powering it off after the commissioning and reset all devices.

The attached file contains an example based on the light_switch example in the SDK for Thread and Zigbee v1.0.0. It have been tested with 50ms intervals and there seems to be pretty traffic without crashes at this rate. Please check the patch file for diff towards original example. 

light_switch_throughput.zip

diff.patch

Hope this helps!

Best regards,
Jørgen

[Nicolas Kauffmann]

Hi,

Thank you !

It works but I have a few more questions if you don't mind :

I've read that a ZigBee packet is 127 bytes (payload) (up to 133 bytes (with headers)).

When I send at 50ms during one second (20 frames), it gives me:

133 * 8 = 1064 bits

1064 * 20 (frames) = 21280 bits -> 21kbps

Am I correct ?

If I want to reach (approximatively) the 250 kbps announced by Nordic, I can decrease the period but if it's too low I have memory buffer problem, ZB_GET_OUT_BUF_DELAYED returns RET_ERROR indefinitely.

Does this throughput (250kbps) is reachable only at lower layer as you suggested earlier ?

Best regards,

Nicolas