Hello.
Well, I've instrumented:
* rbwriter to put it's TSC into the first 8 bytes of each message and
* rbreader to print the difference between it's current TSC and of the
first message in each read chunk.
So, my results are from 36000 CPU ticks to 45000 ticks, about 10-20
microseconds.
It's an order of magnitude less than my previous tests with ipcclient
and ipcserver examples, but an order of magnitude more than Disruptor
and another proprietary eventfd based realization I've seen.
Cheers,
VV
On 18.05.2012 06:54, Angus Salkeld wrote:
On 17/05/12 19:19 +0400, Voznesensky Vladimir wrote:
I've just tested libqb. For every message I've:
- Instrumented a client with tcs reading before qb_ipcc_send and
after qb_ipcc_recv;
- Instrumented a client with CPU frequency testing.
- Commented out qb_log in s1_msg_process_fn of a server.
So, it took 0.000140 sec - 0.000156 sec for every message to pass and
return.
See here:
http://code.google.com/p/disruptor/wiki/PerformanceResults
It is one directional (IPC only), so to compare you need to get a
timestamp
put it in a message and send it. Then on the server compare with
the time there.
If you run libqb ringbuffer benchmarks they look comparible, although
I am not sure of the message size in their tests:
In one shell: ./tests/rbreader
In another: ./tests/rbwriter
[info] write size 14 OPs/sec 7509762.500 MB/sec 100.266
[info] write size 42 OPs/sec 27063600.000 MB/sec 1084.014
[info] write size 84 OPs/sec 25361400.000 MB/sec 2031.667
[info] write size 140 OPs/sec 26525198.000 MB/sec 3541.496
[info] write size 210 OPs/sec 21258504.000 MB/sec 4257.475
[info] write size 294 OPs/sec 13559322.000 MB/sec 3801.766
[info] write size 392 OPs/sec 7675186.000 MB/sec 2869.294
[info] write size 504 OPs/sec 7496252.000 MB/sec 3603.087
[info] write size 630 OPs/sec 6605020.000 MB/sec 3968.394
[info] write size 770 OPs/sec 7752539.000 MB/sec 5692.916
[info] write size 924 OPs/sec 11303267.000 MB/sec 9960.383
[info] write size 1092 OPs/sec 8590327.000 MB/sec 8946.073
etc...
To get more consistent results I probably need to do more
iterations for each size.
I'll setup an IPC test and let you know.
-Angus
As I understood, I'ts very large number.
Compare, for instance, with
http://code.google.com/p/disruptor/
Thanks.
On 17.05.2012 17:54, Voznesensky Vladimir wrote:
Hello.
It seems that corosync gives a very long latency on a one-node
configuration.
We have developed a small test passing messages between two threads.
Each message carried an original tsc timestamp counter value, so we
have been able to compute the difference with the receiver's tsc.
1 (100-bytes) message pass took about 200 us.
30000 messages batch gave about 2 ms.
Some ipc ring-buffer implementation using eventfd showed us less
than a 1 microsecond between two processor cores to pass a 128 byte
message in a 1000 messages batch.
So, what's the source of such relatively high latency?
_______________________________________________
discuss mailing list
discuss@xxxxxxxxxxxx
http://lists.corosync.org/mailman/listinfo/discuss
_______________________________________________
discuss mailing list
discuss@xxxxxxxxxxxx
http://lists.corosync.org/mailman/listinfo/discuss
_______________________________________________
discuss mailing list
discuss@xxxxxxxxxxxx
http://lists.corosync.org/mailman/listinfo/discuss
