Omnet Inet wireless host not recieving packets in example

[Simón Windmuller]

I'm trying to calculate throughput and delay sending packets from a wired host through a router to a wireless host. I managed to calculate throughput and delay using the throughput example in Inet. But now I'm trying to use the wirelessand wiredhostwithAP example to do the same thing but realized that packets coming from the wired host stop at the access point and don't reach the wireless host. Why is this happening? Is there any specific configuration that I need to set for the wireless host to associate to the AP? Or isn't that the problem? I can see that packets sent from the wireless host do reach the AP and are passed through to the other wired hosts. Using Omnet 5.0 and the self-installed Inet project.

Thank you in advance for all the help.

Simon.

[Michael Kirsche]

Are you sure that you've waited until the UDP applications of the wired hosts start sending their messages (every other second)?
I've disabled the second UDP app that sends packets to the other wired hosts and I can clearly see the UDP packets going through the router to the access point and to the wireless host, who replies with an ACK and an UDP reply per packet.

[Simón Windmuller]

Hi, thanks for your reply.

I checked and the authentication between the wireless host and the AP and the authentication is happening, my bad.

What is not happening is that the UDP packets sent from wired hosts 1 or 2 arriving at the wirelesshosts' UDP apps. You can see that if while simulating get into the wireless host 1 view where you can see the UDP apps and you can see the receive count equal to zero all the time. Thus, UDP packets aren't arriving in the wireless host and can't do any statistics then. 

After the authentication, all the communications between the AP and the Wireless host are beacons. 

Unless you tell me that I have to wait a whole lot. My sim is 400sec long.

But I followed the route from the wiredHost1 and at the accessPoint.Eth[1].mac which receives de UDP packets at the AP, the variable numDroppedNotForUs grows indefinitely. Which means that the packets are being dropped.

Is this behavior the same for you?

Or maybe I'm not understanding something correctly?

Thanks,

Simon.

--
You received this message because you are subscribed to a topic in the Google Groups "OMNeT++ Users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/omnetpp/zgNjwmzobcg/unsubscribe.
To unsubscribe from this group and all its topics, send an email to omnetpp+unsubscribe@googlegroups.com.
Visit this group at https://groups.google.com/group/omnetpp.
For more options, visit https://groups.google.com/d/optout.

[Wian Virgi]

Hai everybody..

Your througput meter in UDP not error? If not can you help me because in my simulation I can't found it... Know i can just used TCP.. Thank you...

To unsubscribe from this group and all its topics, 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.

--
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.

[Michael Kirsche]

Hi Simon,

I don't see this behavior at all.
Packets do get routed through tot he wireless host and he replies the packets via the UDP echo app and sends his own packets. There are no dropped packets (numDroppedNotForUs) at all.
Which INET version are you using?
I've tested it with the latest one from the Github repository without any changes to the INET source code or the omnetpp.ini scenario configuration.

Cheers,
Michael

To unsubscribe from this group and all its topics, send an email to omnetpp+u...@googlegroups.com.

[Simón Windmuller]

Hi Michael,

I tried with latest the INET package from the github as you said. Same thing. I'm attaching a video link to the post with a video capture.

https://drive.google.com/file/d/0B2G1O_NivyuxSlE1NDlnSmpHcW8/view?usp=sharing

Im using Omnet 5.0 160414-aa4629c, and INET 3.4.0 I think.

The Omnet.ini file:

[General]

network = WiredAndWirelessHostsWithAP

sim-time-limit = 400s

tkenv-plugin-path = ../../../etc/plugins

**.addDefaultRoutes = false

**.*Host*.numUdpApps = 3

**.*Host*.udpApp[0].typename = "UDPEchoApp"

**.*Host*.udpApp[0].localPort = 1000

**.*Host*.udpApp[*].typename = "UDPBasicApp"

**.wiredHost1.udpApp[1].destAddresses = "wirelessHost1"

**.wiredHost1.udpApp[2].destAddresses = "wiredHost2"

**.wiredHost2.udpApp[1].destAddresses = "wirelessHost1"

**.wiredHost2.udpApp[2].destAddresses = "wiredHost1"

**.wirelessHost1.udpApp[1].destAddresses = "wiredHost1"

**.wirelessHost1.udpApp[2].destAddresses = "wiredHost2"

**.*Host*.udpApp[1..].destPort = 1000

**.*Host*.udpApp[1..].messageLength = 100B

**.*Host*.udpApp[1..].sendInterval = 1s

**.*Host*.udpApp[1..].stopTime = 300s

**.initialZ = 0

I'd really appreciate any comments that you would have.

Thanks, 

Simon.

[Simón Windmuller]

Hi Michael, I checked again and somehow the sim was executing the other Inet example that I had before. So I'm going to backup my Inet folder and re-install the github package to see if it behaves differently. 

What version of Omnet are you using? It feels that the format of the functions in this Inet is different and get a lot of error of the type function not registered. But then again, maybe is because that I had both Inet packages in the workspace.

I will let you know tomorrow.

Thanks, 

Simon.

[Simón Windmuller]

I installed the Inet package and ran the example and I'm getting an error (attachment).

I can delete the condition hasVisualizer() from the NED file and it works but there are several similar errors happening, like it's not getting the right compound modules. Is this a configuration or compatibility error? It seems to be a difference in how the compound modules are named or added.

What do you think?

Simon.

On Wednesday, February 8, 2017 at 3:24:53 PM UTC-7, Simón Windmuller wrote:

[Michael Kirsche]

I am using the 5.1pre2 and 5.1pre3 versions of OMNET with the Github version of INET.
Packets go through the eth1 interface of the Access Point without problems.

