On Fri, Dec 23, 2011 at 10:06 PM, unruh wrote:
> If you really go to stamping the interrupt directly as it comes in on
> the kernel level, rather
> than waiting for a driver (eg the serial driver) to report that the
> itnerrupt has occured to userland, you can get it down to 1-2us.
That is exac
On 2011-12-24, Chris Albertson wrote:
> On Fri, Dec 23, 2011 at 5:51 PM, Mike S wrote:
>> At 01:58 PM 12/23/2011, Chris Albertson wrote...
>>
>>> But there is no hop of doing uS
>>> level over the gigabit either net.
>>
>>
>> IEEE 1588.
>
> Seem 1588 can work at the sub uS level but actual real-w
On 23 Dec, 2011, at 22:47 , Paul Sobey wrote:
>>> I appreciate these may appear to be silly questions with obvious answers
>>> - I am grateful in advance for your patience, and any research sources
>>> you may direct me to.
>>
>> The best (and probably only possible) solution that does give you
On 2011-12-23, Richard B. Gilbert wrote:
> On 12/22/2011 11:35 PM, unruh wrote:
>> On 2011-12-23, Richard B. Gilbert wrote:
>>> On 12/22/2011 2:11 PM, Paul Sobey wrote:
Dear All,
I work for a firm which requires clocks to be synchronised to quite a
high degree of accuracy.
>>>
On 2011-12-23, John Hasler wrote:
> Richard B. Gilbert wrote:
>> How do you "tag" a neutrino so that you can say with assurance that the
>> the neutrino that left Cern is the same neutrino that arrives at Sasso?
>
> Jim Pennino writes:
>> By sending them in a "pulse" of a known width.
>
> It shoul
On Fri, Dec 23, 2011 at 5:51 PM, Mike S wrote:
> At 01:58 PM 12/23/2011, Chris Albertson wrote...
>
>> But there is no hop of doing uS
>> level over the gigabit either net.
>
>
> IEEE 1588.
Seem 1588 can work at the sub uS level but actual real-work software
on Linux works at the "tens of uS" lev
On 2011-12-23, John Hasler wrote:
> An
> upcoming experiment at Fermilab will observe neutrinos at both ends (the
> far end will be in Minnesota).
But not the same neutrino, since you can only detect the neutrino
after it has collided with something else.
At 01:58 PM 12/23/2011, Chris Albertson wrote...
But there is no hop of doing uS
level over the gigabit either net.
IEEE 1588.
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
John Hasler wrote:
> Richard B. Gilbert wrote:
>> How do you "tag" a neutrino so that you can say with assurance that the
>> the neutrino that left Cern is the same neutrino that arrives at Sasso?
>
> Jim Pennino writes:
>> By sending them in a "pulse" of a known width.
>
> It should be noted, h
Richard B. Gilbert wrote:
> How do you "tag" a neutrino so that you can say with assurance that the
> the neutrino that left Cern is the same neutrino that arrives at Sasso?
Jim Pennino writes:
> By sending them in a "pulse" of a known width.
It should be noted, however, that you cannot observe t
Hi Paul, This is probably going further up the track for you, however, with the
HP "c class" blades you can use a PCI expansion blade with a serial IO card in
it. The downside is that the expansion blade takes up one bay (to the left of a
half-height blade, or bottom left slot next to a full hei
Richard B. Gilbert wrote:
> How do you "tag" a neutrino so that you can say with assurance that the
> the neutrino that left Cern is the same neutrino that arrives at Sasso?
By sending them in a "pulse" of a known width.
--
Jim Pennino
Remove .spam.sux to reply.
On 12/22/2011 11:35 PM, unruh wrote:
On 2011-12-23, Richard B. Gilbert wrote:
On 12/22/2011 2:11 PM, Paul Sobey wrote:
Dear All,
I work for a firm which requires clocks to be synchronised to quite a
high degree of accuracy.
We have an existing ntp-based infrastructure but want to improve on
On Fri, Dec 23, 2011 at 2:09 AM, Terje Mathisen <"terje.mathisen at
tmsw.no"@ntp.org> wrote:
> The best (and probably only possible) solution that does give you
> single-digit us is to route a PPS signal to each and every server, then use
> the network for approximate (~100 us) timing, with the PP
I see a common misconception here. Most of the concepts about NTP
can be explained using a common wristwatch.
One is that more frequent checking to a standard keeps the time closer
to the standard. That would be true only if you set your watch to
match the standard each time. NTP does not do
On Fri, Dec 23, 2011 at 17:02, Terje Mathisen <"terje.mathisen at
tmsw.no"@ntp.org> wrote:
> A fast system time query will load the time as of the last hw clock tick,
> along with the corresponding RDTSC (or similar, constant-rate highres clock
> source), load the current RDTSC value, then re-read
Paul Sobey wrote:
Gbit and low jitter is not quite compatible: 100 Mbit switches were
using cut-through, while (afaik) all Gbit and up switches use store &
forward, leading to higher latency and jitter.
There are several varieties of cut-through gig/10GB switch available now
- but noting that s
On 2011-12-23, Paul Sobey wrote:
>>> I hear from many vendors and industry colleagues that 'ntp just isn't
>>> suitable for high precision work and anything less than 1-2ms precision
>>> requires ptp or direct connection to gps clock'. I find these numbers
>>
>> For microsecond accuracy, I wou
What OS are your hosts running? If it's Windows, millisecond, not
microsecond accuracy will be what you can get at best when syncing over
the network.
A mixture of linux flavours and solaris. For the linux hosts I have a
little more control over which version of ntpd I deploy. For the solaris
What OS are your hosts running? If it's Windows, millisecond, not
microsecond accuracy will be what you can get at best when syncing over the
network.
A mixture of linux flavours and solaris. For the linux hosts I have a
little more control over which version of ntpd I deploy. For the solaris
I hear from many vendors and industry colleagues that 'ntp just isn't
suitable for high precision work and anything less than 1-2ms precision
requires ptp or direct connection to gps clock'. I find these numbers
For microsecond accuracy, I would say that NTP needs direct (PPS) connection
to
Paul Sobey wrote:
Our internal testing to this point is that a stock ntpd pointed against
a stratum 1 clock on a low contention gigabit ethernet (stratum 1 source
and client less than 1ms apart) reports its own accuracy at approx 200
microseconds. Further tuning the ntp config by adding the m
Paul Sobey wrote:
Our internal testing to this point is that a stock ntpd pointed against
a stratum 1 clock on a low contention gigabit ethernet (stratum 1 source
and client less than 1ms apart) reports its own accuracy at approx 200
microseconds. Further tuning the ntp config by adding the minpo
ben slimup wrote:
thanks all,
let s say, i have one site in california and another one in new york.
all clients are independent to each other and connected to adsl.
all clients are spread out all over the internet.
six ntp servers are located in each site ( CA and NY)
and need to connect the
Richard B. Gilbert wrote:
On 12/22/2011 9:17 PM, Chris Adams wrote:
The securities traders (especially HFT) want it. I suspect the OP is in
that group. That level of timekeeping has been discussed here before.
I think that the radio astronomers are some of the most demanding.
They need far b
Paul Sobey wrote:
We have an existing ntp-based infrastructure but want to improve on it
to the point where the bulk of our hosts are synchronised to single
digit microseconds of each other if possible. We have about 400 hosts in
production, spread across about 15 sites.
There are very few
"Paul Sobey" wrote in message
news:alpine.lnx.2.00.1112221841020.9...@vulcan.the-annexe.net...
Dear All,
I work for a firm which requires clocks to be synchronised to quite a
high degree of accuracy.
We have an existing ntp-based infrastructure but want to improve on it
to the point where t
27 matches
Mail list logo
