On Mon, Sep 23, 2019 at 08:31:30PM +, Stuart Venters wrote:
> I'm trying to figure out how to fit an experiment into LinuxPtp and end up
> with as much as possible worth pushing back up.
> It looks like the dual filters are easy to fit in.
> Let me talk about the rest of the story and see if
On Mon, Sep 23, 2019 at 08:31:30PM +, Stuart Venters wrote:
> The remaining part appears to be figuring out how to turn off the all the
> kernel packet timestamping help.
> Also, turning off the /dev/ptp0 stuff.
>
>
> Thoughts?
Sounds like a great step backwards. Really.
I didn't quite
Very nice read. But some points:
The rethinking of old-decisions w.r.t. new info may not be valid as the
time to apply them is long gone since the conditions under which those
decisions were made. Maybe the local clock was actually leading or lagging
behind at that time, which might not be the
Richard,
Miroslav,
Thanks for the response.
Yes definitely, tsproc instead of port.c, not sure what I was thinking. I'm
glad I asked.
I'm trying to figure out how to fit an experiment into LinuxPtp and end up with
as much as possible worth pushing back up.
It looks like the dual filters are
On Fri, Sep 20, 2019 at 04:39:06PM +, Stuart Venters wrote:
> To support separate filtering and give the filter access to everything it
> needs, I think what I would like to see is the following refactoring and see
> how it works out:
>
> Change the argument list for filter_create to add
On Fri, Sep 20, 2019 at 04:39:06PM +, Stuart Venters wrote:
> Change the argument list for filter_create to add an indication of
> which filter is being created, and pointers to the clock_type and
> config.
> Change the argument list for filter_sample to be local time of the
> experiment and
Richard,
I'm doing some experiments with linuxptp. It's kind of a neat gadget to have
abound, thanks.
I'd like to try adding lucky packet filters. I think these might be useful
to get to improved accuracy given residual delay variations in the on-path
support's timestamping.
The
