INET, throughput measure

[Stefano]

Hello everybody,

I need to measure network throughput within a multi-hop wireless
network. Right now, I'm testing my network with fixed-size file
transfers between a central node (TCPSinkApp) and many peripheral AP
(TCPSessionApp) which generate traffic at tcp level.
The problem is that I want to measure the actual throughput
(application level) of my file transfer in a simple way. Is there
something integrated into TCPSessionApp or do I need some other block?
I've seen ThruputMeter, but it lacks of documentation, can you point
me to some example?

Thank you.

[Stefano]

Ok, just to be sure and give a bump to the thread: does anybody know a
simple method to measure throughput when using TCPSessionApp/
TCPSinkApp?

S

[Pinto Pinto]

Hi,
you should add the ThruputMeter module, which will measure the throughput in the application level. In order to do that, you should add 2 ThruputMeter modules between the IP and the TCP, one for each direction of the packets (ip-->TCP : incoming throughput, TCP-->IP outgoing throughput).

Hope this helps
bye
pintoX

--
You received this message because you are subscribed to the Google Groups "omnetpp" group.
To post to this group, send email to omn...@googlegroups.com.
To unsubscribe from this group, send email to omnetpp+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/omnetpp?hl=en.

[Stefano]

Ok, thanks. Now I've got another question :)

Is there any chance you know how I can look at the throughput values
after the simulation? I am running my simulation in express mode, and
the thruput vector (cOutVector) keeps track of the throughput only if
I keep its window open. If I run my simulation, and at the end I try
to search for the thruput values, I cannot find them.

Since I measure the throughput between any two end points in my
network, is there any way I can run it in express mode, keep track of
the throughput with thruputMeter, and, at the end, look at its
vectors?

Thanks,

S

> > omnetpp+u...@googlegroups.com<omnetpp%2Bunsu...@googlegroups.com >
> > .

[Pinto Pinto]

Hi,
you get the throughput results like in any other measurement.
You open the General.anf file, you select the input General-0.vec (or any other in the results folder) and you go to the tab "browse data" and there in the vectors tab you will have the results for all kinds of measurements including the throughputmeter

BR
pintoX

To unsubscribe from this group, send email to omnetpp+u...@googlegroups.com.

[Frank]

Hey,

I'm also interested to measure throughput in a mobile ad hoc network.
Therefore I added thruput-meters to the mobileadhocmanethosts of the
inet-module, as described by Pinto.

But as of my point, the issue with setting a TCP CBR is still
existing!? Do I have to set the amount of data to transfer to a 'very
high' value to measure the thruput? What other options do I have?

Another point to take into consideration: Stefano, do you want to
measure the thruput or the goodput? When you use TCP, the thruput-
meter is capturing the thruput, not the actual goodput (the data rate
without all possible retransmissions caused by TCP). In UDP, these
values are the same. UDP is not asking to resubmit data if it's
getting lost on the wireless channel, because it has no flow control.

Frank

On Nov 22, 12:45 pm, Pinto Pinto <pintox...@gmail.com> wrote:

> > omnetpp+u...@googlegroups.com<omnetpp%2Bunsu...@googlegroups.com­>
> > .

[Stefano]

Frank,

you're right, what I had in mind was the goodput, since the point of
my simulation is to understand how fast "useful" data is transferred
across the network. If I use thruputMeter between Transport and IP
layer I'm looking at the throughput (I guess), and not the goodput.
So, does the same block (thruputMeter) work if I put it between TCP
and TCPSessionApp modules? Or should I use another kind of higher
layer module in order to replace TCPSessionApp?


S

[Tobias]

Hi,

ThruputMeter module works also fine between TCP and TCPSessionApp.

[Frank]

Sounds good. Stefano, may I ask how you configured your TCPApp-
Settings to ensure that the simulation is not running out of data?

Frank

> >>>> omnetpp+u...@googlegroups.com<omnetpp%2Bunsu...@googlegroups.com �>

[Stefano]

Tobias, thanks.

