Alright, got a chance to test it, and it works great! Thanks a lot!
Now the problem is that, throughout the task I thought was taking so long, the vast majority of calls are in the idle task. Counters are up in the hundreds around 02005ED4-02005EEX, everything else has 1-5 counts.
Here is the code:
https://gist.github.com/273ad9bf274dfe141c95
I stuck the profilestart() around line 3, the stop and show inside a condition on line 33. That condition checks for a counter exceeding 30 or so, with the counter being incremented after the print_data on line 48.
Assuming the ocp object is not the issue, do you guys see what the problem may be?
Thanks!
Christoph
profiling
Re: profiling
It looks like most of the time will be spent pending in this task, either waiting for the accept or read function. When you are pending it allows other tasks to run. If all tasks are pending then the idle task runs.
So you are trying to reduce the latency from when you receive a packet to when you send it? If so then I do not think the time slice profiler is the best tool to benchmark where the time is being spent. The time slice profiler is better used when you have an active loop or task that does not have pend events, otherwise you will get the results you are seeing. A better method would be to simply use a hardware timer to see how long the various sections of code are taking. First get an overall time measurement from receiving the data to sending it. Then measure the individual pieces of processing to see what is causing the lag. I posted a stopwatch application that will work well for this and is pretty simple to use (http://forum.embeddedethernet.com/viewt ... ?f=7&t=397). You calculations can be sped up significantly if you make use of the on-chip SRAM for your variables or task stack (http://www.netburner.com/downloads/nndk ... rmance.pdf).
So you are trying to reduce the latency from when you receive a packet to when you send it? If so then I do not think the time slice profiler is the best tool to benchmark where the time is being spent. The time slice profiler is better used when you have an active loop or task that does not have pend events, otherwise you will get the results you are seeing. A better method would be to simply use a hardware timer to see how long the various sections of code are taking. First get an overall time measurement from receiving the data to sending it. Then measure the individual pieces of processing to see what is causing the lag. I posted a stopwatch application that will work well for this and is pretty simple to use (http://forum.embeddedethernet.com/viewt ... ?f=7&t=397). You calculations can be sped up significantly if you make use of the on-chip SRAM for your variables or task stack (http://www.netburner.com/downloads/nndk ... rmance.pdf).
Re: profiling
Yeah that's what I want, but also take into account that maybe the packets don't come in fast enough through the serial, but this will work nicely to see if my processing just takes forever. Thanks!
Re: profiling
The source code for everything you are looking to benchmark is available to you. It wouldn't be too difficult to go into the serial driver and add the startstopwatch function in the RX interrupt routine. Just don't try to print out the results from inside the interrupt and this should work fine. Make sure to rebuild the system files if you modify them.
Re: profiling
Looks like most of the time is spent in writestring(), almost 1.2ms compared to 8-80ms for other stuff.
I tried write, but it's just as slow as writestring, so I guess UDP is the only way to go now? Oddly enough, if I remove the write to the network, and just printf the result, it's still too slow. Guess I need to keep looking in other places....
Thanks for all those tools Igitlitz, they help a lot!
Christoph
I tried write, but it's just as slow as writestring, so I guess UDP is the only way to go now? Oddly enough, if I remove the write to the network, and just printf the result, it's still too slow. Guess I need to keep looking in other places....
Thanks for all those tools Igitlitz, they help a lot!
Christoph