http://blog.gmane.org/gmane.comp.time.nuts hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://permalink.gmane.org/gmane.comp.time.nuts/20759 <pre>---------------------------- Original Message ---------------------------- Subject: WWVB test notification From: "John Lowe" &lt;lowe-PlFwYbz7hoJHf7+it3YNdA&lt; at &gt;public.gmane.org&gt; Date: Thu, May 24, 2012 4:22 pm To: "Lowe, John P" &lt;john.lowe-R3+/ord2DXQ&lt; at &gt;public.gmane.org&gt; -------------------------------------------------------------------------- *Notice* NIST Radio Station WWVB will be conducting a test of a phase-modulated broadcast format beginning at 1800 UTC (12:00 noon MDT) Tuesday, May 29 to 1800 UTC on Wednesday, May 30 2012. The normal broadcast format will then be restored for a two-hour period. The test will then resume at 2000 UTC (2:00 PM MDT) and end at 1800 UTC, Thursday, May 31 2012. Radio-controlled clocks and watches will not be affected. Phase-locking 60 kHz timing and frequency standard receivers may lose lock during the test. For more information, call WWVB broadcast manager John Lowe at 303-497-5453, or email john.lowe-R3+/ord2DXQ&lt; at &gt;public.gmane.org &lt;mailto:john.lowe-R3+/ord2DXQ&lt; at &gt;public.gmane.org&gt;. Notice NIST Radio Station WWVB will be conducting a test of a phase-modulated broadcast format beginning at 1800 UTC (12:00 noon MDT) Tuesday, May 29 to 1800 UTC on Wednesday, May 30 2012. The normal broadcast format will then be restored for a two-hour period. The test will then resume at 2000 UTC (2:00 PM MDT) and end at 1800 UTC, Thursday, May 31 2012. Radio-controlled clocks and watches will not be affected. Phase-locking 60 kHz timing and frequency standard receivers may lose lock during the test. For more information, call WWVB broadcast manager John Lowe at 303-497-5453, or email [1]john.lowe-R3+/ord2DXThvxM+mQhndA&lt; at &gt;public.gmane.org References 1. mailto:john.lowe-R3+/ord2DXQ&lt; at &gt;public.gmane.org </pre> J. Forster 2012-05-24T23:20:43 http://permalink.gmane.org/gmane.comp.time.nuts/20758 <pre>As a FYI, the 6 port card I use is based on the4 Netmos NM9845CV. There are a few vendors peddling serial cards using this chipset and part number. Mine is from "Best Connectivity" (SD-PIO9845-6S). The card is windows and linux capable. </pre> gary 2012-05-24T04:40:38 http://permalink.gmane.org/gmane.comp.time.nuts/20757 <pre>Hi Ok, at least now we are down to some numbers. Ever taken a look at NTP on a Windows box running serial? It's not anywhere near a microsecond…. Bob On May 23, 2012, at 6:47 PM, Chris Albertson wrote: </pre> Bob Camp 2012-05-24T00:35:55 http://permalink.gmane.org/gmane.comp.time.nuts/20756 <pre> Yes, 200 ms would be insanely poor. NTP with a direct connected GPS can run the micro second level. The 100x to 1000x worse I'm talking about puts NTP at the 0.5 to 1.0 ms level. With PPS connected directly to the DCD line on a Linux based server the hardware counter is captured with a typical error of 1 micro second. Over the LAN or USB we see this error at about 1 or 2 milliseconds So what I'm saying is by using the LAN you give up micro seconds for milliseconds or about a factor of 1000. You are right. It is never anything at all like 200 ms. We get better than 200 ms error over the Internet from servers 1,000 miles away. In general you should expect a 1 uSec level error from a direct connect to from a GPS's PPS to the DCD line of a serial port and a mSec level error from USB or LAN and tens of ms error from an Internet connection. Where NTP really shines is extracting 10ms level timing from an unreliable connection that has much longer then 10ms delay. It really is not so impressive that it can get u-sec level performance from a directly connected Trimble Thunderbolt. The bottle neck is the PC hardware. You really never can do better then 1 uS with a generic PC. </pre> Chris Albertson 2012-05-23T22:47:02 http://permalink.gmane.org/gmane.comp.time.nuts/20755 <pre>Hi Ok, to be 1000: 1, you would take the 0.2 to 0.5 ms that you see on the LAN and take it up to 200 to 500ms. That's *way* worse than anything I have ever seen for a serial server over a LAN. Bob On May 23, 2012, at 5:15 PM, Chris Albertson wrote: </pre> Bob Camp 2012-05-23T21:59:57 http://permalink.gmane.org/gmane.comp.time.nuts/20754 <pre> Have you actually tried this and measured? 2:1 is very optimistic. Typically it is 1000:1 or worse But you are right that it may not matter. For most uses if the computer's clock is correct at the 0.1 second level they are happy. but this is a "time nut" mailing list and some of us like to get NTP to run at the uSecond level. Useless as that might be. Chris Albertson Redondo Beach, California </pre> Chris Albertson 2012-05-23T21:15:49 http://permalink.gmane.org/gmane.comp.time.nuts/20753 <pre>Hi What ever degradation the serial stream sees on the LAN, the resulting NTP output will see once it's on the same LAN. It's unlikely you will see more than a 2:1 net degradation no matter what is going on. The flywheel in the NTP algorithm will likely help you in this case to actually improve things a bit. Bob -----Original Message----- From: time-nuts-bounces-JSkTLETqlTM&lt; at &gt;public.gmane.org [mailto:time-nuts-bounces-JSkTLETqlTM&lt; at &gt;public.gmane.org] On Behalf Of Chris Albertson Sent: Wednesday, May 23, 2012 3:13 PM To: Discussion of precise time and frequency measurement Subject: Re: [time-nuts] Serial port server .. any interest in a write up on using ? On Wed, May 23, 2012 at 9:08 AM, Bob Camp &lt;lists-30jTmCQ20qY&lt; at &gt;public.gmane.org&gt; wrote: thing. Depends on your accuracy goals. Of course it would work to some degree. But we are talking several orders of degradation if the PPS second is carried over even a dedicated either net that uses only a crossover cable. The problem is not so much the network but the buffer in the ethernet interface. This is the same thing that happens when petiole try and send the PPS over a serial to USB cable. Those cables typically cost you two orders of magnitude timing error. The reason the direct connected PPS is so good is because of the simple hardware design and the even simpler software interrupt handler. There are only four of five lines of code that get executed. It is so simple. Both Either net and USB are "packetized" where the data arrive in chunks and the entire chunk has to get inside the computer before it can be looked at. While PPS to a serial port is just an edge triggered logic gate that forces an interrupt. Again you can do it but you take a 10E2 or 10E3 "hit". If you do need to send a PPS over Ethernet cable you can do it, but don't use networking. Cat-5 cable has "extra" pairs that ethernet does not use. Those can be used to send a balanced, differential signal down the wire. A pair of RS-422 transceiver chips and terminating resistors would work well for this. (Don't try to send an unbalanced TTL level pulse down 100+ feet of Cat-5 cable, it works very poorly.) This is all easy to test. All you need is uSec level test gear. You don't need hyper expensive counters. Compare the transmitted PPS to your Thunderbolt's PPS or simply look at NTP's log files. </pre> Bob Camp 2012-05-23T21:02:40 http://permalink.gmane.org/gmane.comp.time.nuts/20752 <pre>Hi They have been sitting in the shed for 15 years now. They were knock off's when I bought them. Bob -----Original Message----- From: time-nuts-bounces-JSkTLETqlTM&lt; at &gt;public.gmane.org [mailto:time-nuts-bounces-JSkTLETqlTM&lt; at &gt;public.gmane.org] On Behalf Of DaveH Sent: Wednesday, May 23, 2012 2:46 PM To: 'Discussion of precise time and frequency measurement' Subject: Re: [time-nuts] Serial port -- multi-port cards Hi Bob Actually, I checked the website before posting and Digi has drivers for Windows Vista and 2008 ( as well as XP, 2K and 98)-- I will see if it works on Win7 before posting what I have. What cards do you have? Dave _______________________________________________ time-nuts mailing list -- time-nuts-JSkTLETqlTM&lt; at &gt;public.gmane.org To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there. </pre> Bob Camp 2012-05-23T20:59:02 http://permalink.gmane.org/gmane.comp.time.nuts/20751 <pre>On Wed, May 23, 2012 at 12:13 PM, Chris Albertson &lt;albertson.chris-Re5JQEeQqe8AvxtiuMwx3w&lt; at &gt;public.gmane.org&gt; wrote: One thing I forgot to add. Gigabit switches are WORSE for NTP then the 100BaseT switches. Seems odd at first but the two work differently. Faster switches buffer the data and add timing uncertainty. </pre> Chris Albertson 2012-05-23T19:20:06 http://permalink.gmane.org/gmane.comp.time.nuts/20750 <pre> Depends on your accuracy goals. Of course it would work to some degree. But we are talking several orders of degradation if the PPS second is carried over even a dedicated either net that uses only a crossover cable. The problem is not so much the network but the buffer in the ethernet interface. This is the same thing that happens when petiole try and send the PPS over a serial to USB cable. Those cables typically cost you two orders of magnitude timing error. The reason the direct connected PPS is so good is because of the simple hardware design and the even simpler software interrupt handler. There are only four of five lines of code that get executed. It is so simple. Both Either net and USB are "packetized" where the data arrive in chunks and the entire chunk has to get inside the computer before it can be looked at. While PPS to a serial port is just an edge triggered logic gate that forces an interrupt. Again you can do it but you take a 10E2 or 10E3 "hit". If you do need to send a PPS over Ethernet cable you can do it, but don't use networking. Cat-5 cable has "extra" pairs that ethernet does not use. Those can be used to send a balanced, differential signal down the wire. A pair of RS-422 transceiver chips and terminating resistors would work well for this. (Don't try to send an unbalanced TTL level pulse down 100+ feet of Cat-5 cable, it works very poorly.) This is all easy to test. All you need is uSec level test gear. You don't need hyper expensive counters. Compare the transmitted PPS to your Thunderbolt's PPS or simply look at NTP's log files. </pre> Chris Albertson 2012-05-23T19:13:00 http://permalink.gmane.org/gmane.comp.time.nuts/20749 <pre>Hi Bob Actually, I checked the website before posting and Digi has drivers for Windows Vista and 2008 ( as well as XP, 2K and 98)-- I will see if it works on Win7 before posting what I have. What cards do you have? Dave </pre> DaveH 2012-05-23T18:45:40 http://permalink.gmane.org/gmane.comp.time.nuts/20748 <pre>Hi Henry: You might just try using a spreadsheet to calculate the complex impedance of your model circuit and manually play with the parameter values and get them to match the measured data. Have Fun, Brooke Clarke http://www.PRC68.com http://www.end2partygovernment.com/Clarke4Congress.html ehydra wrote: </pre> Brooke Clarke 2012-05-23T18:37:50 http://permalink.gmane.org/gmane.comp.time.nuts/20747 <pre>Hi time-nuts! If I remember correctly here was a discussion about an older HP impedance measurement equipment. The one which is able to calculate a 6 ideal parts replacement circuit for the measured passive device. How does is it works? I would like to fit parts for simulation in SPICE. So I need something like a algorithm to fit for minimum error a input table with complex numbers (frequency-sweep) to this 6 part circuit. For example the universal capacitor component in LTspice is able to hold RLC and even XTAL data and more like residual current for electrolytics. Any ideas? Thanks - Henry </pre> ehydra 2012-05-23T18:12:41 http://permalink.gmane.org/gmane.comp.time.nuts/20746 <pre>I had my Nortel running on the bench, in the open, for about 48 Hours, fed with a pretty good quality Lambda power supply. I suspect that any perceived diiference between it and the T'bolts may be down to the oven, which I suspect may be a double oven in the case of the Nortel. Due to the seller putting a sticky label on it helpfully saying "used" any identification has gone, but the size of it for it's age would indicate that it is something like the Morion inside. I don't see the temperature variation effects on the LH display that both my t'bolts show. It's performance at the 10,000 Tau level after 24 hours, with only the quick survey, and no tuning of any parameters was on a par with my T'bolt / E1938 and a little better than the standard t'bolt, all fed from the same antenna / splitter. It does, as Mark pointed out, see a better signal strength than the standard t'bolts, but as there are two RF amp stages visible on the board, with three filters, that doesn't surprise. I suspect the three LEDs grouped on the left of the little board may be more than just a "power on" indicator. Watching them and the LH 3.1 display with a cold start, I would guess that the red led is a cold oven / warm up indicator, and possibly the yellow one is a minor alert flag, with green being all OK. Only the imminent coming of the leap second will prove this one way or the other. The other two LEDs are steady green for phase lock, green flashing for recovery and the other, yellow, for holdover. These are all a bit delayed compared with the LH display. So, at the right price, worth getting, if you can live with the physical size and power supply needs. I'll be looking for a nice 2U case at the next swap meet. And many thanks to Mark for his swift LH changes! Dan </pre> Dan Rae 2012-05-23T17:35:53 http://permalink.gmane.org/gmane.comp.time.nuts/20745 <pre>Hi If the timing involved is NTP, I'm not so sure that a normal home lan with gigabit switches would be a problem. You can indeed saturate the poor thing. Unless you have a very unusual system, it is unlikely you will saturate it for very long or saturate it very often. NTP is pretty tolerant of the occasional burp of a few ms. Bob -----Original Message----- From: time-nuts-bounces-JSkTLETqlTM&lt; at &gt;public.gmane.org [mailto:time-nuts-bounces-JSkTLETqlTM&lt; at &gt;public.gmane.org] On Behalf Of Attila Kinali Sent: Wednesday, May 23, 2012 11:10 AM To: Discussion of precise time and frequency measurement Subject: Re: [time-nuts] Serial port server .. any interest in a write up on using ? On Wed, 23 May 2012 01:54:20 -0700 Hal Murray &lt;hmurray-8cQiHa/C+6Go9G/jEpaUCQ&lt; at &gt;public.gmane.org&gt; wrote: troubles Yes, i know. I deliberately did not saturate the link. I know that it looks quite differently if i do and that jitter will rise into the ms range even on a local LAN. But anyone who does work with precision timing in such an enviroment is lost anyways. If you do timing over ethernet, you are well advised to use a seperate network that does not carry any other traffic, use fast, low latency, high bandwidth switches, etc pp... Ofcourse unless you go the way of IEEE1588, but then you're playing in a different league and probably have the money to buy a Cs clock or two :-) As for the problem of serial ports (to come back to the original topic), i'd probably use just a bunch of USB serial cables (the ones from Exsys work quite good) if i don't need any timing information. They are cheap, readily available, and if they have FTDI chip, they also work fine. For timing.. I don't know. But i guess a small PC with some RS232 cards in (there are even 4port cards for PCI-E available, and they are not expensive) would be more than enough for the needs i have. Anything else seems to me like either overkill, or not fitting to the problem description. Attila Kinali </pre> Bob Camp 2012-05-23T16:08:33 http://permalink.gmane.org/gmane.comp.time.nuts/20744 <pre>On Wed, 23 May 2012 01:54:20 -0700 Hal Murray &lt;hmurray-8cQiHa/C+6Go9G/jEpaUCQ&lt; at &gt;public.gmane.org&gt; wrote: Yes, i know. I deliberately did not saturate the link. I know that it looks quite differently if i do and that jitter will rise into the ms range even on a local LAN. But anyone who does work with precision timing in such an enviroment is lost anyways. If you do timing over ethernet, you are well advised to use a seperate network that does not carry any other traffic, use fast, low latency, high bandwidth switches, etc pp... Ofcourse unless you go the way of IEEE1588, but then you're playing in a different league and probably have the money to buy a Cs clock or two :-) As for the problem of serial ports (to come back to the original topic), i'd probably use just a bunch of USB serial cables (the ones from Exsys work quite good) if i don't need any timing information. They are cheap, readily available, and if they have FTDI chip, they also work fine. For timing.. I don't know. But i guess a small PC with some RS232 cards in (there are even 4port cards for PCI-E available, and they are not expensive) would be more than enough for the needs i have. Anything else seems to me like either overkill, or not fitting to the problem description. Attila Kinali </pre> Attila Kinali 2012-05-23T15:09:32 http://permalink.gmane.org/gmane.comp.time.nuts/20743 <pre> Hi Tom, Thanks for replying to my request with some info. I went ahead and set the mode to AUTO. After your comment, I read the manual again and it says that the unit will transition to STATIONARY once it detects that the position has not changed for a while. As for the Windows control software, I managed to get it from Symmetricom. If anyone would like to get it, let me know and I will instruct how to. Best regards, Bert, VE2ZAZ -----Original Message----- Hi; It has been a while, I think in Auto Mode it will determine it's location in Survey Mode  1SW4?, and if stationary will switch to Stationary Mode 3SW4? as a Freq Standard. FW is Free Wheel Mode where the oscillator is undisciplined. These units with the Ovenized Quartz option have Phase Noise usally about -85/90 dB &lt; at &gt;1Hz with a floor of about 155/160dB max which is pretty good, but not quite as good as a units based on a 10811 for example. But quartz unit to unit vary widely and like the 10811 the datum oscillator is quite common. You most likely can find a premium one with far better specs. Where the ET6000 shines is features such as programmable inputs and outputs. The manual should be easy to find on line. Best Wishes; Thomas Knox </pre> Bert, VE2ZAZ 2012-05-23T13:31:13 http://permalink.gmane.org/gmane.comp.time.nuts/20742 <pre>I've had really good luck with anything based on the FTDI chip set. Other chip sets have given me problems... Dan On 5/22/2012 6:37 PM, time-nuts-request-JSkTLETqlTM&lt; at &gt;public.gmane.org wrote: </pre> Dan Kemppainen 2012-05-23T12:10:24 http://permalink.gmane.org/gmane.comp.time.nuts/20741 <pre>Hi I have a few of those from back in the BBS days. None of them seem to have drivers any more. Bob On May 23, 2012, at 12:52 AM, DaveH wrote: </pre> Bob Camp 2012-05-23T11:21:32 http://permalink.gmane.org/gmane.comp.time.nuts/20740 <pre> attila-HB9FjVmMKa7tRgLqZ5aouw&lt; at &gt;public.gmane.org said: [snip lots of low jitter samples] 1-2 megabytes/sec is 8-16 megabits/sec. You won't get into serious troubles until you saturate a link. With modern CPUs, it's trivial to saturate 100 megabit links and not very hard to saturate 1 gigabit links. With older/slower CPUs, you might run into problems a lot sooner. I'm not trying to discourage using these boxes. Just don't be surprised when you run into quirks if you are trying to use them for timing. (and don't depend upon loud mouths like me to point out all possible ways they can screw up) </pre> Hal Murray 2012-05-23T08:54:20 http://permalink.gmane.org/gmane.comp.time.nuts/20739 <pre>On Tue, 22 May 2012 17:28:47 -0700 Hal Murray &lt;hmurray-8cQiHa/C+6Go9G/jEpaUCQ&lt; at &gt;public.gmane.org&gt; wrote: On an ethernet it looks quite different: 64 bytes from kaos.kinali.ch (82.197.186.49): icmp_req=164 ttl=64 time=0.189 ms 64 bytes from kaos.kinali.ch (82.197.186.49): icmp_req=165 ttl=64 time=0.182 ms 64 bytes from kaos.kinali.ch (82.197.186.49): icmp_req=166 ttl=64 time=0.189 ms 64 bytes from kaos.kinali.ch (82.197.186.49): icmp_req=167 ttl=64 time=0.188 ms 64 bytes from kaos.kinali.ch (82.197.186.49): icmp_req=168 ttl=64 time=0.196 ms 64 bytes from kaos.kinali.ch (82.197.186.49): icmp_req=169 ttl=64 time=0.182 ms 64 bytes from kaos.kinali.ch (82.197.186.49): icmp_req=170 ttl=64 time=0.191 ms 64 bytes from kaos.kinali.ch (82.197.186.49): icmp_req=171 ttl=64 time=0.194 ms 64 bytes from kaos.kinali.ch (82.197.186.49): icmp_req=172 ttl=64 time=0.185 ms 64 bytes from kaos.kinali.ch (82.197.186.49): icmp_req=173 ttl=64 time=0.172 ms 64 bytes from kaos.kinali.ch (82.197.186.49): icmp_req=174 ttl=64 time=0.177 ms 64 bytes from kaos.kinali.ch (82.197.186.49): icmp_req=175 ttl=64 time=0.186 ms 64 bytes from kaos.kinali.ch (82.197.186.49): icmp_req=176 ttl=64 time=0.186 ms 64 bytes from kaos.kinali.ch (82.197.186.49): icmp_req=177 ttl=64 time=0.190 ms 64 bytes from kaos.kinali.ch (82.197.186.49): icmp_req=178 ttl=64 time=0.189 ms 64 bytes from kaos.kinali.ch (82.197.186.49): icmp_req=179 ttl=64 time=0.203 ms Network is a destkop - switch1 - switch2 - ntp box. The switches are two Level1 Gbit smart switches. The desktop is a ~4y old Xeon 2GHz system with a Gbit interface The ntp box is a AMD Geode LX 500MHz system with a 100MBit interface Both running linux. There aren't noticable more jitter for moderate (1-2 MByte/s) traffic. (Probably visible if i would do a statistical analysis...but..) Attila Kinali </pre> Attila Kinali 2012-05-23T06:12:40 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.comp.time.nuts