Frank: here is my configuration. As a matter of fact, the network
can't transfer the entire 100 MB, but it stops somewhere around 30 MB.
Do you mean this when you say that the simulation could run out of
data? How can I fix this? (I'm sorry for all my questions, I'm just a
beginner in OMNeT++ and I can't find any good tutorial...).

# tcp apps
**.wirelessRouter2.numTcpApps=1
**.wirelessRouter2.tcpAppType="TCPSessionApp" # ftp
**.wirelessRouter2.tcpApp[0].active=true
**.wirelessRouter2.tcpApp[0].connectAddress="172.20.3.10" # <-----
this is wirelessHost
**.wirelessRouter2.tcpApp[0].connectPort=1000
**.wirelessRouter2.tcpApp[0].tOpen=uniform(300s,301s)
**.wirelessRouter2.tcpApp[0].tSend=uniform(310s,311s)
**.wirelessRouter2.tcpApp[0].sendBytes=100000000B # 100Mb
**.wirelessRouter2.tcpApp[0].tClose=0s

**.wirelessHost.numTcpApps=1
**.wirelessHost.tcpAppType="TCPSinkApp"
**.wirelessHost.tcpApp[0].address=""
**.wirelessHost.tcpApp[0].port=1000

[Frank]

Hey Stefano,

a beginner like me ;-)

> As a matter of fact, the network can't transfer the entire 100 MB, but it stops somewhere around 30 MB.

Yes, that is exactly what I mean.

My configuration looks almost the same:
# tcp apps (server side)
**.host[0].numTcpApps = 1
**.host[0].tcpAppType = "TCPSessionApp"
**.host[0].tcpApp[0].active = true
**.host[0].tcpApp[0].port = -1
**.host[0].tcpApp[0].connectAddress = "host[3]"
**.host[0].tcpApp[0].connectPort = 1000
**.host[0].tcpApp[0].tOpen = 0s
**.host[0].tcpApp[0].tSend = 0s
**.host[0].tcpApp[0].sendBytes = 1000MB # the simulation is using
somewhat around 150MB
**.host[0].tcpApp[0].sendScript = ""
**.host[0].tcpApp[0].tClose = 159s # simulation time is 160s

# tcp apps (client side)
**.host[4].numTcpApps = 1
**.host[4].tcpAppType = "TCPSessionApp" # I think this should work
fine like the TCPSinkApp
**.host[4].tcpApp[0].active = false
**.host[4].tcpApp[0].connectAddress = ""
**.host[4].tcpApp[0].port = 1000

I'm not sure, if we have to fix something here or if it's just fine. I
read something about throughput measuring problems when using such
large amounts of data to send, but I didn't experience that for
myself...

Frank

[Tobias]

Perhaps it stops because you have in the .ini file configured a value
for sim runtime?

[Tobias]

>>>>>>>> omnetpp+u...@googlegroups.com<omnetpp%2Bunsu...@googlegroups.com �>

>>>>>>>> .
>>>>>>>> For more options, visit this group at
>>>>>>>> http://groups.google.com/group/omnetpp?hl=en.
>>>> Hi,
>>>> ThruputMeter module works also fine between TCP and TCPSessionApp.

have you checked if you have set in the .ini file the run time of the
simulation. Perhaps this is the reason why it stops before transmitting
the whole data?

[Frank]

Hey Tobias,

yes, that's correct. It's my intention to stop the simulation before
the TCP connection transmitted the whole amount of data. I repeat the
simulation with different MANET routing algorithms (and different
MANET routing algorithm parameters), to see which algorithm /
parameter settings has the highest throughput in a certain time.

Anything to optimize from your point of view?

Thanks, Frank.

[Stefano]

Hello Tobias,

no, in my case the omnetpp.ini does not contain any simulation time
burden, so, to me it's still an open issue I have to solve. On the
other hand, for the previous problem, I tried to put ThruputMeter
between my tcp and my tcpapp (TcpSessionApp) module, but, when I try
to simulate, I get the following error:
http://yfrog.com/1g25334010p
Any idea?

S

[Tobias]

Hello,

do you have put there 2 ThruputMeters (one for each direction) ?

The error message says that its a cast problem in this code in the thruputMeter module handleMessage function:

 updateStats(simTime(), PK(msg)->getBitLength());

The reason is that the active open message is no cPacket.

cPacket is a descendant of cMessage.

