I think you’re worrying about a non-issue. If your timer runs at sub-ms
granularity, everything will still work. The question is whether
sub-millisecond timeouts make sense at all, in the face of network
protocols. I don’t think they do. If you need to set timeouts for RPC
requests that are under a millisecond, you’re probably not wanting to use
nanomsg but rather some highly specialized transport (such as RDMA over
Infiniband.)
On Tue, Jan 17, 2017 at 10:06 PM, Matthieu Bec <mbec@xxxxxxxx> wrote:
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-----On Behalf Of Garrett D'Amore
From: nanomsg-bounce@xxxxxxxxxxxxx [mailto:nanomsg-bounce@xxxxxxxxxxxxx]
Sent: Saturday, January 14, 2017 4:39 PMwell, but the NamedPipe support is still not done yet. TCP *does*
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
work though.everywhere from microseconds to milliseconds. Windows time keeping
Btw, I’m seriously considering changing the unit of timing we use
is actually much coarser than this (we could use the performancecounters, but when we sleep or block on a condition, we have system
clock resolutions), and frankly I’m not aware of any system that offersa resolution of better than 1 ms for event handling.
of timeouts and so forth, it seems like 1 millisecond is more
These times would not be useful for measuring performance, but in terms
than adequate. (I’m having trouble imagining wanting to set a timeoutof less than 1 millisecond, or where 1 millisecond resolution would
be too coarse.)
- Garrett
