[zeromq-dev] PGM throughput testing still terminated short
Steven McCoy
steven.mccoy at miru.hk
Mon Nov 29 08:45:12 CET 2010
Hypothesis appears true by experiment, I implemented a basic peek_data
method but have to disable packet batching due to the implementation
discarding data on reading the next message.
Conversely just disabling packet batching works, but that might be a
test artifact due to the resultant small messages are easier to send.
One example of resolution is to replace the single in_progress zmq_msg_t
with a list and open the API through the layers to permit read and peek.
--
Steve-o
On 29 November 2010 12:59, Steven McCoy <steven.mccoy at miru.hk> wrote:
> Hypothesis: an zmq::encoder_base_t::peek_data method is required so that
> ZMQ does not think the queued data is empty when the rate limiter kicks in.
> This should be reproducible with congestion control on TCP streams.
>
> --
> Steve-o
>
>
> On 29 November 2010 12:47, Steven McCoy <steven.mccoy at miru.hk> wrote:
>
>> Adding trace to master you can see the ZMQ messages are sent to the API,
>>
>> diff --git a/perf/remote_thr.cpp b/perf/remote_thr.cpp
>> index c471481..b98021d 100644
>> --- a/perf/remote_thr.cpp
>> +++ b/perf/remote_thr.cpp
>> @@ -85,6 +85,8 @@ int main (int argc, char *argv [])
>> printf ("error in zmq_msg_close: %s\n", zmq_strerror
>> (errno));
>> return -1;
>> }
>> +
>> +printf ("> %d\n", i);
>> }
>>
>> rc = zmq_close (s);
>> diff --git a/src/pgm_sender.cpp b/src/pgm_sender.cpp
>> index 3fb24c1..d0f9eb9 100644
>> --- a/src/pgm_sender.cpp
>> +++ b/src/pgm_sender.cpp
>> @@ -149,6 +149,8 @@ void zmq::pgm_sender_t::in_event ()
>> }
>> }
>>
>> +static int txpkts = 0;
>> +
>> void zmq::pgm_sender_t::out_event ()
>> {
>> // POLLOUT event from send socket. If write buffer is empty,
>> @@ -185,6 +187,7 @@ void zmq::pgm_sender_t::out_event ()
>> // We can write either all data or 0 which means rate limit reached.
>> if (nbytes == write_size) {
>> write_size = 0;
>> +printf (">> [%d]\n", ++txpkts);
>> } else {
>> zmq_assert (nbytes == 0);
>>
>> *console output:*
>> LD_LIBRARY_PATH=src/.libs/ ./perf/.libs/remote_thr "epgm://eth0;
>> 239.192.0.1:7500" 100 1000
>> ...
>> > 998
>> > 999
>>
>> Followed by the ZMQ IO thread feeding the packets to PGM with the strict
>> default rate limit (100kbs) the packet count appears to match ceil(
>> 1000*100/1428 )
>>
>> *console output:*
>> >> [1]
>> >> [2]
>> ...
>> >> [69]
>> >> [70]
>> >> [71]
>>
>> On the receive side everything that was sent is received without issue
>> suggesting a off-by-one error on send as there should be 72 packets?
>>
>> diff --git a/perf/local_thr.cpp b/perf/local_thr.cpp
>> index 98001be..118b3dd 100644
>> --- a/perf/local_thr.cpp
>> +++ b/perf/local_thr.cpp
>> @@ -100,6 +100,8 @@ int main (int argc, char *argv [])
>> printf ("message of incorrect size received\n");
>> return -1;
>> }
>> +
>> +printf ("%d\n", i+1);
>> }
>> diff --git a/src/pgm_receiver.cpp b/src/pgm_receiver.cpp
>> index 9773847..7b1f980 100644
>> --- a/src/pgm_receiver.cpp
>> +++ b/src/pgm_receiver.cpp
>> @@ -132,6 +132,8 @@ void zmq::pgm_receiver_t::activate_in ()
>> in_event ();
>> }
>>
>> +static int rxpkts = 0;
>> +
>> void zmq::pgm_receiver_t::in_event ()
>> {
>> // Read data from the underlying pgm_socket.
>> @@ -192,6 +194,8 @@ void zmq::pgm_receiver_t::in_event ()
>> data += sizeof (uint16_t);
>> received -= sizeof (uint16_t);
>>
>> +printf ("<< [%d]\n", ++rxpkts);
>> +
>> // Join the stream if needed.
>> if (!it->second.joined) {
>>
>> *console output:*
>> ...
>> << [71]
>> 978
>> 979
>> 980
>> 981
>> 982
>> 983
>> 984
>> 985
>> 986
>> 987
>> 988
>> 989
>> 990
>> 991
>>
>> --
>> Steve-o
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20101129/e8407a02/attachment.htm>
More information about the zeromq-dev
mailing list