As workaround you can do the following:
Put in the handleMessage function:

cMessage tempMsg = dynamic_cast<cPacket*>(msg);
if(tempMsg)
{
send(msg, "out");
return;
}

updateStates(....

[Stefano]

First of all, thanks for your help.
Yep, I put the two blocks (one for each direction), you can see it
here:
http://yfrog.com/4jtcpp

I tried your code, but I still get the error, plus I get this error in
ThruputMeter.cc:
"Conversion from Packet* to non-scalar type Message requested"


S

On Nov 26, 3:56 pm, Tobias <grub...@googlemail.com> wrote:
> Hello,
>
> do you have put there 2 ThruputMeters (one for each direction) ?
>
> The error message says that its a cast problem in this code in the
> thruputMeter module handleMessage function:
>

>  updateStats <http://inet.omnetpp.org/doc/INET/doxy/class_thruput_meter.html#ac502c...>(simTime(), PK <http://inet.omnetpp.org/doc/INET/doxy/_i_n_e_t_defs_8h.html#ae5b816f7...>(msg)->getBitLength());

[Tobias]

hi,

ups sorry, should be a pointer:

cMessage *tempMsg = dynamic_cast<cPacket*>(msg);

> if(tempMsg)
> {
> send(msg, "out");
> return;
>
> }
>
> updateStates(....

Can you try again

[Stefano]

Thanks Tobias, but even whit your workaround I still get the error
during simulation time. :(

S

[Tobias]

Same error?
Can you send me the code of the handleMessage function in the ThruputMeter.

[Tobias]

Sorry I made a mistake. It is too late...

Here the code:

cMessage *tempMsg = dynamic_cast<cMessage*>(msg);

if(tempMsg)
{
send(msg, "out");
return;
}

[Stefano]

I tried that. But, since "updateStats" is after "return", my stats are
not updated and ThruputMeter doesn't measure anything (even If the
previous error is gone). I changed your code by adding an
"updateStats(simTime(), PK(tempMsg)->getBitLength());" before the
"return", but now I still get my previous error...

S

[Tobias]

Hm, It should now measure only cPackets.
But perhaps it can cast cPacket to cMessage (I thought it returns null)
and therefore the if statement is always true.

[Tobias]

ok. cPackets are naturally casted to cMessage.

So do the following:

cPacket *tempMsg = dynamic_cast<cPacket*>(msg);
if(!tempMsg)
{
send(msg, "out");
return;
}
updateStates....

Am 26.11.2010 16:47, schrieb Stefano:

[Tobias]

Hi,

I have tested it with my simulation. It works with the code I have send you.
The reason is that the active open message is not a cPacket and
therefore it doesnt matter not to put it in updateStates.

Best regards

Am 26.11.2010 16:47, schrieb Stefano:

[Stefano]

Hi,

yes, it works (meaning that I do not get any error), but the
throughputMeter still doesn't get any statistic, the throughput plot
is at zero...

S

> ...
>
> read more »

[Tobias]

Hi,

you have to use this code:

So do the following:

cPacket *tempMsg = dynamic_cast<cPacket*>(msg);
if(!tempMsg)
{
send(msg, "out");
return;

}

I have tested it. It works fine. I have results in the thruputMeter vectors with this...
updateStates....

[Stefano]

Hi,

I did that, I even tried to erase my code and paste yours, but it's
exactly the same: vectors are at zero. You can see it from here:

http://yfrog.com/bfomn1p
http://yfrog.com/ghomn3p
http://yfrog.com/hqomn2p

S

> ...
>
> read more »

[Tobias]

In the pictures I cant see the code of the handleMessage method.
There you have to integrate the code..

>> read more �

[Pinto Pinto]

Hi,
as far as i know, the TCP module, forwards the packets to the tcpApp module ONLY when the current session finishes. This means that if the tcp session lasts for i.e. 90sec, from 0 to 90 sec you will see zero as throughput in the tcpApp module, but after that when the tcp has forwarded the packets to tcpApp you will get the value that you want.

BR
pintoX

To unsubscribe from this group, send email to omnetpp+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/omnetpp?hl=en.

[Stefano]

Sorry, I pasted the wrong image, but anyway I've integrated the code
correctly in handleMessage. Doesn't work.

S

> ...
>
> read more »

[Tobias]

I have the same scenario here and it works fine with the code.
I have in the results of the thruputMeter vectors and scalars with lots
of values.

Send me your handleMessage code.

>> read more �

[Stefano]

Here it is:

void ThruputMeter::handleMessage(cMessage *msg)
{

cPacket *tempMsg = dynamic_cast<cPacket*>(msg);
if(!tempMsg)
{
send(msg, "out");
return;

}

updateStats(simTime(), PK(msg)->getBitLength());
send(msg, "out");
}

To me it seems exactly like yours...


S

> ...
>
> read more »

[Tobias]

I have exactly that code in the thruputMeter.cc module.
I get results, because all packets are tracked, only cMessages are skipped.

I can think of one thing, which causes this:
You are not sending cPackets. Instead of Packets you are sending cMessages down from the application ??

[N.omar]

Hello ALL , First i thank every one here for the useful discussion 

I faced the same problem in computing the throughput of TCP only . I implemets what Mr.Tobais saied and replace the code of throughputMeter (handleMessage function )  with his one.

also i added the throughMeter in 

MobileManetRoutingHost , and connect it with tcpApp and tcp in the both direction 

the Question come in my mind : why I should put two throughputMeter in the both direction between tcpApp and Tcp ?! 

Also when i get the scalar result i got the result as in the picture . 

by note that host[1] is active listening and communicate with host[7] , and (11,12) communicate with each other , also (11,12) , (16,15). 

I need to understand why such this result appear like this ! and what i choose the avg throughput of MeterIn or MeterOut ??!! 

Thanks ALOT 

[chitsu...@gmail.com]

Hi Pinto Pinto
 I can't add thruputMeter.
I have placed thruptMeter Between TCP and tcpApps of standardhost.
but I can't connect thruputMeter and TCP , when I add connection between them I got the error message.
Please give me some advice and
.ned and .ini file example using thruputMeter in Ad-hoc Network using TCP protocol.

[Wian Virgi]

Hello Everybody

I need help for make thruputmeter in UDP I dont now why still error
<!> Error in module (IPv4) Scenario.host[0].networkLayer.ip (id=17) at event #680, t=22.055267407558: Gate `udpOut' of compound module (cCompoundModule)Scenario.host[0].networkLayer is not connected on the outside, upon arrival of message (ICMPMessage)ICMP-error-#1-type13-code2.

and

<!> Error in module (cCompoundModule) Net80211.host[0] (id=2) during network setup: No submodule `udp' to be connected, at /home/wian/Downloads/omnetpp-4.3/samples/inet/src/nodes/inet/AdhocHost.ned:58.

I don't know what can I do know.. Could you help me all..
This is my code  in standartHosts

module StandardHost extends NodeBase
{
    parameters:
        @display("i=device/pc2");
        int numTcpApps = default(0);  // no of TCP apps. Specify the app types in INI file with tcpApp[0..1].typename="TCPEchoApp" syntax
        int numUdpApps = default(0);  // no of UDP apps. Specify the app types in INI file with udpApp[0..1].typename="UDPVideoStreamCli" syntax
        int numSctpApps = default(0); // no of SCTP apps. Specify the app types in INI file with sctpApp[0..1].typename="SCTPServer" syntax
        int numPingApps = default(0);  // no of PING apps. Specify the app types in INI file with pingApp[0..1].typename="PingApp" syntax
        bool hasTcp = default(numTcpApps>0);
        bool hasUdp = default(numUdpApps>0);
        bool hasSctp = default(numSctpApps>0);
        string tcpType = default(firstAvailable("TCP", "TCP_lwIP", "TCP_NSC", "TCP_None"));  // tcp implementation (e.g. ~TCP, ~TCP_lwIP, ~TCP_NSC) or ~TCPSpoof
        string udpType = default(firstAvailable("UDP","UDP_None"));
        string sctpType = default(firstAvailable("SCTP","SCTP_None"));
        IPForward = default(false);  // disable routing by default
        networkLayer.proxyARP = default(false);
    submodules:
        tcpApp[numTcpApps]: <> like ITCPApp {
            parameters:
                @display("p=147,54,row,60");
        }
        tcp: <tcpType> like ITCP if hasTcp {
            parameters:
                @display("p=147,141");
        }
        udpApp[numUdpApps]: <> like IUDPApp {
            parameters:
                @display("p=329,54,row,60");
        }
        udp: <udpType> like IUDP if hasUdp {
            parameters:
                @display("p=329,141");
        }
        sctpApp[numSctpApps]: <> like ISCTPApp {
            parameters:
                @display("p=527,54,row,60");
        }
        sctp: <sctpType> like ISCTP if hasSctp {
            @display("p=527,141");
        }
        pingApp[numPingApps]: <default("PingApp")> like IPingApp {
            parameters:
                @display("p=635,141,row,60");
        }
        thruputMeter_tx: ThruputMeter {
            @display("p=265,178;is=s");
        }

        thruputMeter_rx: ThruputMeter {
            @display("p=193,248;is=s");
        }
    connections allowunconnected:
        for i=0..numTcpApps-1 {
            tcpApp[i].tcpOut --> udp.appIn++;
            tcpApp[i].tcpIn <-- tcp.appOut++;
        }

        tcp.ipOut --> networkLayer.manetIn if hasTcp;
        tcp.ipIn <-- networkLayer.manetOut if hasTcp;
        //tcp.ipIn <-- thruputMeter_rx.out if hasTcp;
        //thruputMeter_rx.in <--  networkLayer.manetOut if hasUdp;

        for i=0..numUdpApps-1 {
            udpApp[i].udpOut --> udp.appIn++;
            udpApp[i].udpIn <-- udp.appOut++;
        }

        udp.ipOut --> networkLayer.manetIn if hasUdp;
        //udp.ipIn <-- networkLayer.manetOut if hasUdp;
        udp.ipIn <-- thruputMeter_rx.out if hasUdp;
        thruputMeter_rx.in <--  networkLayer.manetOut if hasUdp;

        for i=0..numSctpApps-1 {
            sctpApp[i].sctpOut --> sctp.from_appl++;
            sctp.to_appl++ --> sctpApp[i].sctpIn;
        }
        sctp.to_ip --> networkLayer.manetIn if hasSctp;
        networkLayer.manetOut --> sctp.from_ip if hasSctp;

        for i=0..numPingApps-1 {
            networkLayer.pingOut++ --> pingApp[i].pingIn;
            networkLayer.pingIn++ <-- pingApp[i].pingOut;
        }
}

Thank you before..

[Alfonso Ariza Quintana]

https://github.com/aarizaq/inetmanet-3.x/commit/2a4b2cd152b6754f774bd4bb14d19309b0a41476

 

This modification allow to activate the meter in the ini file

 

**.hasThrugmeter = true

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

[Wian Virgi]

I'll try this thank you very much Mr. Alfonso...

[Wian Virgi]

Dear Mr.Alfonso

Before I try your suggestion I try some think and can run but can't finis..

And that intruction check module destructor. where is that modul?

I think my thuruput almost done.. could you help me please?

Thank you Mr.Alfonso..

I get this error :

<!> Error in module (NA_IPv4) SimpleDropping.node[3].networkLayer.ip (id=82) at event #1839, t=4.501124068896: Gate `udpOut' of compound module (cCompoundModule)SimpleDropping.node[3].networkLayer is not connected on the outside, upon arrival of message (ICMPMessage)ICMP-error-#29-type13-code2.

Plugin path: ./plugins
undisposed object: (cMessage) SimpleDropping.node[3].networkLayer.ip.end-service -- check module destructor
undisposed object: (ICMPMessage) SimpleDropping.node[3].networkLayer.ip.ICMP-error-#29-type13-code2 -- check module destructor
undisposed object: (ErrorHandling) SimpleDropping.node[3].networkLayer.errorHandling -- check module destructor
undisposed object: (ARP) SimpleDropping.node[3].networkLayer.arp -- check module destructor
undisposed object: (ICMP) SimpleDropping.node[3].networkLayer.icmp -- check module destructor
undisposed object: (IGMPv2) SimpleDropping.node[3].networkLayer.igmp -- check module destructor
undisposed object: (OLSR) SimpleDropping.node[3].manetrouting -- check module destructor
undisposed object: (ThruputMeter) SimpleDropping.node[3].thruputMeter_rx -- check module destructor
undisposed object: (ThruputMeter) SimpleDropping.node[3].thruputMeter_tx -- check module destructor
undisposed object: (RoutingTable) SimpleDropping.node[3].routingTable -- check module destructor
undisposed object: (InterfaceTable) SimpleDropping.node[3].interfaceTable -- check module destructor
undisposed object: (cCompoundModule) SimpleDropping.node[3].wlan[0] -- check module destructor
undisposed object: (UDPBasicApp) SimpleDropping.node[3].udpApp[0] -- check module destructor
undisposed object: (UDP) SimpleDropping.node[3].udp -- check module destructor
undisposed object: (ChannelControl) SimpleDropping.channelControl -- check module destructor
undisposed object: (IPv4NetworkConfigurator) SimpleDropping.configurator -- check module destructor
undisposed object: (cCompoundModule) SimpleDropping.attacker[0] -- check module destructor
undisposed object: (cCompoundModule) SimpleDropping.node[8] -- check module destructor
undisposed object: (cCompoundModule) SimpleDropping.node[4] -- check module destructor
undisposed object: (cCompoundModule) SimpleDropping.node[5] -- check module destructor
undisposed object: (cCompoundModule) SimpleDropping.node[6] -- check module destructor
undisposed object: (cCompoundModule) SimpleDropping.node[7] -- check module destructor
terminate called after throwing an instance of 'cRuntimeError'
  what():  Object SimpleDropping is currently in (cSimulation)simulation, it cannot be deleted. If this error occurs inside cSimulation, it needs to be changed to call drop() before it can delete that object. If this error occurs inside cSimulation's destructor and SimpleDropping is a class member, cSimulation needs to call drop() in the destructor

omnetpp+unsubscribe@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+unsubscribe@googlegroups.com.

[Alfonso Ariza Quintana]

Have you checked the node 3?

 

Apparently, it arrives a packet to the node 3 that doesn’t have udp module.

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.

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.

[Wian Virgi]

Dear Mr.Alfonso
I to confused but I change UDP to TCP I never get error anymore I hope never again..

And now I have new quetion do you know about RTO in statistic? what is the meaning of RTO? I can see if I used TCP.. RTO and Recovery time is same or differend..?

My project is done..

Thank you for always helping me... GBU

omnetpp+unsubscribe@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+unsubscribe@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+unsubscribe@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+unsubscribe@googlegroups.com.

[Alfonso Ariza Quintana]

Here you can find a simple description with figures of the rto

https://www.extrahop.com/community/blog/2016/retransmission-timeouts-rtos-application-performance-degradation/

---

De: omn...@googlegroups.com <omn...@googlegroups.com> en nombre de Wian Virgi <wianvi...@gmail.com>
Enviado: miércoles, 25 de enero de 2017 5:17:06

To unsubscribe from this group and stop receiving emails from it, send an email to omnetpp+u...@googlegroups.com.

[Wian Virgi]

Hello Mr.Alfonso

I have quetion why my OLSR simulation have same value result.. Exampel scenario  I have 8 node with 2 attacker and 9 node with 1 attacker they have same value.. But my AODV simulation have different value with same scenario..

Thank you Mr.Alfonso...

[Alfonso Ariza Quintana]

The mobility has a strong influence in the results OLSR

---

De: omn...@googlegroups.com <omn...@googlegroups.com> en nombre de Wian Virgi <wianvi...@gmail.com>

Enviado: lunes, 30 de enero de 2017 10:18:16

[Wian Virgi]

So If I have same result from my simulation that's no problem? Or What can I do change my mobility? 

Thanks you Mr.Alfonso?

[Alfonso Ariza Quintana]

If you has high mobility the results of OLSR will be bad, the proactive protocols work well in static/quasi-static networks, in conditions of high mobility the results will be bad with independency of the number of attackers  

---

De: omn...@googlegroups.com <omn...@googlegroups.com> en nombre de Wian Virgi <wianvi...@gmail.com>

Enviado: martes, 31 de enero de 2017 12:23:56

[Wian Virgi]

I used randomWPMobility... What do you think about  it? When I used StationaryMobility Still same...

[Alfonso Ariza Quintana]

OLSR and BATMAN will have problems, it is a high mobility scenario.

---

De: omn...@googlegroups.com <omn...@googlegroups.com> en nombre de Wian Virgi <wianvi...@gmail.com>

Enviado: martes, 31 de enero de 2017 12:45:07

[Wian Virgi]

Mr.Alfonso I have new quetion.. Why when I run my simulation Simpledropping with stationary mobility in AODV  I haven't packet loss value? while in OLSR I have packet loss value? You said  proaktif will have problem with mobility so I try stationary mobility with AODV too.. Thank you Mr. Alfonso...

[Alfonso Ariza Quintana]

I suppose that the sources doesn't begin the transmission inmediately, OLSR and BATMAN need some time to build the routing tables, depending of the diameter of the network and number of nodes, it can take even 60 seconds

---

De: omn...@googlegroups.com <omn...@googlegroups.com> en nombre de Wian Virgi <wianvi...@gmail.com>

Enviado: domingo, 5 de febrero de 2017 11:23:18

[Wian Virgi]

Thank you Mr.Alfonso..

My simulation have 80s that enough or not for OLSR and AODV simulation? 

And I didn't know my simulation is already wireless mesh or not can you checking my simulatio right or not? Thank you very much you always want discusion with me 

[Alfonso Ariza Quintana]

In my simulations the sources begin the transmission after the second 60, and 80 seconds is very small for routing, if you want good statistics you need to simulate several thousand of packets.

 

 

De: omn...@googlegroups.com [mailto:omn...@googlegroups.com] En nombre de Wian Virgi
Enviado el: miércoles, 08 de febrero de 2017 1:26
Para: omn...@googlegroups.com
Asunto: Re: [Omnetpp-l] Re: INET, throughput measure

 

Thank you Mr.Alfonso..

My simulation have 80s that enough or not for OLSR and AODV simulation? 

And I didn't know my simulation is already wireless mesh or not can you checking my simulatio right or not? Thank you very much you always want discusion with me 

On Mon, Feb 6, 2017 at 5:56 PM Alfonso Ariza Quintana <aari...@hotmail.com> wrote:

I suppose that the sources doesn't begin the transmission inmediately, OLSR and BATMAN need some time to build the routing tables, depending of the diameter of the network and number of nodes, it can take even 60 seconds

---

De: omn...@googlegroups.com <omn...@googlegroups.com> en nombre de Wian Virgi <wianvi...@gmail.com>

Enviado: domingo, 5 de febrero de 2017 11:23:18

Para: omn...@googlegroups.com
Asunto: Re: [Omnetpp-l] Re: INET, throughput measure

Mr.Alfonso I have new quetion.. Why when I run my simulation Simpledropping with stationary mobility in AODV  I haven't packet loss value? while in OLSR I have packet loss value? You said  proaktif will have problem with mobility so I try stationary mobility with AODV too.. Thank you Mr. Alfonso...

On Wed, Feb 1, 2017 at 12:59 AM Alfonso Ariza Quintana <aari...@hotmail.com> wrote:

OLSR and BATMAN will have problems, it is a high mobility scenario.

 

---

De: omn...@googlegroups.com <omn...@googlegroups.com> en nombre de Wian Virgi <wianvi...@gmail.com>

Enviado: martes, 31 de enero de 2017 12:45:07

Para: omn...@googlegroups.com
Asunto: Re: [Omnetpp-l] Re: INET, throughput measure

I used randomWPMobility... What do you think about  it? When I used StationaryMobility Still same...

 

On Tue, Jan 31, 2017 at 6:33 PM Alfonso Ariza Quintana <aari...@hotmail.com> wrote:

[Wian Virgi]

If 300s? Or 600s?

[Alfonso Ariza Quintana]

The bigger the best, the inconvenience is the duration of the simulation.

[ferra adelinna]

dear mr. alfonso, i try to use ThruputMeter and throughput measuring by ned.Dataratechannel) but why the result is different? can you help me, which one should be better i use? in case, i running simulation in framework veins-lte, thank you so much.

[Devika Bagaria]

can you please tell me the steps for adding the ThruputMeter module between the two modules. It will be of great help

> >>>>>>>> without all possible retransmissions caused by TCP). In UDP, these
> >>>>>>>> values are the same. UDP is not asking to resubmit data if it's
> >>>>>>>> getting lost on the wireless channel, because it has no flow control.
> >>>>>>>> Frank
> >>>>>>>> On Nov 22, 12:45 pm, Pinto Pinto <pintox...@gmail.com> wrote:
> >>>>>>>>> Hi,
> >>>>>>>>> you should add the ThruputMeter module, which will measure the throughput in
> >>>>>>>>> the application level. In order to do that, you should add 2 ThruputMeter
> >>>>>>>>> modules between the IP and the TCP, one for each direction of the packets
> >>>>>>>>> (ip-->TCP : incoming throughput, TCP-->IP outgoing throughput).
> >>>>>>>>> Hope this helps

