SYSENTER/SYSEXIT_vs._SYSCALL/SYSRET
|
From: nmm1 on 22 Jan 2010 10:34 In article <hjcfdl$a4p$1(a)soup.linux.pwf.cam.ac.uk>, <nmm1(a)cam.ac.uk> wrote: > >Actually, that's not true. The only prediction that general relativity >has made that has been confirmed by direct evidence is the effect that >time varies with gravitational potential. I take that back. One of two. The fact of gravitational lensing was, of course, much older - but there were no observations in 1915. According to Wikipedia. Regards, Nick Maclaren.
From: MitchAlsup on 22 Jan 2010 14:01 On Jan 22, 6:52 am, "Ken Hagan" <K.Ha...(a)thermoteknix.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. Very well said. Mitch
From: Robert Myers on 22 Jan 2010 15:12 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? Robert.
From: Mayan Moudgill on 22 Jan 2010 15:43 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.
From: Morten Reistad on 22 Jan 2010 16:41
In article <nkao27-43v.ln1(a)ntp.tmsw.no>, Terje Mathisen <"terje.mathisen at tmsw.no"> wrote: >Bernd Paysan wrote: >> Terje Mathisen<"terje.mathisen at tmsw.no"> wrote: >> >Currently I have one of those 18LVC pucks on my roof top, connected to a >FreeBSD 8 box running on an old laptop in the attic. > >It is reachable from the internet, but only via a dyndns address, which >means that it can change: > > tmsw.dyndns.org:123 > >I have 30 Mbit/s symmetric fiber, so performance is OK, feel free to use >it if you're (network latency) nearby. :-) 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 64.99.80.30 0.0.0.0 16 u - 64 0 0.000 0.000 4000.00 ntpq> rv status=0684 leap_none, sync_ntp, 8 events, event_peer/strat_chg, version="ntpd 4.1.0-a Thu Jun 15 02:56:05 CEST 2006 (1)", processor="i386", system="FreeBSD4.11-RELEASE-p18", leap=00, stratum=2, precision=-20, rootdelay=8.548, rootdispersion=42.394, peer=4750, refid=172.79-161-68.customer.lyse.net, reftime=cf049924.e4ce5f74 Fri, Jan 22 2010 22:37:40.893, poll=6, clock=cf049997.04bec679 Fri, Jan 22 2010 22:39:35.018, state=4, offset=7.112, frequency=14.611, jitter=37.912, stability=2.393 ntpq> -- mrr |