Re: [Linuxptp-devel] [PATCH 3/3] tsproc: Allow clock synchronization immediately after jump.

Paches 2 and 3 work for me as well. Code is cleared, performance improved. Burkhard -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot

Re: [Linuxptp-devel] [PATCH 1/3] tsproc: Track the validity of the filtered delay explicitly.

Yes, this works well. Also using a flag instead of a special value is more linuxptp style. Thanks, Burkhard 2017-04-08 21:20 GMT+02:00 Richard Cochran : > We will want to test whether a valid filtered delay value has been > calculated or not. However, we cannot simply

[Linuxptp-devel] [PATCH] tsproc_update_offset() fails when it should succeed

After the first SERVO_JUMP the following calls of tsproc_update_offset() from clock_synchronize() fail because t3 was reset. But the offset calculation does not necessarily depend on t3, i.e. when filtered_delay is available and neither raw nor weighting is used. Signed-off-by: Burkhard Ilsen

[Linuxptp-devel] [PATCH] port: sequence of nrate and peer_delay calculation

2017-04-04 4:29 GMT+02:00 Richard Cochran <richardcoch...@gmail.com>: > On Mon, Apr 03, 2017 at 03:52:13PM +0200, Burkhard Ilsen wrote: >> 2. >> The nrate ratio should be calculated before the delay, > > I can't see any reason not to put port_nrate_calculate() fi

[Linuxptp-devel] [PATCH] tsproc_update_offset() fails when it should succeed

Hi Richard, Jake 2017-04-04 3:44 GMT+02:00 Richard Cochran : > You mean the call to tsproc_reset() after SERVO_JUMP... > which passes fail=0, preserving tsproc->filter_delay. Since we took > the trouble to keep filter_delay, then yes, we should also use it! Exaclty.

Re: [Linuxptp-devel] First two peer_delay measurements invalid

Hi Richard, Jake, many thanks for your replies. >> The drawback is that peer_delay is not available after the first >> delay_response. > > Yes, and it doesn't make sense to penalize users with reasonable local > clocks by removing the default 1.0 NRR. I agree for AS compliant neighbors, still I

[Linuxptp-devel] First two peer_delay measurements invalid

Hello, I tested two-step peer_delay measurement with two peers with a high nrate ratio. I noticed that the first two measured delays are erronous because the nrate is not known yet, and 1.0 is assumed. The next raw delay measurements are correct but the two first errors still affect the

[Linuxptp-devel] tsproc_update_offset() fails when it should succeed

Hello everyone, while debugging my 802.1AS endpoint I recognized that the servo was idle after the first step. It stopped processing sync messages until the next peer delay was measured. The reason is that t3 is reset after the first step letting tsproc_update_offset() fail. I think

Re: [Linuxptp-devel] 802.1AS Time-Aware Bridge

>> According to 802.1 AS all message timestamps shall be based on a free >> running clock (LocalClock) in order to minimize the errors resulting from a >> varying clock frequency. >> Also phase discontinuities in the pdelay_resp(fup) messages are avoided this >> way. >> So the SlaveClock