Rocksolid Light

Welcome to novaBBS (click a section below)

mail  files  register  newsreader  groups  login

Message-ID:  

Logic is the chastity belt of the mind!


devel / comp.lang.forth / Precision of MS delay

SubjectAuthor
* Precision of MS delayKrishna Myneni
+* Re: Precision of MS delayMarcel Hendrix
|+* Re: Precision of MS delayAnton Ertl
||`- Re: Precision of MS delayKrishna Myneni
|`- Re: Precision of MS delayKrishna Myneni
`* Re: Precision of MS delayantispam
 `* Re: Precision of MS delayKrishna Myneni
  +* Re: Precision of MS delayMike
  |+- Re: Precision of MS delayantispam
  |`- Re: Precision of MS delayKrishna Myneni
  `* Re: Precision of MS delayKrishna Myneni
   `- Re: Precision of MS delaykoo

1
Precision of MS delay

<sgk7nl$i13$1@dont-email.me>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=14401&group=comp.lang.forth#14401

 copy link   Newsgroups: comp.lang.forth
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: krishna....@ccreweb.org (Krishna Myneni)
Newsgroups: comp.lang.forth
Subject: Precision of MS delay
Date: Mon, 30 Aug 2021 22:29:54 -0500
Organization: A noiseless patient Spider
Lines: 99
Message-ID: <sgk7nl$i13$1@dont-email.me>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Tue, 31 Aug 2021 03:29:57 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="68794234ac3ad1a31d7c6a375ac6a778";
logging-data="18467"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+M1t5zkUDcdRRGLNU6JFzz"
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
Thunderbird/78.11.0
Cancel-Lock: sha1:8biYvgRV8fKDbL9QQjVAnaDNVIk=
Content-Language: en-US
X-Mozilla-News-Host: snews://news.eternal-september.org:563
 by: Krishna Myneni - Tue, 31 Aug 2021 03:29 UTC

There can be a significant difference in the precision (and accuracy) of
the delay provided by the standard word MS in different implementations.
We recognized that using an OS sleep function was not suitable for our
precision delay needs early on in the development of kForth (32-bit
version), and switched to using a polling loop to implement MS. To
demonstrate the difference in precision, I performed some tests
comparing kForth-64 (ver 0.2.2) and Gforth (ver. 0.7.9_20210506), which
have different implementations of MS. Test code is given below the results.

\ Test the precision of 100 millisecond MS delay

\ kForth-64
100 ms-precision

Mean difference (microseconds) = 0.017
St. deviation (microseconds) = 0.33886
ok

\ Gforth 64-bit version
100 ms-precision
Mean difference (microseconds) = 388.364
St. deviation (microseconds) = 86.7326700849227

In 1000 measurements, the mean difference between 100 MS delay and the
elapsed time, measured by a microsecond resolution timer, is within one
microsecond in kForth-64 (results should be similar for kForth-32), but
is close to 400 microseconds on average in Gforth. The standard
deviations for the measured difference distributions, likewise shows a
distribution with a width of better than one microsecond for the kForth
MS implementation, while Gforth's shows a standard deviation of 87
microseconds.

The difference is attributable to Gforth's implementation of MS using a
nanosleep system call. Gforth's implementation has better than 1
millisecond resolution, based on the above measurements. The
demonstration simply illustrates that MS can be implemented to higher
precision and accuracy, if one needs such performance in delays.

--
Krishna Myneni

----------
\ ms-precision.4th
\ \ Measure the precision of MS using a microsecond timer.
\

\ include ans-words

false value utimerFound?

[DEFINED] US2@ [IF]
true to utimerFound?
: trial ( udelay_ms -- delta_us )
dup us2@ rot ms us2@ 2swap d- rot 1000 m* d- d>s ;
[ELSE]

[DEFINED] UTIME [IF]
true to utimerFound?
: trial ( udelay_ms -- delta_us )
dup utime rot ms utime 2swap d- rot 1000 m* d- d>s ;
[THEN]

[THEN]

utimerFound? 0= [IF]
cr .( Sorry, recognized microsecond timer not found! ) cr
quit
[THEN]

: fsquare fdup f* ;

1000 constant NTRIALS

create data[ NTRIALS cells allot
: ]! ( n a idx -- ) cells + ! ;
: ]@ ( a idx -- n ) cells + @ ;

: collect ( udelay_ms -- )
NTRIALS 0 DO
dup trial data[ I ]!
LOOP drop ;

: stats ( -- ) ( F: -- mean stdev )
0.0e0 NTRIALS 0 DO data[ I ]@ s>f f+ LOOP
NTRIALS s>f f/
fdup 0e
NTRIALS 0 DO
fover data[ I ]@ s>f f- fsquare f+
LOOP fswap fdrop
NTRIALS 1- s>f f/ fsqrt ;

: ms-precision ( udelay_ms -- )
collect stats fswap
cr ." Mean difference (microseconds) = " f.
cr ." St. deviation (microseconds) = " f.
cr ;
---------

Re: Precision of MS delay

<3c85db21-6b87-406e-8e99-f72d94481eb6n@googlegroups.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=14406&group=comp.lang.forth#14406

 copy link   Newsgroups: comp.lang.forth
X-Received: by 2002:a05:622a:1a9b:: with SMTP id s27mr1509354qtc.165.1630397498969;
Tue, 31 Aug 2021 01:11:38 -0700 (PDT)
X-Received: by 2002:a0c:aa55:: with SMTP id e21mr27524780qvb.41.1630397498814;
Tue, 31 Aug 2021 01:11:38 -0700 (PDT)
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!proxad.net!feeder1-2.proxad.net!209.85.160.216.MISMATCH!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.lang.forth
Date: Tue, 31 Aug 2021 01:11:38 -0700 (PDT)
In-Reply-To: <sgk7nl$i13$1@dont-email.me>
Injection-Info: google-groups.googlegroups.com; posting-host=2001:1c05:2f14:600:4da7:ab63:2a7d:97c4;
posting-account=-JQ2RQoAAAB6B5tcBTSdvOqrD1HpT_Rk
NNTP-Posting-Host: 2001:1c05:2f14:600:4da7:ab63:2a7d:97c4
References: <sgk7nl$i13$1@dont-email.me>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <3c85db21-6b87-406e-8e99-f72d94481eb6n@googlegroups.com>
Subject: Re: Precision of MS delay
From: mhx...@iae.nl (Marcel Hendrix)
Injection-Date: Tue, 31 Aug 2021 08:11:38 +0000
Content-Type: text/plain; charset="UTF-8"
 by: Marcel Hendrix - Tue, 31 Aug 2021 08:11 UTC

On Tuesday, August 31, 2021 at 5:30:00 AM UTC+2, Krishna Myneni wrote:
> There can be a significant difference in the precision (and accuracy) of
> the delay provided by the standard word MS in different implementations.
> We recognized that using an OS sleep function was not suitable for our
> precision delay needs early on in the development of kForth (32-bit
> version), and switched to using a polling loop to implement MS.

Actually, this is quite hard to do because of modern processors' power
management. A simple busy-wait won't work. What are you polling?

-marcel

Re: Precision of MS delay

<2021Aug31.122737@mips.complang.tuwien.ac.at>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=14407&group=comp.lang.forth#14407

 copy link   Newsgroups: comp.lang.forth
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: ant...@mips.complang.tuwien.ac.at (Anton Ertl)
Newsgroups: comp.lang.forth
Subject: Re: Precision of MS delay
Date: Tue, 31 Aug 2021 10:27:37 GMT
Organization: Institut fuer Computersprachen, Technische Universitaet Wien
Lines: 30
Message-ID: <2021Aug31.122737@mips.complang.tuwien.ac.at>
References: <sgk7nl$i13$1@dont-email.me> <3c85db21-6b87-406e-8e99-f72d94481eb6n@googlegroups.com>
Injection-Info: reader02.eternal-september.org; posting-host="056757c5a972bdddd82a7ebd2afed8f6";
logging-data="5786"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19D9YVaflIWpnC4WuqvRVBy"
Cancel-Lock: sha1:cXfLOI6++dlSKbKWWtHCZOO1xvg=
X-newsreader: xrn 10.00-beta-3
 by: Anton Ertl - Tue, 31 Aug 2021 10:27 UTC

Marcel Hendrix <mhx@iae.nl> writes:
>On Tuesday, August 31, 2021 at 5:30:00 AM UTC+2, Krishna Myneni wrote:
>> There can be a significant difference in the precision (and accuracy) of
>> the delay provided by the standard word MS in different implementations.
>> We recognized that using an OS sleep function was not suitable for our
>> precision delay needs early on in the development of kForth (32-bit
>> version), and switched to using a polling loop to implement MS.
>
>Actually, this is quite hard to do because of modern processors' power
>management. A simple busy-wait won't work. What are you polling?

On IA-32 and AMD64 CPUs since Core Solo and K10 (Phenom), the rdtsc
counter runs at a constant rate, so you can poll rtdsc in a busy loop
until the deadline is reached.

And then the OS decides that your thread has occupied enough CPU time
and gives the CPU to a different thread or process right before the
deadline:-) If you cannot get high precision from the OS, one
alternative is to use the OS nanosleep(), pselect() and the like for,
n-e ms (where e depends on the imprecision of the OS call), and use
busy waiting for the rest. This does not guarantee that the scheduler
will not interrupt your thread at an inconvenient time, but it lowers
the probability.

- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2021: https://euro.theforth.net/2021

Re: Precision of MS delay

<sgl6qd$23v$1@dont-email.me>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=14408&group=comp.lang.forth#14408

 copy link   Newsgroups: comp.lang.forth
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: krishna....@ccreweb.org (Krishna Myneni)
Newsgroups: comp.lang.forth
Subject: Re: Precision of MS delay
Date: Tue, 31 Aug 2021 07:20:27 -0500
Organization: A noiseless patient Spider
Lines: 27
Message-ID: <sgl6qd$23v$1@dont-email.me>
References: <sgk7nl$i13$1@dont-email.me>
<3c85db21-6b87-406e-8e99-f72d94481eb6n@googlegroups.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Tue, 31 Aug 2021 12:20:29 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="68794234ac3ad1a31d7c6a375ac6a778";
logging-data="2175"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18kYh0wf7i1kBrYWKr5MYaa"
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
Thunderbird/78.11.0
Cancel-Lock: sha1:/36seRV7GlrqQHizxSmQLqxJYyw=
In-Reply-To: <3c85db21-6b87-406e-8e99-f72d94481eb6n@googlegroups.com>
Content-Language: en-US
 by: Krishna Myneni - Tue, 31 Aug 2021 12:20 UTC

On 8/31/21 3:11 AM, Marcel Hendrix wrote:
> On Tuesday, August 31, 2021 at 5:30:00 AM UTC+2, Krishna Myneni wrote:
>> There can be a significant difference in the precision (and accuracy) of
>> the delay provided by the standard word MS in different implementations.
>> We recognized that using an OS sleep function was not suitable for our
>> precision delay needs early on in the development of kForth (32-bit
>> version), and switched to using a polling loop to implement MS.
>
> Actually, this is quite hard to do because of modern processors' power
> management. A simple busy-wait won't work. What are you polling?
>

The system clock. See the source file vmc.c, function C_usec() from any
of the Linux kForth packages. MS scales the argument by 1000 and calls
C_usec(). The relevant polling loop is

do
{
gettimeofday (&tv2, NULL);
} while (timercmp(&tv1, &tv2, >)) ;

tv2 is the current time, and tv1 contains the computed end time. The
times have a field with microsecond resolution.

--
Krishna

Re: Precision of MS delay

<sgldji$ipt$1@dont-email.me>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=14413&group=comp.lang.forth#14413

 copy link   Newsgroups: comp.lang.forth
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: krishna....@ccreweb.org (Krishna Myneni)
Newsgroups: comp.lang.forth
Subject: Re: Precision of MS delay
Date: Tue, 31 Aug 2021 09:16:16 -0500
Organization: A noiseless patient Spider
Lines: 72
Message-ID: <sgldji$ipt$1@dont-email.me>
References: <sgk7nl$i13$1@dont-email.me>
<3c85db21-6b87-406e-8e99-f72d94481eb6n@googlegroups.com>
<2021Aug31.122737@mips.complang.tuwien.ac.at>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Tue, 31 Aug 2021 14:16:18 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="68794234ac3ad1a31d7c6a375ac6a778";
logging-data="19261"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19+ki+AzH6fL0ogUaEk3PPg"
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
Thunderbird/78.11.0
Cancel-Lock: sha1:6MhvsKGi4gD+4vjEogr396aALpQ=
In-Reply-To: <2021Aug31.122737@mips.complang.tuwien.ac.at>
Content-Language: en-US
 by: Krishna Myneni - Tue, 31 Aug 2021 14:16 UTC

On 8/31/21 5:27 AM, Anton Ertl wrote:
....
> If you cannot get high precision from the OS, one
> alternative is to use the OS nanosleep(), pselect() and the like for,
> n-e ms (where e depends on the imprecision of the OS call), and use
> busy waiting for the rest. This does not guarantee that the scheduler
> will not interrupt your thread at an inconvenient time, but it lowers
> the probability.
>

All approaches to implementing a delay on a system with interrupts will
result in a probability distribution for the deltas, where delta is the
actual elapsed time minus the requested delay time. However, the polling
implementation dramatically reduces the width of the distribution
compared to calling a sleep function. Representative statistics for the
distributions as a function of delay are given below for the two
approaches. The mu and sigma are the mean and standard deviation in
microseconds for the distribution of deltas in 1000 trials for the word MS.

Gforth 64-bit (nanosleep call)
-------
Delay (ms), mu (us), sigma (us)
1, 118, 31.4
10, 300, 110.
100, 388, 86.7
500, 791, 114.
1000, 1223, 253.

kForth-64 (polling system clock)
---------
Delay (ms), mu (us), sigma (us)
1, 0.009, 0.226
10, 0.037, 0.553
100, 0.017, 0.339
500, 0.021, 0.216
1000, 0.035, 0.382

The nanosleep call used by Gforth leads to a clear systematic drift to
larger positive delta in the mean, with increasing delay, and this is to
be expected. At 1000 ms delay, the average delay produced by MS is more
than 1 ms greater. The width of the distribution for this approach also
shows an overall systematic drift to increasing width with delay.

It is difficult to tell, over this range of delays, whether or not there
is a similar, but considerably smaller, systematic drift in the mean vs
delay for the polling approach -- I expect there to be a systematic
error with increasing delay. There is also no clear indication that the
width of the distribution is increasing with delay, over this range of
delays, for the polling approach. The ratio of the sigmas vs delay is
given below.

Delay (ms) sigma(nanosleep)/sigma(polling)
1, 3490
10, 199
100, 255
500, 528
1000, 663

The above results are probably best case results on my system, where
nothing beyond system processes were running while the measurements were
performed, although several applications were open.

kForth provides the following timing words:

Precision Delays: MS US
Non-Time-Critical Delays: USLEEP
Fetch Time: MS@ US2@ TIME&DATE

--
Krishna

Re: Precision of MS delay

<sgnn4n$29m$1@z-news.wcss.wroc.pl>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=14427&group=comp.lang.forth#14427

 copy link   Newsgroups: comp.lang.forth
Path: i2pn2.org!i2pn.org!aioe.org!news.dns-netz.com!news.freedyn.net!newsreader4.netcologne.de!news.netcologne.de!peer02.ams1!peer.ams1.xlned.com!news.xlned.com!peer03.ams4!peer.am4.highwinds-media.com!news.highwinds-media.com!newsfeed.neostrada.pl!unt-exc-01.news.neostrada.pl!newsfeed.pionier.net.pl!pwr.wroc.pl!news.wcss.wroc.pl!not-for-mail
From: antis...@math.uni.wroc.pl
Newsgroups: comp.lang.forth
Subject: Re: Precision of MS delay
Date: Wed, 1 Sep 2021 11:11:19 +0000 (UTC)
Organization: Politechnika Wroclawska
Lines: 45
Message-ID: <sgnn4n$29m$1@z-news.wcss.wroc.pl>
References: <sgk7nl$i13$1@dont-email.me>
NNTP-Posting-Host: hera.math.uni.wroc.pl
X-Trace: z-news.wcss.wroc.pl 1630494679 2358 156.17.86.1 (1 Sep 2021 11:11:19 GMT)
X-Complaints-To: abuse@news.pwr.wroc.pl
NNTP-Posting-Date: Wed, 1 Sep 2021 11:11:19 +0000 (UTC)
Cancel-Lock: sha1:3HyqOsDnbPA6RvEfjFvTpai64gM=
User-Agent: tin/2.4.3-20181224 ("Glen Mhor") (UNIX) (Linux/4.19.0-10-amd64 (x86_64))
X-Received-Bytes: 2993
 by: antis...@math.uni.wroc.pl - Wed, 1 Sep 2021 11:11 UTC

Krishna Myneni <krishna.myneni@ccreweb.org> wrote:
> There can be a significant difference in the precision (and accuracy) of
> the delay provided by the standard word MS in different implementations.
> We recognized that using an OS sleep function was not suitable for our
> precision delay needs early on in the development of kForth (32-bit
> version), and switched to using a polling loop to implement MS. To
> demonstrate the difference in precision, I performed some tests
> comparing kForth-64 (ver 0.2.2) and Gforth (ver. 0.7.9_20210506), which
> have different implementations of MS. Test code is given below the results.
>
> \ Test the precision of 100 millisecond MS delay
>
> \ kForth-64
> 100 ms-precision
>
> Mean difference (microseconds) = 0.017
> St. deviation (microseconds) = 0.33886
> ok
>
> \ Gforth 64-bit version
> 100 ms-precision
> Mean difference (microseconds) = 388.364
> St. deviation (microseconds) = 86.7326700849227
>
> In 1000 measurements, the mean difference between 100 MS delay and the
> elapsed time, measured by a microsecond resolution timer, is within one
> microsecond in kForth-64 (results should be similar for kForth-32), but
> is close to 400 microseconds on average in Gforth. The standard
> deviations for the measured difference distributions, likewise shows a
> distribution with a width of better than one microsecond for the kForth
> MS implementation, while Gforth's shows a standard deviation of 87
> microseconds.
>
> The difference is attributable to Gforth's implementation of MS using a
> nanosleep system call. Gforth's implementation has better than 1
> millisecond resolution, based on the above measurements. The
> demonstration simply illustrates that MS can be implemented to higher
> precision and accuracy, if one needs such performance in delays.

What about running your test on heavily loaded machine? That is
when you have 100% load on each core? Or having several instances
of Forth doing MS in parallel (but with different setpoints)?

--
Waldek Hebisch

Re: Precision of MS delay

<sgnsdl$265$1@dont-email.me>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=14429&group=comp.lang.forth#14429

 copy link   Newsgroups: comp.lang.forth
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: krishna....@ccreweb.org (Krishna Myneni)
Newsgroups: comp.lang.forth
Subject: Re: Precision of MS delay
Date: Wed, 1 Sep 2021 07:41:23 -0500
Organization: A noiseless patient Spider
Lines: 55
Message-ID: <sgnsdl$265$1@dont-email.me>
References: <sgk7nl$i13$1@dont-email.me> <sgnn4n$29m$1@z-news.wcss.wroc.pl>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Wed, 1 Sep 2021 12:41:25 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="9868bf76a6ad4d6cd2d485c6f0f4b5a0";
logging-data="2245"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18Gu+nsOgjrNyf6NJTuOjlK"
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
Thunderbird/78.11.0
Cancel-Lock: sha1:Z3kPL1OVTBoUEjQBKYmnXlbdqtM=
In-Reply-To: <sgnn4n$29m$1@z-news.wcss.wroc.pl>
Content-Language: en-US
 by: Krishna Myneni - Wed, 1 Sep 2021 12:41 UTC

On 9/1/21 6:11 AM, antispam@math.uni.wroc.pl wrote:
> Krishna Myneni <krishna.myneni@ccreweb.org> wrote:
>> There can be a significant difference in the precision (and accuracy) of
>> the delay provided by the standard word MS in different implementations.
>> We recognized that using an OS sleep function was not suitable for our
>> precision delay needs early on in the development of kForth (32-bit
>> version), and switched to using a polling loop to implement MS. To
>> demonstrate the difference in precision, I performed some tests
>> comparing kForth-64 (ver 0.2.2) and Gforth (ver. 0.7.9_20210506), which
>> have different implementations of MS. Test code is given below the results.
>>
>> \ Test the precision of 100 millisecond MS delay
>>
>> \ kForth-64
>> 100 ms-precision
>>
>> Mean difference (microseconds) = 0.017
>> St. deviation (microseconds) = 0.33886
>> ok
>>
>> \ Gforth 64-bit version
>> 100 ms-precision
>> Mean difference (microseconds) = 388.364
>> St. deviation (microseconds) = 86.7326700849227
>>
>> In 1000 measurements, the mean difference between 100 MS delay and the
>> elapsed time, measured by a microsecond resolution timer, is within one
>> microsecond in kForth-64 (results should be similar for kForth-32), but
>> is close to 400 microseconds on average in Gforth. The standard
>> deviations for the measured difference distributions, likewise shows a
>> distribution with a width of better than one microsecond for the kForth
>> MS implementation, while Gforth's shows a standard deviation of 87
>> microseconds.
>>
>> The difference is attributable to Gforth's implementation of MS using a
>> nanosleep system call. Gforth's implementation has better than 1
>> millisecond resolution, based on the above measurements. The
>> demonstration simply illustrates that MS can be implemented to higher
>> precision and accuracy, if one needs such performance in delays.
>
> What about running your test on heavily loaded machine? That is
> when you have 100% load on each core? Or having several instances
> of Forth doing MS in parallel (but with different setpoints)?
>

Yes, it needs to be tested to see how fast the delay precision and
accuracy degrade when the system load is gradually increased. In typical
use we run Forth applications on a system in which no other applications
are concurrently running, i.e. specialized data acquisition systems.
Linux, like most modern OS's, is efficient in distributing load across
multiple cores.

--
Krishna

Re: Precision of MS delay

<40843bc5-64ae-4562-87e7-fce9897179d7n@googlegroups.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=14431&group=comp.lang.forth#14431

 copy link   Newsgroups: comp.lang.forth
X-Received: by 2002:a05:622a:1452:: with SMTP id v18mr8564896qtx.214.1630507681916;
Wed, 01 Sep 2021 07:48:01 -0700 (PDT)
X-Received: by 2002:ac8:43d6:: with SMTP id w22mr8665368qtn.92.1630507681604;
Wed, 01 Sep 2021 07:48:01 -0700 (PDT)
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.misty.com!border2.nntp.dca1.giganews.com!nntp.giganews.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.lang.forth
Date: Wed, 1 Sep 2021 07:48:01 -0700 (PDT)
In-Reply-To: <sgnsdl$265$1@dont-email.me>
Injection-Info: google-groups.googlegroups.com; posting-host=87.94.110.112; posting-account=bfqVhAoAAABnxNiPDFL3mSrvM7YNO32Q
NNTP-Posting-Host: 87.94.110.112
References: <sgk7nl$i13$1@dont-email.me> <sgnn4n$29m$1@z-news.wcss.wroc.pl> <sgnsdl$265$1@dont-email.me>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <40843bc5-64ae-4562-87e7-fce9897179d7n@googlegroups.com>
Subject: Re: Precision of MS delay
From: oh2...@gmail.com (Mike)
Injection-Date: Wed, 01 Sep 2021 14:48:01 +0000
Content-Type: text/plain; charset="UTF-8"
Lines: 23
 by: Mike - Wed, 1 Sep 2021 14:48 UTC

On Wednesday, September 1, 2021 at 3:41:27 PM UTC+3, Krishna Myneni wrote:

> Yes, it needs to be tested to see how fast the delay precision and
> accuracy degrade when the system load is gradually increased. In typical
> use we run Forth applications on a system in which no other applications
> are concurrently running, i.e. specialized data acquisition systems.
> Linux, like most modern OS's, is efficient in distributing load across
> multiple cores.
>
> --
> Krishna

In order to get realtime performance you need to run the forth process with a realtime schedule.

Assigning a realtime schedule to forth would make it it's performance independent of the load
caused by the fair scheduling processes.
Fair scheduling is normally used in linux if nothing else is requested.

There are many scheduling possibilites in Linux.
https://www.kernel.org/doc/html/latest/scheduler/index.html

Mike

Re: Precision of MS delay

<sgos8f$dt5$2@z-news.wcss.wroc.pl>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=14440&group=comp.lang.forth#14440

 copy link   Newsgroups: comp.lang.forth
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!4.us.feeder.erje.net!2.eu.feeder.erje.net!feeder.erje.net!newsreader4.netcologne.de!news.netcologne.de!peer03.ams1!peer.ams1.xlned.com!news.xlned.com!peer02.ams4!peer.am4.highwinds-media.com!news.highwinds-media.com!newsfeed.neostrada.pl!unt-exc-02.news.neostrada.pl!newsfeed.pionier.net.pl!pwr.wroc.pl!news.wcss.wroc.pl!not-for-mail
From: antis...@math.uni.wroc.pl
Newsgroups: comp.lang.forth
Subject: Re: Precision of MS delay
Date: Wed, 1 Sep 2021 21:44:47 +0000 (UTC)
Organization: Politechnika Wroclawska
Lines: 29
Message-ID: <sgos8f$dt5$2@z-news.wcss.wroc.pl>
References: <sgk7nl$i13$1@dont-email.me> <sgnn4n$29m$1@z-news.wcss.wroc.pl> <sgnsdl$265$1@dont-email.me> <40843bc5-64ae-4562-87e7-fce9897179d7n@googlegroups.com>
NNTP-Posting-Host: hera.math.uni.wroc.pl
X-Trace: z-news.wcss.wroc.pl 1630532687 14245 156.17.86.1 (1 Sep 2021 21:44:47 GMT)
X-Complaints-To: abuse@news.pwr.wroc.pl
NNTP-Posting-Date: Wed, 1 Sep 2021 21:44:47 +0000 (UTC)
Cancel-Lock: sha1:OHm6P4R/1iUzdwV9htNc+wIekyE=
User-Agent: tin/2.4.3-20181224 ("Glen Mhor") (UNIX) (Linux/4.19.0-10-amd64 (x86_64))
X-Received-Bytes: 2160
 by: antis...@math.uni.wroc.pl - Wed, 1 Sep 2021 21:44 UTC

Mike <oh2aun@gmail.com> wrote:
> On Wednesday, September 1, 2021 at 3:41:27 PM UTC+3, Krishna Myneni wrote:
>
> > Yes, it needs to be tested to see how fast the delay precision and
> > accuracy degrade when the system load is gradually increased. In typical
> > use we run Forth applications on a system in which no other applications
> > are concurrently running, i.e. specialized data acquisition systems.
> > Linux, like most modern OS's, is efficient in distributing load across
> > multiple cores.
> >
> > --
> > Krishna
>
> In order to get realtime performance you need to run the forth process with a realtime schedule.
>
> Assigning a realtime schedule to forth would make it it's performance independent of the load
> caused by the fair scheduling processes.
> Fair scheduling is normally used in linux if nothing else is requested.
>
> There are many scheduling possibilites in Linux.
> https://www.kernel.org/doc/html/latest/scheduler/index.html
>
> Mike

Have you considerd what happens when there are several "real time"
processes and each tries to use 100 % CPU time?

--
Waldek Hebisch

Re: Precision of MS delay

<sgpaub$k3p$1@dont-email.me>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=14443&group=comp.lang.forth#14443

 copy link   Newsgroups: comp.lang.forth
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: krishna....@ccreweb.org (Krishna Myneni)
Newsgroups: comp.lang.forth
Subject: Re: Precision of MS delay
Date: Wed, 1 Sep 2021 20:55:22 -0500
Organization: A noiseless patient Spider
Lines: 32
Message-ID: <sgpaub$k3p$1@dont-email.me>
References: <sgk7nl$i13$1@dont-email.me> <sgnn4n$29m$1@z-news.wcss.wroc.pl>
<sgnsdl$265$1@dont-email.me>
<40843bc5-64ae-4562-87e7-fce9897179d7n@googlegroups.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Thu, 2 Sep 2021 01:55:23 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="02b03ada99d6e285e3f7bac443c942dd";
logging-data="20601"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18LVKV2LuH7/ztTgPXtVCru"
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
Thunderbird/78.11.0
Cancel-Lock: sha1:qM4Oq+6lnbwkFqu2vrZq80txt1E=
In-Reply-To: <40843bc5-64ae-4562-87e7-fce9897179d7n@googlegroups.com>
Content-Language: en-US
 by: Krishna Myneni - Thu, 2 Sep 2021 01:55 UTC

On 9/1/21 9:48 AM, Mike wrote:
> On Wednesday, September 1, 2021 at 3:41:27 PM UTC+3, Krishna Myneni wrote:
>
>> Yes, it needs to be tested to see how fast the delay precision and
>> accuracy degrade when the system load is gradually increased. In typical
>> use we run Forth applications on a system in which no other applications
>> are concurrently running, i.e. specialized data acquisition systems.
>> Linux, like most modern OS's, is efficient in distributing load across
>> multiple cores.
>>
>> --
>> Krishna
>
> In order to get realtime performance you need to run the forth process with a realtime schedule.
>
> Assigning a realtime schedule to forth would make it it's performance independent of the load
> caused by the fair scheduling processes.
> Fair scheduling is normally used in linux if nothing else is requested.
>
> There are many scheduling possibilites in Linux.
> https://www.kernel.org/doc/html/latest/scheduler/index.html
>

Thanks for the link. I'm not looking to approximate a real-time Forth,
but only about minimizing the width of probability distribution
(improving the precision) for the difference between a requested delay
and the actual delay. This can be useful, for example, if I want to
generate a trigger (e.g. set a digital line high) or respond to an
external trigger and wait for some fixed delay before reading an input.

--
Krishna

Re: Precision of MS delay

<sgpbe7$mcf$1@dont-email.me>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=14444&group=comp.lang.forth#14444

 copy link   Newsgroups: comp.lang.forth
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: krishna....@ccreweb.org (Krishna Myneni)
Newsgroups: comp.lang.forth
Subject: Re: Precision of MS delay
Date: Wed, 1 Sep 2021 21:03:49 -0500
Organization: A noiseless patient Spider
Lines: 29
Message-ID: <sgpbe7$mcf$1@dont-email.me>
References: <sgk7nl$i13$1@dont-email.me> <sgnn4n$29m$1@z-news.wcss.wroc.pl>
<sgnsdl$265$1@dont-email.me>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Thu, 2 Sep 2021 02:03:51 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="02b03ada99d6e285e3f7bac443c942dd";
logging-data="22927"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/trLLVlRvKZLbddKsTTlu2"
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
Thunderbird/78.11.0
Cancel-Lock: sha1:mJVoQwC60hz6DzWhe2jjc6/v6Po=
In-Reply-To: <sgnsdl$265$1@dont-email.me>
Content-Language: en-US
 by: Krishna Myneni - Thu, 2 Sep 2021 02:03 UTC

On 9/1/21 7:41 AM, Krishna Myneni wrote:
> On 9/1/21 6:11 AM, antispam@math.uni.wroc.pl wrote:
....
>> What about running your test on heavily loaded machine?  That is
>> when you have 100% load on each core?  Or having several instances
>> of Forth doing MS in parallel (but with different setpoints)?
>>
>
> Yes, it needs to be tested to see how fast the delay precision and
> accuracy degrade when the system load is gradually increased. In typical
> use we run Forth applications on a system in which no other applications
> are concurrently running, i.e. specialized data acquisition systems.
> Linux, like most modern OS's, is efficient in distributing load across
> multiple cores.

A simple way to test this might be to fork the Forth process, similar to
the way that the program parallel-mm.4th (link below) works, to generate
multiple processes. It should be possible to examine the precision vs.
number of forks, for a given delay. All forked processes should begin
the precision measurements at nearly the same time, however, maybe by
using a start time set by the initial process.

--
Krishna

parallel-mm.4th:
https://github.com/mynenik/kForth-64/blob/master/forth-src/parallel-mm.4th

Re: Precision of MS delay

<d83b9b83-f07b-4309-b693-267f5e039b5en@googlegroups.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=14445&group=comp.lang.forth#14445

 copy link   Newsgroups: comp.lang.forth
X-Received: by 2002:a37:2d04:: with SMTP id t4mr1728043qkh.160.1630563177945;
Wed, 01 Sep 2021 23:12:57 -0700 (PDT)
X-Received: by 2002:ac8:5905:: with SMTP id 5mr1476823qty.286.1630563177689;
Wed, 01 Sep 2021 23:12:57 -0700 (PDT)
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!proxad.net!feeder1-2.proxad.net!209.85.160.216.MISMATCH!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.lang.forth
Date: Wed, 1 Sep 2021 23:12:57 -0700 (PDT)
In-Reply-To: <sgpbe7$mcf$1@dont-email.me>
Injection-Info: google-groups.googlegroups.com; posting-host=59.115.183.137; posting-account=i0okWgoAAAAhglr6JZfOtOJfOJdiRxzV
NNTP-Posting-Host: 59.115.183.137
References: <sgk7nl$i13$1@dont-email.me> <sgnn4n$29m$1@z-news.wcss.wroc.pl>
<sgnsdl$265$1@dont-email.me> <sgpbe7$mcf$1@dont-email.me>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <d83b9b83-f07b-4309-b693-267f5e039b5en@googlegroups.com>
Subject: Re: Precision of MS delay
From: guo.bing...@gmail.com (koo)
Injection-Date: Thu, 02 Sep 2021 06:12:57 +0000
Content-Type: text/plain; charset="UTF-8"
 by: koo - Thu, 2 Sep 2021 06:12 UTC

On Thursday, September 2, 2021 at 10:03:53 AM UTC+8, Krishna Myneni wrote:
> On 9/1/21 7:41 AM, Krishna Myneni wrote:
> > On 9/1/21 6:11 AM, anti...@math.uni.wroc.pl wrote:
> ...
> >> What about running your test on heavily loaded machine? That is
> >> when you have 100% load on each core? Or having several instances
> >> of Forth doing MS in parallel (but with different setpoints)?
> >>
> >
> > Yes, it needs to be tested to see how fast the delay precision and
> > accuracy degrade when the system load is gradually increased. In typical
> > use we run Forth applications on a system in which no other applications
> > are concurrently running, i.e. specialized data acquisition systems.
> > Linux, like most modern OS's, is efficient in distributing load across
> > multiple cores.
> A simple way to test this might be to fork the Forth process, similar to
> the way that the program parallel-mm.4th (link below) works, to generate
> multiple processes. It should be possible to examine the precision vs.
> number of forks, for a given delay. All forked processes should begin
> the precision measurements at nearly the same time, however, maybe by
> using a start time set by the initial process.
>
> --
> Krishna
>
> parallel-mm.4th:
> https://github.com/mynenik/kForth-64/blob/master/forth-src/parallel-mm.4th
I've been wondering implementation of precision timing function embedded in north bridge.
It might be easier, since all data will be store in DDRAM.
Regards, all

1
server_pubkey.txt

rocksolid light 0.9.7
clearnet tor