Michael,
You would be better off using the BroadcastPacket{Accept,Drop} Tables
and UnicastPacket{Accept,Drop}Tables. They provide more information,
such as the reason why a packet is dropped and they are broken out by
source or destination.
>From https://github.com/adjacentlink/emane/wiki/Introduction:
"We use the term downstream for all messages headed towards the OTA
multicast channel and the term upstream for all messages headed towards
delivery to application space processes..."
The 'Tx' and 'Rx' that you see as part of the statistic counters you
reference such as numUpstreamPacketsUnicastRx0 and
numUpstreamPacketsUnicastTx0, reflect the number of packets received at
the layer in the upstream direction and transmitted at the layer in the
upstream direction.
Upstream In (Rx) --> [Layer Processing] --> Upstream Out (Tx)
When we perform analysis we look at the accept and drop tables from all
the layers in the NEM stack. This provides a full view of where and why
packets are dropped.
No, upstream and downstream numbers do not have to be equal. One would
hope that the upstream tx of one layer would be equal to the upstream rx
of the layer immediately above. That is one of the purposes of these
statistics, to add insight into NEM composition.
--
Steven Galgano
Adjacent Link LLC
www.adjacentlink.com
On 07/25/2018 07:16 AM, Vincent, Mike wrote:
> I'm trying to get the number of user-land unicast packets sent between 2
> NEMs. This would be analogous to polling interface utilization counters on a
> router via SNMP. For example, assume a simple network with just 2 NEMs
> connected point-to-point over virtual transport running OLSR like in the
> emane-tutorial examples. I launch a 'ping' from NEM1 to NEM2.
>
> Using emansh, I can see some stats increasing:
>
> NEM1 (get stat 1 phy numUpstreamPacketsUnicastRx0
> numUpstreamPacketsUnicastTx0
> numDownstreamPacketsUnicastRx0
> numDownstreamPacketsUnicastTx0)
>
> There also appears to be correlation between NEM1 and NEM2, where:
>
> NEM1:numUpstreamPacketsUnicastRx0 == NEM2:numDownstreamPacketsUnicastRx0
> NEM1:numUpstreamPacketsUnicastTx0 == NEM2:numDownstreamPacketsUnicastTx0
> NEM2:numDownstreamPacketsUnicastRx0 == NEM1:numUpstreamPacketsUnicastRx0
> NEM2:numDownstreamPacketsUnicastTx0 == NEM1:numUpstreamPacketsUnicastTx0
>
> Counters are the same at the transport layer (just dropping the trailing 0
> from the statistic name.
>
> Documentation at
> https://github.com/adjacentlink/emane/wiki/Physical-Layer-Model isn't very
> helpful:
>
> "numDownstreamBytesUnicastRx0 uint64 yes Number of
> downstream unicast bytes received"
>
> What does "downstream" mean in the phy layer context vs. upstream? I'm
> *assuming* downstream is from transport (i.e., user-land) to the wire and
> upstream is the reverse. But then why the TX and RX distinctions?
>
> QUESTION:
> What is the best way to "measure" transmitted and received unicast packets
> between two NEMs:
>
> * Are the counters I highlighted the best?
> * Should I use the phy and / or transport layer counters?
> * shouldn't upstream and downstream numbers on the same NEM be equal
> (i.e., UpstreamRx == DownstreamTX)? [They aren't!]
> * I see a drop counter (i.e., numUpstreamPacketsUnicastDrop0,
> numDownstreamPacketsUnicastDrop0) but currently equal to 0. Does this need
> to be accounted for somehow?
> * Is it better to just measure from a user-land perspective (i.e., send
> and count pings / replies)?
>
>
> Cheers,
>
> Michael J. Vincent
> Lead Network Systems Engineer | The MITRE Corporation | Network Technology &
> Security (T864) | +1 (781) 271-8381
>
>
>
>
> _______________________________________________
> emane-users mailing list
> emane-users@nrl.navy.mil
> https://publists.nrl.navy.mil/mailman/listinfo/emane-users
>
_______________________________________________
emane-users mailing list
emane-users@nrl.navy.mil
https://publists.nrl.navy.mil/mailman/listinfo/emane-users
