Richard Cochran writes:
> On Wed, Jul 08, 2020 at 03:37:29PM +0300, Sergey Organov wrote:
>> Richard Cochran writes:
>>
>> > On Mon, Jul 06, 2020 at 06:27:21PM +0300, Vladimir Oltean wrote:
>> >> There's no correct answer, I'm afraid. Whatever the default value of the
>> >> clock may be, it's b
On Wed, Jul 08, 2020 at 03:37:29PM +0300, Sergey Organov wrote:
> Richard Cochran writes:
>
> > On Mon, Jul 06, 2020 at 06:27:21PM +0300, Vladimir Oltean wrote:
> >> There's no correct answer, I'm afraid. Whatever the default value of the
> >> clock may be, it's bound to be confusing for some rea
Richard Cochran writes:
> On Mon, Jul 06, 2020 at 06:27:21PM +0300, Vladimir Oltean wrote:
>> There's no correct answer, I'm afraid. Whatever the default value of the
>> clock may be, it's bound to be confusing for some reason, _if_ the
>> reason why you're investigating it in the first place is
Richard Cochran writes:
> On Mon, Jul 06, 2020 at 06:27:21PM +0300, Vladimir Oltean wrote:
>> There's no correct answer, I'm afraid. Whatever the default value of the
>> clock may be, it's bound to be confusing for some reason, _if_ the
>> reason why you're investigating it in the first place is
Richard Cochran writes:
> On Tue, Jul 07, 2020 at 08:56:41PM +0300, Sergey Organov wrote:
>> It won't. Supposedly it'd force clock (that doesn't tick by default and
>> stays at 0) to start ticking.
>
> No existing clockid_t has this behavior. Consider CLOCK_REALTIME or
> CLOCK_MONOTONIC.
>
> T
On Tue, Jul 07, 2020 at 08:56:41PM +0300, Sergey Organov wrote:
> It won't. Supposedly it'd force clock (that doesn't tick by default and
> stays at 0) to start ticking.
No existing clockid_t has this behavior. Consider CLOCK_REALTIME or
CLOCK_MONOTONIC.
The PHC must act the same as the other P
On Tue, Jul 07, 2020 at 07:43:29PM +0300, Vladimir Oltean wrote:
> And overall, my argument is: you are making a user-visible change, for
> basically no strong reason, other than the fact that you like zero
> better. You're trying to reduce confusion, not increase it, right?
;^)
> I agree with t
On Mon, Jul 06, 2020 at 06:27:21PM +0300, Vladimir Oltean wrote:
> There's no correct answer, I'm afraid. Whatever the default value of the
> clock may be, it's bound to be confusing for some reason, _if_ the
> reason why you're investigating it in the first place is a driver bug.
> Also, I don't r
Vladimir Oltean writes:
> On Tue, Jul 07, 2020 at 08:09:07PM +0300, Sergey Organov wrote:
>> Vladimir Oltean writes:
>>
>> > On Tue, Jul 07, 2020 at 07:07:08PM +0300, Sergey Organov wrote:
>> >> Vladimir Oltean writes:
>> >> >
>> >> > What do you mean 'no ticking', and what do you mean by 'non
On Tue, Jul 07, 2020 at 08:09:07PM +0300, Sergey Organov wrote:
> Vladimir Oltean writes:
>
> > On Tue, Jul 07, 2020 at 07:07:08PM +0300, Sergey Organov wrote:
> >> Vladimir Oltean writes:
> >> >
> >> > What do you mean 'no ticking', and what do you mean by 'non-initialized
> >> > clock' exactly
Vladimir Oltean writes:
> On Tue, Jul 07, 2020 at 07:07:08PM +0300, Sergey Organov wrote:
>> Vladimir Oltean writes:
>> >
>> > What do you mean 'no ticking', and what do you mean by 'non-initialized
>> > clock' exactly? I don't know if the fec driver is special in any way, do
>> > you mean that
On Tue, Jul 07, 2020 at 07:07:08PM +0300, Sergey Organov wrote:
> Vladimir Oltean writes:
> >
> > What do you mean 'no ticking', and what do you mean by 'non-initialized
> > clock' exactly? I don't know if the fec driver is special in any way, do
> > you mean that multiple runs of $(phc_ctl /dev/p
Vladimir Oltean writes:
> On Mon, Jul 06, 2020 at 09:24:24PM +0300, Sergey Organov wrote:
>> Vladimir Oltean writes:
>>
>> > Hi Sergey,
>> >
>> > On Mon, Jul 06, 2020 at 05:26:14PM +0300, Sergey Organov wrote:
>> >> Initializing with 0 makes it much easier to identify time stamps from
>> >> oth
On Mon, Jul 06, 2020 at 09:24:24PM +0300, Sergey Organov wrote:
> Vladimir Oltean writes:
>
> > Hi Sergey,
> >
> > On Mon, Jul 06, 2020 at 05:26:14PM +0300, Sergey Organov wrote:
> >> Initializing with 0 makes it much easier to identify time stamps from
> >> otherwise uninitialized clock.
> >>
>
Vladimir Oltean writes:
> Hi Sergey,
>
> On Mon, Jul 06, 2020 at 05:26:14PM +0300, Sergey Organov wrote:
>> Initializing with 0 makes it much easier to identify time stamps from
>> otherwise uninitialized clock.
>>
>> Initialization of PTP clock with current kernel time makes little sense as
>>
Hi Sergey,
On Mon, Jul 06, 2020 at 05:26:14PM +0300, Sergey Organov wrote:
> Initializing with 0 makes it much easier to identify time stamps from
> otherwise uninitialized clock.
>
> Initialization of PTP clock with current kernel time makes little sense as
> PTP time scale differs from UTC time
Initializing with 0 makes it much easier to identify time stamps from
otherwise uninitialized clock.
Initialization of PTP clock with current kernel time makes little sense as
PTP time scale differs from UTC time scale that kernel time represents.
It only leads to confusion when no actual PTP init
17 matches
Mail list logo
