Hi Ian,
compiling the library without tracing did not change the situation. I tried the code on different machines and saw the same behavior. I'd be happy if anybody had any ideas!
Cheers,
Chris
Date: Thu, 5 Mar 2015 22:39:38 +0000 From: icraggs@xxxxxxxxxxxxxxxxxxxxxxx To: paho-dev@xxxxxxxxxxx Subject: Re: [paho-dev] Varying Delay for MQTT Messages
Hi Chris,
thanks for checking, that seems to have got lost in my in tray.
It's always worth raising a bug to make sure it doesn't get lost,
although that doesn't guarantee turnaround :-)
Looking at your original trace, I see the following:
20150130 170213.898 (3380758272) (6)>
MQTTPersistence_put:347
20150130 170213.898 (3380758272) (6)<
MQTTPersistence_put:381 (0)
20150130 170214.898 (3380758272) (6)> Socket_putdatas:443
20150130 170214.898 (3380758272) (7)> Socket_writev:399
the one second gap is actually after the return from
MQTTPersistence_put and before the call to Socket_putdatas. But
there isn't any code between the two, to speak of:
#if !defined(NO_PERSISTENCE)
if (header.bits.type == PUBLISH && header.bits.qos
!= 0)
{ /* persist PUBLISH QoS1 and Qo2 */
char *ptraux = buffers[2];
int msgId = readInt(&ptraux);
rc = MQTTPersistence_put(net->socket, buf, buf0len,
count, buffers, buflens,
header.bits.type, msgId, 0);
}
#endif
#if defined(OPENSSL)
if (net->ssl)
rc = SSLSocket_putdatas(net->ssl, net->socket,
buf, buf0len, count, buffers, buflens, frees);
else
#endif
rc = Socket_putdatas(net->socket, buf, buf0len,
count, buffers, buflens, frees);
My first guess at this point is that the process has been swapped
out for that one second. My second guess is that the tracing
itself may be interfering. That could be checked by building the
library without tracing to see if that makes a difference (compile
with NOSTACKTRACE and NO_HEAP_TRACKING). If anyone has any other
suggestions I'd be glad to hear them.
Ian
On 05/03/15 13:26, Chris Summer wrote:
Hi,
are there any news on this topic?
Has it just been solved with the new versions?
Cheers,
Chris
Date: Mon, 2 Feb 2015 12:14:00 -0500
From: fpagliughi@xxxxxxxxxxxxxx
To: paho-dev@xxxxxxxxxxx
Subject: Re: [paho-dev] Varying Delay for MQTT Messages
Yeah, the bear on my doorstep rarely makes me late for work.
She seems friendly enough. Though it always amazes me how she
can get the lid off the garbage and take the bag out without
even knocking the can over.
On 02/02/2015 12:02 PM, Ian
Craggs wrote:
No problem. Good excuse. Almost as good as the Canadian
post that wasn't delivered because of "bear on doorstep".
:-)
I had plenty to keep me occupied in any case. I'll look at
the persistence call, seems odd.
Ian
On 01/30/2015 10:23 PM,
Frank Pagliughi wrote:
Hello Ian,
Sorry for the delay on this. Earlier this week a very
large pile of snow developed between where I was and where
my laptop was.
I made a slight modification to the MQTTAsync_publish
sample app so that when a transfer is completed another
message is sent immediately, but I was seeing about a
second between each message.
The 'running' variable is now an int counting down the
number of messages to send, five in this case. The normal
output would be:
$ build/output/samples/MQTTAsync_publish
Waiting for publication of 'Hello World!'
on topic 'MQTT Examples' for client with ClientID:
ExampleClientPub
Successful connection
Sent message with token value 1
Message with token value 1 delivery confirmed
Sent message with token value 2
Message with token value 2 delivery confirmed
Sent message with token value 3
Message with token value 3 delivery confirmed
Sent message with token value 4
Message with token value 4 delivery confirmed
Sent message with token value 5
Message with token value 5 delivery confirmed
Attached is the source and log. According to the log, it
seems that the delay I noticed turned out to be exactly
1sec in a persistence "put" call despite
MQTTCLIENT_PERSISTENCE_NONE being specified? This is
~Line 411 in the log and repeats for each message sent.
20150130 170213.898 (3380758272) (3)>
MQTTProtocol_startPublishCommon:124
20150130 170213.898 (3380758272) (4)>
MQTTPacket_send_publish:677
20150130 170213.898 (3380758272) (5)>
MQTTPacket_sends:226
20150130 170213.898 (3380758272) (6)>
MQTTPacket_encode:268
20150130 170213.898 (3380758272) (6)<
MQTTPacket_encode:278 (1)
20150130 170213.898 (3380758272) (6)>
MQTTPersistence_put:347
20150130 170213.898 (3380758272) (6)<
MQTTPersistence_put:381 (0) <------ Here -----
20150130 170214.898 (3380758272) (6)>
Socket_putdatas:443
20150130 170214.898 (3380758272) (7)>
Socket_writev:399
20150130 170214.898 (3380758272) (7)<
Socket_writev:420 (31)
20150130 170214.898 (3380758272) (6)<
Socket_putdatas:485 (0)
20150130 170214.898 (3380758272) (5)<
MQTTPacket_sends:253 (0)
20150130 170214.898 3 ExampleClientPub -> PUBLISH
msgid: 1 qos: 1 retained: 0 (0) payload: Hello World!
This was run on a ThinkPad i7 laptop running Linux Mint13,
x86_64.
Thanks,
Frank
On 01/28/2015 08:29 AM,
Ian Craggs wrote:
Hi
Chris,
I was hoping for a full trace. This seems to be just a
protocol level trace?
Ian
On 01/27/2015 03:07 PM,
Chris Summer wrote:
Hi Ian,
0) I am using the MQTTAsyncAPI with callbacks. I am
processing the incoming messages within the
MessageArrived Callback Function. I did an
implementation using the MQTTClient, then there is
no such effect.
1) Is turned off
2) Find tracefile in the attachement
Thanks a lot!
Chris
Date: Mon, 26 Jan 2015
14:00:35 -0500
From: fpagliughi@xxxxxxxxxxxxxx
To: paho-dev@xxxxxxxxxxx
Subject: Re: [paho-dev] Varying Delay for MQTT
Messages
Hi Ian,
I saw a strange delay of about 1-sec in the latest
Asynhronous C library. I had modified the
publisher example app to send several messages;
sending the next as soon as one is acknowledged
(QoS=1). I ran it all on the same machine over
localhost, talking to mosquitto. The timing seemed
odd, but I haven't had time to investigate further
yet.
I will see I can recreate the test app and send it
to you ASAP.
Frank
On 01/26/2015
08:12 AM, Ian Craggs wrote:
Hi Chris,
are you using the MQTTClient or MQTTAsync API?
If MQTTClient, are you setting callbacks? I
think it's most likely that the timing
differences are an artifact of the threading
model. With MQTTClient, if you use the receive
call rather than the messageArrived callback, no
background threads are started.
1) make sure you have turned off message
persistence when creating the client object (MQTTCLIENT_PERSISTENCE_NONE).
This shouldn't be used for QoS 0, but might have
an effect.
2) You can take a trace by setting the
environment variable MQTT_C_CLIENT_TRACE=(ON or
filename), and then I can check to see what is
happening.
3) Other client options for C/C++ are the Paho
embedded clients and libmosquitto in the
Mosquitto project, which follows the same API
model as the Python API because they are both
written by Roger Light. I'd like to see if we
can understand and solve your problem first
though -- so please take a trace.
Thanks
Ian
On 01/26/2015
10:23 AM, Chris Summer wrote:
Hi all,
I am experiencing some behavior I cannot
explain.
Here is what I do.
I am using the paho-c library and as a
reference the paho python library. My Broker
is mosquitto.
The goal of my experiments is to measure the
application layer roundtrip time. Therefore
I have the following setup
Application <----> Broker <--->
Reflector
What I do is:
* I take the time in the application, put
it into a packet and send it to the broker.
(QoS 0)
* The reflector is subscribed to theses
messages, receives them, packs them into a
new packet and sends the back to the broker
using a different topic.
* Finally I receive the message back at the
application, take the current time and
calculate the time difference between the
current time and the time contained in the
packet.
I have this implementation, both in C and in
Python. All processes are running on the
same machine.
No here are the observations that keep me
busy.
If I watch the application delay for the c
implementation I get something like
5, 1005, 106, 5, 1005, 104, 6 ...
For the python implementation it is like:
5, 5, 5, 6, 4, ....
You see the difference, unfortunately I need
an implementation in C thanks to the target
platform. I checked my code several times,
there is nothing I could pinpoint to cause
the delay.
To me, it resembles effects that I have seen
in other projects when using TCP. Could it
be, that somewhere in the library code
there is some issue with the socket
handling?
Any other ideas? Did I miss a configuration
flag or something?
Cheers,
Chris
_______________________________________________
paho-dev mailing list
paho-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/paho-dev
--
Ian Craggs
icraggs@xxxxxxxxxx IBM United Kingdom
Paho Project Lead; Committer on Mosquitto
_______________________________________________
paho-dev mailing list
paho-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/paho-dev
_______________________________________________
paho-dev mailing list paho-dev@xxxxxxxxxxx
To change your delivery options, retrieve your
password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/paho-dev
_______________________________________________
paho-dev mailing list
paho-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/paho-dev
--
Ian Craggs
icraggs@xxxxxxxxxx IBM United Kingdom
Paho Project Lead; Committer on Mosquitto
_______________________________________________
paho-dev mailing list
paho-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/paho-dev
_______________________________________________
paho-dev mailing list
paho-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/paho-dev
--
Ian Craggs
icraggs@xxxxxxxxxx IBM United Kingdom
Paho Project Lead; Committer on Mosquitto
_______________________________________________
paho-dev mailing list
paho-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/paho-dev
_______________________________________________
paho-dev mailing list
paho-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or
unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/paho-dev
_______________________________________________
paho-dev mailing list
paho-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/paho-dev
_______________________________________________
paho-dev mailing list
paho-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/paho-dev
|