Re: [Emc-developers] latency-test period - (return) problem

[gene heskett]

On Monday, January 31, 2022 8:38:03 PM EST Steffen Möller wrote:
> On 01.02.22 01:57, gene heskett wrote:
> > On Monday, January 31, 2022 12:45:27 PM EST Steffen Möller wrote:
> >> On 31.01.22 18:28, gene heskett wrote:
> >>> On Monday, January 31, 2022 6:14:42 AM EST Steffen Möller wrote:
>  latency-test 100 500
> >>> 
> >>> And it works!
> >> 
> >> This is great to hear! Thank you! This is 32bits now, right?
> > 
> > On the pi, yes, I think the wintel machines are too. The kernels they
> > are running are VERY long in the tooth, from 3.something I think.> 
> >> Where are
> >> you at?
> 
> [the latency I had meant]
> 
> >> Now that I have the proper syntax, the rpi4b latency's for this
> >> kernel
> >> are amazing:
> >> Linux rpi4.coyote.den 4.19.71-rt24-v7l+ #1 SMP PREEMPT RT Thu Feb 6
> >> 07:09:18 EST 2020 armv7l GNU/Linux, I built just shy of 2 years ago,
> >> its reporting under 5 u-secs max jitter for both threads, and its
> >> pretty stable.  And my lathe is moving very smoothly with the new 3
> >> phase stepper servo's. I have not rebooted it back to bullseye to
> >> see if the v5.16.2-rt19 I built last week is any better because so 
far, I haven't gotten past the python 3.9.2 problem.  Throws boost under 
the bus. 
> 
> Save the effort. Let someone else try to beat your 5µs. This looks
> good, indeed.
> 
Truth be known, if firefox is fired up, things can get out toward 200 u-
secs, but we ALL know that the current firefox is a pig. But generally 
the lcnc shutdown report is pretty decent, maybe 3 or so excessive time 
events in a couple hours running as most jobs can be finished in less 
time than that. Anything reading from the u-sd will cause a problem, but 
if it lcnc itself that caused it, it was loading or saving a file at the 
instant that caused it, not when it was actually running code. So THAT 
problem is universal, independent of the os running the show.

> What would be important is that you keep these 5µs when saving
> something to the disk etc. or when there is a touch on the touch
> screen etc.

No touch screens actually in use here, and I only have one lcd monitor 
with it, an escapee from a grocery checkout, but the touch in it has not 
been hooked to anything but a test scope on my watch.
> But I am already sold, will get a Pi again.
> 
> Best,
> Steffen
> 
> 
> 
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers


Cheers, Gene Heskett.
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 





___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] latency-test period - (return) problem

[Steffen Möller]

On 01.02.22 01:57, gene heskett wrote:

On Monday, January 31, 2022 12:45:27 PM EST Steffen Möller wrote:

On 31.01.22 18:28, gene heskett wrote:

On Monday, January 31, 2022 6:14:42 AM EST Steffen Möller wrote:

latency-test 100 500

And it works!

This is great to hear! Thank you! This is 32bits now, right?

On the pi, yes, I think the wintel machines are too. The kernels they are
running are VERY long in the tooth, from 3.something I think.


Where are
you at?


[the latency I had meant]


Now that I have the proper syntax, the rpi4b latency's for this kernel
are amazing:
Linux rpi4.coyote.den 4.19.71-rt24-v7l+ #1 SMP PREEMPT RT Thu Feb 6
07:09:18 EST 2020 armv7l GNU/Linux, I built just shy of 2 years ago, its
reporting under 5 u-secs max jitter for both threads, and its pretty
stable.  And my lathe is moving very smoothly with the new 3 phase
stepper servo's. I have not rebooted it back to bullseye to see if the
v5.16.2-rt19 I built last week is any better.


Save the effort. Let someone else try to beat your 5µs. This looks good,
indeed.

What would be important is that you keep these 5µs when saving something
to the disk etc. or when there is a touch on the touch screen etc. But I
am already sold, will get a Pi again.

Best,
Steffen



___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] latency-test period - (return) problem

[gene heskett]

On Monday, January 31, 2022 12:45:27 PM EST Steffen Möller wrote:
> On 31.01.22 18:28, gene heskett wrote:
> > On Monday, January 31, 2022 6:14:42 AM EST Steffen Möller wrote:
> >> latency-test 100 500
> > 
> > And it works!
> 
> This is great to hear! Thank you! This is 32bits now, right?

On the pi, yes, I think the wintel machines are too. The kernels they are 
running are VERY long in the tooth, from 3.something I think.

> Where are
> you at? 

North central West Virginia, near mile 99 of I-79.

Now that I have the proper syntax, the rpi4b latency's for this kernel 
are amazing:
Linux rpi4.coyote.den 4.19.71-rt24-v7l+ #1 SMP PREEMPT RT Thu Feb 6 
07:09:18 EST 2020 armv7l GNU/Linux, I built just shy of 2 years ago, its 
reporting under 5 u-secs max jitter for both threads, and its pretty 
stable.  And my lathe is moving very smoothly with the new 3 phase 
stepper servo's. I have not rebooted it back to bullseye to see if the 
v5.16.2-rt19 I built last week is any better.