I tried your scenario with OMNeT 5 and INET 3.4 under Windows and everything went fine too.
The numDroppedNotForUs is zero all the time, regardless of my set-up.

I am really a bit puzzled, did you change anything in the simulation setup (omnetpp.ini) or the rest of the INET code?

When do you a clean re-install of INET, does it work out of the box?

OMNeT 5 with INET 3.4
or
OMNeT 5.1pre2/3 with the Github version?

All set-ups worked for me, both under Linux and Windows.

[Michael Kirsche]

Here are two screen captures from the simulation running in OMNeT 5.0 with INET 3.4.

You can see that the packets are echoed at the wirelessHost1 and the numDroppedNotForUs is zero at the MAC...

[Simón Windmuller]

Yeah, It's pretty weird that I don't have the same thing. Can you paste your ini file?

I can see from your second screenshot that the Eth[1] promiscuous bit is set to true. Did you do anything in particular for that? You said that you are running the default config.

My ini:

[General]

network = WiredAndWirelessHostsWithAP2

sim-time-limit = 400s

tkenv-plugin-path = ../../../etc/plugins

**.vector-recording = true

**.scalar-recording = true

**.addDefaultRoutes = false

**.wiredHost1.numUdpApps = 3

**.wiredHost2.numUdpApps = 0

**.wirelessHost1.numUdpApps = 3

**.*Host*.udpApp[0].typename = "UDPEchoApp"

**.*Host*.udpApp[0].localPort = 1000

**.*Host*.udpApp[*].typename = "UDPBasicApp"

**.wiredHost1.udpApp[1].destAddresses = "wirelessHost1"

**.wiredHost1.udpApp[*].sendInterval = 0.865ms

**.wiredHost1.udpApp[*].startTime = 1s

**.wiredHost1.udpApp[2].destAddresses = "wiredHost2"

**.wiredHost2.udpApp[1].destAddresses = "wirelessHost1"

**.wiredHost2.udpApp[2].destAddresses = "wiredHost1"

**.wirelessHost1.udpApp[1].destAddresses = "wiredHost1"

**.wirelessHost1.udpApp[2].destAddresses = "wiredHost2"

**.*Host*.udpApp[1..].destPort = 1000

**.*Host*.udpApp[1..].messageLength = 100B

**.*Host*.udpApp[1..].sendInterval = 1s

**.*Host*.udpApp[1..].stopTime = 300s

**.initialZ = 0

**.router.eth[*].mac.promiscuous = true

**.wiredHost1.numPcapRecorders = 3

I just changed the sendInterval, tried to add promiscuous, which didn't work as you can see, and disabled the apps is wired host 2. But the rest is the same.

Thanks, 

Simon.

--

You received this message because you are subscribed to a topic in the Google Groups "OMNeT++ Users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/omnetpp/zgNjwmzobcg/unsubscribe.

To unsubscribe from this group and all its topics, send an email to omnetpp+unsubscribe@googlegroups.com.

[Simón Windmuller]

I just realized that it was the router promiscuous mode that I was changing. So I'm trying to change the promiscuous bit in the access point and won't let me.

Something like **.accessPoint.Eth[*].mac.promiscuous = true

But says it doesn't match any parameters, although we can see it in the simulation.

Simon.

[Michael Kirsche]

Like I said, I tested the out-of-the-box configuration from Github and the INET 3.4 package:

[General]
network = WiredAndWirelessHostsWithAP

sim-time-limit = 400s
tkenv-plugin-path = ../../../etc/plugins

**.addDefaultRoutes = false

**.*Host*.numUdpApps = 3

**.*Host*.udpApp[0].typename = "UDPEchoApp"
**.*Host*.udpApp[0].localPort = 1000

**.*Host*.udpApp[*].typename = "UDPBasicApp"
**.wiredHost1.udpApp[1].destAddresses = "wirelessHost1"

**.wiredHost1.udpApp[2].destAddresses = "wiredHost2"
**.wiredHost2.udpApp[1].destAddresses = "wirelessHost1"
**.wiredHost2.udpApp[2].destAddresses = "wiredHost1"
**.wirelessHost1.udpApp[1].destAddresses = "wiredHost1"
**.wirelessHost1.udpApp[2].destAddresses = "wiredHost2"
**.*Host*.udpApp[1..].destPort = 1000
**.*Host*.udpApp[1..].messageLength = 100B
**.*Host*.udpApp[1..].sendInterval = 1s
**.*Host*.udpApp[1..].stopTime = 300s

**.initialZ = 0

You probably misconfigured something in your omnetpp.ini and/or NED network definition.

To unsubscribe from this group and all its topics, send an email to omnetpp+u...@googlegroups.com.

[Simón Windmuller]

Well, I guess I'll have to re-install from scratch and test.

So, OMNeT 5.0 downloaded from the omnet.org website? 

And Inet downloaded from the git as .zip or imported from the git directly in OMNeT? Or installed as suggested from OMNeT the first time that it opens a new workspace?

If you install from the .zip from the git, do you follow the exact steps as in INSTALL.txt? For example, the fact of not copying the project into the workspace, etc.

I'm trying to emulate with precision your installation. Sorry for so many questions.

Thanks,

Simon.

[Michael Kirsche]

It really doesn't matter for INET, both the original 3.4 zip or the cloned repository from Github work.
Copying the project into the workspace is also not the problem.
You can simply rename your current INET project and then import a fresh installation of either the latest release (import via existing project - archive file) or the current Github version (import via Git -> clone...).

Nothing complicated about it, two minutes for the download and another two minutes for the import and the compilation process of INET with the wireless examples features enabled. That's it.

[Simón Windmuller]

Ok, I installed Omnet in a new directory, opened a new workspace and used the git - clone way. Then import existing projects from the new git one it was obtained from the git.

Then I tried to run the example and got:

<!> Error during startup: Cannot load library 'C:\omnetpp-5.0_new\git\inet\src\\/libinet.dll': The specified module could not be found.

What should I do?

I'm using windows 10 by the way, don't know if that matters.

Simon.

--

You received this message because you are subscribed to a topic in the Google Groups "OMNeT++ Users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/omnetpp/zgNjwmzobcg/unsubscribe.

To unsubscribe from this group and all its topics, send an email to omnetpp+unsubscribe@googlegroups.com.

[Simón Windmuller]

Now I'm trying just importing it after extracting with winrar since if I try to import from the .zip it creates all the parent folders as subfolders and its a mess. Was having some troubles and then realized that was importing from a folder out of the workspace folder. I'm working on that. Will let you know.

On Thursday, February 9, 2017 at 2:17:40 PM UTC-7, Simón Windmuller wrote:

Ok, I installed Omnet in a new directory, opened a new workspace and used the git - clone way. Then import existing projects from the new git one it was obtained from the git.

Then I tried to run the example and got:

<!> Error during startup: Cannot load library 'C:\omnetpp-5.0_new\git\inet\src\\/libinet.dll': The specified module could not be found.

What should I do?

I'm using windows 10 by the way, don't know if that matters.

Simon.

[Simón Windmuller]

I installed INET 3.4.0 by using the help -> install simulation model menu in OMNeT++ 5.0. By doing it manually by adding a project or using the GIT gave me errors all the time. 

Now the example works as it works for you, what a relief! As you say, packets are echoed by UDPApp[0] and some other received by UDPApp[1] and UDPApp[2]. 

Thank you for all the help my friend!!!

Now I just need to acquire throughput and end-to-end delay as the throughput example and I'm good to go with the research. Do you happen to know why the end-to-end delay is zero in the throughput example?

Cheers,

Simon.

 

To unsubscribe from this group and all its topics, send an email to omnetpp+unsubscribe@googlegroups.com.

[Michael Kirsche]

Importing via Git clones the project, afterwards you can compile it and it works out of the box.
Which tool did you use for the screen capture?? Maybe I'll create a similar capture just to show the basic steps...

As for the throughput example, you mean the endToEndDelay values of the

Throughput.cliHost[0].cli

The End-to-End delay here is a NED parameter of the EtherAppCli:

@statistic[endToEndDelay](title="end-to-end delay"; source="messageAge(rcvdPk)"; unit=s; record=histogram,vector; interpolationmode=none);

It's statistical source is the message age of received packets.
The throughput examples use the EtherAppCli as a message/traffic generator and the WirelessAPWithSink as a receiver, whereas the sink silently discards all packages and only counts the number of received packets.

If you (just an example) restructure the configuration, so that a host with an EtherAppCli module as the application module receives the packets (adjust the destination address of the traffic generator accordingly), then the end-to-end delay will be recorded at the receiver.
There are multiple application modules that record all kinds of statistics out-of-the-box, look for the source code under the inet/applications folder, for almost every protocol (Ethernet, TCP, UDP, IP), there will be traffic generators, sources and sinks and most of them count things like the end-to-end delay.

To unsubscribe from this group and all its topics, send an email to omnetpp+u...@googlegroups.com.

[Simón Windmuller]

Hi Mike, 

Thanks for all the explanations!

To record I used the game bar, it's suppose to be used only for games but it works for any single window. You just focus on the window that you want to record and press win-g and the game bar will appear and ask you if it is a game, you say yes (white lie) and start recording. Keep in mind that if you want to record audio yo have to go to the options of the game bar and there is an option to record audio next time you record a video. So you exit and call the game bar again and when you record it will record audio. Sometimes you need to toggle the mic on in the recording bar.

This should work, I don't remember if you need the Xbox app installed for that also o if it comes pre installed with Windows 10.

Thanks again, 

Simon.

To unsubscribe from this group and all its topics, send an email to omnetpp+unsubscribe@googlegroups.com.

[Michael Kirsche]

Hi Simon,

thanks for the game bar explanation, didn't know about this nice feature. Will use it in the future for easier demos/howtos.

Cheers,
Michael

[Simón Windmuller]

Yes, was as amazed when I discovered that Windows had something like that included. The only downside is that it only records one window at the time.

Simon.

To unsubscribe from this group and all its topics, send an email to omnetpp+unsubscribe@googlegroups.com.

[Simón Windmuller]

Hi Michael, 

I basically want to measure the throughput and delay at the wireless node for packets coming from one of the wired nodes, lets say that I turn off wiredHost1 and configure wiredHost2 to send packets every certain amount of time to wirelessHost2. Regarding the throughput and delay measurement, when you say modify the configuration, do you mean adding a EtherAppCli at the wiredHost2 and an a Sink at the wirelessHost1? This would mean modifiying the inet.node which I don't see how doing so since both wireless and wired host are based in the same compound module. 

The other way that I could understand what you mean is that you mean changing the ini configuration or adding @statistics in the apps in the inet.node.

What would be the best way to do so?

My end means are simulating a connection from a wired PC running a LabVIEW application that sends data to a wireless laptop with a remote LabVIEW application, and doing an analysis of throughput and delay comparing the simulation results with some captures done with Wireshark. There are some variables about the routed connection that I cannot control but I'm starting with the simulation to see if the system behaves in a similar way.

Thanks, 

Simon.

[Simón Windmuller]

