This is a discussion on Problem with Linux Machine's Request for Time from an XP Machine within the Linux Networking forums, part of the Linux Forums category; Allen McIntosh wrote: > >> Only three are connected: 2 is receive data, 3 is transmit data, and >&...
|
|||||||
| FAQ | Members List | Calendar | Search | Today's Posts | Mark Forums Read |
|
|||
|
Allen McIntosh wrote:
> >> Only three are connected: 2 is receive data, 3 is transmit data, and >> 5 is ground. More? > > > OK. You should still look over Garmin's documentation very carefully, > but it looks like you don't have a PPS signal. (As someone else > mentioned, the model number would help.) I've seen postings to the > effect that you may experience too much jitter this way, but maybe it's > worth a shot. Quite frankly when I brought this topic up on a GPS group it was the group that sent me off to investigate NTP. However, no one mentioned jitter, but had both positive and negative things to say about the GPS unit as a time source. prg mentions the "sales name" and not the model #/name is important. As far as I can tell its GPS 12XL Pesonal Navigator". I'm still interested in where this leads. I'll call Garmin later today, and ask them about it. They actually have a tech support line with real people at the other end. -- Wayne T. Watson (Watson Adventures, Prop., Nevada City, CA) (121.015 Deg. W, 39.262 Deg. N) GMT-8 hr std. time) Obz Site: 39° 15' 7" N, 121° 2' 32" W, 2700 feet Web Page: <home.earthlink.net/~mtnviews> |
|
|||
|
prg wrote:
> W. Watson wrote: > >>W. Watson wrote: >> >> >>>Allen McIntosh wrote: >>> >>> >>>>>The PC plug is a nine pin female plug. >>>> >>>> >>>>Do you have any documentation on what's on each pin? >>> >>>No. It's probably obtainable from Garmin. I'll check it out. >>> >> >>Only three are connected: 2 is receive data, 3 is transmit data, and >>5 is ground. More? > > > After reading up on your 2 month travail -- googling by author revealed > alot you had not shared here before ;-) -- I looked at Garmin's site. The previous thread was getting a bit too convoluted. I was spending too much time repeating myself. I'm sure things got lost in translation. Thus the new thread with a summary. Fortunately, some of my effort had some good news. I think I managed to hit every snag one could hit getting to the NTP part of it, and then it has had its snags. I think I've only spent about 7-10 days pondering the NTP approach. Fortunately, I've had some fun on the side on other matters. If you want a very good read on disasters, google the net for the story "A Comet's Tale". See my note just above yours to McIntosh about Garmin. > > You will need the "sales" name for the unit, not its model # -- go > figure. Anyway, it's here: > > http://www.garmin.com/support/download.jsp > > All the ones I tried offered up User's Guides, spec sheets, etc. See Garmin note above. > > As you mentioned, you still need to get XP's ntp working. I'll send > along the docs I've read tomorrow -- I suspected all along that besides > the registry edits you would have to play with the new firewall (WF -- > Windows Firewall, catchy, huh?) and it has changed a _lot_. In fact, > one of MS's better efforts in a while. At least the docs are pretty > clear. Even my current registry (see authoritative time source in the list of URLs you gathered, and I have mentioned seveal times) effort has stalled. One of the instructions makes no sense, #3. They ask me to change a binary with a text string. I'm trying to clear it up. > > I'll also send along the link for the Critical Update for their new WF > -- affects dial-up routing table entries that effectively let _anyone_ > through WF when the link is active ;( > till tomorrow (or is it today already?), > prg > email above disabled > See ya... -- Wayne T. Watson (Watson Adventures, Prop., Nevada City, CA) (121.015 Deg. W, 39.262 Deg. N) GMT-8 hr std. time) Obz Site: 39° 15' 7" N, 121° 2' 32" W, 2700 feet Web Page: <home.earthlink.net/~mtnviews> |
|
|||
|
"W. Watson" <wolf_tracks@invalid.inv> wrote:
>Allen McIntosh wrote: > >> >>> Only three are connected: 2 is receive data, 3 is transmit data, and >>> 5 is ground. More? >> OK. You should still look over Garmin's documentation very >> carefully, but it looks like you don't have a PPS signal. (As >> someone else mentioned, the model number would help.) I've >> seen postings to the effect that you may experience too much >> jitter this way, but maybe it's worth a shot. >Quite frankly when I brought this topic up on a GPS group it was >the group that sent me off to investigate NTP. However, no one >mentioned jitter, but had both positive and negative things to >say about the GPS unit as a time source. The Garmin 12XL is not suitable for use as a time standard. How accurate do you want? -- Floyd L. Davidson <http://web.newsguy.com/floyd_davidson> Ukpeagvik (Barrow, Alaska) floyd@barrow.com |
|
|||
|
Floyd L. Davidson wrote:
> "W. Watson" <wolf_tracks@invalid.inv> wrote: > >>Allen McIntosh wrote: >> >> >>>>Only three are connected: 2 is receive data, 3 is transmit data, and >>>>5 is ground. More? >>> >>>OK. You should still look over Garmin's documentation very >>>carefully, but it looks like you don't have a PPS signal. (As >>>someone else mentioned, the model number would help.) I've >>>seen postings to the effect that you may experience too much >>>jitter this way, but maybe it's worth a shot. >> >>Quite frankly when I brought this topic up on a GPS group it was >>the group that sent me off to investigate NTP. However, no one >>mentioned jitter, but had both positive and negative things to >>say about the GPS unit as a time source. > > > The Garmin 12XL is not suitable for use as a time standard. > > How accurate do you want? > For simplicity, 1 second a day. If there is a cheap GPS unit that is suitable, I'd be interested. -- Wayne T. Watson (Watson Adventures, Prop., Nevada City, CA) (121.015 Deg. W, 39.262 Deg. N) GMT-8 hr std. time) Obz Site: 39° 15' 7" N, 121° 2' 32" W, 2700 feet Web Page: <home.earthlink.net/~mtnviews> |
|
|||
|
Well, let me add a little more to Floyd's question on accuracy.
Ideally, this problem comes down to accurately time stamping the realtime data video observations of meteors at two locations about 30 miles apart. Ultimately it will be a meteor trajectory analyst who has the answer. I think the last time I asked him about this he offered, "very accurate". I've seen him work with less accurate data than we have, and I'd say the results were OK, passable. However, what guides this is money. This effort is really on a shoestring. If my partner and I could afford it, we'd go buy an atomic clock board and be done with it. NTP seems like a cheap but good way to go. At this point, what I'm doing about time synchs is exploratory. However, I'm beginning to think that maybe adjtimex is the way to go. (This is with a nod to the fact that my effort to use the authoritative time change registry change I've mentioned throughout this thread has temporarily aground.) It (adjtimex) sure sounds a lot easier to implement. This (NTP, synching time off the net, and related attempts) is taking too much time in the face of other objectives. Money wise we may have to just settle for it (adjtimex or NTP, but not a board or GPS), and just live with the consequences of having our observations really only agree within say 1/4 of a second of one another, and perhaps being off by the same amount with true time. There is a bit of what I would call politicking here. That is, the better my partner and I do with solving this problem, the more acceptable to the meteor community our data becomes. It's already proven valuable, but there's room for improvement. Interesting, problem, eh? I find the whole effort great fun. So, I guess is the answer is better than we have now, and within an almost infintesimally small budget. However, a big part of this is to have good timestamping between two distant observers. My partner has access to a local college network where he works. I'm out the middle of nowhere in the mountains of California. I don't think I really answered the question, but that's the state of things at the moment. If anyone is interested in donating their time to science, I know about a neutrino project that needs help ... :-) [End of philosphical waxing] Cheers ... -- Wayne T. Watson (Watson Adventures, Prop., Nevada City, CA) (121.015 Deg. W, 39.262 Deg. N) GMT-8 hr std. time) Obz Site: 39° 15' 7" N, 121° 2' 32" W, 2700 feet Web Page: <home.earthlink.net/~mtnviews> |
|
|||
|
"W. Watson" <wolf_tracks@invalid.inv> wrote:
>Floyd L. Davidson wrote: >> The Garmin 12XL is not suitable for use as a time standard. >> How accurate do you want? >> >For simplicity, 1 second a day. If there is a cheap GPS unit >that is suitable, I'd be interested. "1 second a day" doesn't mean much. That would be drift rate, not accuracy. From your discussion it sounds to me like you need something in the 10s of milliseconds (less than 0.1 second error). The simple GPS method (syncing to the NMEA messages), is not good enough. But if you think 0.5 second error is okay, then syncing to the NMEA messages from most inexpensive GPS units would be fine. Go buy one of the typical USB "mouse" style GPS units *if* you can mount it in a location that has sufficient "sky view" (for example right on a roof window in your observatory) *and* if that is within a USB extension cable distance of your computer. Otherwise get something (not made by Garmin) with a remote antenna and a regular RS-232 port. These things cost anywhere from $60 to $150. Do a google search on "GPS NMEA LINUX TIME" or something similar. There are several programs available to set the clock to sync with the NMEA messages, such as the GPGGA response. But they range from bad (200 to 500 ms error) to worse (your Garmin 12XL, which might have 2 second errors). If you want a stand alone time standard, which will be accurate to at least a few milliseconds, or with a good one to within a few microseconds, do a google search on "GPS FREQUENCY STANDARD NTP", and you'll find that several companies make them. For a few hundred bucks you can get something that will probably do fine. For 2-5 thousand bucks you can get a stand alone NTP server that will do everything but polish your shoes. But... given what you have described (which is extremely difficult to decipher), you would still be *far* better off to run ntpd on your Linux box and allow it to have access to the Internet. (Which apparently is *exactly* what the folks in the GPS group already told you.) If what you described was what it sounded like, you have two computers, one running Linux and one running XP, that are connected via a LAN, and the XP box has a dial up modem and can connect to the Internet. I do *not* recommend using the XP box as an ntp server or as a gateway for the Linux box to access the Internet. Instead I would suggest you go find the cheapest old box you can find (I use an old PII-400mHz box) and put a stripped down Linux on it, with IP forwarding enabled and set it up as a firewall with the modem attached to it rather than the XP box. Then both the XP box and the Linux box can safely access the Internet through a real firewall, and both can also run ntp client software to access a remote server (and skip all these various servers... use us.pool.ntp.org, which will give you a different server every time you query it). That will give you accuracy to 10's of milliseconds, and will cost only whatever you pay for an old computer (which you can probably get for free if you try hard). -- Floyd L. Davidson <http://web.newsguy.com/floyd_davidson> Ukpeagvik (Barrow, Alaska) floyd@barrow.com |
|
|||
|
W. Watson wrote:
> Well, let me add a little more to Floyd's question on accuracy. > > Ideally, this problem comes down to accurately time stamping the realtime > data video observations of meteors at two locations about 30 miles apart. > Ultimately it will be a meteor trajectory analyst who has the answer. I > think the last time I asked him about this he offered, "very accurate". I've > seen him work with less accurate data than we have, and I'd say the results > were OK, passable. "very accurate" would indicate the need for ntp, but for now maybe something less will do ;-) [snip] > ... However, I'm beginning to think that maybe adjtimex > is the way to go. ... Actually, I was going to suggest this as a "good enough for now solution" till you work out other issues -- didn't want to inject yet another detour toward ultimate victory lest you shriek, "Gods, my head is aching and my patience is exhausted." > ...(This is with a nod to the fact that my effort to use the authoritative > time change registry change I've mentioned throughout this thread has > temporarily aground.) It (adjtimex) sure sounds a lot easier to implement. > This (NTP, synching time off the net, and related attempts) is taking too > much time in the face of other objectives. [snip] > However, a big part of this is to have good timestamping > between two distant observers. 30 miles ain't that far apart at meteor velocities, is it? That's why the more accurate the better. [snip] The adjtimex manpage looks pretty clear -- is it clear to you what you need to do to use it? As suggested in the manpage, it would be nice if you could run ntp on the Linux box for at least several (12 hrs good, 24 hrs better). Can you afford to use your modem on the Linux box like that to acquire some good error/correction data? Maybe overnight? Quiet net traffic is best for making this work. This combined with a cron job running clockdiff -- $ man clockdiff -- to fetch the timestamp time from XP (d**d firewall gonna allow it?) would allow you to keep Linux awfully close (-10 ms) to XP's time, so that if you can verify that XP's time synching is adequate to your needs this may automate the whole process once adjtimex corrections are applied to Linux. From a Linux X terminal you could run clockdiff and see if it works without messing with XP's fw (not likely is my guess). If this sounds like someting worth exploring, let me know and I'll whip up something -- or someone else around here may have something already scripted. If this will work "good enough" it would allow you to get on to better things and come back to synching to XP's clock when life allows. I'll post some reference links re: XP's firewall separately -- may be usefull to have on hand. hth, prg email above disabled PS Could you maybe set the width on your posts to something like 64 -- I'm getting 10-15 char softwraps with most lines and it makes "quoted" lines break up and hard to read. |
|
|||
|
After takin a swig o' Arrakan spice grog, "W. Watson" <wolf_tracks@invalid.inv> belched out:
> Well, let me add a little more to Floyd's question on accuracy. > > Ideally, this problem comes down to accurately time stamping the > realtime data video observations of meteors at two locations about 30 > miles apart. Ultimately it will be a meteor trajectory analyst who has > the answer. I think the last time I asked him about this he offered, > "very accurate". I've seen him work with less accurate data than we > have, and I'd say the results were OK, passable. > > However, what guides this is money. This effort is really on a > shoestring. If my partner and I could afford it, we'd go buy an atomic > clock board and be done with it. NTP seems like a cheap but good way > to go. At this point, what I'm doing about time synchs is > exploratory. However, I'm beginning to think that maybe adjtimex is > the way to go. (This is with a nod to the fact that my effort to use > the authoritative time change registry change I've mentioned > throughout this thread has temporarily aground.) It (adjtimex) sure > sounds a lot easier to implement. This (NTP, synching time off the > net, and related attempts) is taking too much time in the face of > other objectives. Based on all of this, I think what you need is to have a Linux box be your Authoritative Time Source, and have it sync not against a cheapo GPS unit (which will have enough jitter that it won't play well) or against an XP box (which will be running whatever Microsoft has hacked up as their variation on NTP that is NOT REALLY NTP), but against a couple or three members of the pool.ntp.org NTP 'pool.' After that box has been synced for a while, its times should be pretty stable. You then should sync each of the boxes at those two locations against your internal "time authority" host. > Money wise we may have to just settle for it (adjtimex or NTP, but not > a board or GPS), and just live with the consequences of having our > observations really only agree within say 1/4 of a second of one > another, and perhaps being off by the same amount with true > time. There is a bit of what I would call politicking here. That is, > the better my partner and I do with solving this problem, the more > acceptable to the meteor community our data becomes. It's already > proven valuable, but there's room for improvement. Interesting, > problem, eh? I find the whole effort great fun. If you have a decent fast connection between the two boxes, there's no need for them to agree by a "mere" 1/4 second. They can do way better than that. -- output = ("cbbrowne" "@" "gmail.com") http://linuxfinances.info/info/emacs.html Rules of the Evil Overlord #141. "As an alternative to not having children, I will have _lots_ of children. My sons will be too busy jockeying for position to ever be a real threat, and the daughters will all sabotage each other's attempts to win the hero." <http://www.eviloverlord.com/> |
|
|||
|
What! No interest in the summer job watching for neutrinos light up a detector at
Fermi Lab in Chicago? :-) prg wrote: > W. Watson wrote: > .... > I > >> think the last time I asked him about this he offered, "very > > accurate". I've > .... > > > "very accurate" would indicate the need for ntp, but for now maybe something less > will do ;-) > > [snip] > > >> ... However, I'm beginning to think that maybe adjtimex is the way to go. ... > > > Actually, I was going to suggest this as a "good enough for now solution" till you > work out other issues -- didn't want to inject yet another detour toward ultimate > victory lest you shriek, "Gods, my head is aching and my patience is exhausted." When I approach that stage, I got get my Complete Book of New Yorker contains and begin reading. It and the 2 CDs contain 68,000+ cartoons. I'm through the first 1600 in the book. > > >> ...(This is with a nod to the fact that my effort to use the > > authoritative > >> time change registry change I've mentioned throughout this thread has >> temporarily aground.) It (adjtimex) sure sounds a lot easier to > > implement. > >> This (NTP, synching time off the net, and related attempts) is taking > > too > >> much time in the face of other objectives. > > [snip] > > >> However, a big part of this is to have good timestamping between two distant >> observers. > > > 30 miles ain't that far apart at meteor velocities, is it? That's why the more > accurate the better. Unfortunately, neither one of us wanted to move another 100 miles from the other. :-) Basically, we took what we could get. Yes, ideally we should be much further apart, but our dual sights are often good enough to put together a decent trajectory. > > [snip] > > The adjtimex manpage looks pretty clear -- is it clear to you what you need to do > to use it? As suggested in the manpage, it would be nice if you could run ntp on > the Linux box for at least several (12 hrs good, 24 hrs better). Can you afford > to use your modem on the Linux box like that to acquire some good error/correction > data? Maybe overnight? Quiet net traffic is best for making this work. I definitely know how to use it. I just need to review the methodolgy. My other partner, my wife, is particularly adept with it. Are you thinking of a script that dials out at 2 am and gets the time, and updates accordingly? Ah, I see more below. > > This combined with a cron job running clockdiff -- $ man clockdiff -- to fetch the > timestamp time from XP (d**d firewall gonna allow it?) would allow you to keep > Linux awfully close (-10 ms) to XP's time, so that if you can verify that XP's > time synching is adequate to your needs this may automate the whole process once > adjtimex corrections are applied to Linux. From a Linux X terminal you could run > clockdiff and see if it works without messing with XP's fw (not likely is my > guess). Something to consider. > > If this sounds like someting worth exploring, let me know and I'll whip up > something -- or someone else around here may have something already scripted. If > this will work "good enough" it would allow you to get on to better things and > come back to synching to XP's clock when life allows. I'll keep it in mind. See end note. > > I'll post some reference links re: XP's firewall separately -- may be usefull to > have on hand. > > hth, prg email above disabled > > PS Could you maybe set the width on your posts to something like 64 -- I'm > getting 10-15 char softwraps with most lines and it makes "quoted" lines break up > and hard to read. > Yes, I've found the formatting a little odd. I'll see what I can do. I get some strange things at times. When some I reply some people, their lines are unwrapped completely, and I have to rewrap them. Never quite understood that. Moz 1.6 is what I'm using. We'll at this point, I'm just taking it easy waiting for someone on a windows group to tell me why I cannot get by the 3rd step in the authoritative time document that I tried using to make registry changes for NTP. I'll do what I can through Thursday to deal with what I can, then I'm going on a four day birding trip. When I get back, I'll evaluate what I then know, and follow a path that seems reasonable for at least an improvement in my present arrangement. I'm sure my partner will have some input on it. He's been away for 2 weeks. Whatever it is it'll be something I can do with less effort than I've put into this so far. Then it's back to working on meteor detection methodolgy and algorithms. -- Wayne T. Watson (Watson Adventures, Prop., Nevada City, CA) (121.015 Deg. W, 39.262 Deg. N) GMT-8 hr std. time) Obz Site: 39° 15' 7" N, 121° 2' 32" W, 2700 feet Web Page: <home.earthlink.net/~mtnviews> |
|
|||
|
Christopher Browne wrote:
> After takin a swig o' Arrakan spice grog, "W. Watson" <wolf_tracks@invalid.inv> > belched out: > >> Well, let me add a little more to Floyd's question on accuracy. >> >> Ideally, this problem comes down to accurately time stamping the realtime data >> video observations of meteors at two locations about 30 miles apart. Ultimately .... > > Based on all of this, I think what you need is to have a Linux box be your > Authoritative Time Source, and have it sync not against a cheapo GPS unit (which > will have enough jitter that it won't play well) or against an XP box (which will > be running whatever Microsoft has hacked up as their variation on NTP that is NOT > REALLY NTP), but against a couple or three members of the pool.ntp.org NTP 'pool.' What is that? I guess I can go there and find out. Sounds like perhaps averaging time from three different ntp servers. > > After that box has been synced for a while, its times should be pretty stable. > > You then should sync each of the boxes at those two locations against your > internal "time authority" host. I take it that would be XP--after I figure out why I cannot complete a registry change required to make it authoritative. > > >> Money wise we may have to just settle for it (adjtimex or NTP, but not a board .... >> valuable, but there's room for improvement. Interesting, problem, eh? I find the >> whole effort great fun. > > > If you have a decent fast connection between the two boxes, there's no need for > them to agree by a "mere" 1/4 second. They can do way better than that. Good. Let's hope we can achieve that. I think I'm getting the attention of my partner on this, so maybe we'll achieve it. -- Wayne T. Watson (Watson Adventures, Prop., Nevada City, CA) (121.015 Deg. W, 39.262 Deg. N) GMT-8 hr std. time) Obz Site: 39° 15' 7" N, 121° 2' 32" W, 2700 feet Web Page: <home.earthlink.net/~mtnviews> |