Re: [time-nuts] Raspberry Pi tweaks and custom kernel, was RE: PPS for NTP Server - How Close Is Good Enough?
Hi Unless you have fancy switches on your LAN (1588 stamping), PTP performance will be dependent on load and the “goodness” of the switches you do have. These are pretty much the same (external) things that impact NTP. On a LAN with variable loading (time to stream some movies …) the advantage of PTP over NTP may not be that great. Bob On Jun 15, 2015, at 10:15 AM, Chris Caudle ch...@chriscaudle.org wrote: On Mon, June 15, 2015 1:23 am, David J Taylor wrote: I don't think either system is good enough as a microsecond level server, but either is fine for tenth millisecond level. The BeagleBone Black has the advantage that you can run one of the timers from an external input, so you can use the 10MHz from your GPSDO to drive the timer (takes care of temperature variations of the system clock), and have the timer captured based on the PPS input (eliminates interrupt latency as a factor in capturing the timer). With that setup you should be able to get into the high nanoseconds stability range. For transfer to other systems the BBB Ethernet supports PTP, so you should be able to get just under microsecond level synchronization between systems on the same LAN. Here is someone working on connecting a NavSpark GPS to a BBB. I don't think I have seen his name on the 'Nuts list, but I don't recall for sure. http://blog.dan.drown.org/ -- 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. ___ 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.
Re: [time-nuts] My HP 5370B reads 6 nS out!
Frank; Thanks for your long and detailed explanation. I was able to get the internal OCXO to that precision but it was probably luck to get the trimmer that close. I worked at it for a while. I am using T.I. mode with the averaging mode. I assumed that it took 10K readings and averaged the results. Is that not correct? Is something mode complicated going on? I will have to set up the GPIB and give that a try. I did get TimeLab. This will be new territory to me. I did try measuring it's own 10 MHz frequency with 1 sec gate time. It bounces around by about +- 4 in the 10th decimal place. Is my calibration with the rubidium oscillator valid? Could it be that far off? I will have to ponder this some more. Pete. -Original Message- From: time-nuts [mailto:time-nuts-boun...@febo.com] On Behalf Of Frank Stellmach Sent: Monday, June 15, 2015 5:01 PM To: time-nuts@febo.com Subject: [time-nuts] My HP 5370B reads 6 nS out! Pete, you do not specify, whether you use FREQ or T.I. when you use the averaging function. First of all, its OCXO can be adjusted to a few parts in 1e-9 only, as the trimmer is too unprecise. If the OCXO is running for several weeks already (idle state), its drift may be as low as a few parts in 1e-10 or better. If you put the instrument to FREQ mode, you may measure and the 10MHz of the GPSDO standard to about 2e-11 resolution, if you use 1sec time base on the 5370B. That should work also, if you directly measure 1pps, but you have to properly adjust the trigger level. Important: Don't use the 10k statistics, set the 5370A also to 1sec time base! Due to this low frequency, jitter should be higher, see specifications. You better do statistics by means of a PC, over GPIB. That will show the 30ps jitter of the 5370B, and the jitter of the GPSDO, on the order of 1e-10. You may also calibrate the OCXO of the 5370B this way, instead of that oscilloscope method. I strongly recommend Timelab from John Miles to do these measurements properly. http://www.ke5fx.com/timelab/readme.htm If you use the internal 10k statistics 10k, pay attention!! In this instance, the 5370B will do the frequency measurement in a different manner.. Not 100% sure, it will be a sort of a T.I. measurement, calculated to frequency. And that may produce a constant offset, if the internal T.I. calibration is not done properly. Look into the specs, its absolute T.I. uncertainty is 1ns only, although it resolves 20ps. You may check that behaviour, if you apply its own 10Mhz OCXO ouput to the FREQ input, and measure this frequency first on FREQ, 1sec. That should give nearly exactly 10MHz, 1e-10 jitter or deviation. Mine reads 9.999 999 999 85 MHz, for example. If you now switch to AVERAGE, SAMPLE SIZE 1, 100, 1k, 10K, you will see, that you will get big deviations as big as 0.1%, although it should measure its own OCXO to precisely 10.0MHZ. Mine reads 9,989 294 5 MHz, for example. That's due to the different measurement method, and should explain 6..7ns deviation on the 1pps signal also. This averaging should only be used with T.I.! Frank ___ 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.
Re: [time-nuts] Raspberry Pi tweaks and custom kernel, was RE: PPS for NTP Server - How Close Is Good Enough?
On Mon, June 15, 2015 8:01 pm, Bob Camp wrote: Unless you have fancy switches on your LAN (1588 stamping), PTP performance will be dependent on load and the goodness of the switches you do have. These are pretty much the same (external) things that impact NTP. Yes, but proper differentiated services setup with multiple queues can help mitigate that to a large extent. I'm still trying to get my PTP setup going, so I don't have any measurements of my own yet, but there are lots of examples of large commercial systems in use without transparent clock support which can maintain sub-microsecond synchronization. Using PTP transparent switches should get down into the couple hundred nanosecond range or better, but even without 800 or so nanoseconds has been shown to be consistently possible. I have no idea what level of synchronization you could keep using just NTP with diffserv. That might be an interesting experiment to try for those who only want NTP and aren't interested in setting up PTP. -- 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.
Re: [time-nuts] Using CPLD/FPGA or similar for frequency
Hi I’ve spent a lot of time with both of those papers and with a couple of others in the “series’. The gotcha is in the interpretation of the calibration results. It is often very unclear which pattern comes before which other pattern. Since the internal PLL’s have jitter in the 20 to 30 ps RMS range, that limits a lot of the data you get. Bob On Jun 15, 2015, at 6:03 PM, Attila Kinali att...@kinali.ch wrote: On Wed, 10 Jun 2015 21:45:33 -0400 Bob Camp kb...@n1k.org wrote: The delay line in an FPGA approach might get you to 20 ps. There is a lot of hand waving in the calibration process to get there. ( = figuring out that state A came before state B is based on things that are difficult to prove). If you do get it calibrated, you then find that it’s sensitive to both supply voltage and to temperature. The supply thing you can take care of with a good regulator. The “shifts all over the place when you put your thumb on it” T/C is not quite as easy to deal with. A TDC using an R/C and an ADC is a *much* easier way to go. Just two references on this topic: [1] Is AFAIK the only way to get FPGAs below the intrinsic cell delay (which is varies between a min of 10-20ps and a max of 100-200ps within the same FPGA) And [2] gives an idea how a possible calibration system might work. Attila Kinali [1] The 10-ps wave union TDC: Improving FPGA TDC resolution beyond its cell delay, by Wu, Jinyuan and Shi, Zonghan, 2008 http://dx.doi.org/10.1109/NSSMIC.2008.4775079 [2] Statistical Linearity Calibration of Time-To-Digital Converters Using a Free-Running Ring Oscillator, by Rivior, 2006 http://dx.doi.org/10.1109/ATS.2006.260991 -- I must not become metastable. Metastability is the mind-killer. Metastability is the little-death that brings total obliteration. I will face my metastability. I will permit it to pass over me and through me. And when it has gone past I will turn the inner eye to see its path. Where the metastability has gone there will be nothing. Only I will remain. ___ 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.
Re: [time-nuts] Using CPLD/FPGA or similar for frequency
kb...@n1k.org said: Since the internal PLLâs have jitter in the 20 to 30 ps RMS range, that limits a lot of the data you get. I haven't looked recently, but I doubt if much has changed. Xilinx uses DLLs rather than PLLs. They have a long chain of buffers and a giant multiplexor to select the right tap. Does anybody have data on what the jitter actually looks like? I'd expect several blurry peaks, with the spacing between peaks being the step size of the delay/mux chain and the blur being wider if there is more random logic. -- These are my opinions. I hate spam. ___ 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.
Re: [time-nuts] Using CPLD/FPGA or similar for frequency
Using an ADC to sample a triggered damped sinewave easily achieves 5ps resolution (eg Keysight Acquiris). With a better optimised waveform model and least squares fitting routine greater resolution is feasible. The accuracy is dependent on the ADC sampling clock stability. An optical frequency standard derived clock may be required to maintain ps accuracy for long time intervals. Bruce On Tuesday, June 16, 2015 12:14:01 AM Attila Kinali wrote: On Thu, 11 Jun 2015 14:22:58 + Alan Ambrose alan.ambr...@anagram.net wrote: A clever interpolator for frequency or TIC would kill it - for TIC essentially a PICTIC on steroids. The PICTIC does 19pS with a 10 bit ADC and a 66MHz clock, an SR620 does 4pS with a 12 bit ADC and an 80 MHz clock - so ... cough ... Spartan 3E at 256MHz with 16 bit ADC - and 1pS should be easy Which architecture for the FPGA do you have in mind? The delay line method (which is the most common one for FPGAs) has an intrinsic limit around 10-20ps. But the SR620 and the PICTIC use both a time to amplitude conversion by charging a capacitor (both include a Nutt interpolator). Using this technique, it might be possible to get into the 1ps ballpark, if the design is done carefully (according to Richard McCorkle, the limiting factor for the PICTIC II was the ADC of the PIC, followed by the stability of the reference clock). Attila Kinali ___ 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.
Re: [time-nuts] Using CPLD/FPGA or similar for frequency
Hi Coming up with a reference clock can be harder than you might think. Most of the jitter numbers you see published on frequency sources are based on a “jitter mask” that runs from (maybe) 10 KHz up to 20 MHz. That’s fine for a specific telecom need. It may not in any way apply to capturing a 1 pps pulse. *IF* you believe the phase noise to jitter integration stuff (and there are reasons not to) the jitter goes way up as you integrate closer to carrier. A 0.1 ps source can quickly turn into a 10 or 100 ps source with a change of the lower bound on the jitter mask. Now, once you have the jitter number, you are only part way to knowing it’s impact on your measurement. There are *always* more things to consider. Bob On Jun 15, 2015, at 6:14 PM, Attila Kinali att...@kinali.ch wrote: On Thu, 11 Jun 2015 14:22:58 + Alan Ambrose alan.ambr...@anagram.net wrote: A clever interpolator for frequency or TIC would kill it - for TIC essentially a PICTIC on steroids. The PICTIC does 19pS with a 10 bit ADC and a 66MHz clock, an SR620 does 4pS with a 12 bit ADC and an 80 MHz clock - so ... cough ... Spartan 3E at 256MHz with 16 bit ADC - and 1pS should be easy Which architecture for the FPGA do you have in mind? The delay line method (which is the most common one for FPGAs) has an intrinsic limit around 10-20ps. But the SR620 and the PICTIC use both a time to amplitude conversion by charging a capacitor (both include a Nutt interpolator). Using this technique, it might be possible to get into the 1ps ballpark, if the design is done carefully (according to Richard McCorkle, the limiting factor for the PICTIC II was the ADC of the PIC, followed by the stability of the reference clock). Attila Kinali -- I must not become metastable. Metastability is the mind-killer. Metastability is the little-death that brings total obliteration. I will face my metastability. I will permit it to pass over me and through me. And when it has gone past I will turn the inner eye to see its path. Where the metastability has gone there will be nothing. Only I will remain. ___ 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.
Re: [time-nuts] Raspberry Pi tweaks and custom kernel, was RE: PPS for NTP Server - How Close Is Good Enough?
On Mon, June 15, 2015 1:23 am, David J Taylor wrote: I don't think either system is good enough as a microsecond level server, but either is fine for tenth millisecond level. The BeagleBone Black has the advantage that you can run one of the timers from an external input, so you can use the 10MHz from your GPSDO to drive the timer (takes care of temperature variations of the system clock), and have the timer captured based on the PPS input (eliminates interrupt latency as a factor in capturing the timer). With that setup you should be able to get into the high nanoseconds stability range. For transfer to other systems the BBB Ethernet supports PTP, so you should be able to get just under microsecond level synchronization between systems on the same LAN. Here is someone working on connecting a NavSpark GPS to a BBB. I don't think I have seen his name on the 'Nuts list, but I don't recall for sure. http://blog.dan.drown.org/ -- 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.
[time-nuts] Heol Design N024 GPS receiver
So we finally got in our test Heol N024 GPS replacement board for the Trimble Ace III that ran into the 1995 rollover and most notably affected just about everyone with a Datum/Symmetricom/Microsemi TymServe 2100. As Olivier Descoubes (the contact at Heol) posted I can confirm that their firmware has corrected both the 1995 rollover and the 1 second UTC offset that has been plaguing us since winter. I tried it in the oldest Firmware that is the backup on the 2100 in case of failure (v 2.84 I think) along with versions 3.1 and currently running back up on 4.1. Also the board works with the Datum BC635pci cards as well for anyone that uses those. Finally I am getting good time again to my servers without a mad scientist setup going on. Full disclaimer though the price has increased. The original N024 boards were I believe 95 euro and are still available as such. However these will not work with the TS2100 or bc635pci cards. It looked like it was getting the location data right when I looked through some settings on the 2100 but it won't translate the timing data right. The V2 has the updated firmware that corrects the issues and works properly but the price has gone up to something like 245 euro. Plus it's shipping from France so you're looking at over $300 for this solution. This was due to them putting in about 2-3 weeks of development and they also purchased a 2100 for testing. They hope that after they sell some units and offset those costs they can lower the price gradually down again. I must say however that this $300 solution for us is far superior to the $7,000 3xxx series replacement solution that Microsemi was trying to sell me. Also Heol is stating a 1 year hardware warranty and supporting the software to 2035. I must say that with this support and maybe replacing my oscillator ( I think the original factory is still in mine) that I can get years of service out of this still and not break the bank. Respectfully, Sean Gallagher Malware Analyst 571-340-3475 ___ 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.
Re: [time-nuts] Heol Design N024 GPS receiver
It also has better performance than the original board and some newer NTP servers that use older GPS. This is just based off of data that I'm reading. I'm not proficient enough to do testing and analysis on it other than the data sheet and what my TymServe display tells me. If anyone has any questions I'd be more than happy to try and answer them however I don't really know all the technical stuff as well as most of you do. Respectfully, Sean Gallagher Malware Analyst 571-340-3475 -- Original Message -- From: Sean Gallagher s...@wetstonetech.com To: time-nuts@febo.com time-nuts@febo.com Sent: 6/15/2015 2:31:02 PM Subject: Heol Design N024 GPS receiver So we finally got in our test Heol N024 GPS replacement board for the Trimble Ace III that ran into the 1995 rollover and most notably affected just about everyone with a Datum/Symmetricom/Microsemi TymServe 2100. As Olivier Descoubes (the contact at Heol) posted I can confirm that their firmware has corrected both the 1995 rollover and the 1 second UTC offset that has been plaguing us since winter. I tried it in the oldest Firmware that is the backup on the 2100 in case of failure (v 2.84 I think) along with versions 3.1 and currently running back up on 4.1. Also the board works with the Datum BC635pci cards as well for anyone that uses those. Finally I am getting good time again to my servers without a mad scientist setup going on. Full disclaimer though the price has increased. The original N024 boards were I believe 95 euro and are still available as such. However these will not work with the TS2100 or bc635pci cards. It looked like it was getting the location data right when I looked through some settings on the 2100 but it won't translate the timing data right. The V2 has the updated firmware that corrects the issues and works properly but the price has gone up to something like 245 euro. Plus it's shipping from France so you're looking at over $300 for this solution. This was due to them putting in about 2-3 weeks of development and they also purchased a 2100 for testing. They hope that after they sell some units and offset those costs they can lower the price gradually down again. I must say however that this $300 solution for us is far superior to the $7,000 3xxx series replacement solution that Microsemi was trying to sell me. Also Heol is stating a 1 year hardware warranty and supporting the software to 2035. I must say that with this support and maybe replacing my oscillator ( I think the original factory is still in mine) that I can get years of service out of this still and not break the bank. Respectfully, Sean Gallagher Malware Analyst 571-340-3475 ___ 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.
Re: [time-nuts] Raspberry Pi tweaks and custom kernel, was RE: PPS for NTP Server - How Close Is Good Enough?
Hi Just to be clear, your peer delay numbers for the Pi show and improvement from 0.5 ms down to 0.3 ms with some tweaks. A “non-usb” ethernet setup can get those delays down much further. In the context of the original question “tweaking the USB drivers” this is what was being addressed. Bob = Thanks, Bob. With the “non-usb” Ethernet BBB the mean delay was 0.173 ms compared with the RPi 0.352 ms. Values of mean delay from other LAN systems ranged from 0.167 ms (Win-7/64) to 0.209 ms (Win-8.1), so perhaps with that particular client PC (Linux, Intel Atom) the values all within the noise of being as good as can be achieved. If that's true, the extra delay introduced by the RPi's USB/Ethernet is some 0.18 ms. NTP will measure and compensate for that delay, which helps explain why the resulting mean offset is just -39 microseconds with the RPi (-19 microseconds with the BBB, -1 to +24 microseconds with other GPS-synced systems). I don't think either system is good enough as a microsecond level server, but either is fine for tenth millisecond level. Cheers, David -- SatSignal Software - Quality software written to your requirements Web: http://www.satsignal.eu Email: david-tay...@blueyonder.co.uk ___ 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] My HP 5370B reads 6 nS out!
Pete, you do not specify, whether you use FREQ or T.I. when you use the averaging function. First of all, its OCXO can be adjusted to a few parts in 1e-9 only, as the trimmer is too unprecise. If the OCXO is running for several weeks already (idle state), its drift may be as low as a few parts in 1e-10 or better. If you put the instrument to FREQ mode, you may measure and the 10MHz of the GPSDO standard to about 2e-11 resolution, if you use 1sec time base on the 5370B. That should work also, if you directly measure 1pps, but you have to properly adjust the trigger level. Important: Don't use the 10k statistics, set the 5370A also to 1sec time base! Due to this low frequency, jitter should be higher, see specifications. You better do statistics by means of a PC, over GPIB. That will show the 30ps jitter of the 5370B, and the jitter of the GPSDO, on the order of 1e-10. You may also calibrate the OCXO of the 5370B this way, instead of that oscilloscope method. I strongly recommend Timelab from John Miles to do these measurements properly. http://www.ke5fx.com/timelab/readme.htm If you use the internal 10k statistics 10k, pay attention!! In this instance, the 5370B will do the frequency measurement in a different manner.. Not 100% sure, it will be a sort of a T.I. measurement, calculated to frequency. And that may produce a constant offset, if the internal T.I. calibration is not done properly. Look into the specs, its absolute T.I. uncertainty is 1ns only, although it resolves 20ps. You may check that behaviour, if you apply its own 10Mhz OCXO ouput to the FREQ input, and measure this frequency first on FREQ, 1sec. That should give nearly exactly 10MHz, 1e-10 jitter or deviation. Mine reads 9.999 999 999 85 MHz, for example. If you now switch to AVERAGE, SAMPLE SIZE 1, 100, 1k, 10K, you will see, that you will get big deviations as big as 0.1%, although it should measure its own OCXO to precisely 10.0MHZ. Mine reads 9,989 294 5 MHz, for example. That's due to the different measurement method, and should explain 6..7ns deviation on the 1pps signal also. This averaging should only be used with T.I.! Frank ___ 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.
Re: [time-nuts] Using CPLD/FPGA or similar for frequency
On Wed, 10 Jun 2015 21:45:33 -0400 Bob Camp kb...@n1k.org wrote: The delay line in an FPGA approach might get you to 20 ps. There is a lot of hand waving in the calibration process to get there. ( = figuring out that state A came before state B is based on things that are difficult to prove). If you do get it calibrated, you then find that it’s sensitive to both supply voltage and to temperature. The supply thing you can take care of with a good regulator. The “shifts all over the place when you put your thumb on it” T/C is not quite as easy to deal with. A TDC using an R/C and an ADC is a *much* easier way to go. Just two references on this topic: [1] Is AFAIK the only way to get FPGAs below the intrinsic cell delay (which is varies between a min of 10-20ps and a max of 100-200ps within the same FPGA) And [2] gives an idea how a possible calibration system might work. Attila Kinali [1] The 10-ps wave union TDC: Improving FPGA TDC resolution beyond its cell delay, by Wu, Jinyuan and Shi, Zonghan, 2008 http://dx.doi.org/10.1109/NSSMIC.2008.4775079 [2] Statistical Linearity Calibration of Time-To-Digital Converters Using a Free-Running Ring Oscillator, by Rivior, 2006 http://dx.doi.org/10.1109/ATS.2006.260991 -- I must not become metastable. Metastability is the mind-killer. Metastability is the little-death that brings total obliteration. I will face my metastability. I will permit it to pass over me and through me. And when it has gone past I will turn the inner eye to see its path. Where the metastability has gone there will be nothing. Only I will remain. ___ 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.
Re: [time-nuts] Using CPLD/FPGA or similar for frequency
On Thu, 11 Jun 2015 14:22:58 + Alan Ambrose alan.ambr...@anagram.net wrote: A clever interpolator for frequency or TIC would kill it - for TIC essentially a PICTIC on steroids. The PICTIC does 19pS with a 10 bit ADC and a 66MHz clock, an SR620 does 4pS with a 12 bit ADC and an 80 MHz clock - so ... cough ... Spartan 3E at 256MHz with 16 bit ADC - and 1pS should be easy Which architecture for the FPGA do you have in mind? The delay line method (which is the most common one for FPGAs) has an intrinsic limit around 10-20ps. But the SR620 and the PICTIC use both a time to amplitude conversion by charging a capacitor (both include a Nutt interpolator). Using this technique, it might be possible to get into the 1ps ballpark, if the design is done carefully (according to Richard McCorkle, the limiting factor for the PICTIC II was the ADC of the PIC, followed by the stability of the reference clock). Attila Kinali -- I must not become metastable. Metastability is the mind-killer. Metastability is the little-death that brings total obliteration. I will face my metastability. I will permit it to pass over me and through me. And when it has gone past I will turn the inner eye to see its path. Where the metastability has gone there will be nothing. Only I will remain. ___ 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.
Re: [time-nuts] PPS for NTP Server - How Close Is Good Enough?
On Fri, 12 Jun 2015 18:29:29 -0400 Ed Armstrong eds_equipm...@verizon.net wrote: The Ethernet on the Raspberry Pi is on the USB bus. That adds about a 1/2 ms of jitter. Is it possible to modify the kernel so the USB is polled more often, and would that significantly reduce the jitter? Yes. You can add more interrupt slots per frame. IIRC there was an upper limit on how many you can add (sorry, I don't remember any specifics, it's been some time since I read the USB standard). What you need to ensure as well is, that the device itself does nothing weird with the data, aka that any pipelining and collation is turned off. Attila Kinali -- I must not become metastable. Metastability is the mind-killer. Metastability is the little-death that brings total obliteration. I will face my metastability. I will permit it to pass over me and through me. And when it has gone past I will turn the inner eye to see its path. Where the metastability has gone there will be nothing. Only I will remain. ___ 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.
