On Tue, 7 Oct 2008 09:32:37 +1000, James Mills <prologic@short circuit.net.auw rote:
Indeed, this looks wrong - or at least inconclusive. The benchmark
above demonstrates throughput, not minimum (or maximum, or average,
or any other statistic) response latency, which is what the OP was
really asking about.
Jean-Paul
>On Tue, Oct 7, 2008 at 9:25 AM, Blubaugh, David A. <dblubaugh@belc an.comwrote:
>
>Most event-driven frameworks should be capable
>of this kind of "real-time" performance. Indeed my own
>event/component framework (pymills) is capable of
>much more than 70Hz in terms of performance.
>
>$ python examples/event/bench.py -e 100000
>Setting up Sender...
>Setting up Receiver...
>
>Total Events: 100005 (74663/s after 1.34s)
>
>If i'm not wrong this roughly equates to about
>74 KHz
>
>close to real time constraints? For example is it possible to develop a
>python program that can address an interrupt or execute an operation
>within 70 Hz or less?? Are there any additional considerations that I
>should investigate first regarding this matter??
>python program that can address an interrupt or execute an operation
>within 70 Hz or less?? Are there any additional considerations that I
>should investigate first regarding this matter??
>Most event-driven frameworks should be capable
>of this kind of "real-time" performance. Indeed my own
>event/component framework (pymills) is capable of
>much more than 70Hz in terms of performance.
>
>$ python examples/event/bench.py -e 100000
>Setting up Sender...
>Setting up Receiver...
>
>Total Events: 100005 (74663/s after 1.34s)
>
>If i'm not wrong this roughly equates to about
>74 KHz
>
above demonstrates throughput, not minimum (or maximum, or average,
or any other statistic) response latency, which is what the OP was
really asking about.
Jean-Paul