> Maybe Rod can compare with his 64bit findings.
> 
> > The man page sorta needs help.
> 
> Both the man page and the tool have problems. Found the man page here
> https://github.com/LinuxCNC/linuxcnc/blob/master/docs/man/man1/latency-> 
> test.1 and yes, it is a bit minimalistic :)  I think the way to go is
> to fix the argument parsing when units are added, improve the --help
> and then auto-generate the man page from that output.
> 
> Sidenote - if you (or anyone else reading this) happen(s) to have the
> leisure to contribute bits and pieces to the documentation then by all
> means - please just make your pick in
> https://github.com/LinuxCNC/linuxcnc/tree/master/docs/src. There is an
> effort under way to crowdsource the translation to other human
> languages on wetblate (https://hosted.weblate.org/projects/linuxcnc -
> so far only the tools are covered, but documentation should arrive
> soon, too) which ist motivated mostly from the idea to have all
> languages synced as good as possible to the English original and give
> the English all the best-possible freedom to evolve without the burden
> to keep other languages updated. I happily help with technical bits on
> gitlab.
> 
> Best,

You too Steffen.

Cheers, Gene Heskett.
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 





___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] latency-test period - (return) problem

[Steffen Möller]

On 31.01.22 18:28, gene heskett wrote:

On Monday, January 31, 2022 6:14:42 AM EST Steffen Möller wrote:

latency-test 100 500

And it works!

This is great to hear! Thank you! This is 32bits now, right? Where are
you at? Maybe Rod can compare with his 64bit findings.

The man page sorta needs help.


Both the man page and the tool have problems. Found the man page here
https://github.com/LinuxCNC/linuxcnc/blob/master/docs/man/man1/latency-test.1
and yes, it is a bit minimalistic :)  I think the way to go is to fix
the argument parsing when units are added, improve the --help and then
auto-generate the man page from that output.

Sidenote - if you (or anyone else reading this) happen(s) to have the
leisure to contribute bits and pieces to the documentation then by all
means - please just make your pick in
https://github.com/LinuxCNC/linuxcnc/tree/master/docs/src. There is an
effort under way to crowdsource the translation to other human languages
on wetblate (https://hosted.weblate.org/projects/linuxcnc - so far only
the tools are covered, but documentation should arrive soon, too) which
ist motivated mostly from the idea to have all languages synced as good
as possible to the English original and give the English all the
best-possible freedom to evolve without the burden to keep other
languages updated. I happily help with technical bits on gitlab.

Best,
Steffen




___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] latency-test period - (return) problem

[gene heskett]

On Monday, January 31, 2022 6:14:42 AM EST Steffen Möller wrote:
> latency-test 100 500
And it works! The man page sorta needs help.
Thank you very much!

Cheers, Gene Heskett.
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 





___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] latency-test period - (return) problem

[Steffen Möller]

Dear Gene,

I just tried this locally and it seems like the number conversion is
broken in latency-test. Also there should not be a prefix like
base-period in the command line. First thought it was just the capital
"S" but it wasn't.  Good news: you don't need them, please try again with

latency-test 100 500

which are your times in nanoseconds.

latency-test will open an X window to show these values. No idea why,
really, wish it would not.

Best,
Steffen

$ latency-test --help

Usage:
  latency-test [base-period [servo-period]]
  or:
  latency-test period -  # for single thread
  or:
  latency-test -h | --help   # (this text)

Defaults: base-period=25000nS servo-period=100nS
Equivalently: base-period=25µs servo-period=1ms

Times may be specified with suffix "s", "ms", "us" "µs", or "ns"
Times without a suffix and less than 1000 are taken to be in us;
other times without a suffix are taken to be in ns


On 31.01.22 11:35, gene heskett wrote:

Greetings all;

