[ntp:questions] Sexy Young Beautiful Brides Indian Pakistani UK Ireland Canadian Photos gallery you visit must
Sexy Young Beautiful Brides Indian Pakistani UK Ireland Canadian Photos gallery you visit must http://bridephotogallary.blogspot.com ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Frequently asked question about error bounds?
B, Wrong. Help stamp out urban legends. Take five minutes to review the architcture briefing on the NTP Project page linked from www.ntp.org. Pay close attention to the error budget and its contributing components. Dave B wrote: >On 2 Nov, 22:52, David Woolley wrote: > > >>berra.84 wrote: >> >> >>>And for last, how can root delay be lower than delay for server >>>xx.xx.xx.x2 ? >>> >>> >>Because root delay is the input root delay. You have to add the last >>hop delay to get the output root delay. >> >> > >Yes, that's right, thanks! > >Anyone know how to calculate the synchronization distance to 1.312 in >above?( RFC-1305) > >___ >questions mailing list >questions@lists.ntp.org >https://lists.ntp.org/mailman/listinfo/questions > > ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] NTP absolute accuracy?
RedGrittyBrick wrote: > Unruh wrote: > >> "David J Taylor" >> writes: >> >> >>> At source, it's recently been within about 10 microseconds: >>> >> Sorry, at 10usec, the distance away of the transmitter must be less than 3 >> km. >> > > At *source*, the distance to the transmitter must surely be a lot less > than 3 km :-) > > According to the National Physics Laboratory "Every UTC second is marked > by an 'off' preceded by at least 500 ms of carrier, and this second > marker is transmitted with an accuracy better than ±1 ms." from which I > conclude it's never going to to be more accurate than a few ms at > *receiver*. > Yea - every TAI second is what they mean. UTC is a calculated value which is published after the fact and sets the TOD at a particular instant some 25 to 30 days previous. From that point onward until the next UTC fixing per schedule T the time is measured in incremental TAI seconds per the convention of the Meter's definition of the Second. Todd > Someone has compared a KHz radio time signal from DCF with the GHz radio > time signals from GPS: http://www.hopf-time.com/en/dcf-gps.htm. I > imagine MSF accuracy is similar to DCF. > > > > > > No virus found in this incoming message. > Checked by AVG - www.avg.com > Version: 8.5.423 / Virus Database: 270.14.44/2475 - Release Date: 11/01/09 > 19:39:00 > > ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] NTP absolute accuracy?
David J Taylor wrote: > "David J Taylor" > wrote in > message news:%xqgm.126$ym4...@text.news.virginmedia.com... > >> "Unruh" <> wrote in message news:34jgm.50898$ph1.36...@edtnps82... >> [] >> >>> Note that chrony will give you a factor of 2 or three improvement over >>> ntp in the errors, assuming that the roundtrip is equally split on >>> Linux or BSD. >>> True but it doesnt support AutoKEY operations so it has no value in provable time settings which are now key requirements in many commercial settings. >> For those without wide-bandwidth academic connections - those folks on >> cable or ADSL - how good is an "equal split round trip" assumption? >> >> David >> David - This doesnt take into account the issues of peering agreements and backhauling which add a non-deterministic type of latency to the time-setting process as does the peering agreements between the various carriers who's networks the time-service providers systems operate in. It also takes into account system I/O latency's and the issues of time-provider or infrastructure loading. Also most parties using cable networks are probably running home gear with SNTP enablement in most instances. Its unlikely that a NTP client exists in most sub-$100 infrastructure devices. I think the answer is that no one knows and it could be as little as a few milliseconds or it could be more and we wont know. It also depends on whether the time server those client systems are tied to are located on the Open Internet or are operated by the Cable Providers for their clients use. Then the secondary non-deterministic impulse and the asymmetric routing delays are mitigated or eliminated so again - it depends on how NTP is being used and whether its a real NTP instance or just a SNTP instance (as it exists today) being used. > > Thanks, David, David and Jan. A few milliseconds is what I had expected, > so if you are on a consumer line, what implications does that have for > unruh's comment? > > Cheers, > David > > ___ > questions mailing list > questions@lists.ntp.org > https://lists.ntp.org/mailman/listinfo/questions > > > > No virus found in this incoming message. > Checked by AVG - www.avg.com > Version: 8.5.423 / Virus Database: 270.14.39/2470 - Release Date: 10/30/09 > 15:18:00 > > ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Did we ever get NTP running under Cygwin32
Dave Hart wrote: > On Sun, Nov 1, 2009 at 5:09 PM, todd glassey wrote: > >> As I remember Sven was working on this - did we ever get it completed and if >> so where is the documentation on it? >> > > I don't believe so. There is very little evidence in the code, just a > few tidbits in headers and configure.ac. The major issue is likely to > be adjtime()/SetSystemTimeAdjustment(). cygwin32 likely lacks code to > implement adjtime() using Windows' SetSystemTimeAdjustment(). > Agreed - so I was wondering if there was another port which wasnt tied to VC++ Redistributables. > Undoubtedly there would many minor kinks to work out as well. I know > of another cygwin-based program which on Windows Vista tends to fail > before starting main() in cygwin's heap initialization code, unless > you've restarted recently. My guess is it's being fouled by "address > space layout randomization" causing DLLs to be located in the address > space cygwin wants to pre-reserve for a simple classic sbrk()-based > malloc(). Agreed but installing the time-service interface as a TSR would likely cure this. > One would probably spend most of the effort of such a > project fixing and extending cygwin32, with relatively few changes > required to the NTP code. > Thanks Dave > Cheers, > Dave Hart > ___ > questions mailing list > questions@lists.ntp.org > https://lists.ntp.org/mailman/listinfo/questions > > > > No virus found in this incoming message. > Checked by AVG - www.avg.com > Version: 8.5.424 / Virus Database: 270.14.47/2478 - Release Date: 11/03/09 > 07:36:00 > > ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
[ntp:questions] Using jitter as an indicator of the expecting time
Hi, This is a really interesting question for me. I know about the error bounds, but never heard of using the jitter as an indicator of the expecting time relative offset. While there aren't any certain distribution within the error bound, an indicator of expecting time is important. The jitter isn't introduced before NTPv4 and we are using NTPv3(RFC-1305). Here is a good thread were David L. Mills wrote about using an indicator for the expecting time(NTPv4): http://groups.google.com/group/comp.protocols.time.ntp/browse_thread/thread/e56b7b499b6defc8/870223aa124b5117?lnk=gst&q=by+design+jitter+indicator#870223aa124b5117 There are two statistics involved: jitter, which represents a random error average estimate and dispersion, which represents a worst case error bound. Is there any correspondence to jitter in v3 as in v4? If there isn't any way to calculate a estimate or distribution within the error bound. My idea, peer.dispersion represents the maximum error in offset and maximum error of half the roundtrip delay. Couldn't that be used instead of jitter, due to dispersion > jitter ? Bertil ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Frequently asked question about error bounds?
On 2 Nov, 22:52, David Woolley wrote: > berra.84 wrote: > > And for last, how can root delay be lower than delay for server > > xx.xx.xx.x2 ? > > Because root delay is the input root delay. You have to add the last > hop delay to get the output root delay. Yes, that's right, thanks! Anyone know how to calculate the synchronization distance to 1.312 in above?( RFC-1305) ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
