Hi Armin, > I did locally the following tests on a Linux machine (dual-core, 2.2GHz):
Multicast loopback is pretty annoying piece of code. If you want to get sane results do the tests over the real network. > First I send 1000 messages of 1 byte, then 10000 of the same length. > Is the lower performance created by the ethernet driver by buffering of > messages? > > ----------------- > Linux-New:/home/Archive/RT-Linux/zeromq-2.0-beta2/perf/c # local_thr > "udp://192.168.178.126;224.0.0.1:5555" 1 1000 > udp://192.168.178.126;224.0.0.1:5555 1 1000 > ^[[Amessage size: 1 [B] > message count: 1000 > mean throughput: 13333333 [msg/s] > mean throughput: 106.667 [Mb/s] > Linux-New:/home/Archive/RT-Linux/zeromq-2.0-beta2/perf/c # local_thr > "udp://192.168.178.126;224.0.0.1:5555" 1 10000 > udp://192.168.178.126;224.0.0.1:5555 1 10000 > message size: 1 [B] > message count: 10000 > mean throughput: 15112 [msg/s] > mean throughput: 0.121 [Mb/s] 1k or 10k of data is too little to produce any sensible throughput metrics. It boils down to sending a couple of packets. You should send much more data to get sane results. Also note that PGM uses rate-limited sender. By default it is limited to 100kb/sec. You can specify a diferent limit using ZMQ_RATE socket option. > -------------------- > I don't really understand the results above. Please explain. The test > below was using 10000 messages with a length of 10 bytes: > -------------- > Linux-New:/home/Archive/RT-Linux/zeromq-2.0-beta2/perf/c # local_thr > "udp://192.168.178.126;224.0.0.1:5555" 10 10000 > udp://192.168.178.126;224.0.0.1:5555 10 10000 > ---------------- > -> local_thr doesn't terminate. It seems we are loosing messages ? Tried on my box. It seems to work here. Can you be more specific about the comment lines you are using (both local and remote)? Martin _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
