Re: [Omnetpp-l] Digest for omnetpp@googlegroups.com - 13 updates in 8 topics
66 views
Skip to first unread message
Rahul Sonkamble
Apr 22, 2014, 12:45:54 AM4/22/14
to omn...@googlegroups.com
am not getting .exe file when i build the helloworld programme...Program is giving two errors
Description Resource Path Location Type make: *** [all] Error 2 helloworld C/C++ Problem
Description Resource Path Location Type make[1]: *** [../out/gcc-debug/src/helloworld.exe] Error 1 helloworld C/C++ Problem
Can anyone help me about this?
Mr. Sonkamble Rahul G.
Mtech Second YearOn Mon, Apr 21, 2014 at 1:19 PM, <omn...@googlegroups.com> wrote:
Group: http://groups.google.com/group/omnetpp/topics
- problem for using airtime link metric in hwmp protocol [2 Updates]
- [Possible bug/Query] regarding Network Layer ETX & the role of MAC 80211 retransmisions [INETMANET] [2 Updates]
- Omnet installation problem in Linux Mint 16 [3 Updates]
- end to end delay in vanet [1 Update]
- send a message to a module in AODVUU [1 Update]
- create RREQ in AODVUU [2 Updates]
- calculating end-to-end delay and PDR in AODVUU [1 Update]
- How to a new routing protocol in INET framework [1 Update]
stars york <yorkst...@gmail.com> Apr 20 10:57PM -0700
Dear Alfonso,
Sorry for making any misunderstanding.
I agree with your opinion that the radio module won't send the S/N
information. Instead, PHY layer only forwards the packet error information
to the MAC layer (i.e., mark the bit error) and then MAC layer will check
the CRC to determine the "MAC" packet is error or not. Finally, the ETX
can calculate the packet error rate.
My question is that:
I am doing observation for airtime metric computation in inetmanet 2.0-2.2
version, but it always returns the metric = 268435455 (0xFFFFFFF) from the
hwmp::GetLinkMetric().
However, hwmp:GetLinkMetric() works successfully in inetmanet-master
version.
I take time to trace what it happened. I found that it seems no neighbor
exist and this causes (neighbors.size() is always 1, so the etx packet
cannot be transmitted successfully) in the handleEtxMessage()
Now, I am looking for the process of the neighbor setting.
Can you help me to check the question why the detecting of neighbor is not
incorrect in inetmanet 2.0-2.2 version?
The followings are my .ini file about mesh and etx.
**.wlan[*].mgmt.useHwmp = true ## enables HWMP protocol by default in
reactive mode
**.wlan.mgmt.useReactive = false #DYMO-UM in the mac layer, it's possible
to use AODV
**.wlan.mgmt.useProactive = false #OLSR-UM in the mac layer,
**.minHopCost = false
**.ETXEstimate = true
Thanks,
BRs,
York
Alfonso Ariza Quintana於 2014年4月18日星期五UTC+8下午5時45分14秒寫道：
stars york <yorkst...@gmail.com> Apr 20 11:09PM -0700
Dear Alfonso,
At first I appreciate you very much for providing an airtime metric setting
of hwmp.
But, I am sorry for a bit misunderstanding.
I agree with your opinion that the radio module won't send the S/N
information. Instead, PHY layer only forwards the packet error information
to the MAC layer (i.e., mark the bit error) and then MAC layer will check
the CRC to determine the "MAC" packet is error or not. Finally, the ETX
can calculate the packet error rate.
My question is to sure the ETX module can be worked successfully for the
802.11s HWMP protocol in the inetmanet 2.0-2.2 version
I am doing observation for airtime metric computation in inetmanet 2.0-2.2
version, but it always returns the metric = 268435455 (0xFFFFFFF) from the
hwmp::GetLinkMetric().
However, hwmp:GetLinkMetric() works successfully in inetmanet-master
version.
I take time to trace what it happened. I found that it seems no neighbor
exist and this causes (neighbors.size() is always 1, so the etx packet
cannot be transmitted successfully) in the handleEtxMessage()
Now, I am looking for the process of the neighbor setting.
Can you help me to check the question why the detecting of neighbor is not
incorrect in inetmanet 2.0-2.2 version?
The followings are my .ini file about mesh and etx.
**.wlan[*].mgmt.useHwmp = true ## enables HWMP protocol by default in
reactive mode
**.wlan.mgmt.useReactive = false #DYMO-UM in the mac layer, it's possible
to use AODV
**.wlan.mgmt.useProactive = false #OLSR-UM in the mac layer,
**.minHopCost = false
**.ETXEstimate = true
Thanks,
BRs,
York
Alfonso Ariza Quintana於 2014年4月18日星期五UTC+8下午5時45分14秒寫道：
Ivo Calado <ivo.c...@ifal.edu.br> Apr 20 10:39AM -0300
Hi Alfonso,
just a doubt. You said that the broadcast packets are sent following the
minimum mandatory bit rate. Do you know where I can find out such
information? I tried on [1] with no success (at least I did not use the
correct keywords to search in an almost 3k size file :S).
[1] http://standards.ieee.org/getieee802/download/802.11-2012.pdf
Best regards
[]'s
On Sun, Mar 30, 2014 at 3:57 PM, Alfonso Ariza Quintana <
--
Ivo Calado
*Quidquid latine dictum sit, altum viditur*
Putt's Law:
Technology is dominated by two types of people:
Those who understand what they do not manage.
Those who manage what they do not understand.
Alfonso Ariza Quintana <aari...@hotmail.com> Apr 20 10:20PM +0200
I can't find, I suspect a change in the standard, it is safe to change the bit rate of broadcast frames because MAC control bit rate and broadcast bit rate are now independent.
From: ivo.c...@ifal.edu.br
Date: Sun, 20 Apr 2014 10:39:36 -0300
Subject: Re: [Omnetpp-l] [Possible bug/Query] regarding Network Layer ETX & the role of MAC 80211 retransmisions [INETMANET]
To: omn...@googlegroups.com; aari...@hotmail.com
Hi Alfonso,
just a doubt. You said that the broadcast packets are sent following the minimum mandatory bit rate. Do you know where I can find out such information? I tried on [1] with no success (at least I did not use the correct keywords to search in an almost 3k size file :S).
[1] http://standards.ieee.org/getieee802/download/802.11-2012.pdf
Best regards
[]'s
On Sun, Mar 30, 2014 at 3:57 PM, Alfonso Ariza Quintana <aari...@hotmail.com> wrote:
No, broadcast packets
don't have retransmission, and they has a lower error probability
(the broadcast packets are sent to the minimum mandatory bit rate)
Date: Fri, 28 Mar 2014 13:01:55 -0700
From: rehan...@gmail.com
To: omn...@googlegroups.com
Subject: [Omnetpp-l] [Possible bug/Query] regarding Network Layer ETX & the role of MAC 80211 retransmisions [INETMANET]
Dear all,
I have stumbled across a question during my experiments related to (proactive) ETX packets in DSR and I'd be very thankful if you can shed some light on it.Does 80211g retransmissions (in particular retryLimit) also retry DSRPktExt packets or not?
In other words, do the ETX values that we estimate over the etx window reach the first hop neighbor with or without mac retransmissions ?
I ran experiments with varied MAC retryLimits ={1,2,3,7}.
As i increase the retryLimit, the End-to-end UDP delivery ratio 'substantially' increases, however the link level etx values showed (almost) no change.
From which it seems, that ETX packets which are generated at the DSR Layer (above MAC), do not get re-transmitted.
Which to me doesn't seem to make sense to me. Since for the MAC layer, UDP/TCP packets, and even DSR packets should essentially be treated as same, unless there is an exception or hook (i cant find such exception or hook in the code though) in the code which allows MAC retransmissions for the UDP/TCP layer yet doesn't do retransmissions for the ETX Packets from DSR Layer.
Could this be a bug in the code? or am i overlooking something.
Sincerely,
Ronnie
--
You received this message because you are subscribed to the Google Groups "omnetpp" group.
To unsubscribe from this group and stop receiving emails from it, send an email to omnetpp+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "omnetpp" group.
To unsubscribe from this group and stop receiving emails from it, send an email to omnetpp+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
Ivo Calado
Quidquid latine dictum sit, altum viditur
Putt's Law:
Technology is dominated by two types of people:
Those who understand what they do not manage.
Those who manage what they do not understand.
--
You received this message because you are subscribed to the Google Groups "omnetpp" group.
To unsubscribe from this group and stop receiving emails from it, send an email to omnetpp+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Nicky Didos <poetr...@gmail.com> Apr 20 05:50AM -0700
I am a student and new user to omnet. I want install omnet on Linux Mint
16. For installation I followed the guide :
http://www.nsnam.com/2013/12/installation-of-omnet-in-linux-mint-16.html
I have set the environment variables in the .profile in linux mint. This is
my profile: http://paste.debian.net/94680/ .
<http://paste.debian.net/94680/>After:
~/omnetpp-4.4.1 $ make
make MODE=release
make[1]: ingresso nella directory "/home/nicky/omnetpp-4.4.1"
***** Configuration: MODE=release, TOOLCHAIN_NAME=gcc, LIB_SUFFIX=.so ****
===== Checking environment =====
ERROR: /home/nicky/omnetpp-4.4.1/bin is not in the path! You can add it by
entering:
export PATH=/home/nicky/omnetpp-4.4.1/bin:$PATH
make[1]: *** [check-env] Errore 1
make[1]: uscita dalla directory "/home/nicky/omnetpp-4.4.1"
make: *** [allmodes] Errore 2
Why i have the problem ?
And from shell I get:
$PATH
bash:
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:
File o directory non esistente
Michael Kirsche <michael...@tu-cottbus.de> Apr 20 09:29AM -0700
So you inserted the correct path information (export
PATH=/home/nicky/omnetpp-4.4.1/bin:$PATH) into your .profile file...
Did you re-start your shell? Paths from .profile or .bashrc (Ubuntu
derivates) are set only once during the starting of the shell, if you
change your .profile, you have to restart the shell.
Am Sonntag, 20. April 2014 14:50:25 UTC+2 schrieb nicky:
nicky didos <poetr...@gmail.com> Apr 20 06:34PM +0200
Thanks the problem was that it had to restart the shell. Now it works ;-)
Mojtaba Goudarzi <liber...@gmail.com> Apr 20 06:09AM -0700
Thank you dear Joanne.
I will look at that too. If you get to any point please let me know.
You can contact me through my email if you want.
My email: libera...@yahoo.com
On Saturday, April 19, 2014 4:24:40 AM UTC+8, Joanne wrote:
Alfonso Ariza Quintana <aari...@hotmail.com> Apr 20 02:30PM +0200
aodv_socket_send();
Date: Fri, 18 Apr 2014 23:47:48 -0700
From: shima....@gmail.com
To: omn...@googlegroups.com
Subject: [Omnetpp-l] send a message to a module in AODVUU
Hi Dear Alfonso.I want to send a new type of message that is inherited from cPacket to 1-hop neighbor in aodvuu. Could you please tell me what is the command? I think using send(...) is wrong...Many thanks...
--
You received this message because you are subscribed to the Google Groups "omnetpp" group.
To unsubscribe from this group and stop receiving emails from it, send an email to omnetpp+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Sh Asaadi <shima....@gmail.com> Apr 20 01:12AM -0700
Hi,
I want to know where is the code (which .cc file and which function) that
the source node creates RREQ for routing in AODVUU?
Many thanks
Alfonso Ariza Quintana <aari...@hotmail.com> Apr 20 02:13PM +0200
rreq_route_discovery in aodv_rreq.cc
Date: Sun, 20 Apr 2014 01:12:03 -0700
From: shima....@gmail.com
To: omn...@googlegroups.com
Subject: [Omnetpp-l] create RREQ in AODVUU
Hi,I want to know where is the code (which .cc file and which function) that the source node creates RREQ for routing in AODVUU?Many thanks
--
You received this message because you are subscribed to the Google Groups "omnetpp" group.
To unsubscribe from this group and stop receiving emails from it, send an email to omnetpp+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Alfonso Ariza Quintana <aari...@hotmail.com> Apr 20 02:10PM +0200
it is registered like statictis in the ned file, it uses signals to register the information, see in the manual about this
how to use signal for statistics
From: shima....@gmail.com
Date: Sat, 19 Apr 2014 23:09:44 +0430
Subject: Re: [Omnetpp-l] Re: calculating end-to-end delay and PDR in AODVUU
To: omn...@googlegroups.com
Oh thank you, I meant this parameter in the code in udpbasicburst.cc or some where else... like numSent for the number of the packets sent to the destination...
Many thanks,
On Sat, Apr 19, 2014 at 10:49 PM, Alfonso Ariza Quintana <aari...@hotmail.com> wrote:
From: shima....@gmail.com
Date: Sat, 19 Apr 2014 16:06:59 +0430
Subject: Re: [Omnetpp-l] Re: calculating end-to-end delay and PDR in AODVUU
To: omn...@googlegroups.com; aari...@hotmail.com
Dear Alfonso, I am using inet 2.2 and I don't see delay parameter in UDPBasicBurst, but it exist in inetmanet framework. Is there any parameter related to delay in inet?
if No, Can I copy the .cc and .h files I have modified in inetmanet (e.g. aodv_rreq.cc ... ) , or I should write the code again in inetmanet?
Many thanks for your helpful descriptions...
On Sun, Apr 13, 2014 at 4:46 PM, Alfonso Ariza Quintana <aari...@hotmail.com> wrote:
I have never tested this feature, but the ETX module can (in theory) measure the ETT
From: shima....@gmail.com
Date: Sun, 13 Apr 2014 12:45:33 +0430
Subject: Re: [Omnetpp-l] Re: calculating end-to-end delay and PDR in AODVUU
To: omn...@googlegroups.com
CC: aari...@hotmail.com
Hi,Would please answer my question.
I am using inet framework, Do you know how to calculate delay between a node and its 1-hop neighbor? also delivery ratio (after a period of time) between a node and its neighbor in inet framework?
Thanks in advance.
On Wed, Apr 9, 2014 at 12:44 PM, Shima Asaadi <shima....@gmail.com> wrote:
Hi,
I dont see delay parameter in UDPBasibBurst like numSent and numReceived... where is the delay? (I am working with inet framework.)
+Do you know how to calculate delay between a node and its neighbor? also delivery ratio (after a period of time) between a node and its neighbor?
I would really appreciate if you could help me. thanks.
On Tue, Apr 8, 2014 at 9:03 PM, Shima Asaadi <shima....@gmail.com> wrote:
Dear Ronnie, one another simple question. in UDPBasicBurst which parameter is for endtoend delay?
thanks
On Tue, Apr 8, 2014 at 6:48 PM, Shima Asaadi <shima....@gmail.com> wrote:
Thank u Alfonso.
I want to know can I extract these values in my code to make decision in my algorithm? for example if the delay is more than a threshold do sth else...
On Tue, Apr 8, 2014 at 6:40 PM, Alfonso Ariza Quintana <aari...@hotmail.com> wrote:
In the sca files you have the total number of packet sent, the total number of packets received and the delay
Pdr = packets received/total sent
De: omn...@googlegroups.com [mailto:omn...@googlegroups.com] En nombre de Shima Asaadi
Enviado el: martes, 08 de abril de 2014 15:34
Para: omn...@googlegroups.com; rehan...@gmail.com
Asunto: Re: [Omnetpp-l] Re: calculating end-to-end delay and PDR in AODVUU
Thank you for your reply dear Ronnie.
do you mean i set the
**.fixhost[0].udpAppType = "UDPBasicBurst"
**.host[*].udpApp[*].typename = "UDPBasicBurst"
and disable :
**.fixhost[0].udpApp[*].typename = "UDPSink" ?
because my destination is fixhost[0]: **.udpApp[0].destAddresses = "fixhost[0]"
and would u please tell me if it is possible to access these values (endtoend , PDR) during runtime? is there any access function? (i want to calculate sth).
Thanks.
On Tue, Apr 8, 2014 at 5:54 PM, Ronnie <rehan...@gmail.com> wrote:
UDPBasicBurst provides you with end-to-end delay as well as end to end pdr.
Just make sure both source and destination are "UDPBasicBurst".
Because UDPSink acts as a udp packet dump.
Regards,
Ronnie
On Tuesday, 8 April 2014 14:54:47 UTC+2, Sh Asaadi wrote:
Hi All,
I want to calculate the end-to-end delay from a node to destination during run time for a purpose. also PDR from a source to destination in AODVUU (net80211_aodv).
Could anyone please help me?
Thanks in advance.
--
You received this message because you are subscribed to a topic in the Google Groups "omnetpp" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/omnetpp/1udbxCCij90/unsubscribe.
To unsubscribe from this group and all its topics, send an email to omnetpp+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
Best Regards,
Shima Asaadi,
Tehran Polytechnic, Iran
--
You received this message because you are subscribed to the Google Groups "omnetpp" group.
To unsubscribe from this group and stop receiving emails from it, send an email to omnetpp+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to a topic in the Google Groups "omnetpp" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/omnetpp/1udbxCCij90/unsubscribe.
To unsubscribe from this group and all its topics, send an email to omnetpp+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
Best Regards,Shima Asaadi,
Tehran Polytechnic, Iran
--
Best Regards,Shima Asaadi,
Tehran Polytechnic, Iran
--
Best Regards,Shima Asaadi,
Tehran Polytechnic, Iran
--
Best Regards,Shima Asaadi,
Tehran Polytechnic, Iran
--
You received this message because you are subscribed to the Google Groups "omnetpp" group.
To unsubscribe from this group and stop receiving emails from it, send an email to omnetpp+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to a topic in the Google Groups "omnetpp" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/omnetpp/1udbxCCij90/unsubscribe.
To unsubscribe from this group and all its topics, send an email to omnetpp+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
Best Regards,Shima Asaadi,
Tehran Polytechnic, Iran
--
You received this message because you are subscribed to the Google Groups "omnetpp" group.
To unsubscribe from this group and stop receiving emails from it, send an email to omnetpp+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to a topic in the Google Groups "omnetpp" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/omnetpp/1udbxCCij90/unsubscribe.
To unsubscribe from this group and all its topics, send an email to omnetpp+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
Best Regards,Shima Asaadi,
Tehran Polytechnic, Iran
--
You received this message because you are subscribed to the Google Groups "omnetpp" group.
To unsubscribe from this group and stop receiving emails from it, send an email to omnetpp+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Nishant Gupta <nishant...@gmail.com> Apr 20 02:39AM -0700
--
I want to create my own routing protocol like AODV, DSR , Batman in
manetrouting module in INET framework.
can any one tell me how to do that
You received this message because you are subscribed to the Google Groups "omnetpp" group.
To unsubscribe from this group and stop receiving emails from it, send an email to omnetpp+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Reply all
Reply to author
Forward
0 new messages