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