> >>>>>>>>> bye
> >>>>>>>>> pintoX
> >>>>>>>>> On Mon, Nov 22, 2010 at 11:18 AM, Stefano <ste...@gmail.com> wrote:
> >>>>>>>>>> Ok, just to be sure and give a bump to the thread: does anybody know a
> >>>>>>>>>> simple method to measure throughput when using TCPSessionApp/
> >>>>>>>>>> TCPSinkApp?
> >>>>>>>>>> S

> >>>>>>>>>> On Nov 19, 4:09 pm, Stefano <ste...@gmail.com> wrote:
> >>>>>>>>>>> Hello everybody,
> >>>>>>>>>>> I need to measure network throughput within a multi-hop wireless
> >>>>>>>>>>> network. Right now, I'm testing my network with fixed-size file
> >>>>>>>>>>> transfers between a central node (TCPSinkApp) and many peripheral AP
> >>>>>>>>>>> (TCPSessionApp) which generate traffic at tcp level.
> >>>>>>>>>>> The problem is that I want to measure the actual throughput
> >>>>>>>>>>> (application level) of my file transfer in a simple way. Is there
> >>>>>>>>>>> something integrated into TCPSessionApp or do I need some other block?
> >>>>>>>>>>> I've seen ThruputMeter, but it lacks of documentation, can you point
> >>>>>>>>>>> me to some example?
> >>>>>>>>>>> Thank you.
> >>>>>>>>>> --
> >>>>>>>>>> You received this message because you are subscribed to the Google Groups

