1. Number of bits that can fit in a slot is determined as follows:
bitsInSlot = datarate*(slotDuration - slotOverhead).
2. Any model that required tight timing such as the TDMA model, will
have limitations on how small the slot you can actually support. Missed
slots and Rx drop (in wrong slot) can provide an indication when your
emulator is not keeping up.
Keep in mind this is a generic TDMA model and not necessarily
representative of any specific waveform. There are a lot of knobs in
the open source model but you may have to make changes to meet some of
your specific needs.
There are also EMANE deployment aspects that can impact your
performance. For example, assigning dedicated CPUs to containers
running EMANE can improve performance. Having said that, going down to
slot sizes in the order of several 100usec will be a challenge.
kb
Kaushik B. Patel
Adjacent Link LLC
On 06/12/2018 10:25 AM, Stepien, Joseph E (US) wrote:
> To Whom It May Concern:
>
>
>
> For the TDMA model, there is a /slotduration/ specified as well as a
> /datarate /for the tdma schedule/. /There is no apparent means to
> specify a data length for the slot. Does the slot duration assume the
> slot is entirely filled with data for the specified data rate? Seems
> reasonable since that would be precisely why the slot size were selected
> for the particular data rate or you would have otherwise specified a
> smaller slot. That is, /slotduration=1500/, /datarate=100M/, specified
> for the TDMA Demo 8. This would be 150,000 bits to fully fill this
> particular slot, which seems unusually large. Part of the TDMA model
> description specified a slotduration=1500 and datarate=1M, which seems
> more reasonable.
>
>
>
> The reason I ask is that I ran a TDMA Demo (Demo 8 of a prior set with
> 10 nodes), playing around with the slot duration to see how it might fit
> our current effort. At the originally specified 1500 slot duration at
> 100 M, the olsrview connected completely (after having specified a
> pathloss of 90 db, ie precomputed model in the demo). I modified the
> slot duration to a number of intervening values from 1500 down to 400
> and watched the links to all other nodes go down. Tried to alleviate by
> changing data rate to no avail. But I’m not sure why they went down.
> What am I missing? Presumably, each nem’s PHY has determined that the
> rxPower is no longer sufficient to keep the links up with the revised
> slot duration and data rate. Not sure why though since if all other
> parameters of rxPower calc, ie TxPower, txAntennaGain, rxAntennaGain,
> pathloss, noiseFigure and rxSensitivity calc, ie -174+noisefigure + 10
> log(bandwidth), remain the same, the connections should remain. The
> only other reasons seemed to be that the revised slot duration couldn’t
> accommodate the data and was therefore destined to fail, but there is no
> data size spec or the model couldn’t keep up. Can you provide some
> insight here?
>
>
>
> Are the number of /missed/ slots, ie the ones reported via /emanesh
> node-2 get table nems mac TxSlotStatusTable/, proportional to EMANE’s
> ability to process them in the specified slot times? That is, EMANE
> processing just can’t keep up or is there something inherent in the TDMA
> model itself that precludes reception?
>
>
>
> Thanks,
>
>
>
> Joe Stepien
>
> BAE
>
>
>
>
>
> _______________________________________________
> 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