both my build (on buster armhf) and the buildbot version of 2.9-pre are
failing: terminal output from my build:
===
pi@rpi4:/media/pi/workspace $ latency-test period -
/usr/bin/latency-test: line 26: [: period: integer expression expected
Note: Using POSIX realtime
HAL: ERROR: thread 'slow' not found
lat.hal:3: addf failed
Note: Using POSIX realtime
===
terminal output of buildbot version:
===
pi@rpi4:/media/pi/workspace $ latency-test period -
/usr/bin/latency-test: line 26: [: period: integer expression expected
Note: Using POSIX realtime
HAL: ERROR: thread 'slow' not found
lat.hal:3: addf failed
Note: Using POSIX realtime
===

It has been this way for a bit.

Because on my pi, I have two threads, a 1ms thread for the linuxcnc
control stuff, and a 200 hz, 5 millisecond for the hand controls, it
would be informative if the period syntax also included the ability to
trace/measure this slower thread too but that implied syntax also fails
=
pi@rpi4:/media/pi/workspace $ latency-test base-period=1mS servo-
period=5mS
/usr/bin/latency-test: line 26: [: base-period=1mS: integer expression
expected
awk: cmd. line:1: BEGIN { printf "%.0f\n", (base-period=1mS); }
awk: cmd. line:1:  ^ syntax error
awk: cmd. line:1: BEGIN { printf "%.0f\n", (base-period=1mS); }
awk: cmd. line:1:   ^ syntax
error
/usr/bin/latency-test: line 26: [: servo-period=5mS: integer expression
expected
awk: cmd. line:1: BEGIN { printf "%.0f\n", (servo-period=5mS); }
awk: cmd. line:1:   ^ syntax error
awk: cmd. line:1: BEGIN { printf "%.0f\n", (servo-period=5mS); }
awk: cmd. line:1:^ syntax
error
/usr/bin/latency-test: line 72: [: : integer expression expected
/usr/bin/latency-test: line 73: [: : integer expression expected
/usr/bin/latency-test: line 31: [: : integer expression expected
/usr/bin/latency-test: line 32: [: : integer expression expected
/usr/bin/latency-test: line 33: [: : integer expression expected
/usr/bin/latency-test: line 34: [: : integer expression expected
/usr/bin/latency-test: line 31: [: : integer expression expected
/usr/bin/latency-test: line 32: [: : integer expression expected
/usr/bin/latency-test: line 33: [: : integer expression expected
/usr/bin/latency-test: line 34: [: : integer expression expected
/usr/bin/latency-test: line 77: [: -eq: unary operator expected
Note: Using POSIX realtime
HAL: ERROR: thread 'fast' not found
lat.hal:3: addf failed
Note: Using POSIX realtime
=

The --help shows both upper and lowercase s's being used but both work as
above.

The wintel versions also exit with exactly the same msg.

Thanks all.

Cheers, Gene Heskett.


___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

[Emc-developers] latency-test period - (return) problem

[gene heskett]

Greetings all;

both my build (on buster armhf) and the buildbot version of 2.9-pre are 
failing: terminal output from my build:
===
pi@rpi4:/media/pi/workspace $ latency-test period -
/usr/bin/latency-test: line 26: [: period: integer expression expected
Note: Using POSIX realtime
HAL: ERROR: thread 'slow' not found
lat.hal:3: addf failed
Note: Using POSIX realtime
===
terminal output of buildbot version:
===
pi@rpi4:/media/pi/workspace $ latency-test period -
/usr/bin/latency-test: line 26: [: period: integer expression expected
Note: Using POSIX realtime
HAL: ERROR: thread 'slow' not found
lat.hal:3: addf failed
Note: Using POSIX realtime
===

It has been this way for a bit.

Because on my pi, I have two threads, a 1ms thread for the linuxcnc 
control stuff, and a 200 hz, 5 millisecond for the hand controls, it 
would be informative if the period syntax also included the ability to 
trace/measure this slower thread too but that implied syntax also fails
=
pi@rpi4:/media/pi/workspace $ latency-test base-period=1mS servo-
period=5mS
/usr/bin/latency-test: line 26: [: base-period=1mS: integer expression 
expected
awk: cmd. line:1: BEGIN { printf "%.0f\n", (base-period=1mS); }
awk: cmd. line:1:  ^ syntax error
awk: cmd. line:1: BEGIN { printf "%.0f\n", (base-period=1mS); }
awk: cmd. line:1:   ^ syntax 
error
/usr/bin/latency-test: line 26: [: servo-period=5mS: integer expression 
expected
awk: cmd. line:1: BEGIN { printf "%.0f\n", (servo-period=5mS); }
awk: cmd. line:1:   ^ syntax error
awk: cmd. line:1: BEGIN { printf "%.0f\n", (servo-period=5mS); }
awk: cmd. line:1:^ syntax 
error
/usr/bin/latency-test: line 72: [: : integer expression expected
/usr/bin/latency-test: line 73: [: : integer expression expected
/usr/bin/latency-test: line 31: [: : integer expression expected
/usr/bin/latency-test: line 32: [: : integer expression expected
/usr/bin/latency-test: line 33: [: : integer expression expected
/usr/bin/latency-test: line 34: [: : integer expression expected
/usr/bin/latency-test: line 31: [: : integer expression expected
/usr/bin/latency-test: line 32: [: : integer expression expected
/usr/bin/latency-test: line 33: [: : integer expression expected
/usr/bin/latency-test: line 34: [: : integer expression expected
/usr/bin/latency-test: line 77: [: -eq: unary operator expected
Note: Using POSIX realtime
HAL: ERROR: thread 'fast' not found
lat.hal:3: addf failed
Note: Using POSIX realtime
=

The --help shows both upper and lowercase s's being used but both work as 
above.

The wintel versions also exit with exactly the same msg.

Thanks all.

Cheers, Gene Heskett.
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 





___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers