Experimental Physics and
Industrial Control System

"J. Lewis Muir via Tech-talk" <[email protected]> · Mon, 18 Nov 2019 14:55:41 -0600

On 11/18, Mark Rivers wrote:
> Ø  Strange.  Other things you could try:
> 
>    1. Run curl and curl_gen under strace (e.g., "strace -CftT -s 256
>       <command>") and see if you can tell where curl_gen is taking longer
>       than curl.
> 
> This is the final output of strace when running curl_gen:

[snip]

> This is the output of strace when running the curl command:

[snip]

> I don't know how to interpret these because the total elapsed time
> for curl_gen was 0.33 seconds while for the curl command it was 0.12
> seconds.  The tables above seem to show only 2-3 ms?

Yeah, that's because my suggested strace command is no good.  Sorry
about that.  Try "strace -CfttTw -s 256 <command>" instead.

I added an extra "-t" option to make it print the microseconds.  Without
that, you can't see what's going on.

And I added a "-w" option so that the trace timestamp differences are
wall clock time, not system time.  This affects the total seconds in
the summary table too.  Without it, you were just seeing system time, I
think.  With the "-w" option, the summary total in seconds should equal
the wall clock running time you have observed.  Note, however, that if
the program does any forking where the parent waits for the child to
finish, I think that will mess up the summary total since, e.g., the
parent could be waiting in a system call for the child to die, and the
child could be waiting in a system call for something else, and both of
those would be included in the summary total.  So, you could end up with
a summary total that is greater than the actual wall clock running time
of the program.

Also note that in the trace output, the number at the end of each line
in angle brackets (e.g., "<0.000085>") is the elapsed wall clock time
spent in the system call which might be easier to look at than taking
the difference of the two timestamps.

BTW, I'd be more interested in comparing the trace and less interested
in the summary at the end, but if the summary at the end shows anything
interesting, then great, at least it didn't get missed.

[snip]

>    3. Check the ldd output for curl, libcurl.so, and curl_gen for anything
>       that looks suspicious.  Make sure curl_gen is not linked against
>       libgnutls.
> 
> corvette:motorNewport/newportApp/src>ldd ../../../../bin/linux-x86_64/curl_gen

[snip]

Can you also list the same for curl?

Lewis

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System