|
|
Post by Wolfgang on Nov 21, 2019 21:00:36 GMT
|
|
|
|
Post by Johannes on Jun 25, 2021 19:57:42 GMT
Hello Wolfgang, in the announcement, a running port for V1.2 was planned for a current version of OMNet. As the forum indicated, the project cannot be maintained intensively due to time constraints. I assume there are no release plans for V1.2. I have recently started work on PTP reliability investigations, and the libPTP appears to be a solid foundation for this project. Thanks for your work in advance. Currently, I am mainly interested in getting libPTP running on our target system. Which for other reasons has to be based on the current OMNet Version 5.6.2. Maybe I can contribute something, but for now I'm still missing the entry point. Can you give an estimate of effort from your experience? Are there any known API issues that need to be resolved first? Do you also expect major adjustments for an update of the INET base? (2.6 to 4.2) |
|
|
|
Post by Wolfgang on Jul 13, 2021 19:23:12 GMT
in the announcement, a running port for V1.2 was planned for a current version of OMNet. As the forum indicated, the project cannot be maintained intensively due to time constraints. I assume there are no release plans for V1.2. You are right, the v1.2 was never done. I have recently started work on PTP reliability investigations, and the libPTP appears to be a solid foundation for this project. Thanks for your work in advance. I'm glad it is useful  Can you give an estimate of effort from your experience? No, not really. This would depend a lot on your experience with PTP and the relevant versions of OMNet++ and INET. But I would assume at least a few weeks. When I did work in this implementation, I was under some time pressure, and for this reason - I started to implement stuff before reading the OMNeT++ user manual in all details
- did not discuss any implementation details with the upstream OMNeT++ community
I would really recommend you to start by reading the OMNeT++ user manual completely, in all details. I did loose quite some time by not doing this, because I later recognized that some design decisions where wrong then I re-implemented stuff.
And as a long-term goal, I think it would be wise to discuss with the upstream community how things should be implemented. But I guess as a first step it might be easier to just port everything as it is now to the newer OMNeT++/INET versions and then start refactoring.
Are there any known API issues that need to be resolved first? There is a public list of API changes for each OMNeT++ version, see first post in this thread. Do you also expect major adjustments for an update of the INET base? (2.6 to 4.2) Yes. I haven't followed the INET development, but this part is the part where I would expect the most headaches. I did modify the internals of the INET Ethernet modules to achieve the PTP behavior I wanted, and if these modules have changed (which I expect) it will be necessary to modify the current implementations of those modules. regards, Wolfgang |
|
|
|
Post by Johannes on Jul 15, 2021 12:47:21 GMT
In the meanwhile, I get slowly familiar with OMNet/INET and got a foot in. But I think, I am still at the beginning.
As far as I know until now, the issues with the OMNet++ changes are doable and require mostly an adaption of the namespaces and to the 'new' include behavior.
Quite different with INET.
As you correctly guessed, there were serious changes to the Ethernet modules.
This applies in particular to the components 'PTP_EtherEncap' and 'EthernetII_LLC' (Network Layer 2 model) since some used API functions no longer exist in the new INET Framework.
These modules have to be rewritten according to the new API.
It would be helpful if you could say which PTP related modifications were necessary and what problems were encountered.
|
|
|
|
Post by Wolfgang on Jul 16, 2021 5:50:50 GMT
In the meanwhile, I get slowly familiar with OMNet/INET and got a foot in. But I think, I am still at the beginning. Great Do you have a setup where you can run the old simulations and e.g. see simulation results, like meanPathDelay or port states? I hope to find some time in the next weeks to finally write the Usage Examples section of the project website. Quite different with INET. As you correctly guessed, there were serious changes to the Ethernet modules. This applies in particular to the components 'PTP_EtherEncap' and 'EthernetII_LLC' (Network Layer 2 model) since some used API functions no longer exist in the new INET Framework. These modules have to be rewritten according to the new API. If it would be only the EtherEncap or the LLC that would be great, these are two very simple modules. EtherEncap puts generic PTP messages into Ethernet frames (according to the Ethernet-specific Appendix of the standard), which mainly means setting the correct multicast address. LLC is mostly a demultiplexer for EtherTypes. E.g. you could have Ethernet frames with different EtherTypes coming in from the network and forward them to different network stacks (e.g. a TCP/IP stack and a PTP/Ethernet stack). It would be helpful if you could say which PTP related modifications were necessary and what problems were encountered. As far as I remember the most tricky part was how to integrate timestamping for send/receive into the existing switch modules. The original INET modules did not really have hooks to add something like that, so I had to hack it into there somehow. I would have to look it up, but I think I inherited from the upstream models and overwrote some of the functions with modified versions, but with a lot of ugly copy/pasted code. |
|
|
|
Post by Wolfgang on Jul 17, 2021 23:05:03 GMT
I hope to find some time in the next weeks to finally write the Usage Examples section of the project website. I have uploaded a draft of the Usage Examples page. It only has a small description of the available example networks for now. In a next step I plan to add descriptions on how to run these networks and trace and analyzes simulation results. |
|
