Subject: Re: [Dev] Performance Profiler

From: "M. Mueller/bhu5nji" <[email-masked]>
Date: Tue, 8 Jan 2002 00:41:01 -0500

On Tuesday 08 January 2002 12:32 pm, you wrote:
> > b.
>
> ping will give round trip times. Are you sending the packets over a PPP
> connection via modem?  Typical ping's on a modem connection are usually
> several hundred milliseconds.

The V.35 is SS7 on DDS 56kb/s - definitely not pingable.

>
> I've used snoop on Sun boxen and seem to remember getting timestamps from
> it. tcpdump may be able to retrieve same.

I'll check snoop.  Ethereal (which I am using) is a glorified tcpdump (I 
think).

I'm thinking more along the lines of profiling what's going on inside the box.

Thanks for the hints
Mike

---

From: Brent Verner <[email-masked]>
Date: Tue, 8 Jan 2002 16:21:32 -0500

[2002-01-08 00:41] M. Mueller/bhu5nji said:
| On Tuesday 08 January 2002 12:32 pm, you wrote:
| > > b.
| >
| > ping will give round trip times. Are you sending the packets over a PPP
| > connection via modem?  Typical ping's on a modem connection are usually
| > several hundred milliseconds.
| 
| The V.35 is SS7 on DDS 56kb/s - definitely not pingable.
| 
| >
| > I've used snoop on Sun boxen and seem to remember getting timestamps from
| > it. tcpdump may be able to retrieve same.
| 
| I'll check snoop.  Ethereal (which I am using) is a glorified tcpdump (I 
| think).
| 
| I'm thinking more along the lines of profiling what's going on inside the box.

compile your prog with 'gcc -pg ...'.  When you run the prog, a
gmon.out file will be created, which can processed by gprof to list
called routines, and time spent in routines.

$ gcc -g -pg src.c -o exe
$ ./exe
$ gprof exe gmon.out

hth.
  b

| Thanks for the hints
| Mike
| _______________________________________________
| Dev mailing list
| [email-masked]
| http://www.trilug.org/mailman/listinfo/dev

-- 
"Develop your talent, man, and leave the world something. Records are 
really gifts from people. To think that an artist would love you enough
to share his music with anyone is a beautiful thing."  -- Duane Allman

---

From: "M. Mueller/bhu5nji" <[email-masked]>
Date: Tue, 8 Jan 2002 16:22:05 -0500

> $ gcc -g -pg src.c -o exe

Cool.  I tried it but it busted on a "select".  I will play with this more in 
the future.

I may have worked around the problem.  I have a proprietary wrapper around 
datagrams as they pass through the box.  I added 6 new fields to the wrapper 
as follows:

struct timeval timeStampA
struct timeval timeStampB
struct timeval timeStampC
struct timeval timeStampD
struct timeval timeStampE
struct timeval timeStampF

I loaded the fields with gettimeofday() after the recvfrom on entry and 
before the sendto on exit from each of the 3 daemons n my app.

I found the D to E transfer in one direction was taking about 1/2 minute 
consistently.  After substituting code from a "fast" daemon into the "slow" 
daemon and gnashing my teeth in frustration for a while I noticed that the 
fast daemon had a blocking select (wait-forever).  The "slow" daemon used a 
polling select (no-wait).  I changed the slow daemon select to wait for 10000 
usecs.  Voila. Transfer time overall goes down dramatically.  I went through 
the entire code body and changed all polling selects to wait for 10000 usecs 
selects. 

The change is dramatic.  Before the change, using LOTs of syslogging, I got 
cross 2-box delays of about 30 secs and with almost no syslogging I got .9 
sec delays.  With the new change I get delays of .2-.02 secs with LOTs of 
syslogging.  These numbers are much more reasonable. (Great sigh of relief.)

This result does not seem consistent with how I read Stevens explanation of 
no-wait select in section 5.6 of Unix Network Programming Vol 1.

I am using a 2.2.14 kernel.

Mike