You are not logged in.
Since a lot of research into internet traffic models the rate of incoming packets as a Poisson point process, it would be beneficial to wireless researchers if an LTG_SCHED_TYPE_POISSON_RAND option were available. As such, I've modified wlan_mac_ltg.c and wlan_mac_ltg.h to support such traffic. Additionally, I've also updated ltg.py in wlan_exp and it appears to work as expected in terms of communicating the necessary information.
Finding the time between subsequent packets in such a traffic flow requires the use of the natural logarithm function, which takes up a ton of space. Instead of using the log in the math.h library, I adapted the code from this webpage so that only a handful of bitwise and basic mathematical operations are used.
Results as seen in wireshark seem to show that it is functioning as expected. Choosing a lambda of 50 packets per second yields this pmf for interarrival times, with the blue line representing experimental results and the green line showing the plot of the pmf of an exponential distribution with lambda of 50. Of note is that there do seem to be the occasional pauses where transmissions do not occur for highly improbable gaps (e.g. 10 seconds) and I'm not sure if this can be attributed to the additions I have made because it appears as though the ltg_sched_check is just not being called by the event scheduler.
You guys can do what you wish with this. I just needed Poisson random traffic for my research and figured it'd be good to contribute something back since you guys have provided so much help over the past few years.
Last edited by cancub (2016-Oct-13 13:08:39)
Offline
This is very cool. Thanks for sharing the code - I'm sure this will prove useful to other users of the 802.11 ref design.
Offline
UPDATE TO CODE:
Apparently the code for the loq function is causing the improbably large interarrival times due to receiving an input of 0.000 from the rand function. I'm not sure if this occurs in c++ code or if it's an artifact of porting the code to c, but I've a simple fix for the code and everything should be fine. The only issue is that there will be sliiiightly more of larger delays because I had to shift the rand of 0.000 to 0.001, but these occur so rarely anyways that it shouldn't be an issue.
Offline
