Successful day on mqtt server from my point of view.
I seem to have lost a sample or two at 7:12 AM MDT – I’ll blame that on the facebook.
1 Like
Outage on my devices today 11:24 AM - 1:19 PM MDT, followed by some a catchup period to about 2:44 PM MDT where older data was being timestamped as current. After that, everything smooth again.
I assume it was connected with the announcement about the new server features.
yes it was due to the release of new feature.
Following some strange data last Thursday, I redid my Jitter program to track mqtt. I got some interesting results.
I setup a javascript node.js program running on a raspberry pi to send unixtime to cayenne every 15 seconds, which in turn would be timestamped at the cayenne database with unixtime. Then I fetched the 1-minute summary of the unixtime and substracted the cayenne timestamp on that time, and displayed it in a graph, which should result in zero. Here is a 3 day graph, from Saturday night to Tuesday night.
.
Two observations. First there is the repeating 4 hour cycle, shown here Sunday evening. My pi starts 20 seconds ahead of cayenne, and over 4 hours seems to speed up to 40 seconds ahead of cayenne. There are various samples 2-3 seconds ahead or behind this trend – which I attribute to internet variance, and the 20 to 40 seconds offset, I guess would be a poor quality clock on the pi, which must be reset by the default install of raspberry os every 4 hours.
Second, Saturday and Sunday were quiet, but working days Monday and Tuesday had slowdowns during the day. Here are blowups on Monday and Tuesday.
These times are Mountain Daylight Time - 1 hour off Pacific - and show the normal 20-40 second error ahead of cayenne, drops to 60-80 seconds behind cayenne during mid-morning and mid-afternoon. That is, my 20 seconds too fast time, takes 100 seconds to arrive at the cayenne database, and is marked -80 on the graph.
The evenings are back to normal. I have fiber internet right to my wifi box, which should be good, but who knows, or it could be general internet, or mysterious activities in the server room ??
Either way, the notion of sending a timestamp along with the data sample seems like a good idea. Perhaps difficult to implement, as you are storing data from the recent past, and future in a realtime database. I am more sympathetic with the guy complaining about his system with dialup modems, and remote sensors, rather than fiber internet.
It would be interesting to repeat this experiment in the 4 corners of the world, with different internet technologies. I’m going to set up a 8266 to send unixtime (or whatever Arduino uses) to compare results.
2 Likes
I have been getting a lot of timeouts on queries lately - last 2-3 days. I don’t have a rigorous measurement on that. The sending of data has been good, with an occasional problem - here is May 23 10:30 AM MDT. The first 2 graphs show device-time minus cayenne time, for a 8266 and a pi. They both went 800 seconds behind, for a server reboot ??? - software upgrade ??? or general internet clog somewhere ??? Third graph is a nice sine wave that shows the backlog of data. This could be my internet of course – don’t know if anyone else notices these things.
@jameszahary yes, the legacy arduino server was turned off on 23rd May, that might have caused it.