I added the line:

@statistic[endToEndDelay](title="end-to-end delay"; source="messageAge(rcvdPk)"; unit=s; record=histogram,vector; interpolationmode=none);

to the UDPBasicApp.ned to get the end to end delay.

Is that a good way to go? I'm modifiying a predefined basic module, I mean, it works but I'm just asking if there is a less intrusive method.

So, I works. But is this delay, which is the message age, is measured from the moment is sent to when it's received to the other end, or is it measured since is sent then echoed from the end and comes back to the sender? What I'm not sure is that if the echo app replies with the same packet and the message age adds up or it's a message copy and the message age is reset or has nothing to do with the sent message age.

Thanks, 

Simon.

[Alfonso Ariza Quintana]

From the creation of the packet, if the packet is returned, the destination node records the end-to-end source-destination delay and the source, records the source-destination-source end-to-end delay.

--

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.

[Michael Kirsche]

Of course you can alter the predefined modules.
Just because the initial developer did not add every possible statistic doesn't mean that you should not add them.
Apart from that, you can always add @statistic in NED files, if the signal sources (here messageAge) are already being processed in the relevant source code, then it is the least obtrusive way to add statistic collection via the signal-slot mechanism.
So everything fine here :)

[Simón Windmuller]

Thank you Alfonso, I took a look at both end-to-end delays and the values for one way and round trip make sense. 

Simon.

[Simón Windmuller]

Hey Michael, 

I had the idea that what I was doing was ok, but was just making sure. Nevertheless never occurred that setting an @statistic in an NED would work, but I guess if all the code is included so at the end is all one code. 

Thanks for the confirmation!

Simon. 

[Simón Windmuller]

Actually I take that back. I set up the simulation to last 60s and set the wired2 host to send packets every 1.2ms and the wireless1 host to send packets every 60s (the sim time) so my measurements are not so affected by the wireless host and since I only want to measure the transmission throughput and end-to-end delay from the wired host 2 to the wireless host.

So I took a look to the histograms for end-to-end delays and for wiredHost2.udpApp[1] the packet count is 38985 which are the packets that are sent and come back; but for the wirelessHost1.udpApp[2] the count is 1, which is the packet sent at second 60, so those are not the packets measured from source to destination but the one sent and come back to the wireless hosts. The rest of the histograms are in zero, since I only configured the two apps that are to communicate.

Another comment that I have is that if I don't configure the udp apps in pairs they wont communicate, for example:

**.wiredHost2.udpApp[1].destAddresses = "wirelessHost1"

**.wirelessHost1.udpApp[2].destAddresses = "wiredHost2"

If I comment one of the two the other will not send packets. Is the a way to configure them just to send one way? That is why I do that workaround of setting one of them to send every "sim-time" because I cannot set it up at 0 or -1 for it not to send at all.

Thanks, 

Simon. 

On Tuesday, February 14, 2017 at 1:45:37 AM UTC-7, Alfonso Ariza Quintana wrote:

[Michael Kirsche]

Hi Simon,

which type of UDP apps are you using? Depending on the type, it might echo the packet or not...
You can add your omnetpp.ini so that a clearer picture of what you are doing might emerge...

Best,
Michael

[Simón Windmuller]

Hi Michael, 

Using the stock configuration, UDPEchoApp for the App "0"and UDPBasicApp for 1 and 2.

Maybe I'm not understanding how they work, I only have two of them with destAddress:

**.wiredHost2.udpApp[1].destAddresses = "wirelessHost1"

**.wirelessHost1.udpApp[2].destAddresses = "wiredHost2"

And both of then send packets and receive the equal ammount of packets back. Even if I change their sendInterval:

**.wirelessHost1.udpApp[1..].sendInterval = 60s

 **.*Host*.udpApp[1..].sendInterval = ${1.2,1.1,1,0.9,0.85,0.8,0.7,0.6,0.5,0.3,0.1,0.07,0.05,0.01,0.005,0.001}ms

So the wired app 1 sends 1 packet and may or not receive it back depending on the other app's send interval. The wireless one sends a certain amount of packets and receives a different amount depending on the amount that the network is able to process.

Throughput at wiredHost2.udpApp[1] is the actual packets that are actually able to be sent right? Because for example if I set the sendInterval to 0.001ms for a simtime of 2.7sec 1700000 packets are sent but only around 1100 are received.

So if I measure end to end delay in wiredHost2.udpApp[1], is that the roundtrip delay or the time that takes from wiredHost2 to wirelessHost1?

Here's my ini:

[General]

network = WiredAndWirelessHostsWithAP2

sim-time-limit = 2.7s

tkenv-plugin-path = ../../../etc/plugins

**.addDefaultRoutes = false

#UDP HOST APPS ****************

#**.*Host*.numUdpApps = 3

**.wiredHost1.numUdpApps = 3

**.wiredHost2.numUdpApps = 3

**.wirelessHost1.numUdpApps = 3

#Echo App ************

**.*Host*.udpApp[0].typename = "UDPEchoApp"

**.*Host*.udpApp[0].localPort = 1000

# UDP Apps ****************

**.*Host*.udpApp[*].typename = "UDPBasicApp"

# Destinations ****************

# wiredhost1 --------------- Killed

#**.wiredHost1.udpApp[1].destAddresses = "wirelessHost1"

#**.wiredHost1.udpApp[2].destAddresses = "wiredHost2"

# wired host 2 --------------

**.wiredHost2.udpApp[1].destAddresses = "wirelessHost1"

#**.wiredHost2.udpApp[2].destAddresses = "wiredHost1"

# wirless host 1 ---------------

#**.wirelessHost1.udpApp[1].destAddresses = "wiredHost1"

**.wirelessHost1.udpApp[2].destAddresses = "wiredHost2"

# Configs for UDP apps > 0

**.wirelessHost1.udpApp[1..].sendInterval = 60s

**.*Host*.udpApp[*].startTime = 1s

**.*Host*.udpApp[1..].destPort = 1000

**.*Host*.udpApp[1..].messageLength = 1000B

**.*Host*.udpApp[1..].sendInterval = ${1.2,1.1,1,0.9,0.85,0.8,0.7,0.6,0.5,0.3,0.1,0.07,0.05,0.01,0.005,0.001}ms

#**.*Host*.udpApp[1..].stopTime = 300s

# Z possition

**.initialZ = 0

#pCap Recorders

**.wirelessHost1.numPcapRecorders = 1

**.wirelessHost1.pcapRecorder[*].moduleNamePatterns = "udpApp[*]"

Of course I added to the UDPBasicApp the line:

     @statistic[endToEndDelay](title="end-to-end delay"; source="messageAge(rcvdPk)"; unit=s; record=histogram,vector; interpolationmode=none);

And changed the record=last to record=histogram,vector to the throughput line in the same udpBasicApp.

The Echo app does not have those statistics so I'm not measuring those.

Should I deconfigure (delete) the Echo Apps to see how the results change?

Thanks,

Simon.

[Simón Windmuller]

Any of you guys would know how to generate a packet size every time a packet is generated by using a normal or other distribution?

If I do it in the .ini file the packet size is generated at the start and stays the same throughout the whole simulation and even if I re-run is the same.

for example:

**.udpApp[*].messageLength = weibull(2.5B, 250B) 

Always gives me a packet size of 2B, every time a packet is sent and every time I run is the same.

Thanks,

Simon.

[Michael Kirsche]

Maybe you misinterpret the functionality of random number streams?!?
Weibull and other distribution functions produce a certain stream of random numbers within the given limits.
Using non-uniform distributions works just like using the regular random number generator (which produces uniform distributions): a seed value is used to generate a stream of random variables. As long as the seed stays the same, the stream of random variables is always the same (or reproducibility of simulations wouldn't be possible).
If you do not configure anything special, the seed value for a specific run will hence always stay the same and the stream of random numbers is also the same.
The distribution may generate a stream of variables, but you probably do not do a parameter study over various runs, hence the value (maybe the first) is always the same.
Take a look at the OMNeT manual regarding parameter studies: https://omnetpp.org/doc/omnetpp/manual/#sec:config-sim:parameter-studies
Another idea might be to change the seed value every time your simulation starts...
Check https://omnetpp.org/doc/omnetpp/manual/#sec:config-sim:rng-config and https://omnetpp.org/doc/omnetpp/manual/#sec:config-sim:repeating-runs-with-different-seeds

[Simón Windmuller]

Hi, going back to the actual simulation, I noticed that the capture that I did in the actual lab setup is all TCP protocol. So now I want to change all UDP apps for TCP apps. But I don't have a similar app as the UDPBasicApp but for TCP, I tried to use the TCPBasicClientApp and the TCPEchoApp but are not getting end-to-end delays in the tcpApp in the wired host. They behave a little bit differently. 

The TCPApp in the wiredHost2 does send requests to the wirelessHost1 and they are echoed back to the wiredHost2, so at least that part works. I do get throughput measurement in the wiredHost2 but no End-to-End delay anywhere.

Any tips?

My ini:

[General]

network = WiredAndWirelessHostsWithAP3

sim-time-limit = 2.7s

tkenv-plugin-path = ../../../etc/plugins

**.addDefaultRoutes = false

#TCP HOST APPS ****************

#**.*Host*.numTcpApps = 3

#**.wiredHost1.numTcpApps = 0

**.wiredHost2.numTcpApps = 3

**.wirelessHost1.numTcpApps = 3

#Echo App ************

**.*Host*.tcpApp[0].typename = "TCPEchoApp"

**.*Host*.tcpApp[0].localPort = 1000

# TCP Apps ****************

**.*Host*.tcpApp[*].typename = "TCPBasicClientApp"

**.wiredHost2.tcpApp[2].connectAddress = "wirelessHost1"

**.wirelessHost1.tcpApp[0].connectAddress = "wiredHost2.tcpApp[1]"

**.wiredHost2.tcpApp[0].typename = "TCPSinkApp"

# Destinations ****************

# wiredhost1 --------------- Killed

#**.wiredHost1.tcpApp[1].destAddresses = "wirelessHost1"

#**.wiredHost1.tcpApp[2].destAddresses = "wiredHost2"

# wired host 2 --------------

#**.wiredHost2.tcpApp[1].destAddresses = "wirelessHost1"

#**.wiredHost2.tcpApp[2].destAddresses = "wiredHost1"

# wirless host 1 --------------- 

#**.wirelessHost1.tcpApp[1].destAddresses = "wiredHost1"

#**.wirelessHost1.tcpApp[2].destAddresses = "wiredHost2"

# Configs for TCP apps > 0

#**.wirelessHost1.tcpApp[1..].sendInterval = 60s

**.*Host*.tcpApp[*].startTime = 1s

#**.*Host*.tcpApp[1..].destPort = 1000

#**.*Host*.tcpApp[1..].messageLength = 1000B

#**.*Host*.tcpApp[1..].stopTime = 300s

# Z possition

**.initialZ = 0

#pCap Recorders

**.*Host*.numPcapRecorders = 5

**.*Host*.pcapRecorder[*].moduleNamePatterns = "tcpApp[*]"

**.*Host*.tcpApp[1..].requestLength = (weibull(22.4708, 206.85))*1B

**.*Host*.tcpApp[1..].replyLength = (weibull(22.4708, 206.85))*1B

**.*Host*.tcpApp[1..].thinkTime = ${1.2,1.1,1,0.9,0.85,0.8,0.7,0.6,0.5,0.3,0.1,0.07,0.05,0.01,0.005,0.001}ms

**.*Host*.tcpApp[1..].idleInterval = 0s  

Thanks, 

Simon.

[Simón Windmuller]

Regarding the random functions, I don't quite understand yet, I've researched how to generate a random number, I have set the weibull distribution for the message length and after the sim is set up the messageLength cPar is set as weibull(22.4708, 206.85,1))*1B at the udpApp as I set it up in the ini file, so it should be being generated for every message. But every time a message is generated, the size is 22B (the integer part). 

