Augustine writes:
>On Mar 3, 4:01=A0pm, "Richard B. Gilbert"
>wrote:
>>
>> NTP does this ONLY when the time is off by 128 milliseconds or more. =A0I=
>f
>> NTP is that far off, other than at startup, something is badly wrong
>> somewhere!
>The problem is that I've seen this in the silly reactio
"Richard B. Gilbert" writes:
>I suspect that part of the problem is that the leap second is applied at
>the LOCAL midnight. If everyone inserted the leap second at 00:00:00
>UTC, NTP would be perfectly happy with it but everyone else would be
>unhappy.
No it is not. The leap second is a
Jason writes:
>A sys admin and I discussed the possible solutions today, and we have a
>potential winner, although we can't reach the small 10s of uSec goal, we
>can reach several 100s of uSec (and probably less) easily. We are going
>to make a proposal to mgmt to increase the number of S1 s
ma...@ntp.org (Danny Mayer) writes:
>David J Taylor wrote:
>> I know it's probably one of those "how long is a piece of string"
>> questions but
>>
>> Does anyone know an approximate relationship between polling interval and
>> peak-to-peak jitter for a non-ref-clock system? I.e would the
Uwe Klein writes:
>Unruh wrote:
>> These Gbit
>> switches seem to have, or trigger in the ethernet cards, additional and
>> assymetric delays of the order of 100-200usec. (assymentric delays are of
>> course the worst, since they directly affect the errors in ntp).
Hans =?iso-8859-1?Q?J=F8rgen?= Jakobsen writes:
>On Fri, 06 Mar 2009 05:44:24 GMT, Unruh wrote:
>> Jason writes:
>>
>>
>>
>>>A sys admin and I discussed the possible solutions today, and we have a
>>>potential winner, although we can't reach th
jack writes:
>Hi all,
>I am trying to sync my Windows box to an external GPS source. I
>currently have BU353, whose output is not very periodic. I read up on
>ntpd implementation that uses PPS signal but I don't even have an RS
>232 port on my computer.
How do you get the signal in now? Do you
Augustine writes:
>On Mar 9, 4:23=A0pm, "Richard B. Gilbert"
>wrote:
>>
>> Just about any GPS timing receiver is accurate to within about 50
>> nanoseconds using the PPS signal. =A0
>Just wondering, does one need to consider the delay that the signal
>takes to reach the receiver from the satell
"Richard B. Gilbert" writes:
>jack wrote:
>> Hi all,
>>
>> I am trying to sync my Windows box to an external GPS source. I
>> currently have BU353, whose output is not very periodic. I read up on
>> ntpd implementation that uses PPS signal but I don't even have an RS
>> 232 port on my computer.
fwa...@frankwayne.com (Frank Wayne) writes:
>While several people suggested that Jeff use guest/host synchronization, no
>one ever answered the first question, "is it possible to override the maximum
>offset PPM?"
>-Original Message-
>From: questions-bounces+fwayne=frankwayne@lists.
Martin Burnicki writes:
>David Woolley wrote:
>> Unruh wrote:
>>
>>>
>>> No. That is what GPS does for you. It determines your postion, then uses
>>> that to determine the time delay from the sattelite to your receiver.
>>
>> Actually,
"David J Taylor"
writes:
>jack wrote:
>> Hi everyone,
>>
>> First of all, I thank you for all your response.
>>
>> I understand the best solution would be using an IRIG board and that's
>> what we had been using. We are now trying to make our product more
>> compact by using a small single board
jack writes:
>Hi everyone,
>First of all, I thank you for all your response.
>I understand the best solution would be using an IRIG board and that's
>what we had been using. We are now trying to make our product more
>compact by using a small single board PC with no RS 232 or PCI slot
>(no slot
Matthias Fuchs writes:
>Hi,
>I am trying to understand ntpd's -x option. From the ntpd documentation
>I expect ntpd to adjust the (system-)time in all situations when -x
>is used. The only exception I see is when the system time is totally wrong
>(more than 1000s) ntpd will see this as an error
Matthias Fuchs writes:
>Unruh wrote:
>> Matthias Fuchs writes:
>>
>>>Hi,
>>
>>>I am trying to understand ntpd's -x option. From the ntpd documentation
>>>I expect ntpd to adjust the (system-)time in all situations when -x
>>&g
Tom writes:
>To All,
>How do you demonstrate the traceability of the NTP solution to BIPM
>UTC?
That is what the stratum is all about. It tells you how far away your clock
is, in terms of servers, from some server which claims to synchronized by a
hardware type clock to UTC. The root dispersion
Steve Kostecke writes:
>On 2009-03-12, Unruh wrote:
>> Ie, IF you do not want to have jumps even on bootup, want fast convergence
>> to the good time,
>In your haste to proselytize for chrony you've overlooked the fact the
>the OP did not specify that he needs fast
"Richard B. Gilbert" writes:
>Unruh wrote:
>> Steve Kostecke writes:
>>
>>> On 2009-03-12, Unruh wrote:
>>
>>>> Ie, IF you do not want to have jumps even on bootup, want fast convergence
>>>> to the good time,
>>
>
"Richard B. Gilbert" writes:
>Unruh wrote:
>> "Richard B. Gilbert" writes:
>>
>>> Unruh wrote:
>>>> Steve Kostecke writes:
>>>>
>>>>> On 2009-03-12, Unruh wrote:
>>>>>> Ie, IF you do not wa
David Woolley writes:
>Matthias Fuchs wrote:
>>
>> But now, when I start ntpd with the -x option and an offset of
>> about 30s before ntpd is started, I get error messages like this
>>
>> frequency error 557 PPM exceeds tolerance 500 PPM
>>
>I should also have pointed out that the 50
"Richard B. Gilbert" writes:
>Unruh wrote:
>> "Richard B. Gilbert" writes:
>>
>>> Unruh wrote:
>>>> "Richard B. Gilbert" writes:
>>>>
>>>>> Unruh wrote:
>>>>>> Steve Kostecke w
David Woolley writes:
>Unruh wrote:
>> David Woolley writes:
>>> I should also have pointed out that the 500ppm slew rate limit is
>>> imposed by *n*x kernels, not by ntpd. In the case of -x, which forced
>>
>> No it is not. the kernel limit is 1
Joseph Gwinn writes:
>In article ,
> "Richard B. Gilbert" wrote:
>> > The suspicion is that we have not set something up correctly, not that
>> > NTP v3 has failed, or that NTP v4 would fare better or worse. Don't
>> > understand the comment about funding.
>> >
>>
>> Simple enough. The p
Joseph Gwinn writes:
>In article <49bd3a1e.2020...@ntp.org>, ma...@ntp.org (Danny Mayer)
>wrote:
>> Richard B. Gilbert wrote:
>> > Joseph Gwinn wrote:
>> >> Is NTP v4 proven to run on Solaris 9 (SunOS 5.9 Generic May 2002)?
>> >
>> > Proven? Please define that! It works for me. YMMV!
>>
>>
hal-use...@ip-64-139-1-69.sjc.megapath.net (Hal Murray) writes:
>>It's his privilege to play by his own rules. If he is willing to spend
>>several months slewing the clock. . . .
>>
>>I would be tempted to slew the clock at a rate far beyond 500 PPM if I
>>could figure out how.
>Patch the ker
David Woolley writes:
>Joseph Gwinn wrote:
>> We have moved from the meaning of status code 9514 to the more general
>But you should have kept the thread, even if the subject changed.
>> issue of how NTP shall be supported, so I've collected the relevant
>> threads below.
>>
>> More general
"Richard B. Gilbert" writes:
>David Woolley wrote:
>> Joseph Gwinn wrote:
>>> We have moved from the meaning of status code 9514 to the more general
>>
>> But you should have kept the thread, even if the subject changed.
>>
>>> issue of how NTP shall be supported, so I've collected the relevan
ma...@ntp.org (Danny Mayer) writes:
>Unruh wrote:
>> "Richard B. Gilbert" writes:
>>
>>> David Woolley wrote:
>>>> Joseph Gwinn wrote:
>>>>> We have moved from the meaning of status code 9514 to the more general
>>
"David J Taylor"
writes:
>Dave Hart wrote:
>> Unusually for me, the configuration and code on my reference clock
>> test machine has been static for the last two days UTC. I've posted
>> loopstats and graphs for that period on http;//davehart.net/ntp/
>> refclock/
>[]
>> Cheers,
>> Dave Hart
>
"David J Taylor"
writes:
>Unruh wrote:
>[]
>> Gads, those offsets are huge. And 3PPM variation is also pretty big.
>Dell 4400 hardware sitting in a non-temperature controlled environment -
>warm in the day, cold at night. I would happily accept five times the
Dave Hart writes:
>On Mar 17, 9:21=A0pm, Unruh wrote:
>> "David J Taylor" > writes:
>> >Dell 4400 hardware sitting in a non-temperature controlled environment -
>> >warm in the day, cold at night. =A0I would happily accept five times the
>> >j
"David J Taylor"
writes:
>Unruh wrote:
>[]
>> Maybe when someone finally put refclock support into chrony you will
>> have
>> your wish.
>Not until it runs under Windows.
Fair enough.
>> It sounds like your temp changes causing rate changes on
Dave Hart writes:
>> >The minimum delay
>> >clock filter selects the shortest roundtrip delay of the last eight,
>> >based on the observation the least-delayed exchange results in the
>>
>> And if the variation in the delays is less than the jitter, this simply
>> results in throwing away most o
Dave Hart writes:
>> I have checked for a temperature monitoring SNMP plug-in, but not found a
>> compatible one as yet.
>SNMP is ideal, but anything that could read a temperature that had a
>high degree of correlation with your osciallator's crystal temperature
>would be enough to build upon.
"Towli" writes:
>Hi
>I would like to test my internal clock (from my domain pc) against a public
>ntp server, to see if there is a discrepance (i suspect our domain time is
>not synchronised properly).
>Is there a way to do this?
That is what ntp is all about.
>Bst rgds from Denmark
>/T
"Richard B. Gilbert" writes:
>Rob wrote:
...
>> It almost seems like a religious group. Most people try to convert
>> the world to Mills' NTPD, and then there is the dissident who tries
>> to push Chrony in every thread.
>>
>I think I see people following you, carrying torches and fagots.
>>
hun...@comcast.net (Rob Neal) writes:
>>
>> It almost seems like a religious group. Most people try to convert
>> the world to Mills' NTPD, and then there is the dissident who tries
>> to push Chrony in every thread.
> Chrony has an impulse response that is ill-advised in
> a network
"Richard B. Gilbert" writes:
>Harlan Stenn wrote:
>> Richard,
>>
>> Please be more tolerant.
>>
>> Some of us *vastly* prefer top-posted articles.
>>
>> Let's just agree to disagree about this, and stop lobbying for our personal
>> preferences.
>>
>> H
>> --
> In article , "Richard B.
>>
Steve Kostecke writes:
>On 2009-03-20, Unruh wrote:
>> And it makes even more sense to have it at the top so that I can see that
>> the response is totally off topic without having to scroll through the
>> whole rest of the ancient history of the post.
>A good write
"David J Taylor"
writes:
>David J Taylor wrote:
>[]
>> Yes,
>>
>> I've been searching for a utility which can do what I need, and
>> graphical programs or no problem, but for MRTG I need something with
>> text output to StdOut. Either disk temperature or CPU temperature
>> would be fine, just a
"David J Taylor"
writes:
>Unruh wrote:
>> "David J Taylor"
>[]
>>> I put the temperature graph next to the timekeeping graph here:
>>
>>> http://www.satsignal.eu/mrtg/performance_feenix.php
>>
>>> but I think that
hun...@comcast.net (Rob Neal) writes:
>On Fri, 20 Mar 2009, Unruh wrote:
>> hun...@comcast.net (Rob Neal) writes:
>>
>>>>
>>>> It almost seems like a religious group. Most people try to convert
>>>> the world to Mills' NTPD, and then there
emidd...@gmx.net (Eike Middell) writes:
>Hi,
>I've got a question regarding a ntp daemon that has only the
>"undisciplined clock driver" as a reference clock. To what
>extent does this daemon influence the local clock?
Not at all. The local clock means that ntp does nothing.
>The context of t
Augustine writes:
>On Mar 25, 2:30=A0pm, "David J Taylor" this-bit.nor-this.co.uk> wrote:
>>
>> ntp1.arse.org
>I'm not surprised about this one... :-D
>Jokes aside, why do we still see such announcements months after the
>event? What can be done to mitigate and weed out such servers? Can
>NTP
"alkope...@googlemail.com" writes:
>> 1. Immediately fire the Linux OS and replace with FreeBSD. It has PPS sup=
>port ex box and very good serial drivers. You need to disable the hardware/=
>driver FIFOs to get good serial time. This of course will be secondary to t=
>he PPS.
I have no idea why
Dave Hart writes:
>On Mar 25, 9:19=A0pm, Unruh wrote:
>>
>> I have no idea why and whether kernel PPS code is any better ( or worse)
>> than say PPS discipline using the shm PPS refclock using parallel port
>> interrupt. Ie, both can discipline
>> to about 1-2
"alkope...@googlemail.com" writes:
>On Mar 26, 12:48=A0am, Unruh wrote:
>> However if the only concern was losing PPS discipline due to prefer peer
>> problems, then I agree this is tangential.
>Yes, it was ;-)
>> >I think he's monitoring
cribes how the contraptoin works.
>Unruh wrote:
>>Dave Hart writes:
>>
>>
>>
>>>On Mar 25, 9:19=A0pm, Unruh wrote:
>>>
>>>
>>>>I have no idea why and whether kernel PPS code is any better ( or worse)
>>>>than s
Dave Hart writes:
>On Mar 26, 2:39=A0am, Unruh wrote:
>>
>> So, again I am confused.
>> I have
>> server tick.usask.ca
>> server ntp.ubc.ca
>> server 127.127.28.0 minpoll 4 prefer
>>
>> where 127.127.28.0 is the PPS via shm and this system see
"alkope...@googlemail.com" writes:
>On Mar 26, 5:46=A0am, Unruh wrote:
>> So, I have PPS running the shm refclock, with the seconds supplied by the
>> local clock (ie the reading from the system clock) and the usec from the
>> PPS signal. =A0Since I do not exp
David Woolley writes:
>Unruh wrote:
>>
>> I have now looked at the refclock_atom source and indeed, it demands that a
>> prefer clocksource is available, and ignores the PPS if it is not. This I
>> believe is a bug, or at least a design infelicity. You could
j...@febo.com (John Ackermann N8UR) writes:
>David Woolley wrote:
>> Unruh wrote:
>>
>>> I have now looked at the refclock_atom source and indeed, it demands that a
>>> prefer clocksource is available, and ignores the PPS if it is not. This I
>>> believe
RAN-C receiver, which was modified by the Coast
>Guard, flashes a light at the TOC. The TOCs and the intervals between
>them vary up to several minutes depending on the GRI of the chain. I
>made provisions for the TOC in the LORAN-C receiver I built some years
>ago, but never co
he PPS has become unreliable.
>I am happy to continue this discussion, but only if you read the
>specification.
I think this is an issue of how the atom driver treats the specification,
not of the specification itself.
>Dave
>Unruh wrote:
>>mi...@udel.edu (David Mills) writes:
&g
for the impossible?
>>>
>>
>> Reducing minpoll will help, but you are basically observing an aspect
>> of why Bill Unruh advocates chrony. ntpd has poor startup and
>> frequency change transient handling.
>Thanks, David, I though that might be the case. The syst
ober...@es.net (Kevin Oberman) writes:
>> From: Harlan Stenn
>> Date: Sat, 28 Mar 2009 08:48:35 +
>> Sender: questions-bounces+oberman=es@lists.ntp.org
>>
>> >>> In article , Bill Unruh
>> >>> writes:
>>
>> &g
mi...@udel.edu (David Mills) writes:
>John,
>The intersection algorithm has been documented in several places along
>with configuration controls to modify its behavior. Is the tyranny you
>cite due to that algorithm or the notion of the prefer peer in the first
>place? If the latter, do you ha
mi...@udel.edu (David Mills) writes:
>alkopedia,
>That's not the point. No matter how much you trust the Cs, do you trust
>the seconds numbering? Say you reliably number the seconds and then
>disconnect the numbering source. Obviously, you have to reestablish
>nunmbering every time you reboot.
varrunas...@yahoo.com (Varrun Ashok) writes:
>Hello everybody, Why does ntp (ntp-4.2.4p4 in specific) require an operating
>system? I use embedded Linux (kernel-2.6.23-rc3+Busybox+grub) to run ntpd and
>ntpq.I would like to run NTP (ntpd and ntpq) in a product developent kit of
>LPC 2378 microco
sheikdawoodraj...@gmail.com writes:
>Mills,
>[Dawood] The broadcast was successful after adding shim (Setting "tos
>mindist
>0.010") to the correctness interval. It worked fine once but when I
>tried again the time-sync was -not- successful. Could it be a problem
>in the
>network configuration(s)
Steve Kostecke writes:
>On 2009-04-06, Unruh wrote:
>> sheikdawoodraj...@gmail.com writes:
>>>When I tried running this test case again the next day with (approx
>>>25/30/40 minutes difference in 3 of the systems out of 7), the time
>>>sync didn't happ
"Richard B. Gilbert" writes:
>David Woolley wrote:
>> sheikdawoodraj...@gmail.com wrote:
>>
>>>
>>> Package Version:
>>> NTP v4.2.4.p5
>>
>> I'm not sure that is new enough to stay locked. Unless you use a very
>> recent version, which may have to be a development version, orphan mode
>> wil
Nathaniel Homier writes:
>Hello.
>I would like to know if one can use the line audio out of any old
>portable shortwave radio tuned to a time signal and fed via a line audio
>input. This would be motherboard audio. The primary reason is that I
>get the impression that ntp radio clocks are f
"Richard B. Gilbert" writes:
>David J Taylor wrote:
>> Richard B. Gilbert wrote:
>> []
>>> An error greater than 500 PPM suggests seriously broken hardware!
>>> There might be some way to "kludge" the software to compensate for
>>> this brokenness but I think it would be easier and cheaper to fi
"David J Taylor"
writes:
>Hal Murray wrote:
>>> I'm in a third category (probably) - as long as my PCs "sound" to
>>> have the same time, I'm happy. Actually, I want UTC as well, but as
>>> I have a speaking clock working on two PCs it's "nice" when they
>>> both speak at the same time. I wond
hal-use...@ip-64-139-1-69.sjc.megapath.net (Hal Murray) writes:
>In article <3uftl.5045$lc7.2...@text.news.virginmedia.com>,
> "David J Taylor"
> writes:
>>I don't know if anyone has written a driver which will suit your USB-based
>>BU353.
>The BU-353 uses one of the common serial-USB chips a
"David J Taylor"
writes:
>Hal Murray wrote:
>[]
>> If anybody has figured out how to get good timing out of the
>> SiRF units, please clue me in.
>On my system, I can detect no difference between the GPS 18 and the GSP
>18x. I am looking at jitters in the order of 2.2 microseconds, and
>offs
"David J Taylor"
writes:
>Unruh wrote:
>> "David J Taylor"
>[]
>>> On my system, I can detect no difference between the GPS 18 and the
>>> GSP 18x. I am looking at jitters in the order of 2.2 microseconds,
>>> and offsets in the rang
"David J Taylor"
writes:
>David Woolley wrote:
>> David J Taylor wrote:
>>
>>>
>>> - with operating system calls, the main clock can be read with a
>>> precision of 1 millisecond (although the ticks may be only 15
>>> milliseconds). There are higher resolution counters which can also
>>> be rea
"David J Taylor"
writes:
>Unruh wrote:
>[]
>> Since the same machine can run Linux or BSD whose resolution is usec
>> or
>> nsec, yes, the hardware can do better. The question is how good is the
>> software in the kernel. If I do a timestamp on an eve
johum...@yahoo.com writes:
>The theoretical precision of GetSystemTimeAsFileTime() or equivalent
>procs is 100 nanoseconds. However my tests show the accuracy is
No, that is the number of decimal points that are representable by the
variable used. That does NOT represent the accuracy of the time
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 a stratum 2 or 3
>server? It's all in a GE LAN based scenario, commercial stratum 1
>servers connected to GPS and stratum 2 and 3 servers are typically
>de
>NTP v4 over the LAN would be just as bad as V3. Think about broadcast or
>multicast! That way you don't clutter up the net with queries and
>response. Instead, every N seconds your server announces: "at the chime
>the correct time. . . ." and your clients can adjust their clocks as
>necessa
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 a stratum 2 or 3
>>> server? It's all in a GE LA
Andy Yates writes:
>Unruh wrote:
>> 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 a stratum 2 or 3
>>> server? It's all in a GE LAN b
Andy Yates writes:
>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
"Richard B. Gilbert" writes:
>Andy Yates wrote:
>> Unruh wrote:
>>> Andy Yates writes:
>>>
>>>> Hal Murray wrote:
>>>>> In article <4a15e001$0$18238$da0fe...@news.zen.co.uk>,
>>>>> Andy Yates writes:
>&
"David J Taylor"
writes:
>Folks,
>I have the following entries in ntpd.conf:
>server 192.168.0.2 iburst maxpoll 6
>server 192.168.0.7 maxpoll 6
>server 0.uk.pool.ntp.org minpoll 10
>.. and the following as the most recent loopstats:
>54974 37901.029 -0.000209922 13.840 0.000108471 0.007233
"David J Taylor"
writes:
>Unruh wrote:
>[]
>>> As I have maxpoll set to 6, I would have expected entries no more
>>> than 64s apart. What am I failing to understand here? The poll
>>> values reported in ntpq -p are 64, 64 and 1024 - as expected.
>
Hans =?iso-8859-1?Q?J=F8rgen?= Jakobsen writes:
>On Fri, 22 May 2009 23:47:35 GMT, Unruh wrote:
>> Note also that it can depend on the network harware. When we ran 100Mb/s
>> switches, the delay time was astonishingly regular and repeatable. Now
>> that we have switched to G
piste...@start.no writes:
>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
>mainboard. The Haicom is residing on a USB serial adapter (COM6) to
>che
piste...@start.no writes:
>On 27 Mai, 21:43, Terje Mathisen <"terje.mathisen at tmsw.no"> wrote:
>> 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
"hven...@astound.net" writes:
>On May 13, 10:25=A0am, Unruh wrote:
>> What the structure returns need have nothing to do with the accuracy.
>> Linux system calls can return a structure with nsec but the accuracy of
>> the linux clock is no better than usec.
>T
"Richard B. Gilbert" writes:
>E-Mail Sent to this address will be added to the BlackLists wrote:
>> Unruh wrote:
>> > Note that my checking with something in germany is not going
>> > to give me very good timing. the earth is a large place.
&
E-Mail Sent to this address will be added to the BlackLists
writes:
>Unruh 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's a
E-Mail Sent to this address will be added to the BlackLists
writes:
>Unruh wrote:
> > Note that my checking with something in germany is not going
> > to give me very good timing. the earth is a large place.
>Isn't the round trip delay calc
> (Client Destina
ScottyG writes:
>Hello.
>The company I am working for needs to be able to record timestamps in a
>trading
>system logs down to a .1 microsecond accuracy.
I think you misheard. .1 microsecond accuracy is impossible on a compter. Those
servers
cannot log to that accuracy. The trading system l
Terje Mathisen <"terje.mathisen at tmsw.no"> writes:
>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 n
John Hasler writes:
>I suspect that what is really wanted is to log the trades in the order they
>were received, with those that arrive within the same 100ns interval being
>accepted as simultaneous.
How does a trade "arrive within the same 100ns interval" Even on a GB
network that is only 10 c
E-Mail Sent to this address will be added to the BlackLists
writes:
>Unruh wrote:
>>> The company I am working for needs to be able to record
>>> timestamps in a trading system logs down to a .1
>>> microsecond accuracy.
>>> We will have servers
ScottyG writes:
>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 for.
John Hasler writes:
>Bill Unruh writes:
>> How does a trade "arrive within the same 100ns interval" Even on a GB
>> network that is only 10 characters, and I suspect trades are longer than
>> 10 characters.
>The first byte of the packet containing trade A arriv
"Richard B. Gilbert" writes:
>Harlan Stenn wrote:
>> The time on my cellphone is routinely more than 3 seconds off of GPS time.
>Is your cell phone "CDMA"? Other technologies, there are several, may
>not require the precise timing that CDMA does!
It will be hard for them to get CDMA in Londo
Rob writes:
>Unruh wrote:
>> "Richard B. Gilbert" writes:
>>
>>>Harlan Stenn wrote:
>>>> The time on my cellphone is routinely more than 3 seconds off of GPS time.
>>
>>>Is your cell phone "CDMA"? Other technologies, t
"Richard B. Gilbert" writes:
>Unruh wrote:
>> "Richard B. Gilbert" writes:
>>
>>> Harlan Stenn wrote:
>>>> The time on my cellphone is routinely more than 3 seconds off of GPS time.
>>
>>> Is your cell phone "CDMA
Terje Mathisen <"terje.mathisen at tmsw.no"> writes:
>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
David Lord writes:
>David J Taylor wrote:
>> David J Taylor wrote:
>> []
>>> I might be inclined to go for a screened
>>> cable if you need a 30m run, but thin 3-core mains cable /might/
>>> suffice.
>I'm intending buffering the pps to give 75r output to coax with
>another converter back to ttl
"David J Taylor"
writes:
>David Lord wrote:
>[]
>> Late last night I got round to connecting the Garmin GPS18x-LVC and
>> just after midnight it stepped from around 60s to 0.5ms and 8 hours
>> later is between -74us and +62us. The module is in south facing
>> upstairs window in same location I f
"David J Taylor"
writes:
>David Lord wrote:
>[]
>> I only have a pair of servers as peer and that is maxpoll 8 and
>> both sat at 256 sec. Offsets are 203us and 593us.
>I see more like 1-3ms for the Internet servers (compared to the GPS), with
>delays in the order of 30ms. This is with Window
David Lord writes:
>Unruh wrote:
>> David Lord writes:
>>
>>> David J Taylor wrote:
>>>> David J Taylor wrote:
>>>> []
>>>>> I might be inclined to go for a screened
>>>>> cable if you need a 30m run, but thin 3-core
701 - 800 of 1372 matches
Mail list logo
