Hello,
Is there a way to profile the application to figure out where it spends most of its time? I am trying to optimize reading from a serial port, parsing some data, and shooting it out on a ethernet socket. This needs to be fast, but is rather slow. How can I find out what it's doing?
Thanks!
Christoph
profiling
Re: profiling
How fast does it need to be? What baud rate are you using? How are you measuring throughput on the Ethernet side?
Re: profiling
I would like it to be maybe 10ms at worst, 0.5ms at best. I think it's about 50ms right now. I am using 11200 baud for TX rate. To test I just print out the time (microseconds), do a netcat to connect to the socket and write the output to a file, then abort with C-c, after which it prints out the time again. Then I count the samples and divide the time by it. Very rudimentary. 
Another, more practical test was setting the radar pedestal (that's what this is for) to spin at a constant 20 degrees/s and let the output, which is the current azimuth angle of the pedestal, fly by. When I look at how far apart the samples are, I get about a degree difference, which I don't think is sensitive enough.
This is likely a problem on my side, just trying to figure that out
Thanks!
Christoph
Another, more practical test was setting the radar pedestal (that's what this is for) to spin at a constant 20 degrees/s and let the output, which is the current azimuth angle of the pedestal, fly by. When I look at how far apart the samples are, I get about a degree difference, which I don't think is sensitive enough.
This is likely a problem on my side, just trying to figure that out
Thanks!
Christoph
Re: profiling
If you are doing a TCP connect/disconnect each time there will be overhead. If you can leave the TCP connection open all the time it would be a lot faster. If you can't leave it open, use UDP instead so you don't have the connection overhead of TCP.
The serial port baud rate is also an issue. 11,200 baud is approx. 1,120 bytes per second (counting start, stop bits). This is very rough, but that puts you at about 1.12 ms/byte. So if my math is correct, you could not even send one byte of data 0.5ms just considering the baud rate, even if every other delay was 0.
The serial port baud rate is also an issue. 11,200 baud is approx. 1,120 bytes per second (counting start, stop bits). This is very rough, but that puts you at about 1.12 ms/byte. So if my math is correct, you could not even send one byte of data 0.5ms just considering the baud rate, even if every other delay was 0.
Re: profiling
Network communications are capable of much higher bulk data transmission, but
the latency is much worse than simple serial.
The best your going to be able to do is UDP packets or TCP where you write the
serial block in complete sections.
Opening and closing the TCP connection is a a big time waster.
If you care about latency you must leave it open.
Try the exact same experiment between 2 3Ghz linux PC's and you will be surprised how long the latency is.
Paul
the latency is much worse than simple serial.
The best your going to be able to do is UDP packets or TCP where you write the
serial block in complete sections.
Opening and closing the TCP connection is a a big time waster.
If you care about latency you must leave it open.
Try the exact same experiment between 2 3Ghz linux PC's and you will be surprised how long the latency is.
Paul
Re: profiling
Thanks guys!
What do you mean by "leave the connection open"? I have the listen loop and an accept in there, once I get a connection from the accept I have the main loop that reads from the serial, massages the data and writestring's it to the file descriptor I got from the accept function. I don't ever close the connection (I'd like to from the client, see my other thread, in case you have any ideas).
That said, good call on the UDP. I don't really care if the client gets all the output; I'd rather be super fast and risk losing a packet here and there, so I'll try that. I don't remember what it's called, but there's a setting for TCP/IP that can be disabled for faster transfers. Could try that, too.
Lastly, I think the data from the serial port comes in plenty fast, but I will see about upping the baud rate a bit.
Christoph
What do you mean by "leave the connection open"? I have the listen loop and an accept in there, once I get a connection from the accept I have the main loop that reads from the serial, massages the data and writestring's it to the file descriptor I got from the accept function. I don't ever close the connection (I'd like to from the client, see my other thread, in case you have any ideas).
That said, good call on the UDP. I don't really care if the client gets all the output; I'd rather be super fast and risk losing a packet here and there, so I'll try that. I don't remember what it's called, but there's a setting for TCP/IP that can be disabled for faster transfers. Could try that, too.
Lastly, I think the data from the serial port comes in plenty fast, but I will see about upping the baud rate a bit.
Christoph
Re: profiling
http://forum.embeddedethernet.com/viewt ... ?f=5&t=495
There is a time slice profiling application attached to that thread.
There is a time slice profiling application attached to that thread.
Re: profiling
lgitlitz,
Thanks, I tried that. I had to modify the cpp to include sim5282.h instead of 5270.h since that file doesn't exist on my board. Then I get SIGSEGV on line 64 of TimeProfiler.cpp, in the call to SetIntc().
Christoph
Thanks, I tried that. I had to modify the cpp to include sim5282.h instead of 5270.h since that file doesn't exist on my board. Then I get SIGSEGV on line 64 of TimeProfiler.cpp, in the call to SetIntc().
Christoph
Re: profiling
The 82 has 2 interrupt controllers where the 70 only has 1. You need to change the declaration of the setintc function to the one for the 82 that includes the int controller parameter:
void SetIntc( int intc, long func, int vector, int level, int prio )
Then where this function is called add 0 as the first parameter. Also the vector for the PIT1 timer is 56 on this processor:
SetIntc( 0, ( long ) &NMI_ASM_Part, 56, 7 /* IRQ7 */, 7 );
Haven't tested this on the 82 but these changes should probably make it all work.
void SetIntc( int intc, long func, int vector, int level, int prio )
Then where this function is called add 0 as the first parameter. Also the vector for the PIT1 timer is 56 on this processor:
SetIntc( 0, ( long ) &NMI_ASM_Part, 56, 7 /* IRQ7 */, 7 );
Haven't tested this on the 82 but these changes should probably make it all work.
Re: profiling
Thank you sir, will give that a shot in a few days.