Dear Steven,
I've modified pload.c to test a different pattern for my single-node
configuration.
Each message sending is scheduled by schedwrk_create, so the totem subsystem
is not overloaded by a batch: each message is sent when Corosync process
is idle.
Here are the latencies in CPU ticks and throughput in TP/S:
Batch size| with Totem | w/o Totem
100000 | 24.9K/105K | 24.7K/106K
Surprisingly, no visible difference at all. I'm not kidding. Maybe, tired,
disorientated and discouraged :-( ...
I've double checked two versions of totempg_groups_mcast_joined where
Totem is disabled as you have told us.
Please, also find the comments below.
Thank you.
VV
24.05.2012 18:52, Steven Dake написал:
I would expect totem latency a bit higher, The mean latency can be
calculated as 1/2*token rotation time. Larger batch sizes result in
more messages being assembled into a MTU sized message which will
provide better throughput (at the cost of latency, because now that
token rotation takes longer).
I've measured single node configuration, so the rotation (ping/2)
takes about 7-14 us.
I don't particularly trust tsc. I would prefer to see a
clock_gettime(CLOCK_REALTIME) analysis.
Real time clock does not provide enough accuracy for nanosecond
latency measurements: for example, you will not see a CPU cache
miss for a single message using the RTC. Moreover, the CPU clock
rates are different on different computers, so I'm using TSC.
Totem doesn't make much difference here because the latency you see when
running with cpg is almost entirely introduced by IPC.
Ohhh. I've tested Corosync 2.0.1 here.
pload uses totem api, so there should be no ringbuffer IPC latency here.
_______________________________________________
discuss mailing list
discuss@xxxxxxxxxxxx
http://lists.corosync.org/mailman/listinfo/discuss
