First off you are right, NTP does not run well as it can with only a single reference. But that is a general statement and assumes there is some error in a reference clock. Certainly if using Internet pool servers as reference clocks you want to have 5 to 7 of them. But GPS is so darn good that NTP will be unable to find the difference between any two GPS receivers. GPS is a special case. Remember the NTP can use about a dozen different kinds of reference clocks, even if today only a few are used in practice. (really who uses WWV as a standard for their computer anymore?) Of course there are other ways of getting time into a Windows PC then using NTP. The most primitive thing possible is to simply "jam set" the PC clock from a NEMA sentence. This can be as much as a full second "off" and has a 50% chance of making your PC clock run backward (if it was fast rather then slow) but LOADS of software offer to do just this, Lady Heather included. But if you want something that avoids all those problems and makes the clock perform reasonable at all times then there really are two options NTP and PTP. If you are using a GPS as a reference Either if OK, The problem is harder then most people think. To avoid jumps in time either forward or backwards the software must be something that runs continuously and monitors your clock vs. one or more reference clocks. Logically there is no other way. The correction process must be continuously. PTP and NTP do this well enough that I doubt anyone would bother to write something to compete with them. Between the two PTP performs best in the special case that you own all of the hardware on both ends and the communications network. Most casual users can live with a system that "jam-sets" the clock as they are just reading the display and don't care if (say) 14:45:30.345 happens AFTER 14:45:30.355 But if you are doing something like trying to aim a telescope such a thing will cause it to jump and ruin a time exposure. But I doubt an EME antenna needs to be pointed with the same arc second level precision. The BEST way to get GPS time into a computer, and this is how, I think the world record accuracy was done is to use a GPSDO in place of the cheap crystal on the motherboard and then spend many hours comparing the computer's clock to GPS, sorry I lost the link to this But this method gets you fractions of microseconds. The worst way is to parse NEMA sentences and jam-set them into the clock. This gets you to roughly one second, more or less. On Wed, Oct 5, 2016 at 8:19 AM, Chris Caudle <chris@chriscaudle.org> wrote: > On Wed, October 5, 2016 6:14 am, Bob Camp wrote: > > If you buy a GPS receiver and get it set up for timing, just use it. > > Then there is no need for NTP at all. > > Is there another way to get computer system time set from a GPS receiver > other than NTP? > In the case that the system clock is controlled by GPSDO and the seconds > delineated by PPS, there should be no need for the NTP clock discipline > code, but I am not aware of any way to inform the NTP daemon that no > disciplining is needed. Presumably the code should determine that > eventually. > > In the case that the system clock is free running, the clock discipline is > still needed, but I found a note in one of the NTP documents (that I can > no longer locate at the moment) that stated something to the effect that > NTP did not run well as it could with a single reference, which would seem > to directly affect the case where a GPS receiver is the only reference. > That document had only that short note, no details on why or specifics of > behavior. > > -- > Chris Caudle > > > _______________________________________________ > time-nuts mailing list -- time-nuts@febo.com > To unsubscribe, go to https://www.febo.com/cgi-bin/ > mailman/listinfo/time-nuts > and follow the instructions there. > -- Chris Albertson Redondo Beach, California

