OS is Linux OpenWRT.
Unfortunately, there is no development kit available on the market. Mainly, this chip is used for network routers. I'm also limited with the number of boards, for now.
I will try to find more time to check this issue.
thanks for your answers. A couple of other questions:
1) what OS are you using? Linux or something else?
2) is there a cheap dev kit for the hardware/software environment
you are using? I might consider getting one...
Ian
On 04/08/2016 08:07 AM, Milan Tucic
wrote:
Hi Ian,
I agree with your observation.
Tracing the system logs can be tricky. With 3 ms sleep I
got almost normal behaviour and I'm not sure how much logs can
affect on the result.
Next week, I will try with different compiler (currently
I'm using gcc 4.8.0) and I will notify you about the
behaviour.
I have two clients. One is connected to a localhost broker
and second one is connected to a local network broker. Second
client uses TLS. Same application works find on x86 and x64.
on the failing trace, without the sleep, MQTTClient_cycle
is returning -1 (error) which is not the case for the
working trace. It seems you probably spotted that from
the location of the sleep you added. It looks like
getReadySocket is returning too quickly, when the socket
is not actually ready. If you could get an strace of
network calls in the failing scenario, that might help
narrow it down.
How many client objects are there? Are they all using
TLS? Exactly the same application works on a non MIPS
architecture Linux?
Ian
On 04/01/2016 07:53 AM, Milan Tucic wrote:
Hi Ian,
I will switch to official release, as soon as
it is out.
I've added it inside the if statement,
when ListFindItem
returns NULL (MQTTClient.c:523).
Please, take a look
on logs from the attachment. I'm not quite
sure about differences. There are logs for
configuration with and without 3 ms sleep.
With logs activated, CPU goes up to 7% and
70%, correspondingly.
the latest release is 1.0.3. The develop
branch does contain some additional fixes
above that, which will be released soon.
While there have been some circumstances
under which CPU usage is high, they have
resulted from particular sequences of call,
usually involving destroy().
Where exactly have you inserted the sleep?
My first suspicion is that the select call
is returning immediately for some reason.
Can you take a trace of the situation? (Set
environment variable
MQTT_C_CLIENT_TRACE=ON/filename)
Ian
On 03/30/2016 03:23 PM, Milan Tucic
wrote:
Hi,
I'm currently using Paho C
library on AR9531 MIPS 24Kc and
it keeps CPU at 100%.
Due a synchronization problem,
I've switched from master
1.0.2 to the develop
branch and I'm using it with
latest changes.
I have tested it again, after
adding seep in MQTTClient
loop and it resulted with
lower/normal CPU usage.