SYSENTER/SYSEXIT_vs._SYSCALL/SYSRET
|
From: Terje Mathisen "terje.mathisen at on 23 Jan 2010 07:35 Mayan Moudgill wrote: > Terje Mathisen wrote: > > > > I.e. using a very fast syscall(), you can return an OS timestamp within > > a few nanoseconds, totally obviating the need for application code to > > develop their own timers, based on RDTSC() (single-core/single-cpu > > systems only), ACPI timers or whatever else is available. > > > > And what exactly will that timestamp be useful for? IOW, what are you > ordering? Suppose you are trying to order writes to disk between > multiple processes (running on the same CPU). In that case, > > Process #1 gets time stamp > Context switch > Process #2 gets time stamp > Process #2 writes > Context switch > Process #1 writes > timestamp order != disk order. > > A high precision clock _MAY_ have uses, but timestamps at the user level > is not one of them. Sure. A user-level timestamp is primarily useful for timing operations within a single process, i.e. I have written self-timing code which has N different implementations of a core algorithm: On the first call (which goes via a function pointer) I run the input buffer through all the implementations, timing how fast they are on the current cpu. I then update the function pointer to go directly to the winning version and return to the caller. This way all the subsequent calls will be fast. I can do this with plain rdtsc, and I do so now. Having an OS timestamp which is nearly as fast and returns real-world timestamps would be nice. Using timestamps to order stuff from user-level threads always means that I have to check both before and after each operation, and as you note above, this doesn't give any strict ordering of the individual operations. Terje -- - <Terje.Mathisen at tmsw.no> "almost all programming can be viewed as an exercise in caching"
From: Terje Mathisen "terje.mathisen at on 23 Jan 2010 07:40 Morten Reistad wrote: > Hint taken. I gather 8.5 milliseconds can be considered "nearby". > > The trusty old FreeBSD box synced right up : > > ntpq> lpee > remote refid st t when poll reach delay offset jitter > ============================================================================== > +puff 171.224.199.67 4 u 33 64 377 0.368 44.402 1.253 > +faxe.reistad.na 172.79-161-68.c 3 u 28 64 217 18.446 -6.077 3.613 > *172.79-161-68.c .GRMN. 1 u 38 64 377 8.548 -9.575 8.038 Hmmm. That's pretty bad, actually. I hope this was taken shortly after first sync? After a few hours you should see significantly lower jitter and offset values! Terje -- - <Terje.Mathisen at tmsw.no> "almost all programming can be viewed as an exercise in caching"
From: nmm1 on 23 Jan 2010 08:30 In article <127r27-kt21.ln1(a)ntp.tmsw.no>, Terje Mathisen <"terje.mathisen at tmsw.no"> wrote: >Mayan Moudgill wrote: >> >> A high precision clock _MAY_ have uses, but timestamps at the user level >> is not one of them. > >Sure. > >A user-level timestamp is primarily useful for timing operations within >a single process, i.e. I have written self-timing code which has N >different implementations of a core algorithm: That is primarily because interfaces (whether architectures, ABIs or programming languages) don't provide anything with reasonable specifications. Seriously. >Using timestamps to order stuff from user-level threads always means >that I have to check both before and after each operation, and as you >note above, this doesn't give any strict ordering of the individual >operations. The same thing applies to ALL atomic operations! Here, let me put a C++ / close-coupled hat on. Many people want sequentially consistent atomics - let's skip the (good) arguments that they aren't scalable. Any such design could reasonably be required to have a 'store timestamp' operation as part of the suite. I didn't express it very clearly, but that is the sort of thing that I was getting at earlier. I don't see that providing sequentially consistent timestamps is any harder than providing any other form of sequentially consistent atomics. Now, if I put my MPI / scalable hat on, I can say that those are a crazy idea. But my objection is to the basic model, and not to the timestamps as such - you don't actually get any extra scalability by dropping the timestamp operation. So, as so often, it isn't an absolute matter, but the best solution depends on the assessment criteria and constraints that you choose. Regards, Nick Maclaren.
From: Malcolm Beattie on 23 Jan 2010 09:04 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 --Malcolm
From: Morten Reistad on 23 Jan 2010 09:35
In article <7a7r27-mu21.ln1(a)ntp.tmsw.no>, Terje Mathisen <"terje.mathisen at tmsw.no"> wrote: >Morten Reistad wrote: >> Hint taken. I gather 8.5 milliseconds can be considered "nearby". >> >> The trusty old FreeBSD box synced right up : >> >> ntpq> lpee >> remote refid st t when poll reach delay offset jitter >> ============================================================================== >> +puff 171.224.199.67 4 u 33 64 377 0.368 44.402 1.253 >> +faxe.reistad.na 172.79-161-68.c 3 u 28 64 217 18.446 -6.077 3.613 >> *172.79-161-68.c .GRMN. 1 u 38 64 377 8.548 -9.575 8.038 > >Hmmm. That's pretty bad, actually. I hope this was taken shortly after >first sync? After a few hours you should see significantly lower jitter >and offset values! Yep. You can still see the resync I did on faxe (hosted machine, Denmark) in the "reach" column. Now it says $ ntpq ntpq> lpee remote refid st t when poll reach delay offset jitter ============================================================================== +puff 160.232.232.186 4 u 240 1024 377 0.389 14.386 20.921 +faxe.reistad.na 172.79-161-68.c 2 u 243 1024 377 22.247 -44.329 0.904 *172.79-161-68.c .GRMN. 1 u 233 1024 377 11.047 -43.376 8.310 Still 8 ms jitter, and puff (the firewall (a.k.a. "magic dragon")) keeps misbehaving. I may be watching a hardware failure. I am on a cable network, "GET", with lots of bandwidth, but it is through tons of weird repeaters and has a 10k host flat ethernet (i can see the arp's; around 300 kb/s sustained traffic) so it is full of jitter. Currently 6mb up, 16 down. I cannot detect latency differences up and down through the jitter. I therefore got a second opinion : From faxe, located inland from Copenhagen. Excellent network, I have uncapped 100mb/s bandwith. Copenhagen is a nice compromise between local to Scandinavia, and well reachable to the rest of the world. ntpq> host faxe current host set to faxe.reistad.name ntpq> lpee remote refid st t when poll reach delay offset jitter ============================================================================== +mail.tyroll.dk gps.dix.dk 2 u 22 256 377 0.588 3.932 0.404 -host3.typomedia www.movieget.co 3 u 21 256 377 0.853 5.958 0.416 +blah.jabber.dk gps.dix.dk 2 u 24 256 377 0.983 4.573 0.069 -4504ds1-vo.2.fu ntp.ngdc.net 3 u 5 256 377 26.315 9.081 0.651 *172.79-161-68.c .GRMN. 1 u 67 256 377 10.607 4.408 0.257 I keep watching the ntp reports. In PPOEs I discovered that watching NTP closely tended to give advance warning about hardware failures. It told us clearly about temperature anomalies. I made a little morning report for me, the technical manager; taking that report above; adding the source machine as a column; sorting the host-host pairs by jitter; assigning a rank and reporting everything that changed rank by more than 25 places since yesterday. I also reported machines that went in and out of favour with large amounts of other machines. If 10 routers are synced to box x today, but there were 50 yesterday, then something happened, enough to log onto box x to have a look. By gut feeling is that the firewall here is about to fail. -- mrr |