[time-nuts] Re: Network interface cards that support timestamping

[Matt Corallo]

Makes sense.

Sadly, as far as I can tell, the i211 will mark both the rising and falling edge of the pulse, with 
no distinction between the two. While you'd expect chrony to be able to differentiate based on the 
time between them, the manual for chrony.conf seems to indicate otherwise, saying:

 > width width
 > This option specifies the width of the pulses (in seconds). It is used to filter PPS samples when
 > the driver provides samples for both rising and falling edges. Note that it reduces the maximum
 > allowed error of the time source which completes the PPS samples. If the duty cycle is
 > configurable, 50% should be preferred in order to maximise the allowed error.

which, maybe incorrectly, implied to me that there was no smarts for highly asymmetric 
pulse-to-not-pulsing time.

Matt


On 2/1/23 4:15 PM, Bob Camp wrote:
> Hi
> 
> A 10 or 100 microsecond wide 1 pps signal is more common than a 10 to 100 millisecond
> wide pulse.
> 
> Why?
> 
> Back in the day, they coupled this stuff via a transformer. The frequency response issues
> made a narrower pulse more appealing. These days it is not uncommon to try to drive a
> 50 ohm load to some sort of logic level. The less time you have to do that, the happier
> your driver IC (and regulator) are likely to be.
> 
> One example of this would be the Trimble TBolt. It has a 10 us wide output pulse. Another
> would be a uBlox LEA-6T (and the others in that lineup) with a default 10us wide output.
> 	
> 
> Bob
> 
> 
>> On Feb 1, 2023, at 5:02 PM, Matt Corallo via time-nuts <time-nuts at lists.febo.com> wrote:
>>
>>
>>
>> On 2/1/23 10:38 AM, John Miller via time-nuts wrote:
>>> Hi Matt,
>>
>>> What I'm using right now is a Portwell NANO-6050[1], and it has i210 and i218 NICs. The SDP pins on the i210 aren't broken out into nice pads like the APU2 has, but with some magnet wire and a steady hand I was able to connect directly to one of the pins. Where I am struggling right now is ironing out the software configuration side of things. I'm not interested at all in PTP yet, right now the focus is purely on feeding the PPS into chrony via the SDP pins. The GNSS I'm using is a Sparkfun uBlox NEO-M9N GNSS receiver in its default configuration, connected to the computer over USB. PPS pin connected to the i210's SDP0. PPS pulse is 3v3 for 100ms.
>>> I have tried using refclock strings from chrony's examples page[2] as a jumping-off point, but it doesn't make much sense to me.
>>
>>> 16Hz PPS with a rate of 16 - why not use 1Hz with a default rate of 1?
>>
>> More samples can hide at least some of the noise. As Bob points out in his reply there's a limit, though, of course, the NEO-M9N datasheet says its time-pulse accuracy is 30ns RMS/60ns 99%. If your interrupt jitter is less than that, you're not gonna hide much :).
>>
>>> The Dan Drown blog post makes a little bit more sense, but I think something is missing from the 'relevant chrony.conf' example - notably, it includes a single refclock line with the "pps"  option, which according to the chrony.conf docs[4]: "Another time source is needed to complete samples from the refclock." and that example isn't included.
>>
>> A PPS input is just a pulse. chrony has no idea what time that pulse was meant to indicate, only that it indicated a specific time. You have to somehow hook that pulse up to something else via the "lock" option. Probably you want to run gpsd and tell chrony about the gpsd input via a "refclock SHM...noselect" line. There should be examples of how to do this elsewhere
>>
>>> Furthermore, his "width" parameter is set to 0.7 milliseconds, which seems tremendously short to me. If the PPS pulses are 100ms (which I understand to be fairly standard) why wouldn't the width be configured as such? I may be misunderstanding this parameter.
>>
>> Yea, not sure, that does seem super small. If chrony knows the time (via the lock'ed refclock) with more accuracy than 0.7/2ms then its fine, but if you're locking to an NMEA input via gpsd you're gonna have way more variance than that. Ideally your pulse is half the width of your pulse rate, so 500ms if you're doing 1s PPS.
>>
>>> Either way, am not able to get chrony to lock up to a PHC refclock.[5] This is what my chrony.conf looks like: https://paste.millerjs.org/ajoxigiquc.txt
>>> I have not been able to use the testptp tool on this system yet - building it on another machine and running the copied-over executable fails, citing too old a version of glibc, and when I try and build it locally it fails for reasons that are unknown to me (I am very much not a C developer). I may have to install a newer OS in order to try this out.
>>> I am going to continue to fiddle with this - I think getting testptp working such that I can verify that I'm actually getting a pulse on SDP0 is the most important thing to confirm right now. I would greatly appreciate any help or feedback!
>>
>> chrony has been a bit...fidgety with me, the testptp utility will show at least whether your input is pulsing and being read or not.
>>
>> Matt
>> _______________________________________________
>> time-nuts mailing list -- time-nuts at lists.febo.com
>> To unsubscribe send an email to time-nuts-leave at lists.febo.com
>