[Toybox] [PATCH] A implementaion of the ts command

[Rob Landley]

On 9/9/23 21:17, Rob Landley wrote:
> 
> 
> On 9/9/23 11:39, Oliver Webb wrote:
>> ------- Original Message -------
>> On Friday, September 8th, 2023 at 2:38 AM, Rob Landley <rob at landley.net> wrote:
>> 
>> 
>>> On 9/7/23 23:51, Oliver Webb via Toybox wrote:
>>>
>>> > I wrote a implementation of the command 'ts' for toybox
>>>
>> 
>> To clarify my earlier emails, I normally wouldn't submit a command this obscure,
>> if it wasn't mentioned (Very briefly, but mentioned) in the roadmap page of the project.
> 
> It's fine. I merged what you sent locally and did a cleanup pass earlier today.
> I've added the -s command from busybox's --help and am frowning at the fact
> "dmesg" output gives microseconds and this gives full seconds, and grumbling
> about strptime() and friends apparently not having a _concept_ of fractional
> seconds and looking what I did in date.c to handle that and wondering if I
> should try to genericize it (or just write my own xstrftime() which seems
> overkill but there's no other obvious way to do it RIGHT...
> 
> I'd poke dalias (Rich Felker, the musl-libc maintainer) about it but he recently
> had a "fork() considered harmful" rant that's a bit off the deep end for me. No
> I did not make that up:
> 
> https://hachyderm.io/@dalias/111026718025749959
> 
> (He is, of course, wrong about that...)
> 
>> I have improved the source code of ts to fix a memory leak, and remove the
>> malloc by just doing what 'date' does and writing to 'toybuf'. I also added
>> another reference page that <scsijon at lamiaworks.com> linked
>> 
>> Since submitting a patch to patch a currently pending patch seems wrong,
>> I just made a new standalone one.
> 
> I applied your other one this morning, and have already modified it a bit.
> Trying to finish up tonight (I got distracted)...

I pushed a cleaned up ts.c but haven't promoted it yet because I dunno how to
test it without fixing the fractional seconds issue, and I dunno how to do that
without breaking compatibility with busybox's version.

We output the same as busybox:

  $ for i in one two three four five; do echo $i; sleep 1; done | ./ts
  Sep 09 22:00:35 one
  Sep 09 22:00:36 two
  Sep 09 22:00:37 three
  Sep 09 22:00:38 four
  Sep 09 22:00:39 five
  $ for i in one two three four five; do echo $i; sleep 1; done | ./ts -i
  00:00:00 one
  00:00:01 two
  00:00:01 three
  00:00:01 four
  00:00:01 five
  $ for i in one two three four five; do echo $i; sleep 1; done | ./ts -s
  00:00:00 one
  00:00:01 two
  00:00:02 three
  00:00:03 four
  00:00:04 five

But full second sleeps are unfriendly to the test suite (I usually do .1 or .2
sleeps), and again dmesg shows microseconds.

By default I'd _like_ to show milliseconds, which are the human-friendly
fractional second measurement. An output more like dmesg:

[12.337] Thingy
[12.512] Next thingy
[13.003] Oh look, a thingy.

But that's not what the "existing" command does, for some reason. Which is part
of the reason I was wondering "is this an existing thing anybody really cares
about being compatible with...?" And also why a strftime() able to print
milliseconds would be nice, but no the posix committee is off trying to break
printf instead. Although they seem to have been talked out of that one for the
moment:

  https://lists.gnu.org/archive/html/coreutils/2023-09/msg00031.html

(I'm still tempted to add a strftimespec() to lib/lib.c that understands a few
more escapes. For one thing, it would have an excuse for passing a pointer in as
an argument: time_t is a 64 bit integer, so WHY THE POINTER? It means you can't
do math in the argument so I had to do an extra temporary variable in my
cleanup. Except I don't want to list escapes in the ts help text, and I'd also
want to fix up date.c to use whatever it was and THAT is a whole 'nother can of
worms...)

> Rob

P.S. A 1ghz computer is clocked once per nanonsecond but it takes many clock
cycles to do anything useful and jitter from things like IPI or DRAM page fetch
is regularly dozens to hundreds of nanoseconds. Meanwhile here's an MIT study
that found college students have a 13 millisecond reaction time
(https://news.mit.edu/2014/in-the-blink-of-an-eye-0116) although there's an
age-related component same as hearing higher frequencies: my teenage nephew was
annoyed by fluorescent strobing at 60hz wall current speed which switches on and
off every 17 ms which means he was seeing it be on-or-off for 8 ms. In either
case, ONE millisecond is agreed to be outside human perception threshold (except
as aggregate data like sound frequency which isn't independently signaled by the
nervous system but instead has different receptors resonating at different
frequencies).

tl;dr: milliseconds are plenty for humans, and nanoseconds are plenty for all
but the hardest realtime hardware in places like fermilab. (And even then it's
not the PROCESSOR reacting in nanoseconds, it's the recording of trailing
historical data being processed after the fact that's timestamped in
nanoseconds). This means "microseconds" are both too much precision and not
enough precision for either usecase, which is why gettimeofday() and the whole
"struct timeval" ecosystem annoys me greatly.