[nanomsg] Re: Performance tests so far
- From: Gonzalo Diethelm <gonzalo.diethelm@xxxxxxxxx>
- To: Martin Sustrik <sustrik@xxxxxxxxxx>
- Date: Thu, 27 Jun 2013 10:23:25 -0400
Closed all the issues, since all perf tests run OK (at least on Win32).
On Thu, Jun 27, 2013 at 8:06 AM, Gonzalo Diethelm <
gonzalo.diethelm@xxxxxxxxx> wrote:
> Hi Martin. I just logged three issues:
>
> #71: inproc_lat and incproc_thr perf tests assert on Linux and Win32
> https://github.com/250bpm/nanomsg/issues/71
>
> #72: local_lat and remote_lat perf tests hang on Win32
> https://github.com/250bpm/nanomsg/issues/72
>
> #73: local_thr and remote_thr perf tests assert on Linux and Win32
> https://github.com/250bpm/nanomsg/issues/73
>
> Best regards.
>
>
> On Thu, Jun 27, 2013 at 2:53 AM, Martin Sustrik <sustrik@xxxxxxxxxx>wrote:
>
>> Hi Gonzalo,
>>
>>
>> I am working with the aio2 branch of nanomsg (just updated). I have the
>>> following repeatable behavior in the performance tests:
>>>
>>> 1. Both inproc_{lat,thr} assert (at
>>> nanomsg/src/transports/inproc/**cinproc.c:99). This happens on both
>>> Win32
>>> and Linux.
>>>
>>> 2. Combination {local,remote}_lat works on Linux. My results look
>>> reasonable:
>>>
>>> message size: 1 [B]
>>> roundtrip count: 100000
>>> average latency: 59.656 [us]
>>>
>>> However, the same combination fails on Win32; both programs hang and I
>>> even have to kill the console for both programs.
>>>
>>> 3. When running combination {local,remote}_thr, the local_thr side
>>> asserts on Linux (at nanomsg/src/transports/tcp/**stcp.c:294). I have
>>> not
>>> tried yet this combination on Win32.
>>>
>>> Which of the performance tests are supposed to be running by now? Are my
>>> results (both in the numbers I got for case #2 and the assertions for
>>> cases #1 and #3) expected?
>>>
>>
>> The state of affairs is that more or less all the functionality is
>> already implemented, however, there was almost no testing. So it's still
>> failing pretty often. Even the built-in test don't pass fully yet.
>>
>> It would be great if you could log individual failures into the bug
>> tracker.
>>
>> Martin
>>
>
>
>
> --
> Gonzalo Diethelm
> gonzalo.diethelm@xxxxxxxxx
>
--
Gonzalo Diethelm
gonzalo.diethelm@xxxxxxxxx
Other related posts:
