[nanomsg] Re: [Non-DoD Source] Windows working for libnng (mostly)

  • From: Michael <mwpowellhtx@xxxxxxxxx>
  • To: nanomsg@xxxxxxxxxxxxx
  • Date: Wed, 18 Jan 2017 08:28:15 -0500

In embedded systems you do (have high performance timing), friend. It is 
expected and goes with the territory.

On January 18, 2017 4:28:44 AM EST, Garrett D'Amore <garrett@xxxxxxxxxx> wrote:

inproc runs really fast.  again, you shouldn’t have an issue.  But if
you
want to timeout after tiny amounts of time, you might have problems.  I
don’t recommend it though, as most systems cannot schedule processes
reliably in < 10ms.

You don’t need to have super fine-grained timers to get high
performance.
These timers are generally used to deal with failing or with message
retries.  Most of the time they aren’t needed if things are working
well.

On Tue, Jan 17, 2017 at 10:27 PM, Matthieu Bec <mbec@xxxxxxxx> wrote:

Agreed for network, but
- what about ipc/inproc?
- there were some very interesting development/discussion about nn
over
RDMA (~6 month back in this exploder)
Those seem within reasonable reach.
Matthieu


On 1/17/17, 10:21 PM, "nanomsg-bounce@xxxxxxxxxxxxx on behalf of
Garrett
D'Amore" <nanomsg-bounce@xxxxxxxxxxxxx on behalf of
garrett@xxxxxxxxxx>
wrote:

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-----
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























-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Other related posts:

  1. Home
  2. nanomsg
  3. Archive
  4. 01-2017