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.

MSP-EXP432E401Y: Network Services HTTP Server performance inconsistencies.

Part Number: MSP-EXP432E401Y
Other Parts Discussed in Thread: BOOSTXL-SHARP128,

Hello,

I have been working on a Web server using the HTTPServer module available in the Network Services code that comes with the "simplelink_msp432e4_sdk_4_20_00_12" SDK.

I have also added to the MSP-EXP432E401Y development board a BOOSTXL-SHARP128 Booster pack for the SD card interface.  Currently I have modified the example project "httpserver_MSP_EXP432E401Y_tirtos_ccs" to read web pages off of the SD card and send using the HTTP Server.  I also have some code that will parse the web pages and insert dynamic data before it is sent out.

I have noticed that there are certain inconsistencies in how fast the web pages are delivered whenever I access them via a web browser.  Some of the time the web pages will load within a second and other times the web pages will take several seconds to load, usually 5-7 seconds.  It is a very noticeable difference when accessing the web pages.  This is all done on a local network with a simple switch between the MSP-EXP432E401Y and the PC I am testing with.

As I add more of my code the speed at which the HTTPServer responds changes almost randomly.  Some times it will load the web pages really fast, and other times it will load them slower.  This happens no matter which web browser I use.  I can make the response speed of the HTTP Server change just by commenting out or adding a few lines of code sometimes.  This is very repeatable.

As an example, if I make a small code change to one of my functions the HTTP server slows down.

static void writeHourEEPROM(char *value, uint8_t chanNum, log_eeprom_vars_t postVar)
{
    uint8_t hrVal = (uint8_t)atoi(value);

     /* Check if returned value is an error */
     if(hrVal == 0 && value[0] != '0')
         return;

     /* Check if a valid Hour Value */
//     if(hrVal >= 24)
//         hrVal += 20;

     const eepromVar_meta_t *tablePtr;
     tablePtr = log_EEPROM_Table[chanNum];    // Save Pointer to table for correct channel

     uint16_t eeWordVal = eepromRead_uint8(tablePtr[postVar]);

     /* If write is same as value read from EEPROM the exit */
     if(hrVal == eeWordVal)
         return;

     eepromWrite_uint8(hrVal, tablePtr[postVar]);
}

This version of the function causes the HTTP server to run slowly.  If I uncomment two lines in the function as follows, and rebuild the project, the HTTP server will serve the pages at the faster rate.

static void writeHourEEPROM(char *value, uint8_t chanNum, log_eeprom_vars_t postVar)
{
    uint8_t hrVal = (uint8_t)atoi(value);

     /* Check if returned value is an error */
     if(hrVal == 0 && value[0] != '0')
         return;

     /* Check if a valid Hour Value */
     if(hrVal >= 24)
         hrVal += 20;

     const eepromVar_meta_t *tablePtr;
     tablePtr = log_EEPROM_Table[chanNum];    // Save Pointer to table for correct channel

     uint16_t eeWordVal = eepromRead_uint8(tablePtr[postVar]);

     /* If write is same as value read from EEPROM the exit */
     if(hrVal == eeWordVal)
         return;

     eepromWrite_uint8(hrVal, tablePtr[postVar]);
}

As can be seen the changes to the function are insignificant and should not affect the HTTP server's code.  This is just one of the many times I have seen this while coding.

Sometimes just changing the optimization in the build options will also change the speed at which the HTTP server will respond, and optimizing for speed doesn't necessarily cause the HTTP server to respond more speedily.  It may cause the HTTP server to respond more slowly.

My instinct tells me there is something in the placement of the code that is causing this issue, but I have not idea why.  

If anyone has any suggestions as the what might be causing this issue it would be greatly appreciated.

Thanks,

Josh

  • Hi Josh,

    If you think it has to do with code placement you can diff the generated .map files to see if there is anything suspicious.

    However, it seems like there are some routines that may be timing sensitive that are causing race conditions. I would suggest using the ROV in CCS to see where the code is spending most of its time.

    Regards,

    Evan

  • Thanks Evan,

    I will look into what you suggested and see if I can find anything.

  • Hello Evan,

    I have done a bit of testing with the ROV and so far every time I run the code with ROV running in debug mode the HTTP Server is speedy., and I haven't noticed anything strange in the ROV Views. Once I close debug mode without changing any code the HTTP Server reverts back to the slower response speed.  

    I am not sure what this is indicating, but it might be a clue.

    Josh

  • Thanks for the update.

    The debugger may affect the execution timeline of your program. If your program's behavior changes with the debugger connected, that might also be a clue that there is a race condition somewhere in you program. 

    Do you have any routines or tasks that take a long time to execute that can prevent other tasks from being serviced. You showed an EEPROM function in your code above, it is possible it's getting stuck in there? Or somewhere else?

    Another option for debugging is to toggle GPIO when you enter and exit certain tasks. That can also give you some insight about where you application is spending its time or getting stuck. Of course a GPIO call has a tiny bit of overhead, which may or may not affect you race condition (if it is a race condition) so you may have to experiment. 

    Hope that helps. Post back if you have more questions.

    Regards,

    Evan

  • That can also give you some insight about where you application is spending its time or getting stuck. Of course a GPIO call has a tiny bit of overhead, which may or may not affect you race condition (if it is a race condition) so you may have to experiment. 

    Statistical Function Profiling might help, avoiding the need to instrument the code to toggle a GPIO.

  • Thanks for sharing that Chester!

  • Thank you both for the feedback.

    I will explore both options and see what I can figure out.

    Best,

    Josh