ns-3.38 planning

48 views
Skip to first unread message

Tom Henderson

unread,
Nov 7, 2022, 7:20:22 PM11/7/22
to ns-dev...@googlegroups.com
Hi all,
Let's start to talk a bit about ns-3.38. I was thinking that we aim for
a late January release and get back on track with our planned
January/May/September schedule. We had two lengthy cycles due to some
large-scale changes that took longer than 4 months to settle (CMake and
then coding style). Are any such changes looming in anyone's mind, or
should we be able to work on a shorter release cycle?

Would anyone like to share their goals or plans for ns-3.38 at this time?

Would people like to join a telecon in the next week or two to discuss
next steps?

- Tom

Gabriel Ferreira

unread,
Nov 7, 2022, 10:06:46 PM11/7/22
to ns-developers
Hi Tom,


From the build and bindings side, I believe there will be only bug fixes and tiny features (e.g. additional compilation flag, deep/distclean, etc). 

I plan to refactor a few things (e.g. doxygen executable search) to speed up the configuration/cache refreshes.

Thinking if I should add support for ninjatracing support after chatting with Biljana. It converts the Ninja build log to the about://tracing trace format .
It is pretty good to check what task is slowing down the build. Image below shows an example with most objects ccached.
Untitled.png
It can also use Clang's -ftime-trace data (already supported with NS3_CLANG_TIMETRACE) to give more detailed information about each task (clean ccache in this case).
Untitled2.png

Gabriel.

Eduardo Almeida

unread,
Nov 10, 2022, 12:35:11 PM11/10/22
to ns-developers
Hi all,

In terms of clang-format, I think that work is done. There are some requests in issue 677 to consider some tiny adjustments to clang-format, namely lambda functions, which I'll try to analyze.

In terms of clang-tidy, I would like to add a few more rules to improve the quality, readability and performance of the code, and prevent accidental bugs. I was thinking about creating one MR per clang-tidy rule, so that maintainers could evaluate the impact and usefulness of the rule. Then, we could merge the ones that had general acceptance.

Since clang-tidy is already set up, it is now easier and faster to add more rules. I hope I can finish that work for the ns-3.38 release, but I'm comfortable with postponing it or reducing the list of rules, if I don't have time to finish it in time for the release.

Regards,
Eduardo Almeida

Alberto Gallegos

unread,
Nov 15, 2022, 4:39:12 AM11/15/22
to ns-developers

Hi everybody,

For lr-wpan,   I would like to finish some updates to support "Rx sensitivity configuration".  This is based on some conversations with Tommaso Pecorella.
You can see a completed new lr-wpan per plot example with configurable rx sensitivity in the current  MR (https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/1006).
A similar per plot was previously present in the documentation as an image but not as code. 

Documentation is still missing. Furthermore, I plan to modify the lr-wpan-distance-plot so it can also support 
the configuration of rx sensitivity.

On a different thing, I plan to upload the first draft of an extension to the energy module, in specific, an extension of the lionEnergySource so it can support
other battery chemistries discharge curves, a configuration of cell packs and easier setup with the use of battery presets in the battery helper. I do not expect to be integrated into the next release but
I would like to hear comments when possible.




802.15.4-per-vs-rxSignal.png

stav...@gmail.com

unread,
Nov 15, 2022, 9:35:10 AM11/15/22
to Tom Henderson, ns-dev...@googlegroups.com
Hi Tom, all,

I will shortly be able to push the basic support for transmissions among 802.11be MLDs (STR mode). There are other features in the works but I am not sure which ones will be pushed in time for ns-3.38 (assuming a January release).

Bests,
Stefano


On Mon, Nov 7 2022 at 03:54:37 PM -08:00:00, Tom Henderson <to...@tomh.org> wrote:
Hi all, Let's start to talk a bit about ns-3.38. I was thinking that we aim for a late January release and get back on track with our planned January/May/September schedule. We had two lengthy cycles due to some large-scale changes that took longer than 4 months to settle (CMake and then coding style). Are any such changes looming in anyone's mind, or should we be able to work on a shorter release cycle? Would anyone like to share their goals or plans for ns-3.38 at this time? Would people like to join a telecon in the next week or two to discuss next steps? - Tom
--
You received this message because you are subscribed to the Google Groups "ns-developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to ns-developer...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/ns-developers/ff129dbf-1045-6ee5-a4cb-ea8695194efb%40tomh.org.

Tom Henderson

unread,
Nov 20, 2022, 3:05:54 PM11/20/22
to ns-dev...@googlegroups.com
Thanks for all of the inputs. I collected a summary on this wiki page,
and added a few of my own goals:

https://www.nsnam.org/wiki/Ns-3.38

The GitLab.com issue and merge request tracker is always the best place
to check the day-to-day status of anything; the above wiki page is
mainly for broader goals.

From my perspective, I would like to work on completing the following:

* merge our remaining GSoC and NSoC project work from this year
* merge NetDevice state project work from Ananthakrishnan (GSoC 2020)
* change how we release ns-3 to include app store modules (more on this
at a later date)
* migrate Installation wiki information to Sphinx documentation
* refactor and merge the signal clipping work from Sandia
* finish work on the Flent application
Reply all
Reply to author
Forward
0 new messages