I haven't found a way for that variable to be a random number for every message.

Can you elaborate on this please? I checked the documentation that you mentioned and tried setting Rngs and fixing seeds to see if the number changed but it's not changing.

Thanks,

Simon. 

On Monday, February 20, 2017 at 6:59:59 AM UTC-7, Michael Kirsche wrote:

[Michael Kirsche]

Hi Simon,

why didn't you use the "TCPEchoApp"?
It does provide a simple way to echo back packets and count the send packets and count the end-to-end delay based on the "age" of the arrived packet.
Check the examples (simple code search), where TCPEchoApp or other TCP apps are used to find out how to configure and use them.

Best,
Michael

[Michael Kirsche]

Check for example the TicTocExample number 7.
A delay time is used there, an exponential distribution is set via omnetpp.ini and a random value from this distribution is used in the source code to delay the messages.
Once again, the distribution function does generate a stream of random numbers. Each time you access the function in the source code, a random value is chosen from the stream. If you repeat the simulation with the same settings (same run number etc.), the identical stream of random numbers is generated again. For TicToc7, each delay is hence different, but re-runs produce the same random delays (e.g., first delay 2.39483, second 3.12321, and so on).

Let's take a look at another example, INET got plenty of working examples...
I choose (randomly :) ) the INET -> Broadcast example (which simulates the network inet.examples.inet.broadcast.UDPBroadcastNetwork).
There I simply take the messageLength parameter of the UDPBasicApp and change it from 100B to maybe exponential(100B) and run the simulation.
When I check on the message lengths of the encapsulated UDP Packets (totalLengthField) for UDPBasicAppData-0, I get 87 Bytes, for UDPBasicAppData-1, I get 133 Bytes and so on.
The totalLengthField of the IPv4Datagram is also changing (since it computes the message lengths of all encapsulated messages).

So a random message length for each and every message... and if I re-run the simulation with the same run-number and parameters, the observed message lengths are the same random values for each UDPBasicAppData-xy packet.

I hope that helps.

Regards,
Michael

[Simón Windmuller]

Hi Michael, thanks for the tip about checking the broadcast example, I know whats going on, kind of. Something is going on with the weibull function, or I'm using it wrong. If I use an exponential function instead it does generate different different size UDPBasicAppDatas. I replaced the messageLength = (weibull(22.4708, 206.85,1))*1B which would always give me a 22Byte size for exponential(22.4708B) and it does generate different sizes. Maybe I'm using the Weibull function in a wrong way? I've looked at the documentation about the function and I've found it a little bit vague. I tried several functions that I was able to fit with EasyFit to my data and ended up using gamma_d which does give me different data sizes; I'm going to be using that one, don't know whats wrong with Weibull. 

Regarding the TCP apps, I did change the UDPEchoApp for the TCPEchoApp counterpart, but as you can see there are another two apps at each end that are the ones that generate packets, I tried changing those UDPBasicApps for TCPBasicClientApps with similar @statistics in it's simple module but don't get end-to-end delay or throughput, I don't know if these apps behave differently. As I would think they should like generate a packet in the wiredHost2 send it to the wirelessHost1 which echoes it back, and I just checked and it does exactly that and packets are received back in wiredHost2.tcpApp[2]. It's jus that they behave differently, they open and close the connection as it say in the documentation but although I can see packets received in the statistics it doesn't give me throughput or delay. Would it have to do with the think times or the idle intervals? Or other configurations? Or should I use different apps or only Echo apps (is that what you are suggesting?).

Thanks again,

Simon.

--

You received this message because you are subscribed to a topic in the Google Groups "OMNeT++ Users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/omnetpp/zgNjwmzobcg/unsubscribe.

To unsubscribe from this group and all its topics, send an email to omnetpp+unsubscribe@googlegroups.com.

[Michael Kirsche]

Hi Simon,

