Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Calculate TX air time duty cycles #588

Closed
mc-hamster opened this issue Dec 25, 2020 · 10 comments
Closed

Calculate TX air time duty cycles #588

mc-hamster opened this issue Dec 25, 2020 · 10 comments
Assignees
Labels
enhancement New feature or request

Comments

@mc-hamster
Copy link
Member

mc-hamster commented Dec 25, 2020

Calculate air time duty cycles

Pls include 1hr / 24hr percentages.

maybe maintain the usage over a few days. It shouldn’t cost that much ram.

@mc-hamster mc-hamster self-assigned this Dec 25, 2020
@geeksville
Copy link
Member

This issue has been mentioned on Meshtastic. There might be relevant details there:

https://meshtastic.discourse.group/t/ip-over-meshtastic-kinda-implemented/1775/12

@geeksville geeksville added the enhancement New feature or request label Dec 25, 2020
@geeksville
Copy link
Member

I really like the "track over a long period of time idea (a day or two)" so that throttling (when eventually added) doesn't kick in with false positives.

@geeksville
Copy link
Member

also just knowing what 'real world duty cycle' we are currently getting would be useful.

@mc-hamster mc-hamster changed the title Calculate air time duty cycles Calculate TX air time duty cycles Dec 25, 2020
@mc-hamster
Copy link
Member Author

I think a first pass would be to report the TX airtime. A next step may be to also report on RX airtime so we have an idea of cannel utilization.

@geeksville
Copy link
Member

ooh really good point wrt rx airtime telling us % channel utilization also.

@geeksville
Copy link
Member

geeksville commented Dec 25, 2020

Also nodes with "higher rx airtime than others" might be a really good heuristic for "nodes that should probably be preferentially considered for routing (someday when we are doing something smarter than naive flood routing)" (assuming rx sensitivity and tx reach are symmetric - which alas, might not be true)

@mc-hamster
Copy link
Member Author

Note to self: 1839f8f

@mc-hamster
Copy link
Member Author

mc-hamster commented Dec 25, 2020

@geeksville Thinking about channel utilization, I think there are two measures.

  1. The utilization of the lora channel are we using for our current network
  2. The utilization of the lora channel by the current device, the devices on our current meshtastic channel and other lora devices that may have similar channel configurations.

I'll assume that for #2, if our radio receives a packet that is not designated for the device, it's discarded. Where does that happen? I'd like to also include that.

@crossan007
Copy link
Contributor

Seems like we need 4 counters?

Transmitted packets (originating on device)
Transmitted packets (forwarded for other devices)
Received packets (destined for device)
Received packets (for other devices)

@mc-hamster
Copy link
Member Author

mc-hamster commented Dec 26, 2020

Seems like we need 4 counters?

Transmitted packets (originating on device)
Transmitted packets (forwarded for other devices)
Received packets (destined for device)
Received packets (for other devices)

Hmm ...

Other than for reporting, how would having a counter for packets originating from the device vs to be forwarded to other devices be used?

When maintaining a 48 hour history, each counter costs us about ~100 bytes of RAM. The amount of history to maintain is a config setting.

Regardless, adding more counters will be easy if it's needed. :)

mc-hamster added a commit to mc-hamster/Meshtastic-device that referenced this issue Dec 26, 2020
mc-hamster added a commit to mc-hamster/Meshtastic-device that referenced this issue Dec 27, 2020
mc-hamster added a commit to mc-hamster/Meshtastic-device that referenced this issue Dec 27, 2020
mc-hamster added a commit to mc-hamster/Meshtastic-device that referenced this issue Dec 27, 2020
mc-hamster added a commit that referenced this issue Dec 29, 2020
#588 - Calculate air time. TX and RX logging is done. #601 - tbeam draws too much power from usb
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants