One can implement 4kHz timer driven control loop reasonably solidly in Linux,
rt_preempt as required.
What happens if each of these 250us step intends to call into nn-ng if that
only has ms granularity?
If your allocated processing time is <250us, I'd expect the ability to timeout
in sub-milliseconds.
Thanks,
Matthieu
On 1/17/17, 7:19 PM, "nanomsg-bounce@xxxxxxxxxxxxx on behalf of Garrett
D'Amore" <nanomsg-bounce@xxxxxxxxxxxxx on behalf of garrett@xxxxxxxxxx> wrote:
I’m not sure I understand the question. If the timers on your system are
extremely slow, you will be limited by how accurately you can capture events
(with respect to time). I’d be shocked if you had a system timer that fired
less often than
50 Hz, and that’s probably good enough for most uses. (Windows uses the
slowest timer I know of, at 15.6 ms — about 66 Hz.)
Things will work just fine for you provided you don’t need very short interval
timers. The *performance* may suffer if thread scheduling delays create a
problem, although most systems with slow clocks don’t wait for the entire clock
to expire before task
switching — threads that block on I/O can cause a task switch immediately.
(Compute bound threads are a different problem, but nng should not be
introducing any of those. :-)
I’m curious to understand what exactly you think several kHz is measuring. The
slowest pentium ever was over 10MHz, and the slowest Intel CPU was a 4004
calculator CPU that ran at 740KHz. Even the old 6502 CPU ran at 1MHz. If you
mean the “timer clock”,
i.e. the frequency at which clock interrupts occur and scheduling happens,
anything over 1kHZ is actually quite fast. And yes, if you want to make use of
such frequencies, a 1ms timer granularity won’t be sufficient to match your
finest frequency, so you
might have an opportunity for scheduling interrupts to do things that are
delayed until the next clock interrupt. I think that’s relatively harmless.
That said, I’ve not yet decided whether to reduce the core nng clock unit from
microseconds to milliseconds. I’ll probably leave it at micros for now just
because it would take work to change it.
On Tue, Jan 17, 2017 at 5:13 PM, Matthieu Bec
<mbec@xxxxxxxx> wrote:
newbie question: we expect to have few kHz systems with nn/nnng - few being
like 2, or 4 at most.
Does this means we might detect anomalies more than 1 frame late?
On 1/17/17, 5:59 AM, "Karan, Cem F CIV USARMY RDECOM ARL (US)"
<nanomsg-bounce@xxxxxxxxxxxxx on behalf of
cem.f.karan.civ@xxxxxxxx> wrote:
I can think of theoretical things I can do with microsecond timers that I can't
do with millisecond timers, but they are purely theoretical at this point. As
long as you document what the timing is, I think we can all handle it pretty
easily.
As a suggestion, can you add a function similar to "uint64_t
ticks_per_second(void)"? That way you can change the timing resolution in
future versions of the library, and we can write code that adapts to whatever
the current resolution is in the currently
installed version of the library.
Thanks,
Cem Karan
-----Original Message-----
From: nanomsg-bounce@xxxxxxxxxxxxx [mailto:nanomsg-bounce@xxxxxxxxxxxxx] On ;
Behalf Of Garrett D'Amore
Sent: Saturday, January 14, 2017 4:39 PM
To: nanomsg@xxxxxxxxxxxxx
Subject: [Non-DoD Source] [nanomsg] Windows working for libnng (mostly)
I’ve added Windows support for libnng. So far things are working quite well,
but the NamedPipe support is still not done yet. TCP *does*
work though.
Btw, I’m seriously considering changing the unit of timing we use everywhere
from microseconds to milliseconds. Windows time keeping
is actually much coarser than this (we could use the performance counters,
but when we sleep or block on a condition, we have system
clock resolutions), and frankly I’m not aware of any system that offers a
resolution of better than 1 ms for event handling.
These times would not be useful for measuring performance, but in terms of
timeouts and so forth, it seems like 1 millisecond is more
than adequate. (I’m having trouble imagining wanting to set a timeout of
less than 1 millisecond, or where 1 millisecond resolution would
be too coarse.)
- Garrett
