|
From: Stephen S. <rad...@gm...> - 2014-03-13 17:32:08
|
It is strange, since a glance at the macros suggests that lo_htoo32()
should simply expand to htonl(). I'll try using gcc's -E flag to look
at post-preprocessor output and see if that's the case.
Either way I can't see how such a macro would lead to delays..
interesting. Could be something a bit subtle. Which VM are you
using, Parallels?
Steve
On Wed, Mar 12, 2014 at 12:26 PM, nicolas bats <sl1...@gm...> wrote:
> so, after digging a little more....
> my problem does not come from lo_address_resolve(), so neither from
> getnameinfo().
> I'm sending bundle and delay come from lo_bundle_serialise().
> more precisely from the lo_htoo32() macro.
>
> I'm compiling liblo on a virtual windows box on a mac...
> I don't know if it's related but when I change lo_htoo32() to htonl(), delay
> disappears and everything is smooth even for address that does not exists on
> the network.
>
> does it make sense to you?
> ++
> Nicolas
>
>
> 2014-03-11 14:33 GMT+01:00 nicolas bats <sl1...@gm...>:
>
>> I've moved the lo_address_resolve() at address creation instead of at the
>> send() moment and will be able to test at the end of the week.
>> Not great I suppose but I think it can be ok for my application...
>> Best regards,
>> Nicolas
>>
>> Le 11 mars 2014 14:26, "Stephen Sinclair" <rad...@gm...> a écrit :
>>
>>> The only thing I can think to suggest is that you step through
>>> lo_address_new() with the debugger and see where the delay actually
>>> happens.
>>>
>>> Steve
>>>
>>>
>>> On Mon, Mar 10, 2014 at 10:44 AM, nicolas bats <sl1...@gm...>
>>> wrote:
>>> > Hi,
>>> > any thoughts about the way to resolve/improve this?
>>> >
>>> > best regards,
>>> > Nicolas
>>> >
>>> >
>>> > 2014-02-27 10:43 GMT+01:00 nicolas bats <sl1...@gm...>:
>>> >
>>> >> hello,
>>> >> first, here's how I initialize the address where I need to write:
>>> >>
>>> >> static void new_osc_sender(struct common_Nodes* recordedNodes) {
>>> >>
>>> >> oscWriter_t* this_W = NULL;
>>> >>
>>> >> struct common_Nodes *node, *tmp;
>>> >>
>>> >> node = tmp = NULL;
>>> >>
>>> >> char* buff = NULL;
>>> >>
>>> >>
>>> >> if(NULL != recordedNodes)
>>> >>
>>> >> {
>>> >>
>>> >> if(NULL == (buff = GenAlloc(ALLOCATION_BLOCK_SIZE))) {
>>> >>
>>> >> Indic_Error(UNEXPECTED, 0);
>>> >>
>>> >> return;
>>> >>
>>> >> }
>>> >>
>>> >>
>>> >> HASH_ITER(hh, recordedNodes, node, tmp) {
>>> >>
>>> >>
>>> >> if(NULL != (this_W = dl_SysAlloc(sizeof(*this_W))))
>>> >>
>>> >> {
>>> >>
>>> >> sprintf(buff, "%d", node->port);
>>> >>
>>> >> this_W->addr = lo_address_new(node->ipData , buff);
>>> >>
>>> >> this_W->addr_str = dupstr(node->ipData);
>>> >>
>>> >> this_W->port_str = dupstr(buff);
>>> >>
>>> >> this_W->isUsed = node->idt;
>>> >>
>>> >>
>>> >>
>>> >> //printf("add %s %s\n", this_W->addr_str,
>>> >> this_W->port_str);
>>> >>
>>> >> LL_APPEND(writerServer,this_W);
>>> >>
>>> >>
>>> >>
>>> >> }
>>> >>
>>> >> }
>>> >>
>>> >>
>>> >>
>>> >> FRI(buff);
>>> >>
>>> >> }
>>> >>
>>> >> return;
>>> >>
>>> >> }
>>> >>
>>> >>
>>> >> so it's simply a lo_address_new() and I reuse the address from
>>> >> this_W->addr.
>>> >>
>>> >>
>>> >>
>>> >>
>>> >> 2014-02-26 13:38 GMT+01:00 Stephen Sinclair <rad...@gm...>:
>>> >>
>>> >>> On Wed, Feb 26, 2014 at 11:50 AM, nicolas bats <sl1...@gm...>
>>> >>> wrote:
>>> >>> > Hi,
>>> >>> > with the latest release (but I don't think it's 0.28 related) I can
>>> >>> > see
>>> >>> > some
>>> >>> > behaviors on win that are not particulary desired...
>>> >>> >
>>> >>> > let me explain:
>>> >>> > my app create a server with lo_server_new(), so far so good, and I
>>> >>> > use
>>> >>> > only
>>> >>> > UDP.
>>> >>> > the wifi is off and the firewalls are off.
>>> >>> > the network card address is 192.168.1.30
>>> >>> >
>>> >>> > if I send OSC message to address like 10.x.x.x, as the network
>>> >>> > can't be
>>> >>> > reached I don't see any lag, but, if I send OSC message to
>>> >>> > 192.168.1.x
>>> >>> > and
>>> >>> > there's no receiver, I see a huge lag, like if there's a timeout or
>>> >>> > something like this.
>>> >>> > did you guys noticed the same behavior?
>>> >>> > any leads in order to find wich call is reponsible of lag?
>>> >>>
>>> >>> It would be good to know if it's a write() call for example. Also,
>>> >>> does the lag occur only the first time, or every time?
>>> >>
>>> >>
>>> >> within my app, it happens all the time
>>> >>
>>> >>>
>>> >>> I wonder if
>>> >>> it's more of a name resolution bug, could be something regarding
>>> >>> initializing a lo_address.
>>> >>>
>>> >>> What is "huge lag" exactly? A few ms, a few seconds, a minute or
>>> >>> more?
>>> >>
>>> >> let's say a few seconds, but more than your log shows
>>> >>>
>>> >>>
>>> >>> Possibly stepping through the code in gdb starting at lo_send() might
>>> >>> help.
>>> >>>
>>> >>> Here on my Windows 7 machine I do see a short lag of a couple of
>>> >>> seconds when sending to an unknown address using oscsend.exe, but it
>>> >>> seems to go away the second and third times I run it. If I change
>>> >>> the
>>> >>> last number of the IP address I get the lag again, only once.
>>> >>
>>> >>
>>> >> even once it's a shame...
>>> >> can't we get rid of that?
>>> >>
>>> >>>
>>> >>> Here is
>>> >>> a dump:
>>> >>>
>>> >>> (This is compiled with MingW, and one of my NICs is configured to
>>> >>> 192.168.56.1 / 255.255.255.0)
>>> >>>
>>> >>> -------------------------------
>>> >>> bash-3.1$ time ./oscsend.exe 192.168.56.20 9000 /test
>>> >>>
>>> >>> real 0m2.644s
>>> >>> user 0m0.000s
>>> >>> sys 0m0.015s
>>> >>> bash-3.1$ time ./oscsend.exe 192.168.56.20 9000 /test
>>> >>>
>>> >>> real 0m0.037s
>>> >>> user 0m0.015s
>>> >>> sys 0m0.000s
>>> >>> bash-3.1$ time ./oscsend.exe 192.168.56.20 9000 /test
>>> >>>
>>> >>> real 0m0.037s
>>> >>> user 0m0.015s
>>> >>> sys 0m0.000s
>>> >>> bash-3.1$ time ./oscsend.exe 192.168.56.21 9000 /test
>>> >>>
>>> >>> real 0m2.596s
>>> >>> user 0m0.000s
>>> >>> sys 0m0.015s
>>> >>> bash-3.1$ time ./oscsend.exe 192.168.56.21 9000 /test
>>> >>>
>>> >>> real 0m0.038s
>>> >>> user 0m0.000s
>>> >>> sys 0m0.015s
>>> >>> bash-3.1$ time ./oscsend.exe 192.168.56.21 9000 /test
>>> >>>
>>> >>> real 0m0.040s
>>> >>> user 0m0.000s
>>> >>> sys 0m0.015s
>>> >>> -------------------------------
>>> >>
>>> >>
>>> >> for the same address, mine shows 0m2.928s (more or less) every time.
>>> >> the same as with new address
>>> >>
>>> >> ++
>>> >> NIcolas
>>> >>>
>>> >>>
>>> >>>
>>> >>> Steve
>>> >>>
>>> >>>
>>> >>>
>>> >>> ------------------------------------------------------------------------------
>>> >>> Flow-based real-time traffic analytics software. Cisco certified
>>> >>> tool.
>>> >>> Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer
>>> >>> Customize your own dashboards, set traffic alerts and generate
>>> >>> reports.
>>> >>> Network behavioral analysis & security monitoring. All-in-one tool.
>>> >>>
>>> >>>
>>> >>> http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk
>>> >>> _______________________________________________
>>> >>> liblo-devel mailing list
>>> >>> lib...@li...
>>> >>> https://lists.sourceforge.net/lists/listinfo/liblo-devel
>>> >>
>>> >>
>>> >
>>> >
>>> >
>>> > ------------------------------------------------------------------------------
>>> > Learn Graph Databases - Download FREE O'Reilly Book
>>> > "Graph Databases" is the definitive new guide to graph databases and
>>> > their
>>> > applications. Written by three acclaimed leaders in the field,
>>> > this first edition is now available. Download your free book today!
>>> > http://p.sf.net/sfu/13534_NeoTech
>>> > _______________________________________________
>>> > liblo-devel mailing list
>>> > lib...@li...
>>> > https://lists.sourceforge.net/lists/listinfo/liblo-devel
>>> >
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Learn Graph Databases - Download FREE O'Reilly Book
>>> "Graph Databases" is the definitive new guide to graph databases and
>>> their
>>> applications. Written by three acclaimed leaders in the field,
>>> this first edition is now available. Download your free book today!
>>> http://p.sf.net/sfu/13534_NeoTech
>>> _______________________________________________
>>> liblo-devel mailing list
>>> lib...@li...
>>> https://lists.sourceforge.net/lists/listinfo/liblo-devel
>
>
>
> ------------------------------------------------------------------------------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and their
> applications. Written by three acclaimed leaders in the field,
> this first edition is now available. Download your free book today!
> http://p.sf.net/sfu/13534_NeoTech
> _______________________________________________
> liblo-devel mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/liblo-devel
>
|