SYSENTER/SYSEXIT_vs._SYSCALL/SYSRET
|
From: Terje Mathisen "terje.mathisen at on 23 Jan 2010 15:17 Malcolm Beattie wrote: > On 2010-01-20, robertwessel2(a)yahoo.com<robertwessel2(a)yahoo.com> wrote: >> These days it's somewhat cheaper and more straight-forward, since the >> clock synchronization hardware is now built into current machines, and >> a dedicated external Sysplex Timer is not required (I don't remember >> if the current z10s still support a Sysplex Timer or not - at least >> some generations of hardware did so that you could have a cluster with >> both older and newer boxes). > > Current generation mainframes (System z10) do still support > connections to a Sysplex Timer but there is a Statement of Direction > that it will be the last to do so. Server Time Protocol (STP), as > you refer to above, has been available since 2006 and coexists with > Sysplex Timers for z10 and the previous two mainframe generations. > > STP provides the coordinated timing for a Sysplex cluster that covers > 100km (without needing a location somewhere in the middle to put a > Sysplex Timer) so its focus isn't quite the same as for the > "zillions of more closely coupled CPUs" case. > > The Redbook "Server Time Protocol Planning Guide" gives an overview: > http://www.redbooks.ibm.com/abstracts/sg247280.html Very nice document, showing how much work IBM have had to do in order to migrate from a single 370 with a free-running TOD counter, up to a fully distributed, geographically redundant configuration with external UTC reference input. The most interesting part (to me) was the description of how they tune the HW TOD counter to sync it to an external reference: Instead of the obvious way (add N bits to the right of the counter, then increment by a variable amount on each timer tick) they kept the original hw and instead tweak the normally static offset field: I.e. each Store Clock (STCK*) instruction reads the current value of the TOD counter, then adds the offset and returns the sum. Since the TOD counter has had 104 bits since 1999, it seems like an obvious idea to use this to add a variable amount in order to tune/sync it to UTC, but I guess this would have made the counter hw more complicated? Assuming the HW updates happens at approximately the core cpu clock frequency rate, a 2GHz cpu could require quite a bit of power to handle a full 104-bit add operation every 0.5 ns, but by storing the counter in redundant/carry-save format the addition overhead becomes trivial, right? Terje -- - <Terje.Mathisen at tmsw.no> "almost all programming can be viewed as an exercise in caching"
From: "Andy "Krazy" Glew" on 23 Jan 2010 15:33 Ken Hagan wrote: > On Thu, 21 Jan 2010 20:05:07 -0000, Robert Myers <rbmyersusa(a)gmail.com> > wrote: >> On Jan 21, 12:51 pm, MitchAlsup <MitchAl...(a)aol.com> wrote: > However, I suspect that both you and Mitch are in violent agreement > about the pursuit of wonderfully scalable clocks. A globally consistent > high-performance timer isn't possible, so it really makes no sense > either to try to provide it or to write software that needs it. If > software needs several (logical) threads to agree on a defined order of > events then it must arrange for those threads to meet "at or near" a > particular location and agree to use the timer they find there. Hmm. This is an example of a comp.arch topic going off into the weeds. lnteresting, but irrelevant to non-relativistic computing systems. Nevertheless I'll bite. I think causality <=> observability, and AFAlK relativity is still consistent with causality. Since causality is a partial order, this means that it is possible to establish a total order, a timestamping. But only e.g. if Lamport's Algorithm implemented on every possible communication/message/observation/causal interaction. IMHO not practical except for message passing systems. But this timestamping would be useless for the measurement oftime, duration, etc. Which brings me back to Teje's and my origina\ point: timestamping and time are 2 different things. I prefer to say sequence numbering rather than timestamping.
From: Bernd Paysan on 23 Jan 2010 16:29 Robert Myers wrote: > On Jan 22, 10:07 am, Bernd Paysan <bernd.pay...(a)gmx.de> wrote: > >> As long as the clocks don't move, you don't have problems ;-). > > How does a clock tell time without moving something? No, it's not about parts inside the clock moving, it's about the clocks themselves moving relatively to each other. If they don't, you can establish perfect synchronization (even within a static gravitation field; all that requires is slowing down or speeding up clocks in different distances from the gravitation center). -- Bernd Paysan "If you want it done right, you have to do it yourself" http://www.jwdt.com/~paysan/
From: Robert Myers on 23 Jan 2010 16:42 On Jan 23, 4:29 pm, Bernd Paysan <bernd.pay...(a)gmx.de> wrote: > Robert Myers wrote: > > On Jan 22, 10:07 am, Bernd Paysan <bernd.pay...(a)gmx.de> wrote: > > >> As long as the clocks don't move, you don't have problems ;-). > > > How does a clock tell time without moving something? > > No, it's not about parts inside the clock moving, it's about the clocks > themselves moving relatively to each other. If they don't, you can > establish perfect synchronization (even within a static gravitation > field; all that requires is slowing down or speeding up clocks in > different distances from the gravitation center). > This is not the place to be debating this. Whether it is a prediction of special relativity or not, any realizable clock has the same problem in its own internal workings as do clocks separated by large distances. You have to make assumptions about what's happening far away, even if far away is only a few repeaters away. You can't ever know what time it is without making ancillary and unprovable metaphysical assumptions. Sometimes those assumptions will hold and sometimes they won't. They are never verifiable until it's too late to change any mistakes that were made because of a failure to verify. Robert.
From: Paul Wallich on 25 Jan 2010 09:34
Andy "Krazy" Glew wrote: > Terje Mathisen wrote: >> nmm1(a)cam.ac.uk wrote: >>> In article<1531844.zBA62FjkXi(a)elfi.zetex.de>, >>> Bernd Paysan<bernd.paysan(a)gmx.de> wrote: >>>> It's not so bad as you think. As long as your uncertainty of time is >>>> smaller than the communication delay between the nodes, you are >>>> fine, i.e. >>>> your values are unique - you only have to make sure that the >>>> adjustments >>>> propagate through the shortest path. >>> >>> Er, no. How do you stop two threads delivering the same timestamp >>> if they execute a 'call' at the same time without having a single >>> time server? Ensuring global uniqueness is the problem. >> >> No! >> >> Global uniqueness is a separate, but also quite important problem. >> >> It is NOT fair to saddle every single timestamp call with the overhead >> required for a globally unique value! > > > Amen, brother! > > Too many timestamp and time related functions are rolled into one. > > There are TIMESTAMPS, e.g. for databases. Wanting global uniqueness and > monotonicity. They do not even necessarily need time, although it is > pleasant to be able to compute timestamp deltas and calculate time elapsed. As machines get bigger and faster, it may be important to remember that the physical universe does not not provide the monotonicity function either. Stationary observers located in different places will tell you different things about who did what when. So you're imposing an order that doesn't exist -- fine as long as the things you're ordering aren't supposed to be causally related (aka dependencies). paul |