Re: [ntp:questions] Getting PPS to work with Oncore ref clock
Chris Albertson wrote: I have to admit I know nothing abut Linux serial PPS. My guess is I need to somehow set this up before I try to get it to work with NTP. My clockstats file is filled with the the messages quoted below. Is there something I can read. I've build ntpd with the required pps support, have the correct Linux kernel and header files, made links in /dev. Hard to know what's missing. The error messages are not very helpful It's difficult to know here, too without details of your reference clock hardware and ntp.conf. 55609 21559.296 127.127.30.0 ONCORE[0]: ONCORE: oncore_get_timestamp, error serial pps 55609 21589.292 127.127.30.0 ONCORE[0]: ONCORE: oncore_get_timestamp, error serial pps 55609 21619.312 127.127.30.0 ONCORE[0]: ONCORE: oncore_get_timestamp, error serial pps ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Getting PPS to work with Oncore ref clock
Hal Murray wrote: In article AANLkTikErZ-bkbwnFBQHWsNe7OUL=sx4oetg+9r_u...@mail.gmail.com, Chris Albertson albertson.ch...@gmail.com writes: I have to admit I know nothing abut Linux serial PPS. My guess is I need to somehow set this up before I try to get it to work with NTP. My clockstats file is filled with the the messages quoted below. Is there something I can read. I've build ntpd with the required pps support, have the correct Linux kernel and header files, made links in /dev. Hard to know what's missing. The error messages are not very helpful 55609 21559.296 127.127.30.0 ONCORE[0]: ONCORE: oncore_get_timestamp, error serial pps 55609 21589.292 127.127.30.0 ONCORE[0]: ONCORE: oncore_get_timestamp, error serial pps 55609 21619.312 127.127.30.0 ONCORE[0]: ONCORE: oncore_get_timestamp, error serial pps For things like this, your best bet is to look at the source code. Usually greping for the text in the error message won't get very many hits. I took a quick look. I think it's trying to tell you that it's not getting a PPS pulse. Do you have a scope? Is the hardware making PPS pulses? How wide are they? ... or even a LED + diode + resistor will be enough to show if there is a pulse. Radioclkd2 can be used in debug mode to confirm the single DCD pulse and width. David ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Getting PPS to work with Oncore ref clock
In article ia4v28-a6c@p4x2400c.home.lordynet.org, David Lord sn...@lordynet.org writes: or even a LED + diode + resistor will be enough to show if there is a pulse. Radioclkd2 can be used in debug mode to confirm the single DCD pulse and width. Some devices put out a narrow (10 microsecond) pulse. I don't know what the Oncore does. I have one PC that works fine with a narrow pulse and another PC that doesn't see it. I kludged together a pulse stretcher (diode, R, C) and it started working. Well, I thought it was working. It turns out that it only sees some of the pulses. -- These are my opinions, not necessarily my employer's. I hate spam. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Detecting bufferbloat via ntp?
In article slrnilckj1.3pd.nom...@xs8.xs4all.nl, Rob nom...@example.com writes: Hal Murray hal-use...@ip-64-139-1-69.sjc.megapath.net wrote: It would be good if someone (or someones) has actually been collecting rawstats for a long period, to serve as a baseline. Bufferbloat is a relatively new phenomenon. I'll bet it's been there for a long time. (meaning at least several years) I see delays up to 3 seconds, but only when I'm downloading a big file. I assume it's all queued up at the other end of my DSL link, but I can't prove that. When downloading a single big file causes you 3 second delays, you simply have set an insanely large TCP window. I didn't tweak anything. It's possible that my 3 second delay was while using Firefox rather than a simple download. -- These are my opinions, not necessarily my employer's. I hate spam. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Detecting bufferbloat via ntp?
In article ijhd7d$au6$1...@news.eternal-september.org, E-Mail Sent to this address will be added to the BlackLists Null@BlackList.Anitech-Systems.invalid writes: As far as I can tell the products have all the knobs they need to be properly configured to deal with the issue. The ISPs / NOC staff / IT departments / ... just aren't taking the time, to properly / fully configure the products, rather than just the minimal configuration necessary to make it work. The defaults have to work reasonably well. The support staff doesn't have enough time to help each user setup their system correctly. -- These are my opinions, not necessarily my employer's. I hate spam. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Getting PPS to work with Oncore ref clock
At 01:16 AM 2/17/2011, Chris Albertson wrote... My guess is I need to somehow set this up before I try to get it to work with NTP. Yes, NTP messages aren't very informative. Do you have the pps-tools(ppstest specifically)? Info at http://wiki.enneenne.com/index.php/LinuxPPS_installation#The_userland_tools Get your source working with ppstest working before you try NTP. When your PPS source is set up and working, you should get something like: locke:/usr/src/pps-tools# ./ppstest /dev/pps0 trying PPS source /dev/pps0 found PPS source /dev/pps0 ok, found 1 source(s), now start fetching data... source 0 - assert 1297945532.64855, sequence: 1967640 - clear 0.0, sequence: 0 source 0 - assert 1297945533.45499, sequence: 1967641 - clear 0.0, sequence: 0 ... PPS should be connected to the DCD input. With my source (Trimble Thunderbolt, has a 10-20 us PPS pulse), I had to change the signal polarity. The RS-232 port would not see a positive going PPS pulse, but a negative going one is fine. The Thunderbolt has a command to change polarity. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Getting PPS to work with Oncore ref clock
On 2011-02-17, Hal Murray hal-use...@ip-64-139-1-69.sjc.megapath.net wrote: Some devices put out a narrow (10 microsecond) pulse. I don't know what the Oncore does. I have one PC that works fine with a narrow pulse and another PC that doesn't see it. I kludged together a pulse stretcher (diode, R, C) and it started working. Well, I thought it was working. It turns out that it only sees some of the pulses. My copy of the Oncore Engineering Note shows a 200 ms. pulse width for the PPS signal. It all may depend on the original poster's Oncore version. My book only covers the VP, VT and UT. The newer 12 channel ones may be different. Tom -- Public Keys: PGP KeyID = 0x5F22FDC1 GnuPG KeyID = 0x620836CF ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Getting PPS to work with Oncore ref clock
On 2/17/2011 5:03 AM, Hal Murray wrote: In articleia4v28-a6c@p4x2400c.home.lordynet.org, David Lordsn...@lordynet.org writes: or even a LED + diode + resistor will be enough to show if there is a pulse. Radioclkd2 can be used in debug mode to confirm the single DCD pulse and width. Some devices put out a narrow (10 microsecond) pulse. I don't know what the Oncore does. ISTR that the Oncore uses a pulse with *one* edge within 50 nanoseconds! I don't recall which edge is the time mark. I doubt if it matters much after your computer brutalizes it. If you really need to know, you can try to track down the company that bought the technology from Motorola; I no longer recall the name. You might even try Google to search for the details snip ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Detecting bufferbloat via ntp?
From: hal-use...@ip-64-139-1-69.sjc.megapath.net (Hal Murray) Date: Thu, 17 Feb 2011 04:52:36 -0600 Sender: questions-bounces+oberman=es@lists.ntp.org In article slrnilckj1.3pd.nom...@xs8.xs4all.nl, Rob nom...@example.com writes: Hal Murray hal-use...@ip-64-139-1-69.sjc.megapath.net wrote: It would be good if someone (or someones) has actually been collecting rawstats for a long period, to serve as a baseline. Bufferbloat is a relatively new phenomenon. I'll bet it's been there for a long time. (meaning at least several years) I see delays up to 3 seconds, but only when I'm downloading a big file. I assume it's all queued up at the other end of my DSL link, but I can't prove that. When downloading a single big file causes you 3 second delays, you simply have set an insanely large TCP window. I didn't tweak anything. It's possible that my 3 second delay was while using Firefox rather than a simple download. This is a long shot, but DNS timeout is usually 4 seconds. Could there be some DNS issue? -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: ober...@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Getting PPS to work with Oncore ref clock
The pointer to ppstest might be what I need, a way to see it it's working without depending on ntpd being configured correctly. I'll try it this weekend. I have an LED on my Oncore and I can see by eye the pulse is roughly 0.2 seconds, certainly not in the microseconds range. The PPS goes to a 74F04 inverter then to a MAX232 TTL - RS232 level converter then to pin one of the serial cable. Before I post here again I'll be sure to measure pin-1 using a breakout box at the computer's end of the cable, (It's a 75 foot serial cable.) I suspect a software configuration problem or maybe polarity. The other thing I was looking for was documentation. If the source code it it. I'll read it. -- = Chris Albertson Redondo Beach, California ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] GPX18x LVC 3.50 firmware - high serial delay problem workround
David J Taylor david-tay...@blueyonder.co.uk.invalid wrote in message news:ijhb50$ifm$1...@news.eternal-september.org... V3.60 was out at the start of Jan I think - but there is nothing in the notes to say this issue is resolved. Do we need to chase this with Garmin UK? Yes, we do. I've heard nothing back, so I'll chase them now. I'm supposed to be on the Garmin RSS feed for updates, but I didn't see 3.60 announced. I've now downloaded a copy but, as you say, it doesn't claim to address the issue. I'm still waiting for my Sure Electronics equivalent to arrive from China: Ok I'll go back over your past posts re the problem and report it myself to Garmin UK and see what they say - once I get something back I'll let you know. I have 3.60 running anyway with no new problems (that I can see) ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] GPX18x LVC 3.50 firmware - high serial delay problem workround
David J Taylor wrote: I'm supposed to be on the Garmin RSS feed for updates, but I didn't see 3.60 announced. I've now downloaded a copy but, as you say, it doesn't claim to address the issue. I'm still waiting for my Sure Electronics equivalent to arrive from China: http://www.sureelectronics.net/goods.php?id=99 Thanks for the link! Even though I already have a big bunch of GPSs, I've placed an order for one of those kits. :-) I really liked the multiple interfaces, the ms precision for the NMEA timestamp and the total price which is below the minimum import duty floor here in Norway. :-) Terje -- - Terje.Mathisen at tmsw.no almost all programming can be viewed as an exercise in caching ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Getting PPS to work with Oncore ref clock
Mike wrote: Yes, NTP messages aren't very informative. ... Patches or bug/enhancement requests are welcome. H ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Getting PPS to work with Oncore ref clock
In article aanlktimlss1bjtrde77av92-wwfyr_g7ovm7zd0yr...@mail.gmail.com, Chris Albertson albertson.ch...@gmail.com writes: (It's a 75 foot serial cable.) I suspect a software configuration problem or maybe polarity. If the polarity is wrong, you will just use the other edge. It will be off in timing by the pulse width. It will appear to work, just get the wrong answer. -- These are my opinions, not necessarily my employer's. I hate spam. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] GPX18x LVC 3.50 firmware - high serial delay problem workround
Ok I'll go back over your past posts re the problem and report it myself to Garmin UK and see what they say - once I get something back I'll let you know. I have 3.60 running anyway with no new problems (that I can see) Thanks, Q, I can't see it doing any harm. Cheers, David ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Getting PPS to work with Oncore ref clock
At 02:59 PM 2/17/2011, Hal Murray wrote... If the polarity is wrong, you will just use the other edge. It will be off in timing by the pulse width. It will appear to work, just get the wrong answer. Not necessarily. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Detecting bufferbloat via ntp?
Hal Murray wrote: BlackLists wrote: As far as I can tell the products have all the knobs they need to be properly configured to deal with the issue. The ISPs / NOC staff / IT departments / ... just aren't taking the time, to properly / fully configure the products, rather than just the minimal configuration necessary to make it work. The defaults have to work reasonably well. The support staff doesn't have enough time to help each user setup their system correctly. If the only issue is enduser equipment configuration, then its not going to bring down the whole internet (as implied), as the transit equipment can deal with it as necessary; If the transit equipment features to deal with it were enabled, (which the implication is that is not happening). ISPs, Data Centers, Backbone transit providers, all have to configure their routers, that they apparently chose not to configure the features necessary to mitigate the issue, is what all the hysteria about buffer-bloat appears to be about. To keep it slightly on topic; This means some NTP packets may get excessively delayed or thrown away in transit; Due to too many TCP packets, buffered for too long. For so long that the TCP retries might even reach the same huge buffer. Then the newest packets start getting dropped at the router, as compared to some mitigation techniques, that throw away packets at random when a much smaller buffer starts getting full (still might be a NTP packet that gets dropped). There are also other mitigation techniques the routers can use, that will inform up stream and down stream routers that traffic is backing up at the router in between. The upstream / downstream routers may also start dropping packets after awhile to mitigate the issue, as well as telling the paths up and down stream of the traffic backup. Eventually it might reach all the way back to (yes) the enduser's equipment, and if that end users equipment follows to the traffic jam notification, it is supposed to slow its output pace till the notification goes away. -- E-Mail Sent to this address blackl...@anitech-systems.com will be added to the BlackLists. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Getting PPS to work with Oncore ref clock
On 2/17/2011 12:55 PM, Chris Albertson wrote: The pointer to ppstest might be what I need, a way to see it it's working without depending on ntpd being configured correctly. I'll try it this weekend. I have an LED on my Oncore and I can see by eye the pulse is roughly 0.2 seconds, certainly not in the microseconds range. The PPS goes to a 74F04 inverter then to a MAX232 TTL - RS232 level converter then to pin one of the serial cable. Before I post here again I'll be sure to measure pin-1 using a breakout box at the computer's end of the cable, (It's a 75 foot serial cable.) I suspect a software configuration problem or maybe polarity. The other thing I was looking for was documentation. If the source code it it. I'll read it. I installed my Motorola Oncore several years ago. It was not difficult. I used a standard 9-pin serial cable, plugged one end into the Oncore circuit board and the other into a serial port. I put the hockey puck antenna on top of a Leaf Guard rain gutter. The gutter makes clever use of surface tension to guide water into the gutter and keep vegetable debris out. You must install and configure NTPD software. I've long forgotten the details. ISTR that it was reasonably well documented. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Getting PPS to work with Oncore ref clock
On 2/17/2011 2:59 PM, Hal Murray wrote: In articleaanlktimlss1bjtrde77av92-wwfyr_g7ovm7zd0yr...@mail.gmail.com, Chris Albertsonalbertson.ch...@gmail.com writes: (It's a 75 foot serial cable.) I suspect a software configuration problem or maybe polarity. You should also consider possible problems with the serial cable. The RS232-C standard says fifty feet is the maximum length. Many people have used cable runs far longer than fifty feet. It frequently works but when it doesn't you'll find sympathy in the dictionary! Use high quality cable. The cable run should avoid fluorescent lights, electric motors, and other sources of interference! snip ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Getting PPS to work with Oncore ref clock
On Thu, Feb 17, 2011 at 2:29 PM, Richard B. Gilbert rgilber...@comcast.net wrote: You should also consider possible problems with the serial cable. The RS232-C standard says fifty feet is the maximum length. Many people have used cable runs far longer than fifty feet. It frequently works but when it doesn't you'll find sympathy in the dictionary! I don't think it is a cable problem. The 9600 baud serial data comes through just fine. I can read all the data from the GPS just fine and it is logged without error. I'm using Cat-5 cable inside conduit. I'm still suspecting the problem is related to setting up Linux PPS. The MAX232 chip is actually a very good cable driver -- = Chris Albertson Redondo Beach, California ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Detecting bufferbloat via ntp?
Hal Murray hal-use...@ip-64-139-1-69.sjc.megapath.net wrote: In article slrnilckj1.3pd.nom...@xs8.xs4all.nl, Rob nom...@example.com writes: When downloading a single big file causes you 3 second delays, you simply have set an insanely large TCP window. I didn't tweak anything. If you are running Linux you didn't need to as it will have opened-up the receive window beyond the needs of the bandwidth delay product. And if the other side was also Linux, it will have taken advantage of it. Or at least to a high degree of probability, given it will let the socket buffers/windows grow to 4MB by default. 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] Detecting bufferbloat via ntp?
Dave Täht d...@taht.net wrote: Rick Jones rick.jon...@hp.com writes: Or rather, that even after setting the tx queue lengths to 32 packets, a test between that system and one 7ms away still resulted in 4MB socket buffers by the end of the test. Ie confirming that the linux autotuning code was still willing to grow the windows larger than necessary. Better said. The evidence of bloat is not conclusive. Did you give vegas a shot? Nope. While my posting here suggests otherwise, I've been rather busy with the day job :) A *little* is just fine. Bloated buffers - containing hundreds, thousands, tens of thousands of packets - which is what we are seeing today - is not. Well, the BDP of a 10GbE link might actually be measured in thousands of packets or more... if my systems 7 ms apart were joined by a 10 GbE link, that would be a bit more then 5800, 1500 byte packets. I'm thinking that while we may have to configure queues in terms of number of packets, we shouldn't think of them that way, but as length of time. I agree, the dynamic range of todays devices presents a problem. Perhaps then, to keep the delays for NTP traffic small (trying to keep on topic :) the user interface for configuring txqueues should take a maximum expected RTT, which it can then combine with the known speed of the interface to arrive at a number of packets for the queue. As the default anyway. And if there is no information as to the maximum expected RTT, perhaps use a non-trivial fraction of the IETF's suggested minimum RTO. Then the device can say I am running at N bits per second and when I was created the RTO was 1000 milliseconds, 90% of which is 0.9 seconds, and my MTU is M so I should have a default txqueue of 0.9N/8/M +1 packets. Now the default is automagic no matter what the link speed. 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 http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Getting PPS to work with Oncore ref clock
On Thu, Feb 17, 2011 at 4:40 AM, Mike S mi...@flatsurface.com wrote: At 01:16 AM 2/17/2011, Chris Albertson wrote... Get your source working with ppstest working before you try NTP. When your PPS source is set up and working, you should get something like: locke:/usr/src/pps-tools# ./ppstest /dev/pps0 trying PPS source /dev/pps0 found PPS source /dev/pps0 ok, found 1 source(s), now start fetching data... source 0 - assert 1297945532.64855, sequence: 1967640 - clear 0.0, sequence: 0 source 0 - assert 1297945533.45499, sequence: 1967641 - clear 0.0, sequence: 0 I stopped ntpd then ran ppstest. It produces the following: sudo /usr/src/pps-tools/ppstest /dev/oncore.pps.0 trying PPS source /dev/oncore.pps.0 found PPS source /dev/oncore.pps.0 ok, found 1 source(s), now start fetching data... source 0 - assert 1298011155.999464502, sequence: 64785 - clear 1297840243.197985597, sequence: 36 source 0 - assert 1298011156.999460038, sequence: 64786 - clear 1297840243.197985597, sequence: 36 source 0 - assert 1298011157.999458883, sequence: 64787 - clear 1297840243.197985597, sequence: 36 source 0 - assert 1298011158.999457012, sequence: 64788 - clear 1297840243.197985597, sequence: 36 I don't know what all of this means but I see the time increment by about 1 second every second Here is the ntp.conf file. I've tried to keep it small and simple for now $ cat /etc/ntp.conf driftfile /var/lib/ntp/ntp.drift # Enable this if you want statistics to be logged. statsdir /var/log/ntpstats/ logconfig =all statistics loopstats peerstats clockstats filegen loopstats file loopstats type day enable filegen peerstats file peerstats type day enable filegen clockstats file clockstats type day enable disable auth # Connect to Oncore UT+ GPS server 127.127.30.0 server 0.us.pool.ntp.org server 1.us.pool.ntp.org server 2.us.pool.ntp.org And the the ntp.oncore.0 file $ cat ntp.oncore.0 MODE 2 SHMEM /var/log/ntpstats/ONCORE POSN3D I doubt the SHMEM line is correct but I'll worry about that later -- = Chris Albertson Redondo Beach, California ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
