On Tue, Feb 17, 2015 at 5:31: PM +0100, Richard Cochran wrote:
snip
This is done differently in every driver, depending on the hardware.
Some hardware provides the time stamp in band, for example in the
frame's buffer descriptor or in the frame data. In this case, the
association is
On Tue, Feb 17, 2015 at 12:31:44PM +0100, Miroslav Lichvar wrote:
The delay message doesn't have to be delayed for the sample to have a
smaller weight. The delay calculated from the four timestamps will be
larger than the average when the sync message is delayed, the delay
message is delayed,
On Mon, Feb 16, 2015 at 08:48:15PM +0100, Richard Cochran wrote:
On Fri, Feb 13, 2015 at 01:56:16PM +0100, Miroslav Lichvar wrote:
+ if (sync_delay_rate = 0 servo_weight_samples(c-servo)) {
+ /* Get new sample delay with updated t1 and t2 */
+ sample_delay =
On Tue, 2015-02-17 at 20:25 +0100, Richard Cochran wrote:
On Tue, Feb 17, 2015 at 12:31:44PM +0100, Miroslav Lichvar wrote:
The delay message doesn't have to be delayed for the sample to have a
smaller weight. The delay calculated from the four timestamps will be
larger than the average
On Mon, Feb 16, 2015 at 09:07:12PM +0100, Richard Cochran wrote:
On Fri, Feb 13, 2015 at 01:56:12PM +0100, Miroslav Lichvar wrote:
These patches should improve the synchronization of the clock with
larger jitters, e.g. with software timestamping, wireless networks,
etc.
What kind of
Hello Richard et al,
as you Richard were the main force doing the work for adding hardware
timestamping to the Linux kernel, could you enlight me how the association
of a timestamp residing in kernel space (I guess in the ethernet device
driver's domain) and a PTP message is handled by the
