Different run time on C3000 & C3600

[Dennis Weitzell]

One of our AEs is benchmarking run time on various CPUs (specifically C3000, C3600 & N4000). He is getting different run times using the UNIX "time" command (see the text below).

Can anyone shed light on why there is a difference between the C3000 & C3600 time output?

Thanks in advance.

### AE's email ###

Attached is a cut and past extracted from the end of the output of a test using
a testbench ran on three different HP models. There appears to be
inconsistencies here.

-- The percentage time it takes for the cpu of the overall time to run in
Run#1 is 8%. "uptime" tells me that there was no other activity on the C3600,
...so what was it doing the remainder of the time? The other boxes do not show
this characteristic (they also had load values < .3).

-- The actual time it took the C3600 (94.2s) to execute the script was less
than 1/20 of that required by the C3000 (1856.2s) and yet the over all time of
the two boxes was comparable (27 min. for the C3600 .v.s. 33 min. for the
C3000).

-- The time reported back by the application, ncsim, must be a subset of the
overall time but for the C3600, it is ~20 times more. (It is not known exactly
how the application vendor for ncsim derives its time measurements).



Run #1 -- Result from ec0233 (C3600, HP-UX_B.11.00)
===================================================
...
ncsim: Memory Usage - 10.8M program + 87.4M data = 98.2M total
ncsim: CPU Usage - 13.1s system + 1388.2s user = 1401.3s total (1427.3s, 98.2%
cpu)
Start: 07:34:15 End: 07:58:04
94.2u 46.0s 26:52 8%


Run #2 -- Result from cae663 (C3000, HP-UX_B.11.00)
===================================================
...
ncsim: Memory Usage - 10.8M program + 86.1M data = 96.8M total
ncsim: CPU Usage - 27.5s system + 1730.8s user = 1758.3s total (1780.1s, 98.8%
cpu)
child process exited abnormally
while executing
"close $SIM"
(file "./simulate.tcl" line 55)
1856.2u 84.7s 33:23 96%


Run #3 -- Results from ec0821 (N4000-44, HP-UX_B.11.00)
=======================================================
ncsim: Memory Usage - 10.8M program + 86.1M data = 96.8M total
ncsim: CPU Usage - 22.4s system + 1926.2s user = 1948.6s total (1954.6s, 99.7%
cpu)
child process exited abnormally
while executing
"close $SIM"
(file "./simulate.tcl" line 55)
2051.2u 95.6s 36:21 98%


Test
=====
The command at the csh-shell prompt was:
time ./Run_me -time
This is a 10 line csh-shell script that compiles, elaborates, then simulates a
vhdl design. The commands are vendor executables. The "-time" option tells the
simulation to output status which includes the time it took to simulated the
design (simulation is normally 90% of the time used in executing the csh-shell
script).


Finding the reasons for the seamingly inconsistant results is important because
the metrics will be used to support or breakdown the conclusion that the
N4000-44 box (ec0821) has a problem and might need looking at by hp.

[harry d brown jr]

Are the three machines running with the same patch levels?

Are all three machines running 64bit ??

Is the application designed to run in 64bit mode ??

What about memory configurations?

Enough swap?

Disk IO subsystem differences?

IO cards in the C's ??


live free or die
harry

[Mike Stroyan]

That is not the output of the /usr/bin/time command. It is the output of some shell builtin. It looks like csh in every case, but it might be something like tcsh. You could check which shell each system is using and the patch level of the shell. You could switch to really using /usr/bin/time.

[Evert Ladrak]

I hate to say it but this actually from a tcl script that fails at line 55 on the C3000 and the N4000 it only runs successfully on the C3000.


--ETL

[Dennis Weitzell]

Thanks to all that responded. After running several tests and requesting the AEs to further investigate their script, it was determined that the problem WAS in the tcsh shell. Getting the AE to finally accept that the problem was theirs and not the OS's was challenging but he finally agreed.

Thanks again.

[Pete Randall]

Another nominee for "Stupid User Tricks".

;^)

Pete