There was a time when HAMs where the ones pushing radio technology forward. Maybe these guys are doing that and building a digital EME network on VHF? We don't know. We can guess but typically when you start wanting precise time synchronization it is because of something like TDMA (time division multiple access) to a shared resource. On Wed, Oct 5, 2016 at 9:47 AM, Wes <wes@triconet.org> wrote: > If you are working "real" EME where you, and not a computer plus lookup > table, are coping the signals, none of these precise timing issues exist. > > Wes N7WS > > > On 10/5/2016 6:18 AM, Peter Torry via time-nuts wrote: > >> I must admit to being rather puzzled at the sub microsecond timing >> requirement as I use ntp to set the W7 clock in my computer and have not >> had any issues. In fact less than one second is OK for the usual two minute >> periods that are required to allow for the Faraday rotation. Although I use >> a GPSDO for a frequency reference I find JT software reasonably tolerant of >> frequency. As I may be missing something I would welcome observations on >> how important the period timing requirement is, you never know I might get >> more contacts. >> >> Regards >> >> Peter >> >> >> On 05/10/2016 12:50, Graham / KE9H wrote: >> >>> For the group. This ham is trying to work EME. Earth-Moon-Earth >>> propagation >>> path. Aka, "moonbounce." >>> >>> He is trying to time synchronize a system, where the other station he is >>> communicating >>> with can be any other place on the Earth that can also see the Moon. >>> >>> So the system time sync is for a little bit tougher case than a local >>> area >>> network. >>> >>> --- Graham >>> >> > _______________________________________________ > time-nuts mailing list -- time-nuts@febo.com > To unsubscribe, go to https://www.febo.com/cgi-bin/m > ailman/listinfo/time-nuts > and follow the instructions there. > -- Chris Albertson Redondo Beach, California

Given the number of replies to the OP, most pointed but others drifting OT, it is remarkable that there has been no comment or feedback from Larry. He has slung his bottle and gone away it seems. > Le 5 oct. 2016 à 23:58, Bob Camp <kb8tq@n1k.org> a écrit : > > Hi > > Given that this is for intermittent EME use, it’s not a system that has uber > reliability as a requirement. Once you get the antenna up in a reasonable location > a GPS is going to be pretty stable and reliable. If you have an EME array > running, adding a GPS antenna to it probably not a big deal. > > If it *is* a big deal, run a GPSDO and then it’s no longer a problem. The KS > boxes still seem to be out there for < $100 …. > > Bob > >> On Oct 5, 2016, at 2:32 PM, Gary E. Miller <gem@rellim.com> wrote: >> >> Yo Bob! >> >> On Wed, 5 Oct 2016 07:14:30 -0400 >> Bob Camp <kb8tq@n1k.org> wrote: >> >>> If you buy a GPS receiver and get it set up for timing …. just use >>> it. Then there is no need for NTP at all…. >> >> Assuming your GPS never farts and always has a good lock. A pretty >> good assumption, but not a perfect one. >> >> RGDS >> GARY >> --------------------------------------------------------------------------- >> Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 >> gem@rellim.com Tel:+1 541 382 8588 >> _______________________________________________ >> time-nuts mailing list -- time-nuts@febo.com >> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts >> and follow the instructions there. > > _______________________________________________ > time-nuts mailing list -- time-nuts@febo.com > To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. "The power of accurate observation is commonly called cynicism by those who have not got it. » George Bernard Shaw

Hi That’s very typical in a lot of forums. The OP tosses up a question and then pretty much vanishes. My observation is that roughly 80% of the “I have a question” threads work that way. I’ve never been able to figure out if it is an expectation that all answers will arrive in an hour or two or if the OP is simply reading along and sees no reason to providing more information to the group. Either way, I’m pretty sure that the focus of the answers is not all that great a week after the last input. Bob > On Oct 6, 2016, at 3:33 AM, Mike Cook <michael.cook@sfr.fr> wrote: > > Given the number of replies to the OP, most pointed but others drifting OT, it is remarkable that there has been no comment or feedback from Larry. He has slung his bottle and gone away it seems. > > >> Le 5 oct. 2016 à 23:58, Bob Camp <kb8tq@n1k.org> a écrit : >> >> Hi >> >> Given that this is for intermittent EME use, it’s not a system that has uber >> reliability as a requirement. Once you get the antenna up in a reasonable location >> a GPS is going to be pretty stable and reliable. If you have an EME array >> running, adding a GPS antenna to it probably not a big deal. >> >> If it *is* a big deal, run a GPSDO and then it’s no longer a problem. The KS >> boxes still seem to be out there for < $100 …. >> >> Bob >> >>> On Oct 5, 2016, at 2:32 PM, Gary E. Miller <gem@rellim.com> wrote: >>> >>> Yo Bob! >>> >>> On Wed, 5 Oct 2016 07:14:30 -0400 >>> Bob Camp <kb8tq@n1k.org> wrote: >>> >>>> If you buy a GPS receiver and get it set up for timing …. just use >>>> it. Then there is no need for NTP at all…. >>> >>> Assuming your GPS never farts and always has a good lock. A pretty >>> good assumption, but not a perfect one. >>> >>> RGDS >>> GARY >>> --------------------------------------------------------------------------- >>> Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 >>> gem@rellim.com Tel:+1 541 382 8588 >>> _______________________________________________ >>> time-nuts mailing list -- time-nuts@febo.com >>> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts >>> and follow the instructions there. >> >> _______________________________________________ >> time-nuts mailing list -- time-nuts@febo.com >> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts >> and follow the instructions there. > > "The power of accurate observation is commonly called cynicism by those who have not got it. » > George Bernard Shaw > > _______________________________________________ > time-nuts mailing list -- time-nuts@febo.com > To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there.

  remote           refid      st t when poll reach   delay   offset

