Re: [ntp:questions] NTP settings for machine with irregular, short connections to the Net
If only the human scale is required, how about ntpdate run via cron or its platform-specific equivalent. On the laptop, it would try to get time from the ISP's NTP server(s). On the other systems it would try to get time from the laptop. So, when the laptop is connected to the ISP network, it gets time from there and the clients simply time-out their ntpdate commands. Then when it is on the little network, the laptop's attempt at ntpdate is the one that times-out and the clients get time from the laptop. rick jones -- The glass is neither half-empty nor half-full. The glass has a leak. The real question is "Can it be patched?" these opinions are mine, all mine; HP might not want them anyway... :) feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH... ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] More Granularity in the US in the NTP Pool
Hal Murray <[EMAIL PROTECTED]> wrote: > >Suppose a ntpd client can pick up 5 random pool servers, and > >periodically (say once a day) replace the 'worst' server > >by randomly picking a new one. > I like that suggestion. But, ignoring implementation details, > how do you decide which of two servers is "better"? If one would get a '*' or '+' in ntpq peers output, and the other would not, then it is better? rick jones -- The computing industry isn't as much a game of "Follow The Leader" as it is one of "Ring Around the Rosy" or perhaps "Duck Duck Goose." - Rick Jones these opinions are mine, all mine; HP might not want them anyway... :) feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH... ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] More Granularity in the US in the NTP Pool
Hal Murray <[EMAIL PROTECTED]> wrote: > >> I like that suggestion. But, ignoring implementation details, > >> how do you decide which of two servers is "better"? > > > >If one would get a '*' or '+' in ntpq peers output, and the other > >would not, then it is better? > That tells you which is better "right now". I was looking for > something that averaged over some time period, say a day. > How does 23 "*"s compare with 147 "+"s? > It might be reasonable to assign a weight to the flag character. > Say +3 for a *, +1 for a +, and -1 for a -. I realize the world of NTP isn't a world usually satisfied with "good enough" :) But isn't "right now" more important than "12 hours ago?" I suppose that one could presume that being a good clock for 11 out of the last 12 hours suggests it will be a good clock for the next hour, but is that really the case? rick jones -- oxymoron n, commuter in a gas-guzzling luxury SUV with an American flag these opinions are mine, all mine; HP might not want them anyway... :) feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH... ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] More Granularity in the US in the NTP Pool
I was wondering - is everyone confident enough that all these clients choosing the "best" servers won't eventually settle on the same small handfull of them? rick jones -- a wide gulf separates "what if" from "if only" these opinions are mine, all mine; HP might not want them anyway... :) feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH... ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] getaddrinfo2: "192.168.0.2" invalid host address.
Aggie <[EMAIL PROTECTED]> wrote:
> Sorry for posting the whole output messages.
> When I run ntpd with the debug option, I get the followings:
> //please take a quick look.
> If you do the search on "calling getaddrinfo(192.168.0.2,...)" from
> the following log, you will see
> getnetnum: calling getaddrinfo(192.168.0.2,...)
> reval before = 7476272
> retval = 9
> getaddrinfo2: "192.168.0.2" invalid host address.
> I'm very sure that 192.168.0.2 is the ip address of my host address.
> But then why is it saying it's invalid host address??
> It's weird getaddrinfo() is returning 9. Why??
Can you also take a tcpdump trace to see if the getaddrinfo() call
results in DNS traffic? The getaddrinfo() call, while normally meant
to map a hostname (what I think you called a host address) to an IP
address, can be passed an IP adddress - as a string - and it will use
that. However, if it decided to pass that particular sort of IP
address to a DNS server, some DNS servers will not be pleased with an
RFC1918 "private" IP such as a 192.168 and may return an error
message. One would think that a well-written getaddrinfo() would
notice correctly when something was an IP rather than a name but then
with my experience with netperf, there are still steps on the learning
curve for getaddrinfo implementations...
Now, if that code in NTP is really trying to map from an IP address to
a host name, then it should be calling getnameinfo() rather than
getaddrinfo().
EBADF (errno 9) is indeed a bit strange to be getting - makes me
wonder if the socket() call made by getaddrinfo() was unsuccessful. A
system call trace of the behaviour migth be a good thing to take - you
would then see the system calls being made and which failed within the
getaddrinfo() call. However, looking at the manpage (HP-UX 11.11) for
getaddrinfo() tells me that the return value isn't an errno but a
getaddrinfo-specific error code. In that context a value of "9" might
not be so weird. On my system it seems those values (EAI_mumble) are in
/usr/include/netdb.h:
$ find /usr/include -exec grep -l EAI_FAIL {} \;
/usr/include/netdb.h
and when I look there it suggests that a value of 9 means:
# define EAI_SERVICE 9 /* service not supported for ai_socktype */
which implies (in my mind) that one of the struct addrinfo fields were
off a bit as to as_socktype or ai_protocol.
rick jones
--
portable adj, code that compiles under more than one compiler
these opinions are mine, all mine; HP might not want them anyway... :)
feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...
___
questions mailing list
questions@lists.ntp.org
https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] getaddrinfo2: "192.168.0.2" invalid?host?address.
Danny Mayer <[EMAIL PROTECTED]> wrote: > Rick, > As I'm sure you know from BIND9 this is almost certainly caused by > it trying to look up the A or record for the IP address > "192.168.0.2" which is obviously an IP address and not a name. The > question is why? That's the reason I want to see the config file. Actaully, I'm absent minded enough that it didn't cross my mind :) rick jones -- Process shall set you free from the need for rational thought. these opinions are mine, all mine; HP might not want them anyway... :) feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH... ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Is it possible to run ntpd server behind a?firewall?
imacat <[EMAIL PROTECTED]> wrote: > When IANA officially assigns a port, it always assigns both TCP and > UDP for easier maintainance and fewer confusion. When you see "ntp > 123/tcp" it doesn't necessarily mean that NTP is using TCP/123. Just to > reserve it in order to prevent future confusion. "Reserve" may be too strong a word - it leads to confusion among recent inductees who then think the likes of /etc/services prevents others from binding to thsoe port numbers. rick jones -- Wisdom Teeth are impacted, people are affected by the effects of events. these opinions are mine, all mine; HP might not want them anyway... :) feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH... ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Wireless Routers and NTP
Jason Rabel <[EMAIL PROTECTED]> wrote: > +1 for OpenWRT! I installed it on a Dell Truemoble 2300 router I got > off eBay for ~$10. The hardware is more or less identical to the > Linksys WRT54G, just much cheaper to buy secondhand. Ah, but can you wire a PPS (?) GPS to it?-) rick jones -- firebug n, the idiot who tosses a lit cigarette out his car window these opinions are mine, all mine; HP might not want them anyway... :) feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH... ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Slightly OT: "Amateur Time Hackers Play With Atomic Clocks at Home"
David J Taylor <[EMAIL PROTECTED]> wrote: > Interesting article: > http://www.wired.com/science/discoveries/news/2007/12/time_hackers Hmm, didn't know that Agilent was HP's former R&D arm :) Also, to the best of my knowledge and surfing of Agilent's website[1], they have no Sunnyvale location :) A bit of creative license I suppose, but just how much creative license is permissible in an article about people keeping accurate time?-) rick jones [1] http://www.jobs.agilent.com/locations/usa.html -- The glass is neither half-empty nor half-full. The glass has a leak. The real question is "Can it be patched?" these opinions are mine, all mine; HP might not want them anyway... :) feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH... ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Slightly OT: "Amateur Time Hackers Play With?Atomic Clocks at Home"
Kevin Oberman <[EMAIL PROTECTED]> wrote: > Agilent Labs is the R&D arm of Agilent Technology and was once the > R&D part of HP before spun off its instrumentation business into > Agilent. So the first statement is correct if you add the word > "Labs" after Agilent. Well, what is Agilent Labs was once _part_ of HP Labs, the R&D (researchy) part of Hewlett-Packard. > The campus is actually located in Santa Clara, not Sunnyvale, but > it's easy to miss the fact that you have crossed from one to the > other and mailing addresses often don't match with government > boundaries. Admittedly, even after 19 years here, the whole area feels like one extended suburb to me, but I thought that to get from where Agilent sits on Stevens Creek Blvd in Santa Clara, to Sunnyvale, one first went through Cupertino :) > On the whole (and not knowing much about atomic clocks), I thought it > was a fairly good article. Agreed. rick jones -- No need to believe in either side, or any side. There is no cause. There's only yourself. The belief is in your own precision. - Jobert these opinions are mine, all mine; HP might not want them anyway... :) feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH... ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
[ntp:questions] time delta between clients
Some folks have been asking me if it is possible to use netperf to get the one-way latency between two systems, while sending a unidirectional stream of data from one to the other. Netperf already has a TCP_RR test (ping-pong) that will report the average round-trip latency (and optionally a histogram of the individual RTTs). That though is not a unidirectional test. So, I am assuming I need synchronized "clocks." Running ntp on each of the two systems on which I would run netperf is not a problem. What I'm curious about, and a topic where I would welcome some gentle taps with clue bats, is if I can take the difference in offset between each client and the time server and ass-u-me that is the difference in time between the two clients. Or do I have to do something ntp-like in netperf itself between the two systems? My tests will typically only run for oh, O(60) seconds at a time, so I'm ass-u-me-ing I can ignore issues of the two client clocks rates changing much. For example, here is ntpq peers output from a pair of machines where I might want to do this: Client 1: ntpq> peers remote refid st t when poll reach delay offset jitter == +oslowest.raj15.4.81.61 2 u 118 128 3770.123 -1.602 2.723 +lart.lart 15.235.160.305 u4 128 377 35.6394.115 1.508 *shovlhead.nashu .TRUE. 1 u 54 128 377 101.115 -5.273 8.190 Client 2: ntpq> peers remote refid st t when poll reach delay offset jitter == +linger.raj 15.4.81.61 2 u 104 128 3770.1510.002 0.976 +lart.lart 15.235.160.305 u 97 128 377 35.6823.556 1.003 *shovlhead.nashu .TRUE. 1 u 33 128 377 105.602 -0.839 3.267 I would take the difference in offset - -5.273 - -0.839 - and take that to be the difference in time between Client 1 and 2. Thoughts, suggestions, pointers etc most welcome, rick jones BTW, in this case, I disabled the interrupt coalescing on Client 1's NIC, which I believe is the reason for the difference in delay between Client 1 and 2 and linger.raj - all three are on the same LAN. It gets lost in the noise talking to the other two time sources. -- oxymoron n, commuter in a gas-guzzling luxury SUV with an American flag these opinions are mine, all mine; HP might not want them anyway... :) feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH... ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] time delta between clients
David Woolley <[EMAIL PROTECTED]> wrote: > In article <[EMAIL PROTECTED]>, > Rick Jones <[EMAIL PROTECTED]> wrote: > > taps with clue bats, is if I can take the difference in offset > > between each client and the time server and ass-u-me that is the > > difference in time between the two clients. Or do I have to do > > something ntp-like > No. If NTP is working properly, it is actually an indication of the > order of magnitude of the error you can expect in measuring the > combination of network and system timing. The actual system timing > variation should be considerably less than this, but there may be a > systematic bias, even if offset is consistently almost zero. Systematic bias? > The NTP clock discipline will strive to zero the offset, but cannot > correct for round trip asymmetry. Any individual offset measurement > will contain a measurement error. That measurement error will be of > the same magnitude as the measurement error you will get with your > application. If you are interested in one way latency, you are > interested in asymmetry! I think that in 99 cases out of 10 this would be run on a LAN where I have a decent expectation of symmetry :) Or at least the first places _I_ would be running it would be on a LAN :) Netperf can and does get run over WAN's where any hope of symmetry is out the window, but I'm willing to caveat that in the documentation. > To the extent that the above is not true, either you are making use > of information not available to NTP (like recent temperature > excursions), or the NTP algorithms need fixing. > You need to use local, probably GPS, reference clocks, with pulse > per second feeds, to remove network asymmetry. Is that need, Need, or NEED? Is there is a way to be "good enough" without having the dependence upon anything more than the two endpoints being sync'ed to the same time source? (Other than the same GPS constellation received independently by each via their own PPS pucks that is) -- oxymoron n, commuter in a gas-guzzling luxury SUV with an American flag these opinions are mine, all mine; HP might not want them anyway... :) feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH... ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] time delta between clients
Richard B. Gilbert <[EMAIL PROTECTED]> wrote: > Rick Jones wrote: > > David Woolley <[EMAIL PROTECTED]> wrote: > > > >>In article <[EMAIL PROTECTED]>, > >>Rick Jones <[EMAIL PROTECTED]> wrote: > > > > > >>>taps with clue bats, is if I can take the difference in offset > >>>between each client and the time server and ass-u-me that is the > >>>difference in time between the two clients. Or do I have to do > >>>something ntp-like > >> > > > >>No. If NTP is working properly, it is actually an indication of the > >>order of magnitude of the error you can expect in measuring the > >>combination of network and system timing. The actual system timing > >>variation should be considerably less than this, but there may be a > >>systematic bias, even if offset is consistently almost zero. > > > > > > Systematic bias? > > > >>The NTP clock discipline will strive to zero the offset, but cannot > >>correct for round trip asymmetry. Any individual offset measurement > >>will contain a measurement error. That measurement error will be of > >>the same magnitude as the measurement error you will get with your > >>application. If you are interested in one way latency, you are > >>interested in asymmetry! > > > > > > I think that in 99 cases out of 10 this would be run on a LAN where I > > have a decent expectation of symmetry :) Or at least the first places > > _I_ would be running it would be on a LAN :) Netperf can and does get > > run over WAN's where any hope of symmetry is out the window, but I'm > > willing to caveat that in the documentation. > > > > > >>To the extent that the above is not true, either you are making use > >>of information not available to NTP (like recent temperature > >>excursions), or the NTP algorithms need fixing. > > > > > >>You need to use local, probably GPS, reference clocks, with pulse > >>per second feeds, to remove network asymmetry. > > > > > > Is that need, Need, or NEED? Is there is a way to be "good enough" > > without having the dependence upon anything more than the two > > endpoints being sync'ed to the same time source? (Other than the same > > GPS constellation received independently by each via their own PPS > > pucks that is) > > > Define "good enough"! How close must synchronization be between > machines on your LAN? How accurate must the time be? Well, if the RTT measured by netperf TCP_RR is any indication: [EMAIL PROTECTED] netperf2_trunk]# netperf -t TCP_RR -v2 -H bl480c2 -c -C TCP REQUEST/RESPONSE TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to bl480c2.raj (10.208.0.27) port 0 AF_INET : first burst 0 Local /Remote Socket Size Request Resp. Elapsed Trans. CPUCPUS.dem S.dem Send Recv SizeSize TimeRate local remote local remote bytes bytes bytes bytes secs. per sec % S% Sus/Tr us/Tr 87380 87380 1 1 10.00 19834.15 2.20 2.29 8.888 9.222 87380 87380 Alignment Offset RoundTrip TransThroughput Local Remote Local Remote LatencyRate 10^6bits/s Send RecvSend Recvusec/Tran per sec Outbound Inbound 8 0 0 0 50.418 19834.148 0.159 0.159 I'm presently seeing round-trip times user space to user space, and with interrupt coalescing disabled (not the default) of 50 microseconds. Some folks have reported better TCP_RR perf with other interconnects (the above was simply Gigabit Ethernet). So, we are talking small numbers of microseconds. > Note that having a stable source of time, such as a GPS receiver, > can strongly affect the tightness of synchronization. It's > analogous to the difference in difficulty of hitting a stationary > target versus a moving target. > I've done it with and without GPS. GPS is better as long as you can > site an antenna with a good view of the sky. With GPS I can keep > the herd within one millisecond. Most of what I do is down in the bowels of corporate machine rooms, far from windows, which doesn't fill me with confidence about getting a good view of the sky :( rick jones -- No need to believe in either side, or any side. There is no cause. There's only yourself. The belief is in your own precision. - Jobert these opinions are mine, all mine; HP might not want them anyway... :) feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH... ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] time delta between clients
Per Hedeland <[EMAIL PROTECTED]> wrote: > Well, if you want a reasonably accurate estimate on the time > difference between two hosts on a LAN, it's probably a better idea > to ask ntpd to provide that directly rather than comparing their > offsets to a server that is 50 ms removed (presumably across a WAN) > and that may not have been polled for the last 17 minutes. Yeah, that one gets picked I suspect thanks to its stratum. I've contemplated removing it from the equation. > I.e. you could set up the hosts to peer with each other, possibly > with a lowered maxpoll and/or 'noselect', which would have each give > their estimated offset to the other directly in the ntpq output. I > have no idea *how* accurate that would be in absolute terms, but it > just has to be "better". I will see about giving that a try. I suppose I could also try to see if I can get the powers that be to spring for a GPS18 and see if I can indeed get signal in the machine room(s) of interest. Speaking of which, I was just at the garmin website, and seems they now have a GPS18 5HZ in addition to the regular GPS18. Is there any benefit to the extra four pulses per second? rick jones -- oxymoron n, Hummer H2 with California Save Our Coasts and Oceans plates these opinions are mine, all mine; HP might not want them anyway... :) feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH... ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] time delta between clients
Richard B. Gilbert <[EMAIL PROTECTED]> wrote: > Can you put a small PC with a GPS receiver on the top floor as a > dedicated NTP server? Perhaps, but I doubt I could get a "direct line" on the network from the systems to it. > There are devices (expensive) that will read the time from the > reference signal of a CDMA cell phone base station and serve time > via NTP. I might be able to convince TPTB to fund a GPS18 or GPS185Hz "experiment." In this _specific_ instance the building is two stories plus a mezzanine. Perhaps I could get lucky. rick jones -- No need to believe in either side, or any side. There is no cause. There's only yourself. The belief is in your own precision. - Jobert these opinions are mine, all mine; HP might not want them anyway... :) feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH... ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] time delta between clients
Doug Hughes <[EMAIL PROTECTED]> wrote: > well, I guess the point is, if you think it's going to be symmetric > anyway (in your almost guaranteed sense), why not just simplify > tremendously, run ping, and divide by 2? Then it wouldn't be a unidirectional transfer :) Being the clueless ntpadmin I am, I am not sure I did things correctly with the suggestion to setup a peer association, and drop the polling intervals, I went ahead and tried to do that with my two systems anyway. I also took away the "far away" time servers. On bl480c1: ntpq> peers remote refid st t when poll reach delay offset jitter == bl480c2.raj 10.208.0.1 3 u 13 16 3770.093 -0.002 0.017 *linger.raj 15.4.81.61 2 u2 16 3770.1250.155 0.145 LOCAL(0).LOCL. 10 l 56 64 3770.0000.000 0.001 On bl480c2, when I initially botched the peer line, saying bl481c1 by mistake: ntpq> peers remote refid st t when poll reach delay offset jitter == *linger.raj 15.4.81.61 2 u 11 16 3770.1390.550 0.089 LOCAL(0).LOCL. 10 l 27 64 3770.0000.000 0.001 I corrected that - it was interesting to see how far things migrated in just the 30 seconds or so ntpd wasn't running on bl480c2. Shortly after restarting, the offset reported by bl480c1 was 0.100 rather than 0.002. rick jones -- portable adj, code that compiles under more than one compiler these opinions are mine, all mine; HP might not want them anyway... :) feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH... ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] time delta between clients
Rick Jones <[EMAIL PROTECTED]> wrote: > On bl480c1: > ntpq> peers > remote refid st t when poll reach delay offset jitter > == > bl480c2.raj 10.208.0.1 3 u 13 16 3770.093 -0.002 0.017 > *linger.raj 15.4.81.61 2 u2 16 3770.1250.155 0.145 > LOCAL(0).LOCL. 10 l 56 64 3770.0000.000 0.001 > On bl480c2, when I initially botched the peer line, saying bl481c1 by > mistake: > ntpq> peers > remote refid st t when poll reach delay offset jitter > == > *linger.raj 15.4.81.61 2 u 11 16 3770.1390.550 0.089 > LOCAL(0).LOCL. 10 l 27 64 3770.0000.000 0.001 > I corrected that - it was interesting to see how far things migrated > in just the 30 seconds or so ntpd wasn't running on bl480c2. Shortly > after restarting, the offset reported by bl480c1 was 0.100 rather than > 0.002. And ever since then, I've not seen it anywhere near that 0.002 figure. rick jones -- Wisdom Teeth are impacted, people are affected by the effects of events. these opinions are mine, all mine; HP might not want them anyway... :) feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH... ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] time delta between clients
Rick Jones <[EMAIL PROTECTED]> wrote: > Here is what I have now that I've dropped the minpoll from the server > and dropped LOCAL: > peer bl480c2 minpoll 3 maxpoll 4 iburst > server 10.208.0.1 iburst > server 10.0.0.1 > server 10.202.1.1 Scratch that - I commented-out the last two servers. rick jones -- a wide gulf separates "what if" from "if only" these opinions are mine, all mine; HP might not want them anyway... :) feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH... ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] time delta between clients
Per Hedeland <[EMAIL PROTECTED]> wrote: > Did you lower the maxpoll on the server that is actually providing time > to those two? Don't do that, it prevents ntpd from fine-tuning the > disciplining of the system clock. > Lowering it on the peer setup - which is not intended to provide > time to either of those two hosts, and so could usefully have > 'noselect' (if it is available in your version and works with > "peer", I haven't tried that) - is just so you can have a "recent" > value for the offset. It would be a good idea to lose the LOCAL > clock though, it's totally useless for your purpose. Here is what I have now that I've dropped the minpoll from the server and dropped LOCAL: peer bl480c2 minpoll 3 maxpoll 4 iburst server 10.208.0.1 iburst server 10.0.0.1 server 10.202.1.1 I just restarted that on both ends (adjusting peer accordingly) and will see how that settles-in. thanks, rick jones -- oxymoron n, commuter in a gas-guzzling luxury SUV with an American flag these opinions are mine, all mine; HP might not want them anyway... :) feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH... ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] time delta between clients
Danny Mayer <[EMAIL PROTECTED]> wrote: > Don't do that. You need at *least* 4 servers listed here. Two is very > bad since you have very few ways of telling which clock is better. peer > is useful for comparing how other systems are doing but it will > sometimes discipline your system clock if nothing better is available. > You should use iburst on all lines to speed up initial convergence to a > stable state. OK, I will see about doing that on the 2nd. > If this is one of your neverending testing workbenches consider > getting one of HP's clocks (or is it owned by Agilent now?). Even > better, a cesium clock! The clocks went to Agilent, whom I believe sold that part of the business to another entity. rick jones -- No need to believe in either side, or any side. There is no cause. There's only yourself. The belief is in your own precision. - Jobert these opinions are mine, all mine; HP might not want them anyway... :) feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH... ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] time delta between clients
Tom Smith <[EMAIL PROTECTED]> wrote: > Well, first I missed it if Rick said he was exclusively concerned > about UNIX hosts. I don't think I said one way or the other. While "netperf" means never turning-ones-nose-up at any OS, I think it would be safe to say that various flavors of *nix would be the 99% solutuion here. rick jones -- Process shall set you free from the need for rational thought. these opinions are mine, all mine; HP might not want them anyway... :) feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH... ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] time delta between clients
Danny Mayer <[EMAIL PROTECTED]> wrote: > While Rick may be a relative newbie to NTP he has had years of > conducting performance analysis of applications and systems. His > performance testing of BIND9 is probably *the* seminal reference on > DNS testing. Now _that_ is scary to read :) rick jones -- portable adj, code that compiles under more than one compiler these opinions are mine, all mine; HP might not want them anyway... :) feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH... ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] time delta between clients
Ulrich Windl <[EMAIL PROTECTED]> wrote: > [EMAIL PROTECTED] (Kevin Oberman) writes: > [...] > > Netperf is not really the best way to go. The appropriate tool for > > one-way latency is OWAMP. http://e2epi.internet2.edu/owamp/ > I think you missed the point: AFAIK, Rick is the author of netperf ;-) Shhhh! It's a secret!-) rick jones about to hit-up "management" for aproval to buy a GPS-18 for some experiments, unless someone knows of a better device... -- The glass is neither half-empty nor half-full. The glass has a leak. The real question is "Can it be patched?" these opinions are mine, all mine; HP might not want them anyway... :) feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH... ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] ntpd and network sockets
Harlan Stenn <[EMAIL PROTECTED]> wrote: > We're trying to nail down some better behavior for ntpd and network > sockets. > Please visit http://support.ntp.org/bin/view/Dev/NtpdAndNetworkSockets In the legacy section, I presume where it says wildcard port it really mean to say wildcard IP (INADDR_ANY)? (And I presume at some point if not already, its equivalent for IPv6 :) The second paragraph of the legacy section - those interfaces with colons in their names are IIRC "logical" interfaces and not virtual interfaces (vlans). In HP-UXspeak at least the two are different (HP-UX could be added to that list along with Solaris and Linux). Not sure what folks think a "large" number of sockets might be, but unless it is in the three or four digits it isn't IMO large :) In Security Issues, open-read-drop, it might be good to explicitly mention SO_REUSEADDR and/or SO_REUSEPORT and how they may or may not apply. Is there really much point in actually recving datagrams on such sockets? Could just as easily set the SO_RCVBUF to something "really small" and then blythly ignore the socket entirely. Yes, it means that the stacks "socket buffer overflow" stat will increase I suppose... WRT query-on, seems that a name/ip, and a desired address family - AF_INET, AF_INET6 or AF_UNSPEC would be good. Those are things one would be passing to getaddrinfo() to flesh things out before calling bind() on the socket. If the source port isn't required to be 123 then add-in a port number. WRT query-on, last query-on wins. Otherwise you have to extend to rules to select which query-on when... WRT listen-on, "*" wouldn't specify address family. If instead it parsed 0 or 0.0.0.0 for IPv4 wildcard, or text "INADDR_ANY" or ::0 for IPv6 wildcard or whatever its macro is then it would be implicit. I don't think you can take both interface names and DNS names as arguments because it will not be possible to distinguish one from the other. You could prioritize one over the other - a strawman would be to match the string against interface names first before calling getaddrinfo(). The other complication/opportunity from taking DNS names is the getaddrinfo() call can return multiple IP's for a single name. Strawman there is to listen-on all the IP's returned by getaddrinfo() for a given name. If there is listen-on that means process and drop-on that means readdrop (or opensock and no read) then ntpd doesn't have to care about finding any other IP's on the system, they would be implictly "ignored" Thus IIRC there would no longer be any need/call for ntpd to know how to enumerate all the IP's on a system and/or check that periodically. Unless, of course, the wildcard IP meant that it should open a socket for each IP it finds rather than simply opening one socket bound to the wildcard address. FWIW I'd go with last wins, and process the config file as the command line is processed. Then, any command-line args after a config file arg can override the config file, and the config file can override a previous command-line. But then I'm probably not writing the code, just tossing things in from the peanut gallery. WRT "What about the wildcard socket" - in networking speak, there isn't really a wildcard socket, there can be a socket bound to a wildcard address :) One thing about a socket bound to a wildcard address is that it will pick-up traffic from interfaces enabled after ntpd has been started, without ntpd having to periodically scan for new IP's on the system (and possibly miss one that was only around for less than ntpd's rescan interval). rick jones -- web2.0 n, the dot.com reunion tour... these opinions are mine, all mine; HP might not want them anyway... :) feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH... ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] ntpd and network sockets
Harlan Stenn <[EMAIL PROTECTED]> wrote: > Rick, > OK with you if I incorporate the stuff in your response on > http://support.ntp.org/bin/view/Dev/NtpdAndNetworkSockets > ? I'll either clarify things per your comments or add your comments in. Fine by me. rick jones -- oxymoron n, Hummer H2 with California Save Our Coasts and Oceans plates these opinions are mine, all mine; HP might not want them anyway... :) feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH... ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] ntpd and network sockets
ocess the config file as the command > > line is processed. Then, any command-line args after a config file > > arg can override the config file, and the config file can override a > > previous command-line. But then I'm probably not writing the code, > > just tossing things in from the peanut gallery. > > > I am troubled by that too. I didn't mean to imply I was troubled, just pointing-out how it might conceivably work if one went with last-wins. > > One thing about a socket bound to a wildcard address is that it will > > pick-up traffic from interfaces enabled after ntpd has been started, > > without ntpd having to periodically scan for new IP's on the system > > (and possibly miss one that was only around for less than ntpd's > > rescan interval). I was wrong when I first said this - there will still be a window where a new IP can be brought-up on the system, and some other process can bind port 123 to that IP before ntpd can get there or traffic to arrive. Even if ntpd has a socket bound to the wildcard IP. rick jones -- The glass is neither half-empty nor half-full. The glass has a leak. The real question is "Can it be patched?" these opinions are mine, all mine; HP might not want them anyway... :) feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH... ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] ntpd and network sockets
> > I suspect we are thinking of different buffers. I was talking > > about the socket buffer - aka SO_RCVBUF - overflowing if ntpd > > simply bound a socket and never read from it. I wasn't thinking > > about a buffer overflow in the ntpd itself. Just trying to see if > > ntpd could avoid even doing the partial read of the datagram(s) on > > the socket. > Sorry, I missed that. Maybe you know better than me but I would not > expect the socket buffer to allow overflow or there would be major > problems with all O/S's since anyone can mount an attack to overflow > that buffer. I don't know the internals of most IP stacks. I think you and I are thinking of different sorts of overflows. In the case of the SO_RCVBUF and a "socket buffer overflow" all that is is a datagram arriving, and UDP looking to queue it to the SO_RCVBUF and noting there isn't enough space to put it there. UDP will then simply drop the arriving datagram and increment a counter somewhere in the stats. It is not a buffer overflow a la moving too many bytes and overwriting something. > > I was wrong when I first said this - there will still be a window > > where a new IP can be brought-up on the system, and some other > > process can bind port 123 to that IP before ntpd can get there or > > traffic to arrive. Even if ntpd has a socket bound to the > > wildcard IP. > Binding to a wildcard address does not prevent another process > binding to a different IP address that ntpd is not bound. At least I > don't believe so. We may be in semi-violent agreement there. I am just mentioning it as part of pointing-out that there are no guarantees that ntpd can preclude other normally priviledged processes from potentially receving traffic bound for port 123 and some IP address. rick jones -- denial, anger, bargaining, depression, acceptance, rebirth... where do you want to be today? these opinions are mine, all mine; HP might not want them anyway... :) feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH... ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] oscillations in ntp clock synchronization
Unruh <[EMAIL PROTECTED]> wrote: > www.theory.physics.ubc.ca/chrony/chrony.html Which reads in part: This seems to imply that the outbound ntp packets take slightly longer than the inbound packets. Which seems rather strange indeed. Typically, an application calls "send" and it goes down the stack to be queued to the NIC. If there is nothing else queued to the NIC, the NIC is to be told "Hey! There be traffic here!" and the NIC should DMA it from the host and transmit it onto the network. Now, the NIC might not generate a transmit completion interrupt right away... but the packet should be on its way. Although... if there _is_ traffic already queued to the NIC, this packet will be taked to the end of the list and the "end index" is supposed to be updated so the NIC knows to keep going. I suppose if the NIC didn't grab that index again until after a transmit completion interrupt, and transmit completion interrupts were delayed... or I suppose just good old fashioned queuing delay could be involved if there is other traffic... On the other hand, recv might easily take longer - at least for GbE NICs and their drivers the drivers often set the interrupt settings to favor bulk throughput over low latency and a packet can arrive at the NIC, be DMA'd into the host, and the NIC _not_ tell the host right away, but wait for a while until either a timer on the NIC expires or more traffic arrives. This shows-up as poor netperf TCP_RR behaviour on a number of NICs and their drivers. rick jones -- oxymoron n, Hummer H2 with California Save Our Coasts and Oceans plates these opinions are mine, all mine; HP might not want them anyway... :) feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH... ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] very slow convergence of ntp to correct time.
Eric <[EMAIL PROTECTED]> wrote: > Then there is the MAC cache in your switches, which generally purge > after 1-5 minutes. This can often be adjusted higher, but that can > sometimes cause issues for others when they are reconfiguring part > of the network. I suppose if STP gets involved, but just on its own, the forwarding table in a switch being aged should only mean that the next frame to that MAC will go out all (enabled) ports on the switch until that MAC is seen again as a source. That shouldn't affect timing really. rick jones -- a wide gulf separates "what if" from "if only" these opinions are mine, all mine; HP might not want them anyway... :) feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH... ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] very slow convergence of ntp to correct time.
Eric <[EMAIL PROTECTED]> wrote: > You are probably right about the MAC cache miss not affecting > timing. You are the resident switch guru here. Scary thought :) > Of course, different manufacturers may have different methods of > detecting the cache miss and recovering from that, so it would be > hard to eliminate that effect from consideration entirely. It's the > smallest effect of all the ones I've dealt with. Just to be certain, you are talking about MAC's being aged out of a switch's forwarding tables right? I interpreted it that way based on the previous text discussing ARP caches. rick jones -- The glass is neither half-empty nor half-full. The glass has a leak. The real question is "Can it be patched?" these opinions are mine, all mine; HP might not want them anyway... :) feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH... ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] very slow convergence of ntp to correct time.
Brian Utterback <[EMAIL PROTECTED]> wrote: > Rick Jones wrote: > > Eric <[EMAIL PROTECTED]> wrote: > >> Then there is the MAC cache in your switches, which generally > >> purge after 1-5 minutes. This can often be adjusted higher, but > >> that can sometimes cause issues for others when they are > >> reconfiguring part of the network. > > > > I suppose if STP gets involved, but just on its own, the > > forwarding table in a switch being aged should only mean that the > > next frame to that MAC will go out all (enabled) ports on the > > switch until that MAC is seen again as a source. That shouldn't > > affect timing really. > > > > rick jones > There is some blurring of device type going on. The problem is not > which port to send to, but rather which MAC address to send to. This > is more of a problem with routers than switches, but with VLANS and > whatever these days, the device uin question might be both. I interpreted Eric's text differently. Since a device acting as a "switch" is only operating at layer 2, it doesn't do any lookups on what the destination MAC should be. Indeed, a device operating as a "router" could be doing an ARP lookup, but I ass-u-me-d that was covered by a prior paragraph of Eric's. > In any case, if the needed MAC is not available, there has to be an > ARP request and response before the packet can be sent, but this > delay is not evident in the return trip for the NTP response packet, > introducing an asymmetric delay, the worst thing that happen to > NTP. > I reported this problem many years ago and suggested using burst at > that time, but thought that it would be overkill and asked for a way > to tune it to a fewer number of packets in the burst. Dave was > reticent and I was newer to the project then and didn't want to push > it. Perhaps it is time. I'll probably quite easily display my profound NTP ignorance here :) But if there is assymetric delay stemming from an ARP resolution, won't it affect all the packets in the burst? Unless the tranmission time of the burst getting out of NTP is >> the ARP resolution time, the entire burst is going to be blocked waiting on the ARP resolution. Now, if this burst was really "send a couple; wait for a reply; send a couple more" then one might ass-u-me (I do love that spelling :) that the "couple more" didn't have ARP-induced assymetry. rick jones I probably tweak on "switch" vs "router" much the same way an NTP person tweaks on "accuracy" vs "precision" :) -- web2.0 n, the dot.com reunion tour... these opinions are mine, all mine; HP might not want them anyway... :) feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH... ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] very slow convergence of ntp to correct time.
> The "burst" is sent at 1 second intervals. There should be lots of > time for all the switches and routers to get their act in gear. Ah, well chalk that one up to me being picky (perhaps even wrong :) about network terminology then :) I always think of a burst as a series of packets sent back-to-back. rick jones -- No need to believe in either side, or any side. There is no cause. There's only yourself. The belief is in your own precision. - Jobert these opinions are mine, all mine; HP might not want them anyway... :) feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH... ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] time delta between clients
Rick Jones <[EMAIL PROTECTED]> wrote: > I suppose I could also try to see if I can get the powers that be to > spring for a GPS18 and see if I can indeed get signal in the machine > room(s) of interest. Before I did that I borrowed a hand-held GPS receiver (Magellan "Crossover" IIRC) from someone. Admittedly it will not be a match for the GPS18, and may have a "weaker" receiver. But given that _all_ signal went poof when I entered the building, I suspect the GPS18, unless it is much more sensitive, would have lost all signal too :( rick jones -- denial, anger, bargaining, depression, acceptance, rebirth... where do you want to be today? these opinions are mine, all mine; HP might not want them anyway... :) feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH... ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] time delta between clients
Steve Kostecke <[EMAIL PROTECTED]> wrote: > My GPS18LVC works through a standard US residential roof. But you > probably have lots of metal in the way. So ... YMWV Yep - basic concrete, steel and glass US office building - in this case a "standard" HP "BigFoot" building. rick jones -- oxymoron n, Hummer H2 with California Save Our Coasts and Oceans plates these opinions are mine, all mine; HP might not want them anyway... :) feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH... ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] time delta between clients
David J Taylor <[EMAIL PROTECTED]> wrote: > The GPS18 is not a very sensitive receiver - nothing like as good as > the more recent SiRFstarIII receivers (e.g. Garmin GPSmap 60CSx). > It does need an outdoor location, or one with little RF attenuation. Hmm, I wonder if they will ever merge the two :) rick jones -- portable adj, code that compiles under more than one compiler these opinions are mine, all mine; HP might not want them anyway... :) feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH... ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] NTPD on bond0:0
Danny Mayer <[EMAIL PROTECTED]> wrote: > Is there something special about bond0 or is it just another NIC? What > are you expecting to do when you use -L? Just for the archives - a "bond" interface in Linux is one or more physical interfaces configured into a "bond" by the bonding driver. On other platforms that might be called "trunking" or port aggregation etc. The "transport" (IP and above) sees just the one interface (eg bond0) which then handles all the nitty gritty details of link-failover and/or load balancing among the physical interfaces in the bond. rick jones -- The computing industry isn't as much a game of "Follow The Leader" as it is one of "Ring Around the Rosy" or perhaps "Duck Duck Goose." - Rick Jones these opinions are mine, all mine; HP might not want them anyway... :) feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH... ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] 1 Machine, 2 NICs, 2 Instances of ntpd; Possible?
Maarten Wiltink <[EMAIL PROTECTED]> wrote: > I'm no IP wizard, but isn't there a SO_REUSEPORT flag or something > like that? It still (IIRC) lacks sufficient ubiquity and the semantics on the various platforms may not match what is desired. rick jones -- denial, anger, bargaining, depression, acceptance, rebirth... where do you want to be today? these opinions are mine, all mine; HP might not want them anyway... :) feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH... ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] drift value very large and very unstable
> >File System Standard? What's that?? Unix tends to put things in > >more or less standard places but it's not guaranteed that system > >A's file system or directory naming will be compatible with system > >B. Once you > that is why there is a proposed file system standard. But there are so many from which to choose :) SYSV, probably one from Posix/Xopen, Linux Standard Base (?) etc etc :) rick jones -- a wide gulf separates "what if" from "if only" these opinions are mine, all mine; HP might not want them anyway... :) feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH... ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Frequency Error on Sun4v
Brian Utterback <[EMAIL PROTECTED]> wrote: > Do not even think about using NTP on a T1000, T2000, or T5120 until > you have the latest firmware patch installed (nah-nah, wasn't > hardware OR software. Or maybe both?). There is a bug in all three > that causes the firmware to report an incorrect clock frequency to > the kernel on boot up. Interestingly, the bug in the T1000 and T2000 > is different from the bug in the T5120. See my blog post at > http://blogs.sun.com/blu/entry/spread_spectrum_emi_and_the for an > explanation of the T5120 issue. Interesting write-up. Not sure I understand all of it of course, but interesting regardless. Since no good deed goes unpunished and since I have an insatiable curiousity I will ask :) *) is that just the T5120 or is it more generally the T5X20? *) is the T5X40 affected sincerely, rick jones -- oxymoron n, commuter in a gas-guzzling luxury SUV with an American flag these opinions are mine, all mine; HP might not want them anyway... :) feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH... ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Sunfire X2100 and FreeBSD
jlevine <[EMAIL PROTECTED]> wrote: >I am trying to use a Sunfire X2100 system as a time server using > FreeBSD 6.2. The system clock steps by tens of microseconds every few > minutes with no time software running. I have not seen this on other > non-Sun systems with the identical version of FreeBSD. Is this a > feature of the Sun hardware? If yes, can it be turned off? Otherwise > the time steps will confuse the synchronization process. IIRC the x2100 is an Opteron-based system. Is the one you have using dual-core Opterons? ISTR some issues with the TSC (?) in those things when part of the chip would slow-down, but not other parts and that it confused things wrt time. rick jones -- Process shall set you free from the need for rational thought. these opinions are mine, all mine; HP might not want them anyway... :) feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH... ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] bitsy.mit.edu retired?
Richard B. Gilbert <[EMAIL PROTECTED]> wrote: > David L. Mills wrote: > > Bitsy.mit.edu is alive, but not running NTP for whatever reason. > > > > Bitsy.udel.edu was among the first public timetellers in the > > world, including clepsydra.decwrl.com and fuzzball dcn1.arpa > > (128.4.1.1). They first chimed circa 1984. Of the three, only > > 128.4.1.1 has public chime, but now a Pentium called > > rackety.udel.edu. > Ten years is about three lifetimes in computer years. You can keep > an old box running for longer but many people don't run them even > that long! > Sooner or later you get to the point where the poor old thing can't > run something you want to run; the applications you need, need more > RAM than the box will hold or need more CPU cycles than the box can > do. Then it's a paper weight or a door stop! > Bitsy may have found a place in the Computer History Museum. Or > maybe a place in a dumpster. Specifics of systems named bitsy or with an IP of 128.4.1.1 asside, since a system's hostname and IP can be passed-on from one generation of hardware to another, that a name/IP has been active for N units of time cannot really be used as an accurate estimate of the age of the hardware behind it :) I've had several systems over a number of years called tardy.cup.hp.com... rick jones -- portable adj, code that compiles under more than one compiler these opinions are mine, all mine; HP might not want them anyway... :) feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH... ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Source address in response not the same as target address in request
Danny Mayer <[EMAIL PROTECTED]> wrote: > The general answer is no. It binds to all addresses but use of the > -L option will mean that it ignores anything not received on :0 > interfaces which is what I think you are saying. An enhancement that > I have worked on will allow you to specify the addresses to listen > on and to send on. It's not ready yet. If it simply sends via the socket on which the query was recieved, having bound that socket to a given IP should result in that IP being used as the source IP of the response. Perhaps there is a reason to send via another socket, but as I'm typing I cannot think of it. rick jones -- web2.0 n, the dot.com reunion tour... these opinions are mine, all mine; HP might not want them anyway... :) feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH... ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Source address in response not the same as target address in request
Danny Mayer <[EMAIL PROTECTED]> wrote: > Rick Jones wrote: > > If it simply sends via the socket on which the query was recieved, > > having bound that socket to a given IP should result in that IP being > > used as the source IP of the response. > > > > Perhaps there is a reason to send via another socket, but as I'm > > typing I cannot think of it. > > > > rick jones > NTP always replies on the same interface with the same IP address. It > should never reply with a different IP address as the receiving end > would drop it as invalid. Did you mean to say "replies on the same socket?" To a networking guy "socket" is distinct from interface (eg NIC) and from the first hop routing decision to be made by the stack. S, if NTP is replying on the same socket, and it _isn't_ the/a wildcard socket, then the source IP's should already be correct and the mystery would seem to deepen. Might be a good idea for the OP to get a system call trace of NTP, preferably including the creation and binding of the sockets and then the receipt and sending of a response. rick jones -- oxymoron n, Hummer H2 with California Save Our Coasts and Oceans plates these opinions are mine, all mine; HP might not want them anyway... :) feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH... ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] "ntpd -q" is slow compared to ntpdate
Garrett Wollman <[EMAIL PROTECTED]> wrote: > If you care about having reasonably correct timestamps in your logs, > you need to get a reasonably correct time established at boot time > before anything important starts. Would it be fair to say that "today" anyway, having the time be within a (large fraction of a) second (IIRC that is the precision of most system logs still today?) be sufficient? > Once the system time is validated, the rest of the system may be > permitted to start, possibly including a long-running ntpd. You > don't want that initial step happening after anything else has been > started, and the only way to convey this information to traditional > /etc/rc scripts is to have the program exit. And people (not just performance geeks :) are indeed concerned about the speed at which a system is up and running. Adding minutes to that is right out. Where in the realm of added seconds things are is a very fertile area for discussion. > That is how most systems use ntpdate(1) now, and that is why > distributors are so resistant to change (the well-known problems of > ntpdate notwithstanding). > What they probably actually want is a flag that says "delay > daemonizing until the first time the clock is set". But still want things to happen "quickly" for some relative definition of quickly that probably does not encompass the length of time most (and I do mean the term affectionately) time geeks would wait. rick jones -- Process shall set you free from the need for rational thought. these opinions are mine, all mine; HP might not want them anyway... :) feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH... ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] "ntpd -q" is slow compared to ntpdate
Richard B. Gilbert <[EMAIL PROTECTED]> wrote: > If you must shut down to save electricity or something, you'll just > have to start the machines a few minutes before they need to have > the correct time. While I'm sure there are lots of cases where the start time may be known well enough in advance, I don't think that can be relied upon. Yes, there is a counter argument that "if they need such quick reaction they should have a warm standby" but "green" issues may often trump that. rick jones -- a wide gulf separates "what if" from "if only" these opinions are mine, all mine; HP might not want them anyway... :) feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH... ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] "ntpd -q" is slow compared to ntpdate
Mohit Aron <[EMAIL PROTECTED]> wrote: > On Tue, Oct 14, 2008 at 4:19 PM, Harlan Stenn <[EMAIL PROTECTED]> wrote: > > See http://support.ntp.org/bin/view/Dev/DeprecatingNtpdate . > Thanks. It seems 'sntp -r ' is the appropriate replacement > for ntpdate. I'm sure I'm about to soil my shoe in what may be an old and well-trodden pile, but if sntp can set the time as well and as quickly as ntpdate, why a new program rather than fixes/enhancements to the old one? Command-name inertia can be rather strong. Eg nslookup vs dig or host. rick jones -- Wisdom Teeth are impacted, people are affected by the effects of events. these opinions are mine, all mine; HP might not want them anyway... :) feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH... ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] "ntpd -q" is slow compared to ntpdate
Harlan Stenn <[EMAIL PROTECTED]> wrote: > It seems to me a topic related to initially getting the time set on > a box is the ability to determine the 'synchronization status' of > ntpd. > Toward that end, http://support.ntp.org/bin/view/Dev/NtpdsSyncStatus > has been created. > I'd appreciate folks taking a look at that page, commenting and > discussing the issues. The definition of 'correct' time How about the following: * The decoded system status bits contain sync_ntp * (obsolete) ntpd is in state S_SYNC (which Dave is renaming to EVNT_SYNC) * any slew adjustment in-process is under X (where X is configurable) * Do we care about the root dispersion? If this is in the context of a quick, initial time setting I would wonder if I (for some number of I's) "really" care if none of the time sources I ask aren't yet synced? I'm wondering if being set to a time close to that of an unsynced server above me in the tree is better than no time setting at all. rick jones -- Wisdom Teeth are impacted, people are affected by the effects of events. these opinions are mine, all mine; HP might not want them anyway... :) feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH... ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Slow convergence of NTP with GPS/PPS
Hal Murray <[EMAIL PROTECTED]> wrote: > Actually, it's probably low. > If it was fast, you would be overclocking, maybe not by much, but > there is no longer any guarantee that your CPU will work. [If it > would work reliabily at x% faster, all the manufacturers would bump > things up a bit.] Maybe... if they could also bump-up the price a bit. :) And then there is binning... rick jones -- denial, anger, bargaining, depression, acceptance, rebirth... where do you want to be today? these opinions are mine, all mine; HP might not want them anyway... :) feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH... ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Slow convergence of NTP with GPS/PPS
Hal Murray <[EMAIL PROTECTED]> wrote: > NTP temperature compensation > Mark Martinec, 2001-01-08 > http://www.ijs.si/time/temp-compensation/ > A wonderful read. I wonder how closely Mark's results could be replicated using some (set of) temperature readings from components already in the system rather than adding another temp probe? Stuff like CPU temps and other intra-system components. I'm not sure they have nearly the same accuracy and resolution though :( rick jones -- No need to believe in either side, or any side. There is no cause. There's only yourself. The belief is in your own precision. - Jobert these opinions are mine, all mine; HP might not want them anyway... :) feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH... ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Slow convergence of NTP with GPS/PPS
Unruh <[EMAIL PROTECTED]> wrote: > ( assuming that the network noise is at the 100us type level). That feels like a rather large assumption given the target environment does not seem to allow the system to be synced to be up long-term. rick jones -- Wisdom Teeth are impacted, people are affected by the effects of events. these opinions are mine, all mine; HP might not want them anyway... :) feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH... ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Slow convergence of NTP with GPS/PPS
Hal Murray <[EMAIL PROTECTED]> wrote: > >I wonder how closely Mark's results could be replicated using some > >(set of) temperature readings from components already in the system > >rather than adding another temp probe? Stuff like CPU temps and other > >intra-system components. I'm not sure they have nearly the same > >accuracy and resolution though :( > One system I have reads temperature in quanta of 1C. > (There might be ways to get better. I haven't pushed all that hard.) > That's not very good on this scale. > I played around in this area a while ago. I didn't get good results > until I glued the temperature probe to the xtal. That one reads > to 0.1F, Sigh. I was hoping there might be a middle ground using stuff already present in the system. rick jones -- The computing industry isn't as much a game of "Follow The Leader" as it is one of "Ring Around the Rosy" or perhaps "Duck Duck Goose." - Rick Jones these opinions are mine, all mine; HP might not want them anyway... :) feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH... ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Slow convergence of NTP with GPS/PPS
Hal Murray <[EMAIL PROTECTED]> wrote: > My DSL line has 100 ms of queueing delays. That "feels" about right if one assumes the goal is to enable link-rate on a transcontinental (US at least) path. rick jones http://www.netperf.org/ -- Wisdom Teeth are impacted, people are affected by the effects of events. these opinions are mine, all mine; HP might not want them anyway... :) feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH... ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Preffered OS for a GPS based stratum 1
Kevin Oberman <[EMAIL PROTECTED]> wrote: > Seconded. FreeBSD has taken ntp and timing as a priority for a very > long time. I know that back in the days when BSD was still being > developed at Berkeley, they counted the instructions used by the PPS > kernel code and then used the clock frequency to correct the time > for that delay. I'd have thought that it wasn't the instruction count that mattered but the cycle count? Admittedly, instructions/frequency is closer than nothing but given that a single cache miss is O(100) instructions... so, snap CR16 (PA-RISC interval counter) or its equivalent (assuming there is one and reading it isn't too nasty) on entry and exit. rick jones -- The computing industry isn't as much a game of "Follow The Leader" as it is one of "Ring Around the Rosy" or perhaps "Duck Duck Goose." - Rick Jones these opinions are mine, all mine; HP might not want them anyway... :) feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH... ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Sub-millisecond NTP synchronization for local network
Jeremy Leibs <[EMAIL PROTECTED]> wrote: > Is there possibly a way of configuring the maximum acceptable > latency of a packet? That is, as long as you know that for some > fraction of the day (when the system is not under load) your latency > is going to be less than some threshold, say, 2 ms, configuring the > system to just throw away all packets with latency greater than 2 > ms? What precisely do you mean by "the system" in this context? The TCP/IP stack running on the system on which NTP is running, or in NTP itself? rick jones -- a wide gulf separates "what if" from "if only" these opinions are mine, all mine; HP might not want them anyway... :) feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH... ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Sub-millisecond NTP synchronization for local network
Jeremy Leibs <[EMAIL PROTECTED]> wrote: > On Sat, Dec 6, 2008 at 3:40 PM, Rick Jones <[EMAIL PROTECTED]> wrote: > > Jeremy Leibs <[EMAIL PROTECTED]> wrote: > > > Is there possibly a way of configuring the maximum acceptable > > > latency of a packet? That is, as long as you know that for some > > > fraction of the day (when the system is not under load) your latency > > > is going to be less than some threshold, say, 2 ms, configuring the > > > system to just throw away all packets with latency greater than 2 > > > ms? > > > > What precisely do you mean by "the system" in this context? The > > TCP/IP stack running on the system on which NTP is running, or in NTP > > itself? > > > By system under load, I was refering to the TCP/IP stack running on > the system on which NTP is running. In particular, the available > bandwidth over the wireless link. Unless this is a packet still queued in "the system" for the system to know the packet is 2ms old the system must have a clock reasonably well synchronized with the sender no? SCTP has some idea of discarding old packets as uninteresting - I am not sure if they assume synchronized clocks or if they have done something else. rick jones -- oxymoron n, Hummer H2 with California Save Our Coasts and Oceans plates these opinions are mine, all mine; HP might not want them anyway... :) feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH... ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Sub-millisecond NTP synchronization for local network
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 chips. > I'd expect gigabit cards/chips will be more likely to have that > feature than old "slow" 100 megabit chips. Virtually all the GbE NICs I've ever encountered have such a feature. And literally all the 10 GbE NCIs I've encountered have it. You can see such behaviour in a NIC/driver which does it "badly" (IMO) with a netperf TCP_RR test. For example if you only ever see 8000-12000 single-byte transactions per second with a "contemporary" system. A while back I did a writeup on the tradeoff the NIC/driver strappings were making. A version of it can be found at: ftp://ftp.cup.hp.com/dist/networking/briefs/nic_latency_vs_tput.txt Not all NIC/driver combinations do it as badly as others. I've encountered at least one, perhaps two 10GbE NICs which seem to at least pass the TCP_RR sniff test and get both good TCP_RR performance and good CPU util on TCP_STREAM with defaults. rick jones -- oxymoron n, commuter in a gas-guzzling luxury SUV with an American flag these opinions are mine, all mine; HP might not want them anyway... :) feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH... ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Sub-millisecond NTP synchronization for local network
Kevin Oberman <[EMAIL PROTECTED]> wrote: > Before this gets too far off track, standards compliant Ethernet > uses frames of 1500 bytes, regardless of speed. This is true for 10M > or 10G Ethernet. > Most modern cards have support for jumbo frames. These are, by > definition, non-standard, and are available only when specifically > configured. Unless you turn them on, frames are 1500 data bytes plus > framing of up to 22 bytes. When jumbos are enabled, the size > currently recommended by the US federal Joint Engineering Team is > 9000 bytes to allow the transmission of 8K of actual user data when > allowing for framing, VLAN and MPLS tags and such with a comfortable > margin over that. (Most modern systems page memory in 8K chunks, so > this optimizes performance.) I like JumboFrames. I think they are quite useful. Still... Back in the 1990's we were pleased that the MTU of FDDI was 4500ish bytes because it was larger than the typical page size. Then at least up in the server space the pages becamse variably sized and rather larger. Bye bye page flipping. Today x86 systems might use an 8K page size, but they also have increasingly used support for huge pages. It might be possible to page flip today with a 9000 byte MTU, but don't expect it to last much longer than it did with FDDI. "All" the 10G NICs and I suspect a decent number of the 1G NICs support TSO or TCP/Transport Segmentation Offload. For the sender at least that can be considered a "poor man's jumbo frame." Many (most?) of the curent 10G NICs also support LRO or Large Receive Offload. Together they do a decent if not complete job of getting the bulk transfer performance gains of Jumbo Frames. There is of course some additional benefit of using them on top of Jumbo Frames although it is in the realm of diminishing returns. rick jones -- The computing industry isn't as much a game of "Follow The Leader" as it is one of "Ring Around the Rosy" or perhaps "Duck Duck Goose." - Rick Jones these opinions are mine, all mine; HP might not want them anyway... :) feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH... ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Sub-millisecond NTP synchronization for local network
Ryan Malayter <[EMAIL PROTECTED]> wrote: > On Mon, Dec 8, 2008 at 11:57 AM, Rick Jones <[EMAIL PROTECTED]> wrote: > > "All" the 10G NICs and I suspect a decent number of the 1G NICs > > support TSO or TCP/Transport Segmentation Offload. For the sender at > > least that can be considered a "poor man's jumbo frame." Many (most?) > > of the curent 10G NICs also support LRO or Large Receive Offload. > I don't think you'll ever see baseline support for such features on > Linux. The kernel guys fundamentally disagree with TCP offload: > http://www.linuxfoundation.org/en/Net:TOE I believe you are confusing TSO and LRO, which are stateless offloads (TCP connection state) with TOE (TCP Offload Engine) which is a statefull offload - TCP connection state kept in the card rather than the host stack. It is indeed true there is a considerable and likely to continue immune response in "netdev" to TOE, but they are quite pleased with stateless offloads like TSO and LRO. rick jones -- a wide gulf separates "what if" from "if only" these opinions are mine, all mine; HP might not want them anyway... :) feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH... ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Sub-millisecond NTP synchronization for local network
Terje Mathisen <[EMAIL PROTECTED]> wrote: > Rick Jones wrote: > > A while back I did a writeup on the tradeoff the NIC/driver > > strappings were making. A version of it can be found at: > > > > ftp://ftp.cup.hp.com/dist/networking/briefs/nic_latency_vs_tput.txt > > > Nice work! Thanks - I really should look to revisit the question with more contemprary driver revisions and perhaps with some 10G NICs. Cycles cycles everywhere, but not a one is free :( rick jones > - <[EMAIL PROTECTED]> > "almost all programming can be viewed as an exercise in caching" Which in and of itself is an excercise in latency hiding?-) -- Process shall set you free from the need for rational thought. these opinions are mine, all mine; HP might not want them anyway... :) feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH... ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Sub-millisecond NTP synchronization for local network
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 certainly seem to be stateful from what > I've read (the NIC deals with headers, sequence numbers, etc., and > therefore must have some knowledge of the current connection state). Segmentation offload works simply by "cloning" the TCP header, and updating the sequence number. That can be done by "idiot savant" hardware that has no idea about the remote receive window, the current congestion window etc etc. It is simply told "here is an N byte TCP ubersegment, and the MSS is M - respond accordingly" My impression is that Dave Miller and the rest of the netdev folks consider that a stateless offload. > So I think, perhaps, that "stateless" vs. "stateful" isn't the > deciding factor on Linux support for networking offload > technologies. It seems the kernel guys will support NIC offload > techniques that are limited in scope and don't affect things like > congestion control, instrumentation, security, etc. But they will > not support full-stack replacement (which makes a lot of sense to > me). Most of the TCP stack in Linux will always be software-based. One of the biggies is bypassing all their firewall work - they hate that idea :) > In any case, I agree with the kernel guys that many-core processors > will ultimately render such techniques pointless. When you have ample > CPU resources (and bus bandwidth), hardware assistance from the NIC > just adds a layer of complexity that isn't necessary. Right now, > software-only stacks have no trouble keeping up with GbE using far > less than a single modern core (even on Windows). 10GbE might change > that, but as the kernel guys argue, it will be a temporary situation, > so it's not worth a lot of effort to write NIC offload code which will > have to be supported forever. With TSO on the sending side and LRO on the receiving side it is possible to get to 10GbE link-rate with a single connection and not great gobs of CPU horsepower. > In any case, none of this really applies to NTP, does it? Short UDP > packets, no fragmentation, no TCP checksums. Won't NTP packets > always be handled by the software-only stack on most supported > platforms (except maybe Windows with a full TOE card)? I'm not sure where the "checksum in host" vs "checksum on NIC" cross-over is for UDP in various stacks, but many NICs can and do perform CKO on UDP datagrams in addition to TCP. Heck, the HP-PB (aka NIC) FDDI card of the mid 1990's did that. It could also header-data split up through NFS on the way in. All with magic "if this offset is this value" tables. I'm not remembering how we got here - it may have been related to mention of interrupt coalescing and its possible effect on packet latency. rick jones -- The glass is neither half-empty nor half-full. The glass has a leak. The real question is "Can it be patched?" these opinions are mine, all mine; HP might not want them anyway... :) feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH... ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] .1 Microsecond Synchronization
ScottyG wrote: > To do this the order in which market data was received and trades > transmitted need to be maintained. I do know from their current log > files that 1 ms is not fine enough for this and that on occasion .1 > ms is not good enough. They currently are using a feature of the > processors that seems to return clock tick on the microprocessor > (Some assembly language instruction). Most if not all modern CPUs have an "interval counter" or a similar rose by another name that counts at some fixed rate that may or may not be a fixed frequency to the clock rate of the processor. In PA-RISC it is called "CR16" or "Control Register number 16" and is accessed via a "move from control register" instruction often executed as some inline assembly in otherwise regular "C" code. Itanium calls it the ITC (iirc) and it is accessed in a similar fashion. Other processors will be a variation on the theme. > They have an algorithm for controlling the skew that occurs using > this method. This seems to meet there needs in a single server > scenario but when going across machines this will obviously not > work. Depending on the HW and OS/application support it may not even work on a single machine with multiple processors when/if there is migration from one core to another. HP-UX on PA-RISC and Itanium will "sync-up" (although perhaps not to the rigorous standards of the NTP gurus :) the interval counters on the disparate processors, and I think Linux does the same. Which other OS/HW combinations do so I'm not sure. rick jones -- a wide gulf separates "what if" from "if only" these opinions are mine, all mine; HP might not want them anyway... :) feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH... ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] .1 Microsecond Synchronization
Unruh wrote: > 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 characters, and I suspect trades are > longer than 10 characters. I don't know that it would pack them within a 100ns interval, but interupt coalescing in GbE and higher NICs can cause frames which were otherwise spread-out on the network to appear to the host to arrive at essentially the same instant. Their separation in the eyes of the host will depend on the speed at which the host processes them after being nudged by the NIC. rick jones -- Wisdom Teeth are impacted, people are affected by the effects of events. these opinions are mine, all mine; HP might not want them anyway... :) feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH... ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] .1 Microsecond Synchronization
Rick Jones wrote: > I don't know that it would pack them within a 100ns interval, but > interupt coalescing in GbE and higher NICs can cause frames which > were otherwise spread-out on the network to appear to the host to > arrive at essentially the same instant. Their separation in the > eyes of the host will depend on the speed at which the host > processes them after being nudged by the NIC. And there can be more than one NIC in the system... rick jones -- I don't interest myself in "why." I think more often in terms of "when," sometimes "where;" always "how much." - Joubert these opinions are mine, all mine; HP might not want them anyway... :) feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH... ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] .1 Microsecond Synchronization
ScottyG wrote: > To do this the order in which market data was received and trades > transmitted need to be maintained. I do know from their current log > files that 1 ms is not fine enough for this and that on occasion .1 > ms is not good enough. In broad handwaving terms, isn't 100ns more or less a cache miss on a processor today? Yes, some are less then that some are more but O(100ns) seems about right. rick jones -- I don't interest myself in "why." I think more often in terms of "when," sometimes "where;" always "how much." - Joubert these opinions are mine, all mine; HP might not want them anyway... :) feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH... ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] .1 Microsecond Synchronization
> > 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 be able to receive it without > any requesting. For some reason, that one used to be able to dial a number to hear "At the tone, the time will be ..." springs to mind. And makes me wonder if that service still exists today. Phones have voice recognition in them today (at least some) right? It wouldn't be GPS PPS - but perhaps one could call it POTS PPTS (Pulse Per Ten Seconds). :) :) rick jones -- I don't interest myself in "why." I think more often in terms of "when," sometimes "where;" always "how much." - Joubert these opinions are mine, all mine; HP might not want them anyway... :) feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH... ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] NMEA ref.clock better than my ISP's timeserver?
David J Taylor wrote: > One suggestion might be wireless Isn't that just asking for jitter? rick jones -- oxymoron n, Hummer H2 with California Save Our Coasts and Oceans plates these opinions are mine, all mine; HP might not want them anyway... :) feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH... ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] NMEA ref.clock better than my ISP's timeserver?
David J Taylor wrote: > Rick Jones wrote: > > David J Taylor > > wrote: > >> One suggestion might be wireless > > > > Isn't that just asking for jitter? > Have you tried it? No, I'm just channeling dimm memories of what half-duplex wired Ethernet used to be like under load :) rick jones -- No need to believe in either side, or any side. There is no cause. There's only yourself. The belief is in your own precision. - Joubert these opinions are mine, all mine; HP might not want them anyway... :) feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH... ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Can or should the NTP protocol eventually serve timezone data?
John Hasler wrote: > IMHO a standardized, automated and decentralized way of distributing > changes to timezone files might be useful, though. It just should > not be part of NTP. I'm not sure it is as automated and decentralized as you might want, but there is a mechanism in place to update the "pci.ids" file mapping all the vendor, product, subvendor subproduct IDs in PCI cards to human readable text. http://pciids.sourceforge.net/ which is I believe what the "update-pciids" command under Linux (and perhaps other OSes) will query when run. rick jones -- No need to believe in either side, or any side. There is no cause. There's only yourself. The belief is in your own precision. - Joubert these opinions are mine, all mine; HP might not want them anyway... :) feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH... ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] What to do about broken IPv6 sites
Allen Kistler wrote: > For example, http://www.ntp.org. > NTP.org has a perfectly good IPv4 site, but the IPv6 site doesn't > answer to SYNs. I have no problem with other IPv6 sites, but maybe > I'll find some in the future. > Since RFC-compliant behavior is to try the IPv6 address first, I > have to timeout on every page element before switching to IPv4. > I was wondering what the options are to deal with the situation. I > don't have control of the ntp.org DNS domain (or any other broken > domains I might find). Keeping a list in iptables for special > behaviors for specific IPv6 addresses really isn't attractive. > As more sites put up IPv6 versions, I expect there to be a lot of > brokenness that won't be a high priority to fix as long as 99% of > everybody is still on IPv4. What's the most manageable way to deal > with this? I don't know about the general question, but there are likely folks in comp.protocols.time.ntp who know about the www.ntp.org site and its IPv6 status, so lets redirect the specific issue there. (I've set the Followup-to: header on this post to that end) rick jones -- I don't interest myself in "why". I think more often in terms of "when", sometimes "where"; always "how much." - Joubert these opinions are mine, all mine; HP might not want them anyway... :) feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH... ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Meinberg NTP Software--Time Accuracy
Rob wrote: > This is no longer required. You can just use pool.ntp.org or > 0.pool.ntp.org and the DNS servers for the pool will automatically > determine which servers are closest to you. Is that by geography, hop count or ICMP echo RTT? rick jones -- oxymoron n, commuter in a gas-guzzling luxury SUV with an American flag these opinions are mine, all mine; HP might not want them anyway... :) feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH... ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] If the EMI shoe was on the other foot...
Unruh wrote: > (This is like asking-- if there is a garbage strike would you want > people to put their garbage into bags and pile them up together or > not use bags and spread it out evenly on the streets. How large are the streets and how much garbage is there to be spread? rick jones -- oxymoron n, commuter in a gas-guzzling luxury SUV with an American flag these opinions are mine, all mine; HP might not want them anyway... :) feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH... ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] OT: GPS18x LVC failure
Unruh wrote: > "David J Taylor" > writes: > >"Unruh" wrote in message > >news:ttqam.47651$db2.44...@edtnps83... > >[] > >> USB only has one data line. It cannot "do" a DCD line except as > >> another bit of serial data, interleaved with all the other serial > >> data. Ie, you are not going to get any good signals for an > >> "interrupt". > >> You definitely need either a real serial port with a true > >> hardware line, or a parallel port to get true interrupts. > >Be that as it may, a GPS/PPS system working over USB provided > >better results (45 microseconds jitter) on my test PC than a 1Gb/s > >Ethernet card (110-140 microseconds jitter) on a 1Gb/s lightly > >loaded LAN talking to a stratum-1 server, so I would not say that > >USB is useless. > Actually those Gb ethernet switches seems to have some really bad > and variable latencies. My system, before they installed Gb > switches, had a consistant roundtrip of 140 usec and gave better > than 20usec jitter (with 100Mb switches). Since those new switches > were installed things have gone to hell-- variable roundtrips ( > 140usec, 300usec and up to 1 sec roundtrip) and much much worse > jitter. NOt sure where the problem is, but it sure is terrible. > Doing a plot of roundtrip vs offset it is definitely one way delay. I cannot speak to what happens in the switches, but in the NICs, I think that almost all GbE NICs have some form of interrupt coalescing/avoidance - the idea is to reduce the CPU utilization to allow higher throughput. This does nasty thing to latency, and could be somewhat variable depending on how much other traffic is flowing through the NIC. In linux-land, some variations on ethtool commands and/or modprobe parameters would be involved in diminishing if not outright disabling the interrupt coalescing. ftp://ftp.cup.hp.com/dist/networking/briefs/nic_latency_vs_tput.txt is an old writeup, but it should give the gist of it. As for things switches, when and what sort of spanning tree is done, and perhaps lifetimes for the MAC forwarding tables come to mind. rick jones -- oxymoron n, Hummer H2 with California Save Our Coasts and Oceans plates these opinions are mine, all mine; HP might not want them anyway... :) feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH... ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] OT: GPS18x LVC failure
Has anyone asked Garmin about the specs vs what they've seen? rick jones -- oxymoron n, Hummer H2 with California Save Our Coasts and Oceans plates these opinions are mine, all mine; HP might not want them anyway... :) feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH... ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] OT: GPS18x LVC failure
E-Mail Sent to this address will be added to the BlackLists wrote: > Rick Jones wrote: > > Has anyone asked Garmin about the specs vs what they've seen? > <http://www8.garmin.com/support/pdf/iop_spec.pdf> > > 3 Physical Protocols > 3.1 Serial Protocol > The Serial Protocol is based on RS-232. > The voltage characteristics are compatible with most hosts; > however, the device transmits positive voltages only, > whereas the RS-232 standard requires both positive > and negative voltages. > Also, the voltage swing between mark and space may not be >large enough to meet the strict requirements of the RS-232 >standard. > Still, the device voltage characteristics are compatible >with most hosts as long as the interface cable is wired >correctly. > I meant more along the lines of an email to a support alias or somesuch saying "we notice this discrepancy between what your specs say and what our scopes tell us" as opposed to perusing their website. rick jones has seen all too many websites with incorrect/inaccurate information in them. -- web2.0 n, the dot.com reunion tour... these opinions are mine, all mine; HP might not want them anyway... :) feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH... ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] OT: GPS18x LVC failure
Uwe Klein wrote: > With switches the problem tends to be the strategy for handling > (potentially) colliding traffic. > "Passthrough", "store-and-forward", "drop/cause resend" have > massively different transit times. > Depending on traffic density any single switch will use a mix of all > transfertypes. I don't think it is what you meant by "drop/cause resend" but something else "new" in 1 Gigabit Ethernet relative to old 10/100 is support for pause and resume (moral equivalent to xon/xoff?) flow control. rick jones -- oxymoron n, commuter in a gas-guzzling luxury SUV with an American flag these opinions are mine, all mine; HP might not want them anyway... :) feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH... ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Strange NTP problem on AMD Geode LX cards.
Unruh wrote: > Yup. That is why you have regulations. It is clear that the present > spread spectrum approach is basically an end run around the > regulations. The regs were set up based on the idea that things that > emit tend to be more or less monofrequency ( radio transmitters, > sidebands, microwave ovens, etc), so the regulation framers ( mostly > lawyers) regulated the obvious, and the manufacturers, concerned as > you say with pennies, did everything they could to fulfil the letter > of the law, damn the spirit. When the impact of the evasion hits > some people in some other country, it is the letter of the law that > will rule, so the regulations need to be more broadly crafted. And/or better educated customers willing and able to understand the value of a better crafted system when comparing to the one that didn't "spend the pennies." Customers want lower prices, shareholders want greater profits. Something ends-up giving when squeezed between those two. As to it being pennies, or scores of pennies, or hundreds of pennies more, where can one go to veryify that it is indeed pennies? Is it indeed pennies to rework a PCB or redesign a chassis when say ostensibly socket-compatible wizzy new processor Z tickles things one never saw before with processors W, X and Y? rick jones -- I don't interest myself in "why". I think more often in terms of "when", sometimes "where"; always "how much." - Joubert these opinions are mine, all mine; HP might not want them anyway... :) feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH... ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Strange NTP problem on AMD Geode LX cards.
Unruh wrote:
> E-Mail Sent to this address will be added to the BlackLists
> writes:
> >Rick Jones wrote:
> >>>> ... EMC / EMI, Unintentional / Incidental, Radiators
> >> And/or better educated customers willing and able to understand
> >> the value of a better crafted system when comparing to the one
> >> that didn't "spend the pennies."
> > For anyone that cared enough about emissions, (and not about
> > price) they could always get a EMSEC / TEMPEST, Level A / 1, PC.
> > {I've worked on a few TEMPEST PCs (decades in the past), it often
> > takes 15 minutes of removing shielding panels just to get to where
> > you can remove the shielded container a component (e.g. hard
> > drive) is inside.
> In one case to make it so that it does not destroy other people's
> enjoyment of their system, and the other to make sure a determined
> adversary cannot make use of yours. Different boxes for different
> folks.
I resisted mentioning TEMPEST since I figured it would be overkill
when perhaps just "TEAPOT" would be sufficient (perhaps one could have
an aftermarket to put a TEMPEST in a TEAPOT...)
But the main point I wanted to make was that there are several actors
involved in getting where we are today, and it isn't necessarily
_just_ the people who's emails end in .com or .gov
rick jones
--
Wisdom Teeth are impacted, people are affected by the effects of events.
these opinions are mine, all mine; HP might not want them anyway... :)
feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...
___
questions mailing list
questions@lists.ntp.org
https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] OT: GPS18x LVC failure
Uwe Klein wrote: > then: > some pakets are sent as broadcast to all ports. > switches store for each port the MAC addresses seen. > I have no idea if modern switches do (r)arp queries to > find the port a target MAC is sitting on or just broadcast > unknown MACs. Do you mean "flood?" Broadcast implies ff:ff:ff:ff:ff:ff destination MAC. > Hail for the times hubs were dumb repeaters with neither memory nor > intelligence ;-) Indeed :) Of course, then we'd be complaining about variability in back-off times and capture effect and whatnot instead :) rick jones -- oxymoron n, commuter in a gas-guzzling luxury SUV with an American flag these opinions are mine, all mine; HP might not want them anyway... :) feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH... ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] OT: GPS18x LVC failure
Uwe Klein wrote: > Rick Jones wrote: > > Uwe Klein wrote: > > > >>then: > >>some pakets are sent as broadcast to all ports. > >>switches store for each port the MAC addresses seen. > >>I have no idea if modern switches do (r)arp queries to > >>find the port a target MAC is sitting on or just broadcast > >>unknown MACs. > > > > > > Do you mean "flood?" Broadcast implies ff:ff:ff:ff:ff:ff > > destination MAC. > Most certainly not. > A switch (usually) forwards packets from one port to _one_ other > port ( the one were the switch has seen the target MAC ) > ( exempt are broadcast and multicast packets. ) > Now if there is no entry for the target MAC the thing to do is > either forward this packet to all ports or start a reverse arp > cycle. I don't think I've ever heard of a switch doing reverse ARP - and that would belimited to IP traffic where Ethernet carries more than just IP. Apart from that, while I think we may differ in terminology (I was tweaking on "just broadcast unknown MACs) I suspect we are in agreement on semantics. rick jones -- the road to hell is paved with business decisions... these opinions are mine, all mine; HP might not want them anyway... :) feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH... ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] testing slew only mode (-x), not slewing correctly (linux sles10, ntpd v 4.1.1)
Brian Utterback wrote: > And indeed, slewalways mode is unstable. That is why it was changed > to a "slew mostly" mode in later versions. What does "mostly" mean here? I see discussion all over the place (perhaps it is now entrenched into folklore?) about how one "never" wants to have the clock of say a database server "stepped." rick jones -- I don't interest myself in "why". I think more often in terms of "when", sometimes "where"; always "how much." - Joubert these opinions are mine, all mine; HP might not want them anyway... :) feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH... ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] ntp.cs.mu.oz.au going away - 2010-01-01
Unruh wrote: > "Wilson R. Afonso" writes: > >The Department of Computer Science of the University of Melbourne > >has for many years hosted the stratum 1 NTP server at > >ntp.cs.mu.oz.au. This service is heavily used, with requests coming > >from all corners of the world; it responds to approximately 500 > >requests per second on average. > >This service will be discontinued from 01 January 2010. We no > >longer have the capability (budget and manpower) to maintain the > >service in its current state, and rather than letting it degrade > >and fail, we're bringing it down in a controlled manner. > To bad. But I am wondering what the manpower requirements are? You > have GPS receivers and they would not seem to me to require must > maintainance. We may all be at least idly curious as to the why, but it seems that it would be better to thank Wilson and the University of Melbourne for their service to the community and wish them well. Our's is not to second guess their decision. rick jones -- The glass is neither half-empty nor half-full. The glass has a leak. The real question is "Can it be patched?" these opinions are mine, all mine; HP might not want them anyway... :) feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH... ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Busybox and ntp
Hal Murray wrote: > >but have hit some snags where certain commands are not supported in > >busybox (service start/stop/reset, chkconfig). > service is just a script/program to run one of the start/stop > scritps. It may be a redhat/fedora/linux thing. google will > find the man page. > chkconfig is a utility to setup the links for starting > and stopping services. Again, there is a man page. > If you aren't familiar with how servers get started/stopped, > look in /etc/rc.d and friends. Would this then be a case of it being better to at least occasionally build one's mnemonic memory circuits from stone knives and bear skins?-) Or put another way, an example of the perils of speed-dial... rick jones -- I don't interest myself in "why." I think more often in terms of "when," sometimes "where;" always "how much." - Joubert these opinions are mine, all mine; HP might not want them anyway... :) feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH... ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Client doesn't drop failed source
David Woolley wrote: > For a start, if it dropped a source on the first missing reply it > would result in clock hopping, which is undesirable. UDP is > unrliable, and you cannot rely on getting every query returned. In that sense then, even TCP is unreliable for it cannot guarantee getting every query returned. What distinguishes TCP from UDP is that TCP will make multiple attempts to deliver the data and then signal the probable (but not certain) non-delivery of data. rick jones -- oxymoron n, commuter in a gas-guzzling luxury SUV with an American flag these opinions are mine, all mine; HP might not want them anyway... :) feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH... ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] NTP for iPhone
casebash wrote: > I am building an iPhone application that needs to ensure thats its > time is accurate to a fraction of a second. I am considering setting > up the devices to check the time on startup using the NTP protocol > (or maybe the simple NTP protocol). Depending on your definition of a fraction of a second, wouldn't an iPhone already be getting rather accurate time from the cell towers? Or are you also concerned about devices like the iPod touch? rick jones -- oxymoron n, commuter in a gas-guzzling luxury SUV with an American flag these opinions are mine, all mine; HP might not want them anyway... :) feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH... ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
[ntp:questions] Don't toss that WWVB receiver?
I suspect that the latest issue of the Risks Digest will appear in comp.risks failry soon, meanwhile, from that issue, something that starts to make one wonder if "Tomorrow Never Dies" was prescient. (Or, perhaps less directly the second "Die Hard" move or...) I have to wonder - is NTP, or more generally, time synchronization, part of the affected set, or might it be part of the cure by helping detect the spoofing? rick jones RISKS-LIST: Risks-Forum Digest Sunday 28 February 2010 Volume 25 : Issue 95 ACM FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS (comp.risks) Peter G. Neumann, moderator, chmn ACM Committee on Computers and Public Policy * See last item for further information, disclaimers, caveats, etc. * This issue is archived at <http://www.risks.org> as <http://catless.ncl.ac.uk/Risks/25.95.html> The current issue can be found at <http://www.csl.sri.com/users/risko/risks.txt> Contents: [Backlogged] Growing Threat to GPS Systems From Jammers (Jerry Leichter) Sat-nav systems under growing threat from 'jammers' (Amos Shapir) ... -- Date: Thu, 25 Feb 2010 20:44:03 -0500 From: Jerry Leichter Subject: Growing Threat to GPS Systems From Jammers The BBC reports (http://news.bbc.co.uk/2/hi/science/nature/8533157.stm) on the growing threat of jamming to satellite navigation systems. The fundamental vulnerability of all the systems - GPS, the Russian Glonass, and the European Galileo - is the very low power of the transmissions. (Nice analogy: A satellite puts out less power than a car headlight, illuminating more than a third of the Earth's surface from 20,000 kilometers.) Jammers - which simply overwhelm the satellite signal - are increasingly available on-line. According to the article, low-powered hand-held versions cost less than È100, run for hours on a battery, and can confuse receivers tens of kilometers away. The newer threat is from spoofers, which can project a false location. This still costs "thousands", but the price will inevitably come down. A test done in 2008 showed that it was easy to badly spoof ships of the English coast, causing them to read locations anywhere from Ireland to Scandinavia. Beyond simple hacking - someone is quoted saying "You can consider GPS a little like computers before the first virus - if I had stood here before then and cried about the risks, you would've asked 'why would anyone bother?'." - among the possible vulnerabilities are to high- value cargo, armored cars, and rental cars tracked by GPS. As we build more and more "location-aware" services, we are inherently building more "false-location-vulnerable" services at the same time. -- Jerry -- Date: Wed, 24 Feb 2010 17:54:47 +0200 From: Amos Shapir Subject: Sat-nav systems under growing threat from 'jammers' "While "jamming" sat-nav equipment with noise signals is on the rise, more sophisticated methods allow hackers even to program what receivers display. At risk are not only sat-nav users, but also critical national infrastructure." Full story at: http://news.bbc.co.uk/1/hi/sci/tech/8533157.stm [This risk noted by several others as well.] -- oxymoron n, Hummer H2 with California Save Our Coasts and Oceans plates these opinions are mine, all mine; HP might not want them anyway... :) feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH... ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] NTPv4 Peer Event Codes - secret decoder ring sought
Joseph Gwinn wrote: > In article , > unruh wrote: > > On 2010-03-19, David Mills wrote: > > > That's a typo; event 16 does not exist. Glad you caught that. > > Pretty elaborate typo. Did they mean to give it a number other > > than 16, or were 50 letters somehow mistyped? > Ahh, be nice. We all know perfectly well how such things happen. When it comes to this bikeshed I'm not sure I'd have called that a typo either. Htis is a tyop. Call it a cut-and-paste error, call it a bug. Heck, call it an honest mistake or even an "oops." rick jones -- oxymoron n, Hummer H2 with California Save Our Coasts and Oceans plates these opinions are mine, all mine; HP might not want them anyway... :) feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH... ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Quick sync between two computers not connected to the internet
unruh wrote: > I am sorry, but getting an authoritative time source is trivial. A > GPS18x is cheap ( a lot less than you have spent on your salary in > these postings) reliable and easy. If they do not need the > microsecond precision of PPS, they can get a serial or usb version > and get millisecond precision, which is probably all they need. Is it still "trivial" in a below-ground data center? Heck, even a data center on the ground floor? It wasn't a GPS18x, but I tried taking a garmin GPS12 into a few machine rooms and had no joy whatsoever getting any GPS signal. rick jones -- a wide gulf separates "what if" from "if only" these opinions are mine, all mine; HP might not want them anyway... :) feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH... ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Quick sync between two computers not connected to the internet
unruh wrote: > Well, you might have to run a line out to the ground floor, or just > stick a $200 laptop with a connection to the data center. That is > slightly less trivial I agree. Which leads us to the interaction between the technically straightforward vs the administratively prohibited :) rick jones -- firebug n, the idiot who tosses a lit cigarette out his car window these opinions are mine, all mine; HP might not want them anyway... :) feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH... ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Quick sync between two computers not connected to the internet
David J Taylor wrote: > Rick, just for your information, the GPS12 is a rather deaf unit by > today's standards - something like a GPS18x LVC or GPS 60 CSx is > significantly more sensitive. No, I'm not saying it works > below-ground! Understood. So, if anyone in the vicinity of Cupertino, CA happens to have one of these things and would care to visit... :) rick jones -- portable adj, code that compiles under more than one compiler these opinions are mine, all mine; HP might not want them anyway... :) feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH... ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Quick sync between two computers not connected to the internet
> > On the other hand recent Linux kernels have screwed up the basic > > calibration on startup so rebooting a machine is much worse than a > > temperature change. (If they have fixed it recently, I haven't > > seen any announcement. You can fix it by hacking a constant into > > your kernel.) > Yes, it seems to be fixed. My machines with the more recent kernels > are getting about 10PPM out, while the older ones with the > calibration problems are more like 100-200PPM out. and varying by > 50PPM or so between boots. Which kernel versions are we talking about here, and are the fixes backported to distro kernels? rick jones -- A: Because it fouls the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] VM host not snyching time
David Woolley wrote: > Were I work, the number of cores are seriously over-committed, as is > memory. Many modern server applications are designed to use all the > cores that they can get. The Law of Unintended Consequences strikes following the Demise of Timesharing :) rick jones -- Wisdom Teeth are impacted, people are affected by the effects of events. these opinions are mine, all mine; HP might not want them anyway... :) feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH... ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] how to have offset < 1ms
unruh wrote: > > Unless "oceanographic vessel" is a euphamism for something that > > spends much of it's time "out of sight of any satellites!" > But in dock it is surely not out of sight. Depends on the "dock" - if it is a submarine pen then while the "dock" may not be out of sight, the submarine within it is. Or perhaps the original poster is a minion of Dr. Evil and he is trying to sync time to the servers back in the "in the volcano" lair :) rick jones -- portable adj, code that compiles under more than one compiler these opinions are mine, all mine; HP might not want them anyway... :) feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH... ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] how to have offset < 1ms
Random thoughts - sleep/hibernate mode on the client? Extreme/botched interrupt coalescing on the client's NIC? Preferential treatment of ICMP messages by the client or server TCP/IP stack? Preferential treatment of ICMP messages by the Cisco switch (ISTR some issues with NFS mounts over UDP on older Cisco switches hitting some throttle)? rick jones -- a wide gulf separates "what if" from "if only" these opinions are mine, all mine; HP might not want them anyway... :) feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH... ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] how to have offset < 1ms
nemo_outis wrote: > However, it would be irresponsible for Unruh and others here not to > point out that a much better timekeeping solution is readily > available - a solution which is technically easy to implement. Slapping a GPS onto a system on land in a "radio transparant" structure may indeed be technically easy, but is the *solution* here easy? How many decks down is this client? How far below decks will the GPS signal penetrate? How many water-tight bulkheads must be traversed to get from the antena to the client? Is there any free space in the existing through-holes the network traverses? Will any of the other things traversing the through holes along with the network cable(s) interfere with the single traversing the antenna cable to be added? Presumably we cannot trust the network here, which means getting GPS signals to the client. rick jones One wonders if that might relate to some of the network problems - interference with the network cables - so checking link-layer stats on the client, the switch etc would be goodness. -- I don't interest myself in "why". I think more often in terms of "when", sometimes "where"; always "how much." - Joubert these opinions are mine, all mine; HP might not want them anyway... :) feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH... ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] how to have offset < 1ms
lhommedumatch wrote: > This is ntpgmt aceb. they don't have the english version. > http://www.aceb-elec.com/sofy_EXP320.htm http://translate.google.com/translate?js=y&prev=_t&hl=en&ie=UTF-8&layout=1&eotf=1&u=http%3A%2F%2Fwww.aceb-elec.com%2Fsofy_EXP320.htm&sl=auto&tl=en for those who don't speak French, or who failed it twice in high-school :) rick jones -- web2.0 n, the dot.com reunion tour... these opinions are mine, all mine; HP might not want them anyway... :) feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH... ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] how to have offset < 1ms
nemo_outis wrote: > Well, no, not exactly as you point out. For the (potential) > problems you point out (and we're both speculating here) Agreed, we are both speculating. > have little to do with using a GPS sensor, per se, but rather with > cobbling up a *separate and independent network* for transmission > and propagation of the GPS signals within/through the ship. Once > again we're back to network problems, not GPS/timekeeping ones. Will you agree that is part of the GPS-based solution? rick jones -- web2.0 n, the dot.com reunion tour... these opinions are mine, all mine; HP might not want them anyway... :) feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH... ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] how to have offset < 1ms
lhommedumatch wrote: > The ACEB box is near my equipment. > My PC and the ACEB box are both connected to a CISCO Catalyst 4510R. The 4510R is a big-honking switch: http://www.cisco.com/en/US/products/hw/switches/ps4324/ps5653/ http://www.compsource.com/mscs_images/epics/large/1011201476.jpg What else is connected to this switch? Are the PC and the ACEB box connected to the same line-card in the switch or different line-cards? What other data is flowing through this switch? > We have encountered problem with the ntp card of the clock several > years ago. > When too many clients are connected the clock used to have problems. Details like that can be rather important... how many other clients are asking for time from the ACEB? Is the ACEB connecting to the switch at a full 100 Mbit/s or only 10 Mbit/s? Is the link running full-duplex or only half-duplex? I doubt there is a way to get link-level stats from the ACEB, but how about from the port on the 4510W - if the link is half-duplex, how about collision counts or excess retries? rick jones > May be this problem of latency and asymmetry comes from the ntp > card. -- The glass is neither half-empty nor half-full. The glass has a leak. The real question is "Can it be patched?" these opinions are mine, all mine; HP might not want them anyway... :) feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH... ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Recommendations for good NIC cards
> > How do you configure it on Linux? > http://freshmeat.net/projects/ethtool/ > ( never used it myself yet ) I've used it from time to time in my guise as "Mr. Netperf" - the biggest issue I have with it is that you have to script it post-boot - the linux folks eschew having module parameters for "things that can be set via ethtool." Also, the specifics of what you can/should change can vary from NIC to NIC. Where one can first see if the defaults are "bad" for interrupt coalescing would be the output of a netperf TCP_RR test between two of those NICs on a private network. If the inverse of the transaction rate is not "close to" (for a fairly liberal definition of close) the service demand (CPU consumption) per transaction, likely as not interrupt coalescing is taking place. Or, you can simply try changing the coalescing and if the transaction rate increases you know the default was bogus from a latency standpoint. I've seen that on a number of GbE NICs, and 10GbE NICs. I have seen good (IMO) default behaviour with the likes of the HP AD386A 10 GbE NIC, which is based on a Chelsio T3C chip. I think I've seen good default behaviour on a couple other 10G NICs as well, but their names escape me !-( rick jones -- The computing industry isn't as much a game of "Follow The Leader" as it is one of "Ring Around the Rosy" or perhaps "Duck Duck Goose." - Rick Jones these opinions are mine, all mine; HP might not want them anyway... :) feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH... ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] NTP timestamps
David Woolley wrote: > It is there. It is at the very front of the tcpdump output; i.e. it > is the timestamp of the tcpdump capture. The only way you could do > better is with debug code in ntpd itself. Well, you could use the timestamp of the system call trace of ntpd calling recvfrom() on the socket :) Or I suppose its call (does it make one?) to gettimeofday() just afterwards. rick jones -- a wide gulf separates "what if" from "if only" these opinions are mine, all mine; HP might not want them anyway... :) feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH... ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Network latency questions
This should have been in comp.dcom.lans.ethernet - followups set accordingly. Frans Grotepass wrote: > Hi all, > Sorry for abusing my membership to this forum for this question. > We are busy with building an embedded application that must retrieve > data very fast. The choice is to either have the data locally or go > to a central server(pool) that contains the data. > In evaluating the network option, I thought that the people here > could possibly help me with the expected network latency for a Gb > network via a switch. My gut feeling says that with increased load, > the switch will bundle the traffic to the different nodes more and > this will result in higher latency. "How long is a piece of string?" "It depends." An unloaded Gigabit Ethernet network might have quite low latency, but at the same time, a rather loaded network can have non-trivial latency. rick jones > Best regards, > Frans Grotepass -- a wide gulf separates "what if" from "if only" these opinions are mine, all mine; HP might not want them anyway... :) feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH... ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
