For the moment I am pairing my P1 with a celluar hotspot. I have a program running and found that the celluar hotspot is using a lot of data 53MB in one day.
I am wondering if anyone knows how much data is used for the Spark.process() that is called automatically in semi-automatic mode?
I can’t answer your actual question, but a part (maybe even a big one) might be the granularity your network provider counts your usage.
Some count a junk of several kB even if you’re only transmitting a few byte.
The cloud is pinged from the device every 15 seconds, so that will add up over the course of a day! For the Electron we will be heavily optimizing bandwidth use for Cellular and backfitting this to photon/P1.
Oh yeah that would do it… A ping every 15 seconds means 5,760 pings per day. The normal MTU gives us 1500 bytes per network packet. If you use 6 packets per ping (open connection, ack, auth, auth ack, data, close? – I’m making stuff up), that would be 51.8MB/day.
Sounds like you might want to use MANUAL mode and see how infrequently you can get away with calling Spark.process(). Though that note about losing data to buffer overruns makes me nervous.
@dougal, Can you explain further about " Though that note about losing data to buffer overruns makes me nervous."? I’m not really sure what this means.
@mdma, from you best guess what do you think is the largest possible Sprark.process(); interval?
I dug out some old data (wasn’t able to set up the test last night, sorry)
For a quiescent core/photon, I measured (in Feb/Mar 2015) ~100KBytes of TCP payload in each direction, per 24 hr period. That’s just the application level keep-alives, not the TCP -level keepalives or the IP overhead.
There’s a world of difference between 100KB of application level data flowing in each direction, and 50MB.
I’ve started a capture on a device that is publishing every 5 mins (which should exceed your conscious data usage by a considerable margin) - I’ll report back on what that usage looks like at the application & raw packet level.
You may be falling foul of the billing practices of the carriers (e.g they round up for a given time interval) - I’ll have more data in a few hours, but at the moment I’d have to say that one or both of these might apply:
In the US, Verizon and less so others, have service plans for “telemetry”. Far cheaper than consumer service plans for data/voice/SMS. Not sure you can get 1each of these. Last time I checked, Verizon’s price was $5/mo, assuming telemetry type low volumes.
Beware airtime cost of keeping a constant TCP connection on cellular. Or doing frequent TCP connect/data/disconnect.
Better to use UDP for telemetry. The receiving server can timeout and re-request data if the UDP packet is lost.
After 4 hours of testing, snooping on a photon that is in fully automatic mode, publishing an event every 5 mins, I have the following data to share:
Total COAP data transmitted by photon to cloud - 20274 bytes (tcp payload)
Total COAP data received by photon from cloud - 16434 bytes (again, tcp payload)
Most COAP packets are 16 bytes of payload, meaning 18 bytes in the tcp payload of that packet.
TCP header is 20 bytes
IP header is 20 bytes
There are additional TCP keep-alives exchanged in each direction approx every 80 seconds (part of the TCP protocol) - these consist of 20 bytes of TCP header and 20 bytes of IP header.
That extrapolates (roughly) to, per day:
Tx COAP data: ~120KBytes
Rx COAP data: ~96KBytes
Total TX IP data (COAP + TCP (incl. keep alives) + IP): ~400KBytes
Total RX IP data (COAP + TCP (incl keep alives) + IP): ~330KBytes
This is without any network sillyness, retries, new TCP connections etc.
Still a long, long way from the 50MB you reported.
I will try and make time to create a SEMI_AUTOMATIC test case, that just publishes every 90 mins. To see if there is any pathological behaviour introduced that way.
Methodology: I use tcpdump/wireshark to dump the packets directly off my wired network between the access point and the firewall. Then inspect/process the resulting pcap files.
@AndyW, I was able to change the default celluar connection with the Hotpot to 1x from LTE. Since this change hardly any data is being reported as being used in multiple days.
Excellent news. I wonder what was up with the other hotspot, that behavior was definitely off-the-charts bad ( but, I suspect, par for the course in the mobile hotspot business)