[zeromq-dev] s390x support

[Neale Ferguson]

The stck instruction stores the TOD clock (each CPU in a complex has its own TOD clock). The resolution of the lowest bit is 244.3 picoseconds. In the early days IBM used to guarantee that bit 51 of the 64 bit clock would be updated every microsecond. These days the lower bits are updated in real time to allow nanosecond resolution. However, get the gettimeofday() syscall is a "fast" call on System z on Linux (through the use of address space tricks it's effectively a userland call - no context switch). So if it's simpler to use gettimeofday() then that may be the easiest and most maintainable path to follow. (The TOD clock was extended to 128 bits about 10 years ago as the 64-bit version will roll-over in 2042 and gettimeofday() will/does use the 128 bit TOD clock so it is future-proof. It will also guarantee a unique value on each CPU.)

So, I'm happy to go with whatever you think is more appropriate.


On 1/7/11 10:35 PM, "Steven McCoy" <steven.mccoy at miru.hk> wrote:

On 8 January 2011 04:28, Neale Ferguson <neale at sinenomine.net> wrote:
Hi,
 I have built 2.1.0 under Linux on System z (aka s390x). I made a couple of
changes to enable PGM support:

+#elif defined(__s390__)
+    uint64_t tsc;
+    asm("\tstck\t%0\n" : "=Q" (tsc) : : "cc");
+    return(tsc);

Nice, is an inline instruction really needed for System z boxes when compared with gettimeofday or clock_gettime?

There are three properties investigated for timing sources, first is the clock resolution, i.e. 1ms clocks are preferred to 16ms counterparts; second is stability, whether the source is monotonic, whether subsequent reads will jump backwards, and constant, will the frequency of updates vary over time, i.e. power states; thirdly is the time cost of the read, picoseconds to nanoseconds, is it a simple counter read like RDTSC, an external chip read like HPET, or a complicated software routine like gettimeofday on x86 pre-Nehalem?

For example, on SPARC gettimeofday is very reliable and has a high resolution so it is preferred to use that rather than rd %%tick which libc can still use to keep the call in user-space.

ØMQ and PGM start to diverge at high resolutions, ØMQ preferring the lower cost implementation, whilst PGM preferring stability.

--
Steve-o

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20110107/1ba610fb/attachment.htm>