Allo Christian, > We tried a combination of large message sizes (up to 17000 bytes) and > large number of message (1000, 5000, 10000) but the local_thr.exe did > not finish and display the stats. Further investigation (Windows’ > perfmon tool and task manager) indicated that a large number of messages > seem to be dropped at the remote_thr.exe side before reaching “wire”. In > our test setup, the two machines are directly connected together (i.e. > no switches, no routers). With this setup, I would expect that all > messages are sent and received assuming that two machines have similar > CPU and network capacity.
A sanity check: Are you starting local_thr before remote_thr? Throughput test is based on PUB/SUB sockets (not an ideal option) and PUB/SUB socket semantics is that of radio transmission. PUB (remote_thr) publishes messages and in nobody is listening, they are simply dropped. > We also tried this same test with two Windows Server 2003 based machines > and a combination of Windows Server 2003 and XP machines (all Windows OS > are 32-bit version). In all cases we obtained similar results as the > original test on two XP machines. A quick code walkthrough and network > cable test did not reveal anything suspicious. I assume that the values > defined in the platform.hpp and config.hpp files are a good start (i.e. > only change them when necessary). > > So, the hardware seems ok. The source code seems ok. The test setup > seems ok. > > Could we have missed configuring a setting/flag/#ifdef/#define during > the build process on Windows using MSVC2008 Express? No. It should work out of the box. Martin _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
