[time-nuts] Programming of 5370B

[David Kirkby]

I was going to send this to Poul-Henning Kamp personally, but thought it 
might be useful to put here, as the discussion might be useful to others.

BACKGROUND.
I was aware Poul-Henning Kamp had written some software to read from the 
HP 5370B TI counter.

I asked him to send it to me, which he did. After getting Solaris 
drivers for my GPIB card, the software was reading around 4000 
measurements/second on my old Sun (4x450MHz) which was not too different 
from the 5000 on his OpenBSD box. (I doubt CPU performance is a limit, 
but probably bus speed).

Poul-Henning Kamp's program was reading in binary mode and I had some 
difficulty working out exactly how the numbers were obtained from all 
the shifts and logical operations. Things such as:

                 n0 = (buf[3] << 8) + buf[4];
                 if (!(buf[0] & 0x20))
                         n0 = -n0;

                 n12 = ((buf[0] & 3) << 16) + (buf[1] << 8) + buf[2];
                 if (n12 & (1 << 17))
                         n12 -= (1 << 18);

are not too obvioous, although they seem to work very well.

I took the software and some of the ideas to write my own, so I 
understood it. I learnt one thing for sure - I can write slower 
software!! But at least I understand it.

What I did do however (for simplicity) was to read the data in as the 
standard ASCII, which is the default output data format of the HP. I did 
not use binary.

The 5370B manual says each measurment consists of about 5 differnet 
parts, all of which add up to exactly 23 bytes.

For TI, a measurement might something like:

TI = 9.98898989E-08\r\n

but will be exactly 23 bytes.

But I am getting very poor performance, with around 63ms between each 
data point collected (around 16 results/second), which is a lot poorer 
than the 4000 measurements/second I was getting with  Poul-Henning 
Kamp's program. I suspect this is the result of reading with ASCII, but 
would be interested in comments.

The program I wrote is called 'hptic' and takes options for function 
(time-interval, frequency etc), as well as SD etc. It uses 
autoconf/automake and accepts long options, so it should be pretty 
friendly if I get the peformance up.

The program prints a couple of lines of notes, including the GPIB string 
the program actually sends to the counter. In this case its just 'FN1' 
for time-interval.

sparrow /export/home/drkirkby/5370B-code/src % hptic --function 
time-interval --text "Note the long delays on TI too"

# Note the long delays on TI too
# Sending FN1 to the HP 5370A or 5370B Time Interval counter
t= 0.000000615 TI= 9.979e-08
t= 0.062570361 TI= 9.982e-08
t= 0.124602710 TI= 9.977e-08
t= 0.186614622 TI= 9.979e-08
t= 0.248818597 TI= 9.973e-08
t= 0.311027399 TI= 9.975e-08
t= 0.373508745 TI= 9.973e-08
t= 0.435905975 TI= 9.975e-08

It basically has a loop:

while (1) {
ibwrt(device_descriptor,cmdstring,strlen(cmdstring));
ibrd(device_descriptor, buf, 23);
print_results(buf);
}

I seem to be transferring about 16 measurements/second, with each 
needing 3 bytes written and 23 read, making a total of just 
16*(23+3)=416 bytes/s. I've no idea of what the bus should support, but 
clearly this is very slow.

I know when I stuck the ibrd command into a bit of software supplied 
with Labview (I'm not using Labview, but one of its tools is handy for 
testing GPIB command), the counter returns more than one result at a 
time, but I am not sure that number of results returned is consistent. 
It might be consistent with just TI in mean mode, but try to do 
something else and the number of bytes returned is very different.

At least reading 23 bytes I can guarantee to get one measurement and 
only one measurement, but I suspect this is slowing me down.

BTW, I see some note from you about your program Allan.tgz and attempted 
to compile it. Neither Sun's make of gnu make could handle the makefile, 
but there seems nothing much to it, so it should compile once I remove 
the err.h and the fpsetmask(FP_X_UFL), which my Solaris box croaks on.

There was one thing I noticed looking at your program. If I am not 
mistaken, you are creating a lookup table of sines and cosines, rather 
than compute them as you need them. Have you actually checked whether 
this is faster on your processor than just computing them as needed? I 
know this is a trick used to speed things up, but I've found it slower 
on some modern CPUs. Certainly on modern Suns, reading from lookup 
tables is slower than calling sin() or cos().

-- 
David Kirkby,
G8WRB

Please check out http://www.g8wrb.org/
of if you live in Essex http://www.southminster-branch-line.org.uk/