Scope

Determine the average monthly data usage of a Digi DAL OS device’s communication with Digi Remote Manager. Measure and report the data usage for DAL devices connected over cellular versus non-cellular (Ethernet, Wi-Fi WAN client, etc).

DAL devices utilize the following data paths when communicating with DRM:

1. Initial EDP TLS connection to DRM. Once established, all communication between the device and DRM flows through this tunnel

   1. 12,544 bytes to establish tunnel, which is inconsequential and non-impacting to the total data usage per month given the data sent between the device and DRM through the EDP tunnel

2. keep-alive packets

   1. 184 bytes per keep-alive exchange between the device and DRM

   2. default interval: 5-minutes for cellular, 1-minute for non-cellular

   3. configured under Central Management → Keep-alive interval (config name is Cellular keep-alive interval for cellular connections)

3. query_state RCI calls to report device status/health information

   1. 4100 bytes per query_state upload

   2. default interval: 1/hour

   3. configured under Central Management → Device telemetry

Results

Cellular

Ethernet

The same keepalive setting applies to all non-cellular interfaces, so the below results apply to other non-cellular type interfaces beyond just Ethernet (e.g. Wi-Fi WAN)

OLD - Data usage when utilizing datastreams on 23.6 and older firmware

the below information applies to Digi DAL OS devices running 23.6 and older firmware, which utilizes datastream uploads from the device to DRM instead of query_state Telemetry

Data Usage Summary:

Average monthly data usage:

• 4.68MB on cellular connections
• 18.1 MB on non-cellular connections (wired Ethernet, Wi-Fi client, PPPoE, etc)
• No configuration/firmware updates
• Digi RM-related configuration settings at their defaults
  • Connection to Digi RM enabled
  • Keep-alives set to 290-seconds for cellular, 60-seconds for non-cellular
  • Health metrics set to once per hour
  • Device event logging disabled

Maximum monthly data usage:  263MB

• One configuration update with 50 config settings (approximately 10kB in size)
• One firmware update included (approximately 30 MB as the average DAL product firmware size, some platforms have smaller firmware some have larger)
• All Digi RM-related config settings enabled and tuned to their most-often frequency
  • Initial connection sequence to Digi RM along with query_state and query_setting RCI calls from Digi RM - 12.25kB
  • Device event logging enabled at 1/minute intervals - 137 MB per month
  • Keep-alives set to once per 30-seconds - 34 MB per month
  • Health metrics reported once per minute - 62.64MB per month

Minimum monthly data usage:  154 kB

• No configuration/firmware updates
• Only critical Digi RM-related configuration settings enabled to maintain a base connectivity to Digi RM
  • Initial connection sequence to Digi RM along with query_state and query_setting RCI calls from Digi RM - 12.25kB
  • Keep-alives set to once per 2 hours - 141.84 kB
  • Device event logging disabled
  • Health metrics disabled

Breakdown Chart

Notes:  

The above data usage metrics were determined by monitoring the Rx/Tx bytes on the associated Internet connection/interface used by the DAL device to connect to DigiRM. This was done by viewing the rx/tx bytes reported in ifconfig for the interface in the shell console of the DAL device, which is also included in DAL’s runt system so you can view the same rx/tx byte count in the CLI, web UI, or DigiRM. I also utilized tcpdump to capture the packets going between DigiRM and the device to verify the byte count reported by the interface, just in case any non-DigiRM traffic went through the interface during the test.

Example tcpdump command you can run on the shell console of the DAL device to capture packets going to/from DigiRM:

tcpdump -nw /tmp/digirm_update-metrics.pcap -i any src 52.73.23.137 or dst 52.73.23.137

Where 52.73.23.137 is the IP of the my.devicecloud.com domain the DAL device used to connect to DigiRM. This can then be transferred to a host PC with wireshark where you can use its statistics to see how many total bytes were sent/received in the packet capture. There’s also a handy terminal tool called capinfos that comes with wireshark that you can use.

Example:

$ capinfos update-metrics.pcap
 
File name:           update-metrics.pcap
File type:           Wireshark/tcpdump/... - pcap
File encapsulation:  Linux cooked-mode capture v2
File timestamp precision:  microseconds (6)
Packet size limit:   file hdr: 262144 bytes
Number of packets:   6
File size:           1,719 bytes
Data size:           1,599 bytes
Capture duration:    0.347196 seconds
First packet time:   2021-08-11 14:46:21.360715
Last packet time:    2021-08-11 14:46:21.707911
Data byte rate:      4,605 bytes/s
Data bit rate:       36kbps
Average packet size: 266.50 bytes
Average packet rate: 17 packets/s
SHA256:              5fb99e83614bfc6375929794cbdb0c0160fb8e6532a785a655274588562ff153
RIPEMD160:           b46d0f846bb0a36a28d5ff11393282f9aaf3df29
SHA1:                bc9135b5dbabd79e950354e9257b2bcbd98f25fb
Strict time order:   True
Number of interfaces in file: 1

Interface #0 info:
                     Encapsulation = Linux cooked-mode capture v2 (210 - linux-sll2)
                     Capture length = 262144
                     Time precision = microseconds (6)
                     Time ticks per second = 1000000
                     Number of stat entries = 0
                     Number of packets = 6