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