> >>>>>>>>>> "omnetpp" group.
> >>>>>>>>>> To post to this group, send email to omn...@googlegroups.com.
> >>>>>>>>>> To unsubscribe from this group, send email to
> >>>>>>>>>> omn...@googlegroups.com<omnetpp%2Bunsu...@googlegroups.com >
> >>>>>>>>>> .
> >>>>>>>>>> For more options, visit this group at
> >>>>>>>>>>http://groups.google.com/group/omnetpp?hl=en.
> >>>>>> Hi,
> >>>>>> ThruputMeter module works also fine between TCP and TCPSessionApp.
> >> have you checked if you have set in the .ini file the run time of the
> >> simulation. Perhaps this is the reason why it stops before transmitting
> >> the whole data?

[bidisha banerjee]

Can anyone help me with how to measure throughput for BATMAN in inetmanet-4.x? Thanks a lot.

[Alfonso Ariza Quintana]

https://github.com/aarizaq/inetmanet-4.x/commit/1255643b5856ac092af475004c9fb9073aceb497

---

De: omn...@googlegroups.com <omn...@googlegroups.com> en nombre de bidisha banerjee <b.bane...@gmail.com>
Enviado: domingo, 17 de mayo de 2020 8:12
Para: OMNeT++ Users <omn...@googlegroups.com>

Asunto: [Omnetpp-l] Re: INET, throughput measure

--

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.

To view this discussion on the web visit https://groups.google.com/d/msgid/omnetpp/648a6405-4670-4897-bd9b-1c23ad1ff99a%40googlegroups.com.

[bidisha banerjee]

can anyone give me the appropriate algorithm for BATMAN-ADV please.