• State Resolved
  • Locked Locked
  • Replies 2 replies
  • Subscribers 53 subscribers
  • Views 652 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

EtherMind Throughput and CPU Utilization

Robby Morrill
Prodigy 135 points

Hi, i think this question these questions are directed mostly to Gustavo, but if anyone else has any information, feel free to chime in:

 

The EtherMind Bluetooth SDK Developer Guide provides several measurements regarding CPU utilization and throughput, but I have a few questions. Both measurements are said to have been taken with a packet size of 110, is there any reason 110 was chosen? Is there a maximum a packet can be? Is throughput or CPU utilization even a function of packet size?

 

The reason I ask, is that there seems to be a ‘maximum packet rate’ that is independent of the maximum throughput of the system, is that correct, or is there documentation that clarifies this? Or is the code used to run these tests available? What would be most useful for us is to know the actual number of packets sent per second, at varying payload sizes.

 

The CPU utilization measurements look good, however, is there a bounded maximum amount of time that the BT stack will use the processor before another task is able to run? We can test is this somewhat experimentally, but it would be nice to know under what condition will cause the stack to use the CPU for the longest contiguous block of time, which would greatly help us design the rest of our somewhat real time system.

 

Thanks!

 

  • 0
    Intellectual 320 points

    Hi Robby,

    I'm running into this right now as well. I am trying to develop a RS232 replacement with high throughput and the ability to perform XMODEM and YMODEM transfers. These two protocols call for packet sizes of 128 and 1000 bytes, which is a problem if the module can only handle packets of 110. I haven't been able to figure out why it can only handle 110.

    By making several changes to arrays and buffer sizes, I can now send the BT module packets of up to 244 bytes without causing it to crash. And yes, larger packet size does appear to positively impact throughput (not sure about CPU utilization though).  Right now I believe what is preventing me from sending larger packets are UART_RX_BUFFER_SIZE and UART_TX_BUFFER_SIZE, which unfortunately cannot be changed due the definitions in modules that cannot be edited. This is what you get if you try:

    "Warning[w6]: Type conflict for external/entry "read_task_buffer", in module msp430_uart against external/entry in module read_task; array types have different sizes."

    Does anyone know why the module is limited in this way or if there is a way to change it?

    Fred

  • 0 in reply to Fred J
    Intellectual 425 points

    Hi Robby,

    As you must be aware Bluetooth protocol as such doesn’t limit the packet size to any specific value, but we in our BT library configuration has limited it to 110 bytes of SPP data payload.

     

    The SPP payload size is coupled to the L2CAP MTU size and to the BT memory bank size, so an increase in the SPP payload size will mean an increase in the BT memory pool sizes, which would further mean more MSP430 RAM consumption. This led to the decision to limit the payload size to 110 bytes so that we keep the RAM usage to an optimal level w.r.t the SDK.

     

    If your application requires more than 110 bytes of data to be sent at a time, then you would need to have a fragment-defragment mechanism in your application which creates data chunks in order of 110 bytes. The only way the BT library can handle more than 110bytes is by changing the BT configuration and rebuilding the library.

     

    Yes, CPU Utilization and throughput measurement is a function of packet size, and the measured values mentioned in the developer guide is taken with 110 bytes payload.

     

    Hi Fred,

    read_task_buffer and uart_tx_buffer are defined in the BT library with size of the buffers set to UART_RX_BUFFER_SIZE and UART_TX_BUFFER_SIZE respectively. Hence the warning. You should not be modifying the value of these macros.

    Regards,

    Senthil.