I still think NTP can detect asymmetric delays. Only it can't know that is what it is detecting. What else generate those offset numbers? Yes it could very well be that MRS is running slow but I doubt that is the case. And I really doubt your GPS' PPS is off by even one microsecond. A good bet is that ALL the results we see is because the real-world communication path is different from the assumption NTP makes about communications paths. In practice what NTP sees is all due to the Internet and not so much the reference clocks. Your data shows this. 162.23.41.10 .MRS has different stat depending on who is looking at it. So those billboards are showing network stats not server stats. (but NTP can't know that for certain so it is obliged to call them server stats) This is 2016. Almost any reference clock you are likely to use will be pretty much dead-on, at least to within the precision that NTP works with. So anything those billboards say is really about the communications paths. But NTP has no theoretical right to assume the cause of what it sees. Theory and practice differs, In theory NTP can not detect asymmetric delay but in practice that is about all it detects Maybe I should say NTP detects asymmetric delay just like the speedometer in my car deters engine failure. All that said, if the OP is still reading this it should be very good news for him because your data shows that NTP can give him his required accuracy even without a GPS if he has an Internet connection as good as yours In fact what you are showing is that NTP using the Internet can beat GPS over USB to Winows. and can certainly beat any software the "jam sets" the clock. All you need is your Internet connection, no aded hardware. On Wed, Oct 5, 2016 at 5:14 AM, Magnus Danielson <magnus@rubidium.dyndns.org > wrote: > > > On 10/05/2016 01:48 PM, Attila Kinali wrote: > >> On Tue, 4 Oct 2016 18:05:16 -0700 >> Chris Albertson <albertson.chris@gmail.com> wrote: >> >> The problem, I think with your Internet sync's NTP servers is you are only >>> using one server S. The most common practice is to use 3 to 5 with 5 >>> being >>> about the right number. If you get Ntp enough Internet servers to work >>> with it can detect problem like asymmetric path lengths which I'm sure is >>> you problem. >>> >> >> No they are correctly configured with 3 and 5 servers respectively. >> I singled out server S out, because i didn't want to clutter the argument >> with too many numbers and because S is common to both machines A and B >> and because it's very close in internet terms (with 4.5ms and 2ms >> respectively). >> >> The full view of A is (the last line is B): >> >> remote refid st t when poll reach delay offset >> jitter >> ============================================================ >> ================== >> +162.23.41.55 .MRS. 1 u 357 1024 377 4.555 0.198 >> 0.293 >> *162.23.41.10 .MRS. 1 u 318 1024 377 4.403 -0.040 >> 0.123 >> -131.188.3.223 .PZF. 1 u 548 1024 377 9.524 -0.654 >> 0.039 >> +2001:67c:8:abcd .GPS1. 1 u 74 1024 373 12.163 0.143 >> 0.168 >> -81.94.123.17 85.158.25.74 2 u 297 1024 377 0.985 -0.798 >> 0.158 >> -2a02:418:f022:: 162.23.41.10 2 u 792 1024 377 0.649 -0.727 >> 2.120 >> >> And the full view of B is: >> remote refid st t when poll reach delay offset >> jitter >> ============================================================ >> ================== >> *162.23.41.10 .MRS. 1 u 175 1024 377 2.067 -0.033 >> 0.069 >> +195.186.1.101 195.186.150.242 2 u 504 1024 377 1.317 -0.360 >> 0.086 >> +130.60.204.10 130.60.159.7 4 u 901 1024 377 1.539 0.932 >> 2.065 >> >> >> Note: 162.23.41.10 (the server S) is one of the three NTP servers run by >> METAS >> and fed by the official PPS of Switzerland. >> >> >> And no, NTP cannot detect asymmetric network delays. They are completely >> indisdinguishable from clock offsets. One can easily show that the >> uncertainty in the network delay symmetry is the fundamental accuracy >> limit of NTP. As the asymmetry is in general unbounded, the only guarantee >> you have is that you are at most off by the RTT (aka delay) of the >> reference. >> (given the reference itself is accurate) >> > > It is trivial to show that any two-way time-transfer mechanism, be it NTP, > PTP, TWTFST, DTM TT or whatever, cannot unaided separate Time Error between > two clocks from that of the asymmetry between them. The Round Trip Time > (RTT) is however guaranteed unbiased under the assumption of no (major) > frequency difference. PTP adds means by which intermediate nodes can > provide delay estimations and thus allow cancellation of delay in those > equipments, but it does not help for asymmetry in path, such as different > fiber-lengths. Such delays needs to be calibrated. > > With lots of observations you can however draw some conclusions of likely > cause of offsets, but without aiding through calibration, you cannot draw a > strict conclusion. > > You CAN do very well, to just a few Millisecond using NTP sync'ing to >>> Internet servers, but pick 5 of them or even 7. and make sure they are >>> dispersed and not all at the same place. >>> >> >> You want to have them (time wise) as close as possible. Having many >> servers >> does not help as much as having one accurate close by. Actually, once you >> have a very close stratum 1, any additional server will _degrade_ the >> accuracy of NTP as NTP cannot know which of it's reference servers is >> accurate or not (unless specifically configured). >> >> >> In this case the correct answer to this "problem" would be to set up a >> stratum 1 server in either of the colo centers and synchornize to that. >> And if i had the hardware, I would do that. But then, being off by only >> 1ms >> is not that bad for an internet facing ntp server where most of the >> clients >> will be on ADSL/VDSL lines which exhibit some 10ms of delay. >> > > Indeed. Asymmetry can build up in places where you do not expect it. > Most systems isn't designed for symmetric delay. Many works fairly decent > (at low load), but you never know and it's hard to tell. > > Cheers, > Magnus > _______________________________________________ > time-nuts mailing list -- time-nuts@febo.com > To unsubscribe, go to https://www.febo.com/cgi-bin/m > ailman/listinfo/time-nuts > and follow the instructions there. > -- Chris Albertson Redondo Beach, California

 remote           refid      st t when poll reach   delay   offset

Hi NTP can *not* detect “common mode” asymmetric delay. Having a local GPS does not count in this respect. What does count is an NTP client / server sitting in your home trying to figure out what time it is only by hooking to the internet. To do this it must do a few things: 1) Get a signal out through the (slow / long lag) upload channel on your modem. 2) Route that signal through the cable guy’s low capacity upstream network to one of his (at best) two or three gateways to your local empire. These may or may not be in the same state you live in. 3) Fly the signal over the backbone to whatever server is involved. 4) Fly a signal back over the backbone to possibly another set of gateways. 5) Route that signal through the cable guy’s high capacity downstream network. 6) Run it through the (quite fast / low lag) downstream channel on your modem. Steps 1,2,5 and 6 are common to every single server you try to access. If your modem has an “upstream” lag of (say) 101 ms and a “downstream” lag of (say) 1 ms, every server you contact will have a round trip time of at least 102 ms. They *may* have more than this, but none will ever have less. As the day progresses and various groups pop on and off the system in your state, the usage of the upstream and downstream channels changes. It is not unreasonable to guess that both change as a percentage. If that guess is correct, your upstream varies by significantly more than your downstream. That will get into NTP’s loop correction stuff as well. You *might* ask, how about pings? Well, you *might* look into it and find that your local cable system recognizes pings at a very low level and preferentially routes them. Yes, that’s hogwash and nobody would ever do it ….. except that’s the way it works here with my internet. The network can be completely dead and pings (along with other ICMP traffic) will get through. Hmmm….. You are indeed a guy with 5 watches to check against. The gotcha is that every single one of them has been set fast or slow by the same amount. Bob > On Oct 6, 2016, at 11:03 AM, Chris Albertson <albertson.chris@gmail.com> wrote: > > I still think NTP can detect asymmetric delays. Only it can't know that is > what it is detecting. What else generate those offset numbers? Yes it > could very well be that MRS is running slow but I doubt that is the case. > And I really doubt your GPS' PPS is off by even one microsecond. A good > bet is that ALL the results we see is because the real-world communication > path is different from the assumption NTP makes about communications paths. > > In practice what NTP sees is all due to the Internet and not so much the > reference clocks. Your data shows this. 162.23.41.10 .MRS has different > stat depending on who is looking at it. So those billboards are showing > network stats not server stats. (but NTP can't know that for certain so it > is obliged to call them server stats) > > This is 2016. Almost any reference clock you are likely to use will be > pretty much dead-on, at least to within the precision that NTP works with. > So anything those billboards say is really about the communications paths. > But NTP has no theoretical right to assume the cause of what it sees. > Theory and practice differs, In theory NTP can not detect asymmetric > delay but in practice that is about all it detects Maybe I should say NTP > detects asymmetric delay just like the speedometer in my car deters engine > failure. > > All that said, if the OP is still reading this it should be very good news > for him because your data shows that NTP can give him his required accuracy > even without a GPS if he has an Internet connection as good as yours > > In fact what you are showing is that NTP using the Internet can beat GPS > over USB to Winows. and can certainly beat any software the "jam sets" the > clock. All you need is your Internet connection, no aded hardware. > > > > On Wed, Oct 5, 2016 at 5:14 AM, Magnus Danielson <magnus@rubidium.dyndns.org >> wrote: > >> >> >> On 10/05/2016 01:48 PM, Attila Kinali wrote: >> >>> On Tue, 4 Oct 2016 18:05:16 -0700 >>> Chris Albertson <albertson.chris@gmail.com> wrote: >>> >>> The problem, I think with your Internet sync's NTP servers is you are only >>>> using one server S. The most common practice is to use 3 to 5 with 5 >>>> being >>>> about the right number. If you get Ntp enough Internet servers to work >>>> with it can detect problem like asymmetric path lengths which I'm sure is >>>> you problem. >>>> >>> >>> No they are correctly configured with 3 and 5 servers respectively. >>> I singled out server S out, because i didn't want to clutter the argument >>> with too many numbers and because S is common to both machines A and B >>> and because it's very close in internet terms (with 4.5ms and 2ms >>> respectively). >>> >>> The full view of A is (the last line is B): >>> >>> remote refid st t when poll reach delay offset >>> jitter >>> ============================================================ >>> ================== >>> +162.23.41.55 .MRS. 1 u 357 1024 377 4.555 0.198 >>> 0.293 >>> *162.23.41.10 .MRS. 1 u 318 1024 377 4.403 -0.040 >>> 0.123 >>> -131.188.3.223 .PZF. 1 u 548 1024 377 9.524 -0.654 >>> 0.039 >>> +2001:67c:8:abcd .GPS1. 1 u 74 1024 373 12.163 0.143 >>> 0.168 >>> -81.94.123.17 85.158.25.74 2 u 297 1024 377 0.985 -0.798 >>> 0.158 >>> -2a02:418:f022:: 162.23.41.10 2 u 792 1024 377 0.649 -0.727 >>> 2.120 >>> >>> And the full view of B is: >>> remote refid st t when poll reach delay offset >>> jitter >>> ============================================================ >>> ================== >>> *162.23.41.10 .MRS. 1 u 175 1024 377 2.067 -0.033 >>> 0.069 >>> +195.186.1.101 195.186.150.242 2 u 504 1024 377 1.317 -0.360 >>> 0.086 >>> +130.60.204.10 130.60.159.7 4 u 901 1024 377 1.539 0.932 >>> 2.065 >>> >>> >>> Note: 162.23.41.10 (the server S) is one of the three NTP servers run by >>> METAS >>> and fed by the official PPS of Switzerland. >>> >>> >>> And no, NTP cannot detect asymmetric network delays. They are completely >>> indisdinguishable from clock offsets. One can easily show that the >>> uncertainty in the network delay symmetry is the fundamental accuracy >>> limit of NTP. As the asymmetry is in general unbounded, the only guarantee >>> you have is that you are at most off by the RTT (aka delay) of the >>> reference. >>> (given the reference itself is accurate) >>> >> >> It is trivial to show that any two-way time-transfer mechanism, be it NTP, >> PTP, TWTFST, DTM TT or whatever, cannot unaided separate Time Error between >> two clocks from that of the asymmetry between them. The Round Trip Time >> (RTT) is however guaranteed unbiased under the assumption of no (major) >> frequency difference. PTP adds means by which intermediate nodes can >> provide delay estimations and thus allow cancellation of delay in those >> equipments, but it does not help for asymmetry in path, such as different >> fiber-lengths. Such delays needs to be calibrated. >> >> With lots of observations you can however draw some conclusions of likely >> cause of offsets, but without aiding through calibration, you cannot draw a >> strict conclusion. >> >> You CAN do very well, to just a few Millisecond using NTP sync'ing to >>>> Internet servers, but pick 5 of them or even 7. and make sure they are >>>> dispersed and not all at the same place. >>>> >>> >>> You want to have them (time wise) as close as possible. Having many >>> servers >>> does not help as much as having one accurate close by. Actually, once you >>> have a very close stratum 1, any additional server will _degrade_ the >>> accuracy of NTP as NTP cannot know which of it's reference servers is >>> accurate or not (unless specifically configured). >>> >>> >>> In this case the correct answer to this "problem" would be to set up a >>> stratum 1 server in either of the colo centers and synchornize to that. >>> And if i had the hardware, I would do that. But then, being off by only >>> 1ms >>> is not that bad for an internet facing ntp server where most of the >>> clients >>> will be on ADSL/VDSL lines which exhibit some 10ms of delay. >>> >> >> Indeed. Asymmetry can build up in places where you do not expect it. >> Most systems isn't designed for symmetric delay. Many works fairly decent >> (at low load), but you never know and it's hard to tell. >> >> Cheers, >> Magnus >> _______________________________________________ >> time-nuts mailing list -- time-nuts@febo.com >> To unsubscribe, go to https://www.febo.com/cgi-bin/m >> ailman/listinfo/time-nuts >> and follow the instructions there. >> > > > > -- > > Chris Albertson > Redondo Beach, California > _______________________________________________ > time-nuts mailing list -- time-nuts@febo.com > To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there.

To be fair, this is at least partly because asking a relatively simple question here routinely turns into a dissertation defense. > On Oct 6, 2016, at 3:45 AM, Bob Camp <kb8tq@n1k.org> wrote: > > Hi > > That’s very typical in a lot of forums. The OP tosses up a question and then pretty much vanishes. > My observation is that roughly 80% of the “I have a question” threads work that way. > I’ve never been able to figure out if it is an expectation that all answers will arrive in an hour or two > or if the OP is simply reading along and sees no reason to providing more information to the group. > Either way, I’m pretty sure that the focus of the answers is not all that great a week after the last input. > > Bob

On 10/5/2016 7:40 PM, Chris Albertson wrote: > There was a time when HAMs where the ones pushing radio technology > forward. Maybe these guys are doing that and building a digital EME > network on VHF? We don't know. Actually, we do know. Regarding my earlier comments, I believe at the time (mid-1970) those of us pursuing EME _were_ pushing the technology forward. > We can guess but typically when you start wanting precise time > synchronization it is because of something like TDMA (time division > multiple access) to a shared resource. Not so. What is now common is the use of "JT" modes. JT modes have a number of variations but what they have in common is they were developed by Nobel Prize winner, Dr. Joe Taylor, who has freely given the software to the ham radio community. See: http://physics.princeton.edu/pulsar/K1JT/JT65.pdf Although I personally ceased pursuing this activity many years ago, there remain some of us, who are not Luddites, but still believe that "Deep Search Decoding" is a questionable practice, no matter how it is rationalized. Nevertheless, the referenced paper should explain the need for precise timekeeping. > On Wed, Oct 5, 2016 at 9:47 AM, Wes <wes@triconet.org> wrote: > >> If you are working "real" EME where you, and not a computer plus lookup >> table, are coping the signals, none of these precise timing issues exist. >> >> Wes N7WS >>

Indeed, Nick. And more than a little (usually) courteous one upmanship couched in terms of being helpful by correcting all previous posters. This gentlemanly "mine is bigger than yours" phenomenon is part of what makes this group fun to read. On Thu, Oct 6, 2016 at 2:03 PM, Nick Sayer via time-nuts <time-nuts@febo.com > wrote: > To be fair, this is at least partly because asking a relatively simple > question here routinely turns into a dissertation defense. > > > On Oct 6, 2016, at 3:45 AM, Bob Camp <kb8tq@n1k.org> wrote: > > > > Hi > > > > That’s very typical in a lot of forums. The OP tosses up a question and > then pretty much vanishes. > > My observation is that roughly 80% of the “I have a question” threads > work that way. > > I’ve never been able to figure out if it is an expectation that all > answers will arrive in an hour or two > > or if the OP is simply reading along and sees no reason to providing > more information to the group. > > Either way, I’m pretty sure that the focus of the answers is not all > that great a week after the last input. > > > > Bob > > _______________________________________________ > time-nuts mailing list -- time-nuts@febo.com > To unsubscribe, go to https://www.febo.com/cgi-bin/ > mailman/listinfo/time-nuts > and follow the instructions there. > -- Intelligence has never been proof against stupidity.

Hi Often the dive into the fine details is all that is left without guidance from the OP. After a few days (here or elsewhere) it can get pretty deep …. Bob > On Oct 6, 2016, at 2:03 PM, Nick Sayer via time-nuts <time-nuts@febo.com> wrote: > > To be fair, this is at least partly because asking a relatively simple question here routinely turns into a dissertation defense. > >> On Oct 6, 2016, at 3:45 AM, Bob Camp <kb8tq@n1k.org> wrote: >> >> Hi >> >> That’s very typical in a lot of forums. The OP tosses up a question and then pretty much vanishes. >> My observation is that roughly 80% of the “I have a question” threads work that way. >> I’ve never been able to figure out if it is an expectation that all answers will arrive in an hour or two >> or if the OP is simply reading along and sees no reason to providing more information to the group. >> Either way, I’m pretty sure that the focus of the answers is not all that great a week after the last input. >> >> Bob > > _______________________________________________ > time-nuts mailing list -- time-nuts@febo.com > To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there.