[time-nuts] Programming of 5370B

[Poul-Henning Kamp]

Joint answer to the entire thread:

>============================================================================
>From:    David Kirkby <david.kirkby at onetel.net>
>Message-Id: <429CCD43.8090902 at onetel.net>
>
>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).

FreeBSD, not OpenBSD :-)

Actually, it is probably rather complex, but it is certainly not
the basic bus-speed, much more likely is systemcall overhead, DMA
delay and interrupt latency.  In either case, it's nothing you
can do anything about.  I won't claim that the FreeBSD IEEE488
driver is optimized for the HP5370B, but it was certainly a primary
benchmark target :-)

>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.

They are taken directly from the manual (the exact pages missing in
my copy of the manual).

The reason for all this bit-flipping is that this is how the internal
CPU does it.  The internal CPU is not very fast, so they have to use
convenient binary arithmetic to make 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.

>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.

Right, in ASCII mode you push all of the above (and statistics) onto
the internal CPU and it slows it down a lot.

>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().

When I wrote the program it was faster, havn't checked recently.

>============================================================================
>From:    David Kirkby <david.kirkby at onetel.net>
>Subject: Re: [time-nuts] Programming of 5370B
>Message-Id: <429CE2AF.9090807 at onetel.net>

>I note the binary mode is only suitable for the +/- TI function. A 
>binary mode would be useful for frequency or period at gate times of 
>0.01 or 0.1 s, but I guess the HP 5370B would have to process the data 
>in those modes, so it would be no quicker than the ASCII.

Binary mode basically pulls the raw bits out of the hardware timing
circuitry and hands it to you.  Frequency is measured either as
the timeinterval of a single period, or as two timeintervals and
a zero-crossing count.  None of this is possible to do with
binary mode because the IEEE-488 bus does not allow the host
computer to react fast enough.

>Given my SPARC processor is Big Endian, whereas the Intel format CPU in 
>Poul Henning Kamp's PC is Little Endian, it is perhaps surprising the 
>binary data could be read properly on my SPARC.

No, it's defined as a byte-stream, and my code treats it as such,
so it should be sound on any byte-order.

>PS,
>you may be aware I had some difficulty locating the Solaris drivers for 
>the GPIB board (National Instruments want more for them than I paid for 
>the GPIB board and the HP53270B put together!!) Converted to $US, the 
>drivers are around $750 or so.

I told you a FreeBSD PC would be cheaper :-)

>============================================================================
>From:    "Tom Van Baak" <tvb at leapsecond.com>
>Subject: Re: [time-nuts] Programming of 5370B
>Message-Id: <001c01c56636$ce8f6ba0$5615f204 at computer>
>

>If you look at the schematics and theory of ops
>you'll get a hint of why this is so. Still, compared
>to the generation of counters it replaced, the 5370
>is, even by today's standards, quite an amazing
>instrument. Later, the 5371 blew away the readings
>per second limitation with deep memory, and it
>included built-in statistics, histograms, and CRT
>display, but it sacrificed resolution.

The 5371 & 5372 does not have the "nonius" interpolation
circuitry which is the *really* clever thing in the
5370.

I guess the reason they left it out is that the restartable PLL
contained in it needs a pretty long dead-time to lock onto the
reference frequency and this limites the speed at which you can
make measurements to something in the 10-50K/sec range.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.