I am not sure that Weibull is the function that you should use.
Judging from the Wikipedia article (https://en.wikipedia.org/wiki/Weibull_distribution), it has quite different application areas, where you define a scale and a shape of a distribution curve with the parameters... but then again, I am not an expert on distribution functions.

As for the TCPEchoApp, not 100% sure why it does work.
Looking through the INET examples, the nclient examples does produce the end-to-end delays that you want. It uses a TelnetApp and a TCPGenericSrvApp in the configuration.

Regards,
Michael

To unsubscribe from this group and all its topics, send an email to omnetpp+u...@googlegroups.com.

[Simón Windmuller]

I finally used a gamma_d distribution as the normal distribution would give me negative values once in a while and give me a runtime error as negative packet sizes are of course not allowed.

Regarding the TCP apps I ended up configuring the wiredHost2 node with a TCPGerericClientApp and the wirelessHost1 with a TCPGenericSrvApp. But the main reason that the end-to-end delay was recorded as zero all the time was that the dataTransferMode was set to the default "bytecount" in contrary of "object". That I found out looking at the nclients/nclients2 example. Thanks for that tip Michael.

Simon.

[Simón Windmuller]

Hello friends, I'm back. 

So I have TCP simulation running and all, and running it for several values of thinkTime and I'm getting throughput and delay curves all good and pretty. But I'm checking the results and comparing them with what I captured in a similar real life situation and the results are not similar at all. 

In the capture I have a mean throughput of 1.34Mbps and for the simulation around 480000bps (0.48Mbps). Do you have an idea which simulation parameters I could change to raise that value? I kind of think that a value of 500 kilo bits per second for a connection from a wired computer to a wireless computer through a router and an access point is kind of low. 

Or is it right and maybe I'm mistakenly analyzing analyzing my pcapng file?

I know that real life situations may differ a lot with the simulation but I would expect the simulation to have higher throughput results than the real life capture.

What do you think?

Thanks,

Simon.

[Michael Kirsche]

Hi Simon,

Did you check (for example) that the generated traffic is the same when compared to your real life scenario?
Depending on the number of packets generated per second, a higher throughput might not be possible...

Which parameters did you set in comparison to your real life scenario?

Cheers,
Michael

[Simón Windmuller]

I cannot control the real life scenario, I just open a remote connection using LabView to a specific port and at the same time start capturing traffic from and to the remote PC using Wireshark filtering the specific IPs and ports to make sure that only traffic from the connection is captured and not from other applications.

In the Omnet part I traid changing several parameters likes numRequestsPerSession and the results dont change. I just know that the capture have 1 session as the stream number is the same for all packets captured.

I tried chaging the IdleInterval and the reconnectInterval and also have no change in the thoughput. 

The only parameter that affects the throughput is the thinkTime and the request and reply lenghs.

The request and reply lengths I fixed to a gamma distribution that I got from the packet sizes I got from the capture. The thinkTime I do a sweep from 0.9ms to 3000ms (16 runs with different times), the highest value of throughput I got is around 480kbps for thinktime values smaller that 0.05ms but doesn't go higher than that. The reply delay I set to 0s.

When you ask if I have taken a look to the generated traffic, isn't that the throughput? I check .wiredHost2.tcpApp[0] for throughput.mean, that should be around the mean bits/sec for the simulation and I'm trying to match it to the throughput from the capture which is 1.35Mbps but I'm only getting arround 500kbps in the simulation. With the udp sim I used to get like 5Mbps troughputs, shouldn't it be the other way around? Or maybe I'm comparing apples with pears? Maybe my real life link has several connections at the same time? But I don't see why since my stream index is 0 for all my captured packets.

Thanks, 

Simon.

[Michael Kirsche]

If you cannot control the real-life scenario, how do you set the parameters to a similar value?
When you do not control the traffic generator in the real life scenario, how do you want to generate a similar amount of traffic in the simulation?

Also consider that throughput is measured on the transport layer (or even below), while the application goodput (throughput minus all retransmissions, header overhead, etc.) might often be a more appropriate value to compare.

As for the difference in UDP and TCP, surely you get a higher throughput with UDP, since the sender just keeps sending without waiting for acknowledgements etc. That's the usual case when you use unacknowledged transport layer protocols compared to acknowledged ones.

Take a look at the documentation inside the TCPBasicClientApp.ned and the TCPGenericSrvApp.ned to understand how the parameters work.
The client requests a reply from the server, who just replies with the requested replyLength. Changing the replyLength will of course enlarge or shrink the throughput, as the sent traffic will differ.
In your real life scenario, what type of traffic is actually generated? Try to find out more about your traffic source and which TCP app type is the most accurate representation.
Also, dataTransferMode has a third option, bytestream, which "which transmits real bytes of messages". Did you try this option too?

[Simón Windmuller]

-I know what you mean, but that happens when you don't have control over your application. And that's why I'm "triying" to tweak the simulation to match one of the simulations mean to the throughput to see in which part of the curve I am.

I downloaded the Steelcentral packet analyzer which gives me some extra information in an easier way, and I noticed that the 1.35Mbps counts all transmissions requests and responses (in this case ACKs and PSH-ACKs) and I was comparing with the simulation in OMNET to a one way throughput (how dumb of me comparing apples with half apples), so I ran the simulation again and got for example thinkTime=0.005 and got a throughput of 360Kbps in either way, so symetric TP. But in the captured data the TP is not symetric, like 1.17Mbps in one way vs 0.26Mbps in the other way. So only with that I feel that something in the simulation is not resembling the real scenario. And eve if you add both up and down TP for the simulation, it doesn't reach the 1.35 total TP of the capture.

About the TP vs GoodPut, if I'm measuring the TP in the tcpApp[0]s am I measuring the GoodPut as you mention? How would I measure the TP in the wire? Which is what I feel that the pcapng is giving me.

In regrads of the traffic generated, in my capture, there are only ACKs and PSH-ACKs, almost no retransmissions (2 out of 100k samples). I used a ip filter and a tcp.port filter when I captured. Maybe I made a mistake and I'm only seeing part of the information?

I tried to use  bytestream for the dataTransferMode but gives me an error:

undisposed object: (inet::GenericAppMsg) WiredAndWirelessHostsWithAP3.wiredHost2.tcp.data -- check module destructor

Simon.

[Michael Kirsche]

The TCP apps calculate the message length at the arrival of the message. Maybe this is indeed smaller when compared to your captured messages...

Your real-life application does have an asymmetric traffic pattern, like 0.26 Mbps of requests and 1.17 Mbps responses?
What type of traffic is it? HTTP?
There might be other applications/traffic generators that fit better in this case.

How do you calculate the throughout in OMNeT? With an additional statistic or do you calculate it manually from the collected statistics?

Regarding your error message, you use a wired and wireless scenario... is this the same for your real-life capture or is this a pure wired connection?

[Simón Windmuller]

All the packets in the capture are marked as TCP protocol, I wonder if I captured in a wrong way. What kind of applications would you suggest?

I calculate throughput and end to end delay in each tcpApp using @statistics:

@statistic[endToEndDelay](title="end-to-end delay"; source="messageAge(rcvdPk)"; unit=s; record=histogram,vector; interpolationmode=none);

@statistic[throughput](title="throughput"; unit=bps; source="throughput(rcvdPk)"; record=histogram,vector); 

For TCPGenericSrvApp and TCPBasicClientApp.

The real life scenario is a wired PC running my LabView App, with VI server set to port 8000, this PC connected to the university's wired network. And a laptop with Labview running a remote VI from the VI server set in the other PC, this laptop connected to the university's Wi-Fi network and running Wireshark capturing packets coming from and going to the wired PC's IP address at tcp port 8000.

Does any of this sound wrong? I mean, when I start the Wireshark with those IP and port filters I don't see any packets being captured until I start the remote connection from Labview to Labview. And if I do a quick review of random packets in the capture I can see Labview data.

Simon.

[Michael Kirsche]

`No, scenario does not sound wrong, I was merely curious :)
Wireshark would also be my first choice for packet capture. There are other tools for performance measurements. I think NetPerfMeter has been used by the SCTP developers to compare the performance of SCTP vs TCP. There's also an example in INET, but I haven't worked with that, so no idea about how to use it.

Your simulation throughput does not go over a certain number, right? Do the captures throughput values make sense when you calculate the raw (possible) throughput for a simple connection based on your traffic generator settings in OMNeT?

[Simón Windmuller]

Hi all, I have been away from this discussion for some weeks, I was working on some other part of my thesis which was related to matlab. But I'm back to the Omnet simulation and I'm trying to match the Throughput of the Omnet simulation top the throughput obtained in my Wireshark captures, as I mentioned before.

Before I went MIA I was working on finding a way of rising the TP from 500Kbps to arround 1.29Mbps which is the TP that Wireshark is giving me as overall TP. For that I tried modifying various variables in my omnet.ini file; the only one that seems to raise the TP is the requestLength which I I'm modeling to a gamma distribution based on the packet sizes of my wireshark capture. So I used:

**.wiredHost2.tcpApp[0].requestLength = (gamma_d(4.73,32.993)*1B)    Which gives a mean size of 150Bytes. 

And if I run the simulation with that I get a TP at most of 420Kbps (Wireshark gives me 1.29Mbps for that mean request size).

But if I raise the request size mean to around 700Bytes (instead of 150Bytes) I get the desired TP of 1.29Mbps.

So, my question is, do you have any idea why this big difference? What would differ between a real scenario and a simulation to behave so differently? I know that a lot of things can differ, but I asking configuration wise, may I be missing other layer configurations, header sizes, other layers or layer types in the simulation or other things?

I appreciate all the ideas that you could have.

Thanks,

Simon.

[Michael Kirsche]

Hi Simon,

what's the throughput result when you take a constant request length of 150 Bytes and 700 Bytes instead of the gamma distribution?

Cheers,
Michael

[Simón Windmuller]

Hey Michael,

I haven't tried with 150 but I did with 700 and the throughput is similar when using 700B constant or using a gamma distribution equivalent to a normal with 700B mean.

Thanks,

Simon.

--

You received this message because you are subscribed to a topic in the Google Groups "OMNeT++ Users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/omnetpp/zgNjwmzobcg/unsubscribe.

To unsubscribe from this group and all its topics, send an email to omnetpp+unsubscribe@googlegroups.com.

[Michael Kirsche]

Hi Simon,

I am at a loss here. If both set-ups (simulation and real network) use the same protocols, similar packet generation times (traffic generation) and same packet sizes, then the throughput should be pretty similar.
How do you calculate the real network's throughput? By hand? Do you calculate the goodput (only payload of the application packets) or the throughout (headers of underlying protocols included)?
Any parts that might be included in the real network's calculation that are not included in the simulation could maybe differ the outcomes.
How much should the throughput / goodput be in a simple calculation (given the packet generation rate and the packet / payload size)?

Cheers,
Michael

[Simón Windmuller]

Hi Michael, 

Yesterday I noticed that in my simulation there was statistics called bits/sec sent and bits/sec rcvd which are measured in the Eth[*] and the values resemble pretty much what Wireshark reports as overall bits/sec. 

So maybe I was looking / measuring in the wrong spot of my sim. Throughput is measured in the apps (app layer) and Wireshark takes into consideration other encapsulations for TCP, IP and Ethernet. 

I think that was the problem, if I measure at the apps all the protocol encapsulations are dropped, thus the measurements are lower compared to a physical capture.

Let me know what you think. 

Thanks, 

Simon.

[Michael Kirsche]

Hi Simon,

that seems to be the case.
If your simulation measures the throughput on the application layer, all the lower layer overhead (additional headers and footers) will be left out while your Wireshark measurement captures the layer 2 traffic, including Ethernet, IP and TCP headers/footers.

So if the simulation measurements from the Ethernet layer in OMNeT are similar to what you expect from the real network, than everything's fine :)

Best,
Michael

To unsubscribe from this group and all its topics, send an email to omnetpp+u...@googlegroups.com.