• State Not Answered
  • Replies 5 replies
  • Subscribers 71 subscribers
  • Views 217 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 333965
Options

Networking Stats - Socket Data Usage (sent/received data amount)

Povilas S

I am developing a project on nRF9161.

I am interested in calculating data usage for different protocols (for example MQTT with TLS) when communicating with a server over cellular network/socket. Is there a way to do so?

I have found "net stats" sample code:
https://docs.nordicsemi.com/bundle/ncs-latest/page/zephyr/samples/net/stats/README.html
But after integrating it into my code it does not seem to function properly (I have only moved init function call to my main). It always prints zeros for all data, even though I am certain that communication is working, additionally function calls, such as send(), are returning the amount of application data it has sent.

Global network statistics
IPv6 recv      0        sent    0       drop    0       forwarded       0
IPv6 ND recv   0        sent    0       drop    0
IPv6 MLD recv  0        sent    0       drop    0
IPv4 recv      0        sent    0       drop    0       forwarded       0
IP vhlerr      0        hblener 0       lblener 0
IP fragerr     0        chkerr  0       protoer 0
ICMP recv      0        sent    0       drop    0
ICMP typeer    0        chkerr  0
UDP recv       0        sent    0       drop    0
UDP chkerr     0
TCP bytes recv 0        sent    0
TCP seg recv   0        sent    0       drop    0
TCP seg resent 0        chkerr  0       ackerr  0
TCP seg rsterr 0        rst     0       re-xmit 0
TCP conn drop  0        connrst 0
Bytes received 0
Bytes sent     0
Processing err 0
Statistics for interface 0x200113e8 [1]
IPv6 recv      0        sent    0       drop    0       forwarded       0
IPv6 ND recv   0        sent    0       drop    0
IPv6 MLD recv  0        sent    0       drop    0
IPv4 recv      0        sent    0       drop    0       forwarded       0
IP vhlerr      0        hblener 0       lblener 0
IP fragerr     0        chkerr  0       protoer 0
ICMP recv      0        sent    0       drop    0
ICMP typeer    0        chkerr  0
UDP recv       0        sent    0       drop    0
UDP chkerr     0
TCP bytes recv 0        sent    0
TCP seg recv   0        sent    0       drop    0
TCP seg resent 0        chkerr  0       ackerr  0
TCP seg rsterr 0        rst     0       re-xmit 0
TCP conn drop  0        connrst 0
Bytes received 0
Bytes sent     0
Processing err 0

Has anyone been successful in monitor modem/socket data usage with an nRF91 series device?

  • 0

    I'm used to "AT%XCONNSTAT?", which works pretty well on the nRF91 series. I'm not common to other approaches.

  • 0 in reply to Achim Kraus

    I've seen that one, but it is kilobytes and for this case I am interested in bytes.

  • 0 in reply to Povilas S

    > I am interested in bytes.

    Send 1024 messages and you will see the bytes ;-).

    To be frank, with all the things happening "unexpected" (e.g. TCP internal retransmissions or retransmission from upper UDP protocols), counting bytes won't reflect the real data consumption in the wild. There you need to run the device for a couple of days and the k-bytes will be a pretty well value reflecting the reality. 

  • 0

    Encountering the same issue (NRF9161), when trying to check data usage for MQTT communications. Any chance that support can provide a reason why this doesn't work?

  • 0 in reply to AdrianT

    I'm not an employee of Nordic, but for me the reason is pretty clear:

    "AT%XCONNSTAT?" does a good job.

    If you use MQTT you will have some unaware data consumption (TCP connect/TCP ACK) and if you use TLS, each connect will come with an handshake (several k bytes). So the experience is pretty clear and simple: let it run for a week and see how much data-volume that requires in the "wild" outside your laboratory. Especially in cases with low radio signals you will need some extra data for TCP/TLS.

    For UDP it's up to you (and the use-case), if a missing message should "restart the connection" or simply "try it later again" works. Using CoAP/DTLS 1.2 CID requires for IP/UDP/DTLS 1.2 CID/CoAP an average overhead of about 100 bytes per message (rare DTLS handshakes included). If you use IP/TCP/TLS 1.2 the overhead per message will be slightly smaller (you mainly save the CID), but the average the depends pretty much from the number of required connect/TLS handshakes. Therefore, only a test in the "wild" will give you realistic results.

Related