Re: after ids

On 16 avr, 16:34, Kevin Kenny <kenn...@xxxxxxx> wrote:

OK, so I think it deserves a TIP (is there one already ?). Again to
stay on the radar... If nobody else steps forward, maybe I could write
it, but I'd appreciate your eventual implication in the ref
implementattion.

TIPs are not needed for changes that affect only performance and
do not change the API. Reorganizing [after] to use a better data
structure is something that we can just do as a performance enhancement.

OK, I stand corrected. But is it sufficient reason to ignore it during
one year and four months ?
Had somebody told me it was not TIPpable, I would have happily moved
it to a more appropriate channel...

Did you see my comment at the bottom?  I've misgivings about
whether it's feasible. Yes, I've *looked* at it.

Two answers:

(1) no, I hadn't seen your comment at the bottom until now, because
there is no e-mail notification of TIP updates apparently (or it
failed on me, or on Gmail's antispam, etc.)

(2) I disagree with the comment. Quoting you:

> The times function in Unix is not an appropriate time base.
> It reports the user and system time (CPU time, in other words)
> of the currently executing process and its children...

What you say accurately describes what times() returns in its argument
structure. But it also has a return value, which is of type clock_t,
and, quoting the manpage:

>> times() returns the number of clock ticks that have elapsed
>> since an arbitrary point in the past.

So again, why is not an appropriate time base ?

    (2) wake up at a particular (UTC or local) time, tracking any clock
        changes that take place.

"Tracking" is a bit of an exaggeration. "Undergoing" would be closer
to the truth...

Well, with a functioning NTP infrastructure, it's a non-issue.

Yes but not everybody has this. I routinely get to handle machines
jailed in strange subnetworks with armies of firewall around, and NTP
not an option. Nor would it deserve any effort: on these machines,
accuracy of the 'date' command is not required. Only from time to time
a sysadmin may find too large a drift and decide to take action,
without imagining the harm this operation does to Tcl (and on Tcl
alone, since sh's sleep command uses setitimer() which is also
insensitive to date-setting).

Even today, the [after] command doesn't depend on time zone changes,

Yeah, this red herring has been covered to death on c.l.t :-)
We both know TZ and DST are a separate layer from the true time base
ticking [after], let's dismiss that.

I would be very surprised to see a single example of a beneficial, or
even depended-upon, effect of a gettimeofday()-shift on [after].

I have one important one: NBC.
[...] So unlike your assertion that the
hardware clock is "rock solid" while system time is capricious,
in the NBC system, system time is traced to a primary reference

OK, I understand the specific need, but:

(1) this is closer in my view to an [at] command, rather than an
[after]

(2) even with a ticks-based, drifting time reference in [after], it
would be easily achievable with a two-resolution scheme: a periodic
task running every (say) minute, checking [clock], and posting short-
range [after]s.

(3) Conversely, even in the current implementation, with a tight NTP
hand on the system clock, if there is one single long [after] with no
intervening events, Tcl will compute one single select() timeout
value, and the syscall will sleep until its end, regardless of any
intervening NTP corrections; so it will suffer from the drift. Of
course, this won't happen if the select() is frequently interrupted by
other events (including shorter-term afters), since in this case
gettimeofday() is called at each time to recompute the next target).
Is it your case ?

(4) I'd be curious to know how many dozens of cases of the stalled
periodic task there are per single NBC-like case ... But I admit the
voice of a TCT member can weigh higher than 1 ;-)

configured to Just Work is easier.) Your suggestion in TIP #302
of using times() is not workable, because times() reports CPU time,
not wall-clock time; when a process is idle, times() does not
advance.

Not true, see above :-}

Perhaps my experience is unusual, but it's been literally years
since I've set a system clock by the wristwatch-and-eyeball method.
Even my wristwatch (like millions of others) gets its time from
NIST; there's a WWVB receiver aboard that resynchronizes daily to
the radio signal from Fort Collins.

I understand, but again, if your experience is "unusual", mightn't it
be advisable to ease the life of the Neandertalian masses including
myself ? (of course with an explicit option, like the -robust in the
TIP)

-Alex
.

Relevant Pages

  • Re: Reference clock driver for /dev/rtc
    ... exceeding the 500PPM that ntp handles) with the VM clock ... situation ntp is designed to handle. ... VM system time does not seem to me to be the right approach. ... system call or device driver level, but at the level of hardware. ...
    (comp.protocols.time.ntp)
  • Re: Clock Problem?
    ... with a clock in many more words we can look for a solution. ... Local time or UTC. ... started NTP ... The KDE clock should just be the same as the system time. ...
    (alt.os.linux.suse)
  • Re: [PATCH 6/8] ptp: Added a clock that uses the eTSEC found on the MPC85xx.
    ... This clock may be less accurate and thus our slave clock ... So you may have a PTP or NTP clock providing basic system time but also ... With NTP it's not so far been a big issue - NTP isn't used for industrial ...
    (Linux-Kernel)
  • Re: Solairs 8 xntpd client oscillates
    ... But the clock doesn't really synchronize either. ... That is the range that ntp can handle, ... It goes on and tells that in that case one has to add "disable pll" to ntp.conf. ... I would like to understand that: When one uses "disable pll", is the Unix system time now updated or not? ...
    (comp.protocols.time.ntp)
  • Re: [PATCH 1/5] ptp: Added a brand new class driver for ptp clocks.
    ... The PTPd need not change the system time at all for PTP clock to be ... Could you explain why the alarm interface is necessary? ...
    (Linux-Kernel)