|
From: nicolas b. <sl1...@gm...> - 2014-03-13 18:32:32
|
Steve,
After more test, it appears that it's not htonl() related...
What's strange is that I successfully compiled a working liblo (e.g. no
delay...) but I do not succeed in doing it again...
So maybe it's something with the way I'm compiling...
++
Le 13 mars 2014 18:32, "Stephen Sinclair" <rad...@gm...> a écrit :
> 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
> >
>
>
> ------------------------------------------------------------------------------
> 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
>
|