HI,
Need following clarification.
Our Application needs to have two individual hardware (with DSP processor)
to have same crystal clock freqency. Though individual boards are alike, due
to environmental factors there might be drift after long run.
As the two boards are connected to local LAN thro
Richard B. Gilbert wrote:
> Bob wrote:
>> I've been experimenting with running a timeserver under FreeBSD. Basically,
>> I'm trying to build a dedicated box as a time server. I am currently running
>> the Meinberg port under windows, and that seems stable.
>>
>> I installed FreeBSD on a drive, an
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> QueryPerformanceCounter() directly off the hardware. Windows
> scheduling has no impact here, the drawbacks of tick counts do not
Windows scheduling will cause uncertainty in the time you get from
your SNTP requests which you use to cal
Guys,
David J Taylor wrote:
> The Windows implementation does try to provide granularity within the
> tick, but I have no idea how the Meinberg port I'm using handles
> multi-processors. Checking. I see the routine: nt_clockstuff.c mentions
> that how to handle multi-processors is not yet decide
Martin Burnicki wrote:
[]
> I think a few notes are required here.
>
> The ntpd port for Windows does interpolate (or extrapolate?) between
> the timer ticks. This has been in the NTP code base for a long time
> and has _not_ been invented by Meinberg. And, just to recall, there
> is no "Meinberg p
Danny Mayer wrote:
> David J Taylor wrote:
>> Thanks for your reply. Perhaps my recollection is at fault here, but I
>> recall that NTP on Windows uses some interpolation technique to overcome
>> timer granularity, and that the interpolation used a CPU counter.
>
> We are intending to implement t
Hal Murray wrote:
> In article
> <[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] writes:
>>Does anybody know of any *practical* samples on how to
>>implement NTP/SNTP client?. The goal is to provide accurate
>>time for a program/client running on Windows Vista.
>
> Just curious. Why do you want to roll
"Bob" <[EMAIL PROTECTED]> writes:
> I installed FreeBSD on a drive, and booted my windows machine from it. The
> FreeBSD port of ntpd shows a offsets in the 20-60 ms range. Issues with
> jitter, also. Remember, the same machine running windows is generally sub
> millisecond - http://www.pool.ntp
David J Taylor wrote:
>> There is one other thing that needs to be considered. This is a 64-bit
>> system> In that case it's possible that the code may need to be
>> changed to deal with it properly. For example using the VS 2005
>> compiler I have found that it uses a 64-bit integer instead of 32-
Martin Burnicki wrote:
> Guys,
>
> David J Taylor wrote:
>> The Windows implementation does try to provide granularity within the
>> tick, but I have no idea how the Meinberg port I'm using handles
>> multi-processors. Checking. I see the routine: nt_clockstuff.c mentions
>> that how to handle m
Martin Burnicki wrote:
> Danny Mayer wrote:
>> David J Taylor wrote:
>>> Thanks for your reply. Perhaps my recollection is at fault here, but I
>>> recall that NTP on Windows uses some interpolation technique to overcome
>>> timer granularity, and that the interpolation used a CPU counter.
>> We a
Hi Jason,
I agree with you to some extent(#1, #2).
I am trying to accomodate the changes in the NMEA driver itself.
Binary format was designed to send GPS time and position data to
another PCI card.
I cannot tell you the whole story but the binary format has GPS
time, sync
Hi Jason and Harlan,
I'll try to accomodate the changes for supporting the Accord
GPS Clock in the NMEA
driver itself. I shall test it in the production environment and
let you know.
Let me know the procedure to submit the code changes to the NTP code base.
Venu
_
Danny Mayer wrote:
[]
> With VS 2005, just open the dsw file and tell it to convert all the
> project files. I recently add the necessary macros to the dsp files so
> that I don't have to add a bunch of macros every time I pull in a new
> tarball. I'm only building on VS 2005 these days. Building o
Danny,
Danny Mayer wrote:
> David J Taylor wrote:
>> The version I'm testing is the 32-bit version of Vista, albeit on a
>> 64-bit
>> capable CPU. 64-bit can be a pain though for subtle errors, I
>> appreciate.
>>
>
> That's a problem. There are even more subtle issues when you run a
> 32-bit O
David,
David J Taylor wrote:
> Martin Burnicki wrote:
>> While on legacy multiprocessor systems the CPU clocks (and thus the
>> TSC) may differ for each CPU, I'm _assuming_ that multicore CPUs are
>> clocked by the same source, so the TSCs should runs synchrounously.
>
> This assumption is probab
Martin Burnicki wrote:
> Danny,
>
> Danny Mayer wrote:
>> David J Taylor wrote:
>>> The version I'm testing is the 32-bit version of Vista, albeit on a
>>> 64-bit
>>> capable CPU. 64-bit can be a pain though for subtle errors, I
>>> appreciate.
>>>
>>
>> That's a problem. There are even more subtl
>The NMEA driver uses 3 mode bits. I think more are available.
>The docs say that flag1 is unused for the NMEA driver.
It would be really nice if there was a clean way to specify the
baud rate.
Several of the NMEA units I'm familiar with allow you to set
the baud rate they use. I expect there a
Martin Burnicki wrote:
[]
> I've just set up a new test under Vista, so let's see.
>
> What I can say right now is that the default tick adjustment value is
> 156001 instead of 156250 which it used to be on earlier Windows
> versions. Also the granularity of the system clock has changed from
> 15.6
Are there any clear requirements in NTP/SNTP RFC docs about the UDP
source address in
all responses the same as the UDP target address in the original
requests?
I doubt it would be a UDP requirement because this is domain of upper
protocols.
___
question
Hal Murray wrote:
>> The NMEA driver uses 3 mode bits. I think more are available.
>> The docs say that flag1 is unused for the NMEA driver.
>
> It would be really nice if there was a clean way to specify the
> baud rate.
This is a general issue -- there are other drivers (e.g. the HP 58503)
th
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (linux newbie) writes:
>HI,
>Need following clarification.
>
>Our Application needs to have two individual hardware (with DSP processor)
>to have same crystal clock freqency. Though individual boards are alike, due
>to environmental factors there m
>> It would be really nice if there was a clean way to specify the
>> baud rate.
>
>This is a general issue -- there are other drivers (e.g. the HP 58503)
>that also assume a fixed baud rate and parity/stop bits. They cause a
>lot of problems when trying to use not-quite-identical hardware (as
Hal Murray wrote:
>>> It would be really nice if there was a clean way to specify the
>>> baud rate.
>> This is a general issue -- there are other drivers (e.g. the HP 58503)
>> that also assume a fixed baud rate and parity/stop bits. They cause a
>> lot of problems when trying to use not-quite-
On Dec 3, 3:34 am, [EMAIL PROTECTED] (David
Woolley) wrote:
> In article <[EMAIL PROTECTED]>,
>
> [EMAIL PROTECTED] wrote:
> > QueryPerformanceCounter() directly off the hardware. Windows
> > scheduling has no impact here, the drawbacks of tick counts do not
>
> Windows scheduling will cause unce
On Dec 2, 9:34 pm, [EMAIL PROTECTED] (Danny Mayer) wrote:
> [EMAIL PROTECTED] wrote:
> > On Dec 1, 3:07 pm, Joseph Gwinn <[EMAIL PROTECTED]> wrote:
> >> In article
> >> <[EMAIL PROTECTED]>,
>
> >> [EMAIL PROTECTED] wrote:
> >>> Does anybody know of any *practical* samples on how to
> >>> implement
[EMAIL PROTECTED] wrote:
> Just look at the NTP/SNTP request format and for ***every*** field
> explain why would a client send it to a server. Do not pick just one
> field like MODE, explain for ***all*** fields.
I believe that the principal reason for having the same format for the
received
linux newbie wrote:
> HI,
> Need following clarification.
>
> Our Application needs to have two individual hardware (with DSP processor)
> to have same crystal clock freqency. Though individual boards are alike, due
> to environmental factors there might be drift after long run.
This suggests tha
Jason, et al,
You might have noticed the mode subcommand in the refclock command. It
uses the ttl member in the association data structure and is intended to
pass stuff like bit rate, etc., to the base driver. If at all posible,
it would be best if the driver could automatically select the baud
Evandro,
Yes, the nanocode is aware that individual CPU clock rates can differ
and vary over time. Since the only purpose is to interpolate between
timer interrupts (Alpha) or second overflows (FreeBSD), all the code
does is count the number of PCC cycles since the last interrupt to
construct
Hal,
You raise a frustrating issue. It would be easy to add all kinds of
things to the server line; however, the mobilization routine has a fixed
format consistent with the ntpdc association managment code. Presumably,
the new ntpq can do many things using existing configuration file
commands,
>>> In article <[EMAIL PROTECTED]>, "David L. Mills" <[EMAIL PROTECTED]> writes:
David> ... The urge for utmost KISS and fewest driver files in the
David> public distribution is very strong. The problem is that the
David> distribution build process is so intricate that few refclock
David> builders
>>> In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (linux newbie) writes:
linux> We run 'ntpd' in server and ntpdate in the client and after every 5
linux> seconds, if we query the client (ntpdate -q) we find there is
linux> millisecond difference. As both of them are connected through the
lin
>>> In article <[EMAIL PROTECTED]>, Jan Ceuleers <[EMAIL PROTECTED]> writes:
Jan> Work is ongoing in the IETF (e.g. TICTOC) and elsewhere (e.g. IEEE
Jan> 1588). But before choosing a solution, you need to be clear on what
Jan> problem you are trying to solve.
I gather TICTOC is only a BOF at this
Folks,
Recently there have been several occasions where folks complained about
one thing or another in the documentation, in particular when not using
the "official" documentation via the web. The NTP maintainers and I have
a very strict security policy for the NTP products maintained at U
D
Venu,
Are you volunteering to be the maintainer for this code?
If not, somebody will have to step up to do it.
H
--
http://ntpforum.isc.org - be a member!
___
questions mailing list
questions@lists.ntp.org
https://lists.ntp.org/mailman/listinfo/ques
On Dec 3, 2:18 pm, Jan Ceuleers <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] wrote:
> > Just look at the NTP/SNTP request format and for ***every*** field
> > explain why would a client send it to a server. Do not pick just one
> > field like MODE, explain for ***all*** fields.
>
> I believe t
>>> In article <[EMAIL PROTECTED]>, "David L. Mills" <[EMAIL PROTECTED]> writes:
David> In fact, all snapshots, releases, bugzilla, repositories, NTP home
David> page and NTP project site physically reside at U Delaware. Only the
David> documents maintained by the NTP Support Project are physicall
Harlan,
Sorry, this is not true. It used to be that refclock contributors need
only provide a driver file together with a couple of modifided tables.
Now the submissions must include modified build scripts of arcane
structure. Maybe you don't rememeber the ancient days.
Dave
Harlan Stenn wrot
Hi Harlan,
Yes. I am volunteering to be the maintainer of the code.
Infact I'll be more than happy to do this. I have been a fan of
open-source community
since about six years. I always wanted to be part of a project and
contribute back to
this community. I hope this is my c
"Dag-Erling Smørgrav" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> "Bob" <[EMAIL PROTECTED]> writes:
>> I installed FreeBSD on a drive, and booted my windows machine from it.
>> The
>> FreeBSD port of ntpd shows a offsets in the 20-60 ms range. Issues with
>> jitter, also. Remem
41 matches
Mail list logo
