Richard B. Gilbert wrote:
> Doesn't Windows update its clock at 17 millisecond intervals?
>
Yes, but ntpd has contained code to interpolate for several years now,
and we've recently tested various updates to this hack that seems
capable of another order of magnitude improvement, at which point w
Richard B. Gilbert wrote:
>
> I don't think that a 14 channel receiver would be useful! There simply
> are not that many satellites! The last I knew, there were 27 NavStar
> (GPS) satellites in orbit. Of these, about seven are usually above the
> horizon at any one time.
Totally wrong:
Her
Henk Penning wrote:
> In <[EMAIL PROTECTED]> Uwe Klein <[EMAIL PROTECTED]> writes:
>
>> [EMAIL PROTECTED] wrote:
>>> I would however add that having time-zone aliases would make it easy
>>> for OS distributions to automatically configure the NTP servers. For
>
>> The next best thing imho would b
Antonio M. Moreiras wrote:
> The Cesium clock at observatorio nacional (ON) is UTC. In fact, the ON
> is one of the metrology laboratories that colaborates with the Bureau
> International des Poids et Measures (BIPM) in generating the UTC (as
> NIST does in USA, for example).
>
> The Rubidium cloc
Dennis Hilberg, Jr. wrote:
> Hi,
>
> I have a stratum one server running ntpd [EMAIL PROTECTED] with a Garmin
> GPS 18 LVC as a refclock. I use the shmpps driver from
> http://time.qnan.org/ . Since this driver only provides the PPS signal,
> I need to have a few other servers defined in my nt
Antonio M. Moreiras wrote:
> Calculating in a mensal basis (but considering 5e-11 as a constant freq
> error within the month, what is wrong too but with a smaller
> overestimated error):
>
> MonthAccum AgeingErr(ms)Tot Error(ms)
> 10,0050,1300,130
> 20,00
David L. Mills wrote:
> In regards to how the clocks work, all the above WWV clocks use the
> munutes and seconds pulses as well as he 100-Hz subcarrier modulation.
> The PSTI/Traconex clock uses a comb filter for the seconds pulse and
> brute force for the subcarrier demondulation. The NTP WWV
Shaochun Wang wrote:
> Danny Mayer wrote:
>> Shaochun Wang wrote:
>>> The stupid net administrator of my institute blocked all UDP datagram
>>> in the firewall. I know that NTP uses UDP to do its work, but is it
>>> possible to let ntpd use TCP?
>>
>> No. You cannot "let" ntpd use TCP. NTP is a UD
Svein Skogen wrote:
> If you are running a cisco router with reasonably new IOS, the Cisco
> router itself runs a fairly decent ntp implementation.
This seems obvious, unfortunately it has tended to be wrong. (Things
might have changed recently though?)
>
> Thus you can set up the router itself
[EMAIL PROTECTED] wrote:
> Hi,
>
> I want to display complete output field names of the "ntpq -p" command
> e.g stratum instead of 'st', type instead of 't'. Is the any command
> line option provided by ntpq that will allow me to do so? Can anybody
> help me?
There are two obvious alternatives:
John Ioannidis wrote:
> Out of curiosity: what is wrong with the Garmin GPS 18LVC that someone
> would like to look at an alternative? At < $70, it's practically free.
Absolutely nothing wrong with it.
I personally got one to work in a couple of hours, including the drive
to the parts store to p
David Woolley wrote:
> Martin Burnicki wrote:
>
>>
>> This is not quite correct. Even older versions of the NTP port for
>> Windows
>> have tried to interpolate the timer ticks using the performance counter.
>>
> I *was* aware of that, but that doesn't change the fact that ordinary
> application
Martin Burnicki wrote:
> Terje,
> As you've already mentioned a possible improvement would be indeed to try to
> determine the TSC sample with the lowest latency in order to decrease the
> interpolation jitter between several tick intervals.
Right
>
> However, there's still the frequency of the
Uwe Klein wrote:
> Steve Kostecke wrote:
>
>> The GPS 18 LVC costs less than $70. Add to that the time for someone to
>> work out the wiring and solder up the connector (well under an hour for
>> a competant tech).
>
> If you ask Garmin Europe for a quote : ~190Euro + VAT Grrr.
Huh???
I bou
Richard B. Gilbert wrote:
> Hal Murray wrote:
>> The Garmin GPS 18 LVC is popular. "Some assembly required."
>> (aka soldering) No big deal if somebody has a soldering iron
>> handy. There are a couple of links from here:
>> http://support.ntp.org/bin/view/Support/InexpensiveOemGps
>
> You wi
Uwe Klein wrote:
> Hal Murray wrote:
>
>> There are a lot of low cost USB GPS gizmos that use the
>> SiRF Star III. They suck for timekeeping.
>>
> Is there a reason known for this?
No PPS signal.
Terje
--
- <[EMAIL PROTECTED]>
"almost all programming can be viewed as an exercise in caching
Richard B. Gilbert wrote:
> Terje Mathisen wrote:
>> Using a USB port for the +5V line is the canonical solution: Very
>> cheap, dependable, and no extra wall warts.
>>
>> Terje
>>
>
> I have read claims here that the high and unpredictable latencies in US
Brian Utterback wrote:
> So, apparently not entirely useless. Using USB as a power source is
> getting to be highly popular. Witness the number of cup warmers, fan,
> etc. on the market. As long as you don't try to read the signal via USB,
> it should be okay.
>
> One thought occurs to me. Woul
Richard B. Gilbert wrote:
> Routers do not make the best clocks! They are highly specialized
> devices with a great deal of work to do.
Seconded.
>
> Do you have an old X86 server that's not quite good enough any longer?
> NTP is not terribly demanding and an old server running Linux would make
[EMAIL PROTECTED] wrote:
> Thank you all for your answers. For FreeBSD, I know it would be cheap
> but :
> - we don't need a high time accuracy.
In which case any Linux server will do just fine.
> - we need to take into account the corporate environment (who manages
> the server ? what about the m
Gabrie wrote:
> Hi
>
> Our Active Directory admin wants to start syncing time with our ESX hosts.
> But he has one requirement, he wants me to limit the clock adjustment to max
> 1 hour. So if our ESX host has an incorrect time compared to the ntp server,
> the ESX host should not correct it if it
Unruh wrote:
> David Woolley <[EMAIL PROTECTED]> writes:
>> My understanding was that -g turns off the 1000 second check for the
>> first step, but still leaves the time within +/- 128ms, which will still
>> take an unacceptable time to converge to +/- 5ms. Certainly the 4.2.4p4
>> documentatio
Spiffed wrote:
> I've dug up an Oncore GT+ GPS receiver, matching antenna, and PPS
> stretching converter box. WinOncore shows a 'Time Solution one sigma' of
> 38ns, so it seems to be an acceptable ref clock for my purposes.
>
> After surveying the computing hardware available, a Sun Ultra10 see
Unruh wrote:
> clock, and how much is inherent I do not know. But since the clock on Linux
> is 1usec quantization and the accuracy of my gps is 1 usec, I figure this
> is about as good as it gets. I doubt that you can get consistant reading of
> the cpu clock even from the kenrel to better than ab
Richard B. Gilbert wrote:
> Melanie Pfefer wrote:
>> Hi
>>
>> What ports need to be opened if my ntp servers are inside a firewall?
>>
>> thank you
>
> Port 123. But only if you need to query outside servers or serve time
> to systems outside the firewall. If you purchase and install a hardware
Hal Murray wrote:
>> I have three inhouse GPS receivers, in three separate cities. Each city
>> has two FreeBSD-based ntp servers, one of which is currently connected
>> to the local GPS, but the other is pre-configured so that in case of a
>> primary server crash, the serial cable can be moved
Maarten Wiltink wrote:
> "Unruh" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
> [...]
>>> What should I be doing to get 20 us? Buy all new computers with
>>> gigabit Ethernet?
>> I suspect buying better switches. And it looks to me like you should
>> definitely NOT go to gigabit Et
Rick Jones wrote:
> Hal Murray <[EMAIL PROTECTED]> wrote:
>> Some Ethernet adapters have a bug/feature similar to RS-232 chips. The
>> idea is to batch interrupts to reduce overhead. Ethernets do it by
>> only making one interrupt for several packets as compared to several
>> bytes for the RS-232
Rick Jones wrote:
> Ryan Malayter <[EMAIL PROTECTED]> wrote:
>> You're right, I was mis-remembering the scope of "No TCP Offload"
>> statement I linked - I read it quite a while ago. And while I think
>> TCP checksum offload could be considered stateless, segmentation
>> offload and receive offload
Rick Jones wrote:
> Terje Mathisen <[EMAIL PROTECTED]> wrote:
>> "almost all programming can be viewed as an exercise in caching"
>
> Which in and of itself is an excercise in latency hiding?-)
Sure.
In fact, taken to its (il-)logical endpoint, any kind of program
Andy Helten wrote:
> Unruh wrote:
>> uh, ntpdate is severely depricated, and ntpd -g is what is supposed to be
>> used. If ntpd -g fails it is a bug.
>>
>
> Then it is a bug because, as previously mentioned, no command line
> argument or tinker can disable this behavior. I suppose the solutio
Diego Ramos wrote:
> Thanks.
>
> Is there any GPS model that provides PPS and I don't need to make a
> connector for it?
The Motorola Oncore MT+ is the "gold reference", but they stopped making
them some years ago.
I got 5 or 6 of the last ones. :-)
...
I just checked their home page, and it se
Unruh wrote:
> leitu...@gmail.com (Diego Ramos) writes:
>
>> All right. I'll show those options to my manager, but I think he will prefer
>> the USB Option as we don't need to be extremely accurate.
>
> Some consider 1ms extremely accurate. Some consider it extremely
> inaccurate.( Mine runs abou
Folkert van Heusden wrote:
>>> Does a valid NTP source need to set the reftime to something valid?
>>> Does the ntp spec say so?
>> I can't tell you that, Folkert, but, in your particular environment, would
>> /you/ trust a NTP source which was last synched 3 days ago?
>
> Well, they (NMi) are the
Steve Kostecke wrote:
> On 2009-01-08, Charles Brown wrote:
>
>>I have a processor with a serial GPS on a closed private network. If
>> the GPS is not locked, or the GPS inputs are missing, I still want the
>> ntpd to serve *some* time, perhaps from the undisciplined local clock.
>
> ntp
Dave Hart wrote:
> On Jan 11, 6:04 pm, ma...@ntp.isc.org (Danny Mayer) wrote:
>> Dave Hart wrote:
>>> I am not suggesting you to go referencing Wsp* functions willy-nilly
>>> to avoid some perceived (and insignificant) overhead of using
>>> published APIs. I'm suggesting you use the published API
Unruh wrote:
> Steve Kostecke writes:
>> Never.
>
>> The Undisciplined Clock Driver does poll the system clock
>> (often misleadingly referred to as the "local clock") _but_ the poll
>> results are discarded. So ntpd never actually serves time _from_ the
>> Undisciplined Local Clock.
>
>
> Sorr
Unruh wrote:
> Steve Kostecke writes:
>> You're assuming that all computers / SBCs / Embedded Systems have a USB
>> port.
>
> Agreed, it you do not have a usb port, you cannot get power from it.
> Then you have to get power from elsewhere. Getting it from the serial port
> is almost certainly no
ryad@gmail.com wrote:
> Hello everybody,
>
> I'm trying to track (offline) the drift of my gps clock relative to my
> hw clock (the clock that I would have obtained without GPS).
> My final goal is to convert a series of gps timestamps to the
> equivalent hw timestamps (with microsec precision
ryad@gmail.com wrote:
> On Jan 19, 10:26 pm, Terje Mathisen
> wrote:
>> ryad@gmail.com wrote:
>>> Hello everybody,
>>> I'm trying to track (offline) the drift of my gps clock relative to my
>>> hw clock (the clock that I would have obtained wit
Dave Hart wrote:
> I have a couple of machines on the same LAN behind consumer broadband
> NAT running ntp 4.2.4p6.
>
> One is running Windows XP, the other Windows Vista, both 32-bit OSes.
> The Windows XP machine has done well with NTP, usually below 10ms
> offset. The Vista machine, however, h
Richard B. Gilbert wrote:
> Terje Mathisen wrote:
>> Running with logging a GPS which isn't used to steer the clock is
>> actually much easier and more accurate.
>>
>> You'll find that you don't need us precision: After a few hours the
>> offsets
Dave Hart wrote:
> I've since realized that on this Vista laptop, the minimum step
> observed from the OS clock is 1 msec but only after starting ntpd with
> -M to use timeBeginPeriod to request 1ms timing service. Run withouut
> -M, my hacked ntpd observes the traditional 15.mumble msec clock
> q
Dave Hart wrote:
> Are you using ntpd on Windows and dissatisfied with its timekeeping?
> I have a patched ntpd with changes intended to improve its accuracy
> that could use some wider testing. Source and binaries are linked to
> below.
>
> Two changes are particularly noteworthy:
>
> 1. Code
Richard B. Gilbert wrote:
> j...@sailorfej.net wrote:
>> Hi folks,
>>
>> I have a some FreeBSD systems running as guests in Microsoft Virtual
>> Server. There is a known problem with these were the clocks run very
>> fast. I am trying to use ntpd to keep their clocks in sync, but the
>> frequency
Dave Hart wrote:
> On Jan 28, 11:52 pm, Terje Mathisen <"terje.mathisen at tmsw.no">
> wrote:
>> I've installed your version, and included -M in my startup parameters:
>>
>> I get Event Log (Application) messages about stuff like:
>>
>&
Dave Hart wrote:
> ntpd/refclock_nmea.c when using $GPGGA tests for 0 and declares the
> clock not in sync. When I read "estimated" or "dead reckoning" wonder
> if ntpd should consider the clock not of sync when it sees fix
> indicator 6. The gotcha that comes to mind is what if there are too
> f
Dave Hart wrote:
> After close to a week of calibration, I fudged then flipped off
> noselect on my GPS+PPS refclock in the early minutes of the UTC day.
>
> It looks to me (from my limited perspective of no other local
> refclocks) that I've gone from single-digit milliseconds to double-
> digit
p.kenn...@fugro.com.au wrote:
> On Feb 6, 7:23 am, Dave Hart wrote:
>> It's running with a patch to lock the main and timer threads to the
>> 2nd CPU using SetThreadAffinity. I haven't tried locking the async I/
>> O thread as well, but I will now. It's also running with a patch to
>> the interp
shane-dated-1234940...@csy.ca wrote:
>> Chris Adams wrote:
>>> Once upon a time, Richard B. Gilbert said:
My bet would be that there is an asymmetry in your ADSL link! If I'm
not mistaken, the "A" in ADSL stands for asymmetric!
>>> The asymmetry in ADSL is in bandwidth, not path or lat
Stefan Schimanski wrote:
> Hi!
>
> We are trying to implement a NTP installation over a redundant
> network, connecting the stratum 2 servers to the stratum 3 clients.
> The precise situation is the following (compare with
> http://1stein.org/download/network.png):
>
> 3 networks, 192.168.3.0, 19
Kevin Oberman wrote:
> Also, the jitter on your time is extremely high for PPS which should be
> < 1 us. I suspect that this is a system problem, but I can't be sure. I
> never see this much jitter on any of our PPS synced reference clocks (of
> which we have about 25 scattered across the US). If t
Joseph Gwinn wrote:
>> It depends on the size of the network. The chances of a duplicate
>> 32-bit number on a network including 65000 hosts is about 40%. The NTP
>> Pool network, which comprises at least 10^6 hosts, for example, would
>> have collision probability very close to 1.
>
> How did you
David Woolley wrote:
> Danny Mayer wrote:
>> David Woolley wrote:
>>> Danny Mayer wrote:
>>>
There is no way to mark an NTP packet as invalid but then why would you
>>> There are several ways of marking a packet as effectively invalid.
>>> The real problem is that there is a lot of software
Dave Hart wrote:
> If you wish to try serialpps.sys and are on a 32-bit system, download
> that .zip, extract all files, and run the enclosed install.bat. If
> you're on a 64-bit system you could be the first to build a
> serialpps.sys for your processor architecture, after a hefty WDK
> download,
ryad@gmail.com wrote:
> Hi everybody,
>
> I've bought 10 PCs with identical hardware (motherboard,...).
> The PCs are located in the same room and running identical
> configurations for 4 days now.
> They are synchronized using garmin 18 GPSes.
>
> I've just checked the NTP's loopstats file a
David J Taylor wrote:
> Jason wrote:
> []
>> G. What have I missed, or gotten confused?
> []
>> Thanks,
>>
>> Jason.
>
> You forgot to say what the going rate is for the consultancy you want!
>
>
Indeed. My standard rate is $200+ per hour.
First of all: The 10s of us requirement within a site
David J Taylor wrote:
> http://www.ntp.org/ => a blank page in both Firefox and Internet Explorer
>
> Is this correct?
No, it works here, now (20 minutes after your post).
Terje
--
-
"almost all programming can be viewed as an exercise in caching"
Jason wrote:
> The critical time-stamp of the transactions must be tighter than 100us.
Sorry, no can do, except probabilistically: You can get X% of time
samples within 100us, as measured by the loopstats file on each client
machine, but you cannot guarantee it up front.
OTOH, what you _can_ do
Jason wrote:
> Terje Mathisen wrote:
>> First you buy 3 or 6 Garmin 18 LVCs (or better: Synergy/Oncore timing
>> receivers set in Zero-D mode) and connect them directly to your
>> primary servers (using the appliance NTP servers as backup), then run
>> both clock
Ask Bjørn Hansen wrote:
> On Mar 4, 5:49 am, Terje Mathisen <"terje.mathisen at tmsw.no"> wrote:
>
>> It is probably better than the Garmin, but almost certainly much less
>> good than a dedicated FreeBSD box with an Oncore timing receiver.
>>
>> Th
Martin Burnicki wrote:
> As a consequence of the above I'd say using RDTSC directly instead of QPC is
> a step in the wrong direction. From what I've seen adding the /usepmtimer
> switch should fix problems on systems where TSC is used even though it is
> not reliable.
TSC has one huge advantage,
Martin Burnicki wrote:
> Agreed, too. However, if we are discussing about Garmins with 50 ns accuracy
> then 1000 ns delay is magnitudes worse.
Garmins never give better than about 1000 ns, i.e. 1 us.
>
> Also, PPS pulses must not necessarily be used only as PPS signals for
> computers. We have a
Martin Burnicki wrote:
> Here, 2 consequent QPC calls retrun a difference of ...
> 350..400 ns using TSCs on an Intel 3 GHz CPU
That's horrible!
Since the RDTSC takes less than 10 ns on that cpu, the remaining 340-390
ns is lost in the OS library interface. :-(
> 1.6..1.9 us using the PM timer
Uwe Klein wrote:
> Kevin Oberman wrote:
>> To get an idea of the fanaticism involved, several years ago, Kirk
>> McKusick and my former boss here in Berkeley counted the machine cycles
>> in the FreeBSD kernel for the PPS response(all done in the interrupt
>> service routine) and used that to corre
Juliusz Chroboczek wrote:
> Hi,
>
> How can a userspace application decide whether the current time is
> trustworthy?
>
> For a project of mine, I need to reliably find out whether the system
> time is within 5 minutes of UTC. The network will include both
> unmanaged client nodes and routers th
cjc wrote:
> We have some time servers with GPS clocks. One of their uses is in
> operations centers where satellites are being flown. The satellites
> use
> GPS (as opposed to UTC) internally, so we want the computers on the
> ground also to use GPS (rather than UTC). The time servers speak NTP
>
randy wilson wrote:
> syncing to the server. I have the time zones set to
> GMT on all the PC. The problem is the time is off by
> an hour on all the PCs and I can't figure out why.
>
> Any pointers would be appreciated. I would really like
> to just set the PC clocks to UTC but it does not appea
Hal Murray wrote:
>> An greater than 500 PPM suggests seriously broken hardware!
>
> Or software.
>
Indeed.
This sounds a lot like the trouble many Linux boxes got into with
HZ=1000, where dropped timer ticks could cause all sorts of problems in
the form of unstable systems clocks that seemed
Steve Kostecke wrote:
> Can anyone report on NTP performance on Intel Atom based systems (such
> as http://supermicro.com/products/chassis/1U/502/SC502L-200.cfm)?
>
I'm running the latest Ubuntu Netbook version on my Eee 901 PC, afaik
that one has an Atom chip.
If you want me to, I can start col
Andy Yates wrote:
> Unruh wrote:
>> Andy Yates writes:
>>
>>> Hal Murray wrote:
In article <4a15e001$0$18238$da0fe...@news.zen.co.uk>,
Andy Yates writes:
> Does anybody have any figures that shows the effect on accuracy of an
> NTP v3 client using a stratum 1 server rather than
Hal Murray wrote:
>> PS. Previous to this setup, all three NTP appliance servers failed at
>> least once, and failed wrong, i.e. they kept responding but with the
>> wrong time! Each time this happened, we found one or two critical
>> servers that had been rebooted, then used ntpdate to pick the
Jan Ceuleers wrote:
Terje Mathisen wrote:
This is why you want ntpd to do the initial step, after first doing
the full vote collection from all configured servers, not ntpdate
which picks the first server to respond!
If that is so, then the ntpdate manpage is wrong:
ntpdate is deprecated
Andy wrote:
> About 10 years ago we used to have 2 seperate GPS receivers feeding
> into two Sparc servers via their serial port. I can't remember the
> version of NTP we ran however these were our stratum one servers, One
> of the Sparcs developed a fault on it's serial interface which delayed
> t
vhfme...@t-online.de wrote:
> That was my first thought, too. But 2^32 milliseconds give 49 days and
> 17 hours. Where are those 28 hours gone? Since the system is ntp-
> controlled, imprecision can't be the reason. I have some amount of CAN-
> bus and ethernet interrupts too, so maybe the total in
piste...@start.no wrote:
> After first trying the Haicom HI-204III claiming to have PPS in the
> manual without really having it, I bought a Garmin 18x LVC and
> connected it to the onboard COM-port (COM1) on my Asus M3N78 PRO
Very good!
(Using USB power I assume?)
> mainboard. The Haicom is res
piste...@start.no wrote:
> On 27 Mai, 21:43, Terje Mathisen <"terje.mathisen at tmsw.no"> wrote:
> Actually the Garmin 18x LVC is quite expensive here in Norway? Seems
> like it's quite a lot cheaper abroad, but with tax and postage I don't
> think it'
Unruh wrote:
> All I was saying was that just because the time routines are capable of
> recording time with nsec precision does not mean that that accuracy of
> the clock is anywhere near that, and I have great difficulty believing
> that the accuracy is any better than usec.
You are somewhat cor
piste...@start.no wrote:
> On 28 Mai, 09:14, Terje Mathisen <"terje.mathisen at tmsw.no"> wrote:
>> OK, you're about an hour or two away then. OTOH my servers are located
>> in Oslo, Porsgrunn and Bergen, with fast private (mostly fiber) between
>> them.
Unruh wrote:
>>> How much is "quite expensive" It should be about US$100.
>
>> $70usd-$80usd, + tax, +shipping, ... ?
>
> I was asking how much it cost in Norway.
And I wrote a few days ago that I paid NOK 800 (i.e. ~$120) over the
counter here in Oslo.
Terje
--
-
"almost all programming can
Mike K Smith wrote:
> On 31 May, 22:20, Brian Utterback wrote:
>> Hal Murray wrote:
>>> In article <1243711613.525...@news1nwk>,
>>> Brian Utterback writes:
David Woolley wrote:
> It only requires 2. The argument about having four initially is about
> having a clear majority even a
John Hasler wrote:
> ScottyG writes:
>> Has anyone had any experience doing this? Can anyone suggest how to
>> achieve this accuracy?
>
> Talk to the very long baseline radio astronomers.
>
>> We do have some budget but this but if I need to spend a whole lot on
>> this I need to get in front of
ScottyG wrote:
> Thanks everyone for pointing out the, let call it silliness of this
> requirement. Also thanks for all your quick responses.
>
> I went back to the traders who defined this requirement. They do
> seem to think that they know what they want, it's just not what they
> are asking
Rob wrote:
> Unruh wrote:
>> No it requires the network to send the time when requested. Eg, Rogers
>> in Canada (GSM) does deliver the time but I have no idea what its
>> accuracy is.
>
> How dumb... something like time-of-day should be broadcast just like
> cell broadcast and everyone would b
Richard B. Gilbert wrote:
> I don't travel excessively! I live in NJ and travel to/through PA, DE,
> MD, NY, CT, MA. The parts of these states I have been to/through all
> seem to have adequate cell phone coverage although I'm sure that there
> must be a few places without it; I haven't found
Unruh wrote:
> Terje Mathisen <"terje.mathisen at tmsw.no"> writes:
>> During the last 5 years or so, my GSM phones have started to work in
>> pretty much all of those locations. :-)
>
> You were lucky that you bought a tri or quad band phone, or it would not
Lei wrote:
> In RFC 2030(written by Prof. D.Mills), we have roundtrip delay time
> formula as follows:
>
> d = (T4 - T1) - (T2 - T3) .(1)
>
> However, IMHO, it should be
>
> d = (T4-T1) - (T3 - T2)(1)'
This is the same as
d = -T1 + T2 -T3 +T4
or
d =
David Woolley wrote:
> Ronan Flood wrote:
>
>>
>> The question remains why the Brandywine PTS device is claiming synch
>> to LOCAL(O) with stratum 2.
>>
> I suspect it is using the local clock driver for its original purpose,
> i.e. to propagate the value of a disciplined local clock that is
> d
erik magnuson wrote:
> Richard B. Gilbert wrote:
>> It's easier to get and keep close synchronization if you have have
>> some sort of a "hardware reference clock" such as a GPS timing
>> receiver, a WWV receiver, etc. GPS timing receivers are available
>> from $100 US and up. The bottom of th
David J Taylor wrote:
> "nemo_outis" wrote in message []
>> I fail to see the value or relevance of "500ppm satisfies 98% of computer
>> clocks" if some other number, perhaps 5000 ppm, could satisfy yet even
>> more
>> than 98% of computer clocks with no downside - as indeed seems to be the
>> ca
Lorcan wrote:
> Folks,
>
> Could any NTP experts suggest how I should best configure NTP in
> a loosely-coupled Linux cluster, where intra-cluster synchronization
> is the top priority?
In this case, the only real answer is to route a GPS+PPS signal to every
box in the cluster, this will give you
Unruh wrote:
>> I believe the delays are asymmetric in large part due to vastly
>> different data rates from the earth to the ship (high rate) vs from
>> the ship (low rate).
>
> No idea why that would make it assymetric. Light does not travel at a
> different velocity simply because it is a crowd
Unruh wrote:
>> IIRC, the round trip time approaches 40 min when they are
>> farthest apart? With the worst case velocity difference
>> approaching 121K mph (54KmpS)? Thats approaching 65km
>> difference in distance between when a message is sent,
>> and the response is sent?
>
> So what? The sig
Unruh wrote:
>> Terje Mathisen wrote:
>> IMHO, this is simply wrong.
>
> Well, your humble opinion in this case does not accord with the way the
> world works.
Mea Culpa!
You are absolutely right: Mars does stand still, so as long as (t3-t2)
is short, both times will be m
rotor...@yahoo.com wrote:
> For example: Internal node A polls the external UTC source
> B and gets the time, then B jumps 5 minutes, and then internal
> node C gets the time. At this point, node C could start slewing
> its clock to converge on the new time from B, moving it away
> from A. And rai
rotor...@yahoo.com wrote:
> On Oct 6, 11:52 am, Terje Mathisen wrote:
>
>> Having an external server fail but still reply (a "falseticker") is an
>> expected issue, it is solved by having at least 4 servers.
>
> Right. But even if we require 4, there is the unl
rotor...@yahoo.com wrote:
> On Oct 6, 1:04 pm, Unruh wrote:
>
>> That is why you do not use ONE external source, you use at least 4, so
>> that such bad behaviour from one does not destroy your system.
>
> I still have to allow for the general case, where for N servers,
> N-1 go offline while the
rotor...@yahoo.com wrote:
> And while a hardware time source would cleanly solve the issue,
> it isn't feasible to retrofit that to thousands of existing
> installations.
> Even if it were $500, there is the expense of getting it installed
> into
> thousands of commercial data centers. Which would
Unruh wrote:
> John Hasler writes:
>> There isn't any tone. It's the UK equivalent of WWVB.
>
> How is the beginning of the second ( an hour) marked?
> The bandwidth of whatever marks it has to be pretty narrow, or the transmitter
> would interfer with everything around it. Ie, that means a large
Evandro Menezes wrote:
> On Nov 6, 3:10 pm, Terje Mathisen wrote:
>>
>> Making it more convenient to lock polling at 64s isn't a good idea, imho.
>
> What do you suggest to mitigate the wild swings between daytime and
> nighttime, sunny and cloudy, cold-front and w
1 - 100 of 436 matches
Mail list logo
