Is there any possibility to monitor the actual Round-Trip time of a device as a Particle variable in order to optimize the process of reading data from the device and prevent overflow of the request queue???
I’m not sure how the round-trip time will help.
- When reading a variable or calling a function, the operation doesn’t return until the data is returned, and it’s best to only issue one request at a time, so that’s self-limiting.
- When the device is publishing, when using WITH_ACK mode, the publish won’t complete until the data is received by the cloud, so you can limit the number of outstanding publishes.
The one thing that is not self-limiting is subscribing to events on-device and you plan to send a lot of events to it. Some of these will be buffered in the cloud. However, since publishes do not have guaranteed delivery, you’ll probably want to layer something on top of that anyway to handle lost publishes. This could also be used to limit the number of concurrent publishes outstanding.
The round-trip time will be very inconsistent, to the point of being nearly meaningless. It’s not uncommon for the first round-trip to take 10 seconds (especially on the Electron and E Series) but subsequent packets be in the hundreds of milliseconds range.
I was looking for some kind of figure that might be used as an indication on how fast one can pull data from a Photon device (using Particle console or through a webpage).
I can understand that the round-trip time is not really usefull to adapt the pulling frequency “on-thë-fly”, but on the otherhand I assume that the people at Particle’s are not publishing a figure in their console that is completely meaningless, do they?
Would the following approach be valid, or is it complete nonsense what I am suggesting::
If the turn-around time is -for instance- 330ms, that would mean -as a rue of thumb- that I can pull 3 requests per second from the device. If I would want to monitor 3 variables this way I never should exceed a rate of 1 per second for each.
There may be a way to increase this rate by putting all relevant data into one character string (one Particle variable) that can be pulled at the frequency of 3 per second and that is parsed afterwards in the application. This could than be done of course within the Photon-limitation of having strings of max 622 characters.
(And of course one should be aware that in day-to-day practice the observed turn-around time is not very stable and it would make sense to build in some marging…)
Does this make sense?
I’d appreciate your comment!
The round-trip time is more stable for Wi-Fi devices, assuming you have a good Internet connection.
There are other factors than the round-trip time that will have a much more significant difference in the speed that variable can be handled. The round-trip time is calculated at the CoAP layer, which is a lower level of the networking stack. Variable requests are dispatched sequentially at the user loop thread level. Thus the speed that they can be processed is highly dependent on how quickly other tasks in the loop thread are running. Blocking the loop thread for long periods will significantly slow down the rate variables can be processed.
The other problem with polling variables will not be the speed of the connection, but rather the API limits, at least if you plan on having more than a few devices. There is currently a limit of 5000 API requests every 5 minute period.
As a general rule, polling devices at a high rate is not recommended. It’s better to have device push their current values to the cloud and process them there.
Thanks for your quick response! That makes sense.
Last question: is my understanding from your remark correct that the limit of 5000 API requests per 5 minute period is per user (i.e. per Access Token), and NOT per device???
The 5000 API request limit in a 5 minute period is per public IP address making the request.
It does not depend on the user, product, access token, or device being queried.