Energy Efficient Ethernet IEEE 802.3az implementation
54 views
Skip to first unread message
Federico Tramarin
Feb 23, 2016, 10:05:56 AM2/23/16
to OMNeT++ Users
Dear all,
at a recent Omnet++ event a presentation raised the issue of a missing implementation of IEEE 802.3az within INET.
https://summit.omnetpp.org/archive/2015/assets/pdf/OMNET-2015-23-Slides.pdf
I agree with the "missing pieces" that the presentation highlights. And that are the same pieces that stopped me from providing an effective implementation by myself.
Actually, I realized some time ago an implementation but it was way too focused on Ethernet Powerlink and it is not so much portable to a real framework.
Anyway, it has also to be said that it should not be so difficult to implement such a feature.
Moreover, I saw that a strong effort on this path is going on with ns-3, and also saw that some of the main omnet developers also develop on ns-3 as well.
So, my question, and also my tentative discussion is: why not to try to provide a realization of such a feature for the Omnet++ environment?
Has anyone started to deal with this?
I hope the discussion could become interesting and prolific ;)
Cheers,
Federico
at a recent Omnet++ event a presentation raised the issue of a missing implementation of IEEE 802.3az within INET.
https://summit.omnetpp.org/archive/2015/assets/pdf/OMNET-2015-23-Slides.pdf
I agree with the "missing pieces" that the presentation highlights. And that are the same pieces that stopped me from providing an effective implementation by myself.
Actually, I realized some time ago an implementation but it was way too focused on Ethernet Powerlink and it is not so much portable to a real framework.
Anyway, it has also to be said that it should not be so difficult to implement such a feature.
Moreover, I saw that a strong effort on this path is going on with ns-3, and also saw that some of the main omnet developers also develop on ns-3 as well.
So, my question, and also my tentative discussion is: why not to try to provide a realization of such a feature for the Omnet++ environment?
Has anyone started to deal with this?
I hope the discussion could become interesting and prolific ;)
Cheers,
Federico
Carpa Radu
Mar 3, 2016, 7:54:48 AM3/3/16
to omn...@googlegroups.com
Hello,
The Ecofen ns-3 models are basically C++ code, which can easily be brought into OMNET++ in a couple of days via dirty hacks. This solution will allow to do your simulations, write a couple of papers, and "throw away" your code afterwards.
I'm aware that this may not be what you expected :)
The biggest problem towards a clean port to Omnet++ is entirely "ideological": even the core Omnet++/INET developers didn't yet decided (at the time of the summit) how they wanted to see an(y) energy model integrated into INET.
Let me explain myself :
INET simulates only software components. Take a look at the INET modules: IPV4, TCP, OSPF, .... it is entirely a software stack and does not simulate any hardware. With one unique exception : the radio module used for wireless communications.
IMHO, what I understood at the summit, is that the developers want to get rid of this hardware radio module mixed into software, because mixing hardware and and software is as bad as mixing apple and oranges : no one would ever want to eat them anymore :)
Among the discussed solutions to this problem, the most popular would involve splitting INET in 2 separate groups of components : the software and the hardware ones.
The problem with this solution is that someone must actually write the source code and NED description of all hardware components : CPU/Memory/Network Interface/etc.
Once this is done, the software actions must be matched into hardware. For example, an intensive Dijkstra computation in the OSPF software module may be matched into 1 microsecond of CPU time.
Now, the existing (INET > 3.0) energy model can be used to asses the energy consumption of the CPU.
I think that this is a very good design choice and it will fit very well into the OMNET++ /INET clean component-based design (IMHO, one of the best source code I've ever seen).
However, that means that somebody must actually do all the refactoring and write A LOT of very boring placeholder code.
I didn't follow very closely the development of INET from the summit onward, but it seems that absolutely nothing was done in this direction. (Dear Andras, correct me if I'm wrong).
If the software/hardware separation is implemented, I will willingly sacrifice a couple of weeks of my spare evenings to actually port Ecofen to INET. However, I don't have the time or the motivation to just do a dirty hack which will never be accepted into INET. (I've already done to many of them for my simulations and they don't even work in INET3 :) ).
Sincerely,
Radu
The Ecofen ns-3 models are basically C++ code, which can easily be brought into OMNET++ in a couple of days via dirty hacks. This solution will allow to do your simulations, write a couple of papers, and "throw away" your code afterwards.
I'm aware that this may not be what you expected :)
The biggest problem towards a clean port to Omnet++ is entirely "ideological": even the core Omnet++/INET developers didn't yet decided (at the time of the summit) how they wanted to see an(y) energy model integrated into INET.
Let me explain myself :
INET simulates only software components. Take a look at the INET modules: IPV4, TCP, OSPF, .... it is entirely a software stack and does not simulate any hardware. With one unique exception : the radio module used for wireless communications.
IMHO, what I understood at the summit, is that the developers want to get rid of this hardware radio module mixed into software, because mixing hardware and and software is as bad as mixing apple and oranges : no one would ever want to eat them anymore :)
Among the discussed solutions to this problem, the most popular would involve splitting INET in 2 separate groups of components : the software and the hardware ones.
The problem with this solution is that someone must actually write the source code and NED description of all hardware components : CPU/Memory/Network Interface/etc.
Once this is done, the software actions must be matched into hardware. For example, an intensive Dijkstra computation in the OSPF software module may be matched into 1 microsecond of CPU time.
Now, the existing (INET > 3.0) energy model can be used to asses the energy consumption of the CPU.
I think that this is a very good design choice and it will fit very well into the OMNET++ /INET clean component-based design (IMHO, one of the best source code I've ever seen).
However, that means that somebody must actually do all the refactoring and write A LOT of very boring placeholder code.
I didn't follow very closely the development of INET from the summit onward, but it seems that absolutely nothing was done in this direction. (Dear Andras, correct me if I'm wrong).
If the software/hardware separation is implemented, I will willingly sacrifice a couple of weeks of my spare evenings to actually port Ecofen to INET. However, I don't have the time or the motivation to just do a dirty hack which will never be accepted into INET. (I've already done to many of them for my simulations and they don't even work in INET3 :) ).
Sincerely,
Radu
--
You received this message because you are subscribed to the Google Groups "OMNeT++ Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to omnetpp+u...@googlegroups.com.
Visit this group at https://groups.google.com/group/omnetpp.
For more options, visit https://groups.google.com/d/optout.
Rodrigo Hagstrom
Apr 16, 2018, 10:06:46 AM4/16/18
to OMNeT++ Users
Reply all
Reply to author
Forward
0 new messages