Menu
▾
▴
wipsim-devel — WIPSIM developers mailing list
You can subscribe to this list here.
| 2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(8) |
Dec
(17) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: <ben...@id...> - 2004-05-25 10:47:54
|
Dear Open Source developer I am doing a research project on "Fun and Software Development" in which I kindly invite you to participate. You will find the online survey under http://fasd.ethz.ch/qsf/. The questionnaire consists of 53 questions and you will need about 15 minutes to complete it. With the FASD project (Fun and Software Development) we want to define the motivational significance of fun when software developers decide to engage in Open Source projects. What is special about our research project is that a similar survey is planned with software developers in commercial firms. This procedure allows the immediate comparison between the involved individuals and the conditions of production of these two development models. Thus we hope to obtain substantial new insights to the phenomenon of Open Source Development. With many thanks for your participation, Benno Luthiger PS: The results of the survey will be published under http://www.isu.unizh.ch/fuehrung/blprojects/FASD/. We have set up the mailing list fa...@we... for this study. Please see http://fasd.ethz.ch/qsf/mailinglist_en.html for registration to this mailing list. _______________________________________________________________________ Benno Luthiger Swiss Federal Institute of Technology Zurich 8092 Zurich Mail: benno.luthiger(at)id.ethz.ch _______________________________________________________________________ |
|
From: Martijn K. <mk...@wi...> - 2004-01-06 23:05:35
|
Hi, Finally after 3 weeks (including Christmas) of broken code I can finally compile the simulator again. I have performed a major upgrade in the initialisation and before releasing this I want to fix one more outstanding issue, namely restarting of source. I will move the restart-list to outside the application, into the list of applications. I will also change the initialisation of applications. 1. An application will be created, when the scenario-file is read (constructor call) 2. The application will be started when the application is scheduled=20 (call to Start()). As mentioned: Applications will be managed by the list of applications, which will also handle stopping applications (other than application that stop themselves (like ping can do)), changing applications (used to be called restart). To sum what has changed: - New sniffing network (working, but need some finishing touches) - New initialisation routine (complete clean-up, ready) - Scenario-file now handles (almost) all the command-line parameters - Clean-up of main wipsim.cpp file /Martijn |
|
From: Gerben K. <gk...@ko...> - 2003-12-19 16:00:00
|
On Fri, 19 Dec 2003, Martijn Kuipers wrote: > Hi, > > There is a temp HACK in readscenario for > bluetooth. > bt_con and bt_dis > > Are these still in use? I couldn't find any example where they are used, > so it is a bit tricky to test for me (without reading the entire code > for it). > > Is it ok if I do not implement this part in the new readscenario? > > /Martijn It's ok not to implement this in the new readscenario. They are/where used for some neighbour discovery improvements to Bluetooth. I can put them back in again later, if I need to do more simulations. /Gerben |
|
From: Martijn K. <mk...@wi...> - 2003-12-19 15:50:06
|
Hi, There is a temp HACK in readscenario for bluetooth. bt_con and bt_dis Are these still in use? I couldn't find any example where they are used, so it is a bit tricky to test for me (without reading the entire code for it). Is it ok if I do not implement this part in the new readscenario? /Martijn |
|
From: Martijn K. <mk...@wi...> - 2003-12-19 11:22:39
|
Some thought for the analyser (thought we should collect them). If the analyser has as input both the scenario and the sniffer-file then we can do some smart things (see below). We could add a line to the sniffer file which tells it what scenario-file to use. Maybe we should even provide some kind of checksum (some CRC or simpy the date, last is not so safe, because it might not allow to copy the files)), so the sniffer-file can be sure that the scenario-file is the same as when it was used for the simulation. Advantages: - because the analyser can now go through the scenario-file and figure out which events are sniffed. This means that it can also inform the user what information can be extracted from the sniffer file (no MAC-info if MAC-sniffing has been turned of), - Nodes can be identified by their name (as the scn-file also holds the network file). /Martijn |
|
From: Martijn K. <mk...@wi...> - 2003-12-19 11:14:27
|
I need some info... I am rewriting the init section of the simulator (almost done), and I ran into the following. In the old init we take the following steps: - Create the network (nodes, interfaces, etc) - Create the routingtables for interfaces that want fixed routing It does this based solely on the IP-Addresses - Register the media (interfaces) into Marconi - Fill the location database of Marconi Now, my guess is that this is in the wrong order, it should be: - Create the network - Register the media, - Fill the location database - Create the routingtables for interfaces that want fixed routing. This should be (much) easier, because it only needs to get information from Marconi as to which interfaces are in its range (this info is exactly what is stored in the LocationDB). =09 For now I will not change it, because it is a rather complicated change (CreateRoutingTables must be one of the most horrific functions, so I would be glas if I could fix that up later). Does this seem appropriate? /Martijn P.S. Just to keep you informed of the progress. - cInit no longer exist - Analyser will be ripped out (sorry) cInit has been split up for readabillity and neatness (these classes should/will be moved to their own files) + cNetwork (all the info for the network) + cScenario (has been split into stage1 and stage2 reading, where stage 1 is the new USE command for the nwk-file and more and stage 2 is the scheduling of events (applications and the new snif (last is todo)) + cSimulation |
|
From: Martijn K. <mk...@wi...> - 2003-12-18 14:38:58
|
On Thu, 2003-12-18 at 14:06, Gerben Kuijpers wrote: > On Thu, 18 Dec 2003, Martijn Kuipers wrote: >=20 > > Hi, > > > > I am having some problems with the parameters. > > There is a huge amount of parameters for the analyser and as I mentione= d > > before I would like to have the parameters to a minimum. > > > > Also, I have great fear that the simulator is not a good place for the > > analyser. > > I love it's results, but it is not up to date, as only some protocols > > can be analysed. > > > > How about moving this code to a seperate program and doing something > > smart between simulator and analyser? >=20 > Sounds like a good idea to move the analyser back to a separate program. > We'll have to have some sort of communication between the two programs an= d > trying to avoid too much overhead. Separating the simulator and analyser > will ofcourse result in some reduction in speed. Only if you want analyser results, otherwise it should improve the speed. It should be possible to read the sniffer-file while it is being generated. All the analyser app has to do is watch the file to see if it has changed (either access time, or perhaps more portable filesize). The analyser never closes the file and records the readpointer. When it sees an increase in filesize, it reads the next portion....etc. This probably requires the simulator to add the stop command to the sniffer file and a time-out in case the wipsim crashes (wipsim crashes, impossible!)... /Martijn |
|
From: Gerben K. <gk...@ko...> - 2003-12-18 14:07:03
|
On Thu, 18 Dec 2003, Martijn Kuipers wrote: > Hi, > > I am having some problems with the parameters. > There is a huge amount of parameters for the analyser and as I mentioned > before I would like to have the parameters to a minimum. > > Also, I have great fear that the simulator is not a good place for the > analyser. > I love it's results, but it is not up to date, as only some protocols > can be analysed. > > How about moving this code to a seperate program and doing something > smart between simulator and analyser? Sounds like a good idea to move the analyser back to a separate program. We'll have to have some sort of communication between the two programs and trying to avoid too much overhead. Separating the simulator and analyser will ofcourse result in some reduction in speed. /Gerben |
|
From: Martijn K. <mk...@wi...> - 2003-12-18 11:08:42
|
Hi, I am having some problems with the parameters. There is a huge amount of parameters for the analyser and as I mentioned before I would like to have the parameters to a minimum. Also, I have great fear that the simulator is not a good place for the analyser. I love it's results, but it is not up to date, as only some protocols can be analysed. How about moving this code to a seperate program and doing something smart between simulator and analyser? /Martijn |
|
From: Gerben K. <gk...@ko...> - 2003-12-17 20:56:25
|
On Wed, 17 Dec 2003, Martijn Kuipers wrote: > Hi, > > Here is the my proposal for the command-line parameters. > Everything you are missing from the old one should go into the scn-file, > or I simply forgot :-) > > > Wireless IP Simulator 2.1.0-mk-2 > Copyright (C) 2003 WIPsim Developers (see AUTHORS) > This software is released under the GNU GPL v2.0. > Usage: > <scenario file> a scenario-file > -i, --info creates the info-file > -h, --help prints the help message > -dN,--debugN switch on debugging level > where n is > 1 switch on TEST-messages > 2 switch on WARNING-messages > 4 switch on ERROR-messages > 8 switch on ASSERT-failures > > Switches can be combined, by adding them, so TEST and WARNING > can be combined as -d3 > > The TEST and WARNING messages can be switched off but do not > stop the simulator, while ERROR messages will stop the simulation. > Switching on the ERROR switch the ERROR messaes will be treated as > WARNINGS and simulation will not be stopped. > > The ASSERT will output a message and ask the user whether simulation > should be stopped. If you use the ASSERT switch the messages will be > treated as WARNINGS and simuations will not be stopped. > > ERROR and ASSERT messages can NOT be completely switched off, as they > indicate severe errors, where you SHOULD doubt the sniffer-file. > > More documentation can be found in ... > > Comments ? Looks great to me. At the moment I do not have any changes/additions. /Gerben |
|
From: Martijn K. <mk...@wi...> - 2003-12-17 18:30:14
|
Hi,
Here is the my proposal for the command-line parameters.
Everything you are missing from the old one should go into the scn-file,
or I simply forgot :-)
Wireless IP Simulator 2.1.0-mk-2
Copyright (C) 2003 WIPsim Developers (see AUTHORS)
This software is released under the GNU GPL v2.0.
Usage:
<scenario file> a scenario-file
-i, --info creates the info-file
-h, --help prints the help message
-dN,--debugN switch on debugging level
where n is
1 switch on TEST-messages
2 switch on WARNING-messages
4 switch on ERROR-messages
8 switch on ASSERT-failures
Switches can be combined, by adding them, so TEST and WARNING
can be combined as -d3
The TEST and WARNING messages can be switched off but do not
stop the simulator, while ERROR messages will stop the simulation.
Switching on the ERROR switch the ERROR messaes will be treated as
WARNINGS and simulation will not be stopped.
The ASSERT will output a message and ask the user whether simulation
should be stopped. If you use the ASSERT switch the messages will be
treated as WARNINGS and simuations will not be stopped.
ERROR and ASSERT messages can NOT be completely switched off, as they
indicate severe errors, where you SHOULD doubt the sniffer-file.
More documentation can be found in ...
Comments ?
/Martijn
|
|
From: Martijn K. <mk...@wi...> - 2003-12-17 17:46:43
|
Hi, Just a note not to expect an answer from me/or updated code untill next year :-) I will be leaving next Thursday and have lot's of things to finish before the WIPSim :-( Merry christmas and happy coding in the new year! /Martijn |
|
From: Martijn K. <mk...@wi...> - 2003-12-16 10:42:33
|
On Tue, 2003-12-16 at 07:26, Gerben Kuijpers wrote:
> On Mon, 15 Dec 2003, Martijn Kuipers wrote:
>=20
> > Hi,
> >
> > I am working on the enw sniffing framework and thought I would share
> > some of its functions with you.
> >
> > enum { NORMAL =3D 0,
> > TEST =3D 1,
> > WARNING =3D 1 << 2,
> > ERRORS =3D 1 << 3,
> > ASSERT =3D 1 << 4};
> >
> > When you use the new printf command to print there are several options
> > for its priority.
> > Test - will be printed to the logfile and simulation continues
> > Warning - will be printed to the logfile and simulation continues
> > Error - will be printed to the logfile and simulation is stopped
> > Assert - will be printed to the logfile and you will be asked if you
> > want to continue or not
> Maybe there should also be an option to automatically stop or continue on
> assertion failures. This would be nice to have when doing a large number
> of simulations using scripts, so simulation is not stopped when one of
> them fails.
Sure,this can be done.
>=20
>=20
> >
> > The simulator will have a new commandline parameter that influences wha=
t
> > info is to be printed.
> > -dn, where n is a number in [0;31], where it switches on some of the
> > messages
> Sort of a debug-level, where each message should belong to a certain
> level?
If you look at the list above you can see that
4321
||||
||| \---> Test=20
|||
||\-----> Warning=20
||
|\------> Errors=20
|
\-------> Assert
Now read this as an unsigned int[4] and you can make the numbers.
Standard we would choose all (1111 =3D 31) on, which is maybe not what you
want when scripting. With scripting (as you mentioned) you don't want to
control the assert manual, so in that case you would use (111 =3D 15) so
that Asserts are not stopped (Maybe we could make it like asserts are
not stopped, but messages are written to the log-file, since they are
pretty severe). I would like to do the same for Errors.
Erros and Asserts are/can be showstoppers. This means that Error is
really an error in the programm, and not an error in the protocol.
Example:
1. You send something to port 666 and there is no application listening
to 666, this should be triggered as a warning.
2. If you want to move the packet, but the pointer is (falsely) zero,
the this is an error and should be markes as such.
> > We will also write a small shell-script that will crossreference the lo=
g
> > file and the sniffer file. I was thinking about something like
> > xref [-s] file1.snf file2.log
> > where the output goes to standard out.
> > The -s option will give the logfile added with the 5 lines of
> > snf-actions before and 5 lines of snf-action after it. This would
> > prevent you from going to large files.
> And without the -s option? Just combining the 2 files, sorted by time?
Indeed. The thing is if you want to zoom in on the errors (and you
probably want to) then it could be easier to just have the lines arround
the errors, warnings. If the snf-file is very large, it will not be very
easy to just look at these areas. For small files, this is no problem at
all. What do you think? I thought about having another option in the
simulator, but really believe this should not be in the simulator. It is
something that can easily be done outside and gives you clear snf-files
to analyse.
>=20
> > Now a bit about sniffing...
> > You still have to derive the object you want to sniff from a class
> > (currently snifline). You can then control the sniffing from the
> > scenario file (you have to add some code, which will convert the
> > commands from the scn-file into booleans to sniff). Standard there are
> > up to 16 different messages that can be sniffed (or 16 different groups
> > to sniff). If you need more you can add some extra code and extend this
> > in your class).
> > The line you use to sniff is like a printf-line, so you have more
> > freedom how to print your message. The sniffer-class will add the time
> > for you.
> > wsPrint(Mac802_11::Data,"MAC %s data frame",mMacAddress->Print());
> > Mac802_11::Data is one of the groups you can switch on to sniff...
> >
> > You can also use dbgPrint to add messages to the log-file, but these
> > cannot be controlled from the scn-file and cannot be used for printing
> > to the snf-file. This one works like
> > dbgPrint(DBG::Error,"Some strange error in %s due to code from NOT
> > ME!!!",mName);
> > Where the DBG:Error is one of the aforementioned commands.
> >
> > /Martijn
> This sounds like a major improvement to debug output, finally getting rid
> of all the printf's!
Exactly, now there is no need to hold your own pointers to error-files,
etc... There is no need to remove usefull printf's. Evrything will be
dealt with by the simulator. I have it working now and am pretty happy
with the result. Before I release it to you I will implement the
command-line parameters. Next thing is to add the sniffing info to the
scn-file, but this is a rather large job (and seperate form what we
already have). Next thing is to move all other files to the scn-file too
(this should be trivial).
What do you want to do with the analyser?
Any chance we can rewrite these easilly in perl or something and leave
them outside the simulator?
Maybe we can have a script attached to the simulator like
./wipsim -d0 ping.scn |analyse >results.txt
where the stdout-output of the simulator is the input of the analyser,
and the analyser redirects its stdout to the text-file results.txt.
I like the analyser, but if we keep on adding modules to it for all
protocols, we make it more messy inside the simulator (me thinks).
What are your thoughts on this?
/Martijn
|
|
From: Gerben K. <gk...@ko...> - 2003-12-16 07:26:07
|
On Mon, 15 Dec 2003, Martijn Kuipers wrote:
> Hi,
>
> I am working on the enw sniffing framework and thought I would share
> some of its functions with you.
>
> enum { NORMAL = 0,
> TEST = 1,
> WARNING = 1 << 2,
> ERRORS = 1 << 3,
> ASSERT = 1 << 4};
>
> When you use the new printf command to print there are several options
> for its priority.
> Test - will be printed to the logfile and simulation continues
> Warning - will be printed to the logfile and simulation continues
> Error - will be printed to the logfile and simulation is stopped
> Assert - will be printed to the logfile and you will be asked if you
> want to continue or not
Maybe there should also be an option to automatically stop or continue on
assertion failures. This would be nice to have when doing a large number
of simulations using scripts, so simulation is not stopped when one of
them fails.
>
> The simulator will have a new commandline parameter that influences what
> info is to be printed.
> -dn, where n is a number in [0;31], where it switches on some of the
> messages
Sort of a debug-level, where each message should belong to a certain
level?
> We will also write a small shell-script that will crossreference the log
> file and the sniffer file. I was thinking about something like
> xref [-s] file1.snf file2.log
> where the output goes to standard out.
> The -s option will give the logfile added with the 5 lines of
> snf-actions before and 5 lines of snf-action after it. This would
> prevent you from going to large files.
And without the -s option? Just combining the 2 files, sorted by time?
> Now a bit about sniffing...
> You still have to derive the object you want to sniff from a class
> (currently snifline). You can then control the sniffing from the
> scenario file (you have to add some code, which will convert the
> commands from the scn-file into booleans to sniff). Standard there are
> up to 16 different messages that can be sniffed (or 16 different groups
> to sniff). If you need more you can add some extra code and extend this
> in your class).
> The line you use to sniff is like a printf-line, so you have more
> freedom how to print your message. The sniffer-class will add the time
> for you.
> wsPrint(Mac802_11::Data,"MAC %s data frame",mMacAddress->Print());
> Mac802_11::Data is one of the groups you can switch on to sniff...
>
> You can also use dbgPrint to add messages to the log-file, but these
> cannot be controlled from the scn-file and cannot be used for printing
> to the snf-file. This one works like
> dbgPrint(DBG::Error,"Some strange error in %s due to code from NOT
> ME!!!",mName);
> Where the DBG:Error is one of the aforementioned commands.
>
> /Martijn
This sounds like a major improvement to debug output, finally getting rid
of all the printf's!
/Gerben
|
|
From: Martijn K. <mk...@wi...> - 2003-12-15 18:25:00
|
Hi,
I am working on the enw sniffing framework and thought I would share
some of its functions with you.
enum { NORMAL =3D 0,
TEST =3D 1,
WARNING =3D 1 << 2,
ERRORS =3D 1 << 3,
ASSERT =3D 1 << 4};
When you use the new printf command to print there are several options
for its priority.
Test - will be printed to the logfile and simulation continues
Warning - will be printed to the logfile and simulation continues
Error - will be printed to the logfile and simulation is stopped
Assert - will be printed to the logfile and you will be asked if you
want to continue or not
The simulator will have a new commandline parameter that influences what
info is to be printed.
-dn, where n is a number in [0;31], where it switches on some of the
messages
We will also write a small shell-script that will crossreference the log
file and the sniffer file. I was thinking about something like
xref [-s] file1.snf file2.log=20
where the output goes to standard out.
The -s option will give the logfile added with the 5 lines of
snf-actions before and 5 lines of snf-action after it. This would
prevent you from going to large files.
Now a bit about sniffing...
You still have to derive the object you want to sniff from a class
(currently snifline). You can then control the sniffing from the
scenario file (you have to add some code, which will convert the
commands from the scn-file into booleans to sniff). Standard there are
up to 16 different messages that can be sniffed (or 16 different groups
to sniff). If you need more you can add some extra code and extend this
in your class).
The line you use to sniff is like a printf-line, so you have more
freedom how to print your message. The sniffer-class will add the time
for you.
wsPrint(Mac802_11::Data,"MAC %s data frame",mMacAddress->Print());
Mac802_11::Data is one of the groups you can switch on to sniff...
You can also use dbgPrint to add messages to the log-file, but these
cannot be controlled from the scn-file and cannot be used for printing
to the snf-file. This one works like
dbgPrint(DBG::Error,"Some strange error in %s due to code from NOT
ME!!!",mName);
Where the DBG:Error is one of the aforementioned commands.
/Martijn
|
|
From: Martijn K. <mk...@wi...> - 2003-12-15 17:04:22
|
On Mon, 2003-12-15 at 16:35, Gerben Kuijpers wrote: > On Mon, 15 Dec 2003, Martijn Kuipers wrote: >=20 > > On Mon, 2003-12-15 at 15:34, Gerben Kuijpers wrote: > > > Hi, > > > > > > Currently, the scheduler will give a general warning when an event is > > > scheduled with a delay < 0 or when trying to schedule an event that i= s > > > already scheduled. No information is provided about the specific even= t. > > > Extra information will speed up debugging. This can be done in differ= ent > > > ways: > > > > > > 1. An event-ID can be added to each event, with a unique identifier f= or > > > each event, so the scheduler can output which event caused a scheduli= ng > > > problem. However, this means that more memory is used by each event a= nd > > > specially for small active classes, this might be unacceptable. > > I was also thinking about adding a name/identifier for each class (as a > > static) so we can identify classes. This way if we get an > > assertion-failure or other weird error, we can produce adequate > > information where to look. > Ofcourse it is also possible to combine this with the extra function > (option 2). The identifier can then be outputted by the error-function. It should be. I was just arguing in favour of being able to identify the corrupting class somewhere. >=20 > > > > > 2. Add two virtual functions to cActive (one for AlreadyScheduled and= one > > > for ScheduledInPast). By default these functions are empty, but each > > > derived class that wants to add additional information can re-impleme= nt > > > the functions and add as much information as needed. The functions on= ly > > > take up space once per active class and not per instance. > > How about a debug function, which prints out all kind of information of > > the class. The scheduler can easy say if it was because of prior > > scheduling or scheduling in the past > So, first the scheduler outputs some error and then calls the Debug > function of the active class? Yes, but the action depends on the error I guess (or on the error-level). I have classified debugging info under: normal, warning, error, test Normal: no debug information is outputted Warning: Warnings are printed Error: Error is printed, execution is stopped Test: Just something to be able to add some printf info to the simulator for extra investigations. >=20 >=20 > > > > > My preference is for option 2, since it is easy to extend and does no= t > > > require any significant changes to the simulator. What do you think? > > > > > We used to have a reason that a class can only be scheduled once. This > > so at a later time it will not be scheduled before the already schedule= d > > item. > > I am inclined to have an extra identifier in the active class which > > tells you if the class has to be scheduled uniquely or can be scheduled > > more than once. There are a number of events which can be easily > > scheduled more than once (source application is one). > I think we should be very careful with this. So far, the errors from the > scheduler have helped me to avoid some nasty bugs. Scheduling more than > once should only be used if really necessary. For a source application, > the next event can just as easily be scheduled in the current event > function. Scheduling each class only once will also reduce the memory > usage of the scheduler. Hmm, I guess I could implement it with a lot of RunOnce actives (which are destructed at the end of the event). Forgot about that option...look into it. /Martijn |
|
From: Gerben K. <gk...@ko...> - 2003-12-15 16:35:36
|
On Mon, 15 Dec 2003, Martijn Kuipers wrote: > On Mon, 2003-12-15 at 15:34, Gerben Kuijpers wrote: > > Hi, > > > > Currently, the scheduler will give a general warning when an event is > > scheduled with a delay < 0 or when trying to schedule an event that is > > already scheduled. No information is provided about the specific event. > > Extra information will speed up debugging. This can be done in different > > ways: > > > > 1. An event-ID can be added to each event, with a unique identifier for > > each event, so the scheduler can output which event caused a scheduling > > problem. However, this means that more memory is used by each event and > > specially for small active classes, this might be unacceptable. > I was also thinking about adding a name/identifier for each class (as a > static) so we can identify classes. This way if we get an > assertion-failure or other weird error, we can produce adequate > information where to look. Ofcourse it is also possible to combine this with the extra function (option 2). The identifier can then be outputted by the error-function. > > > 2. Add two virtual functions to cActive (one for AlreadyScheduled and one > > for ScheduledInPast). By default these functions are empty, but each > > derived class that wants to add additional information can re-implement > > the functions and add as much information as needed. The functions only > > take up space once per active class and not per instance. > How about a debug function, which prints out all kind of information of > the class. The scheduler can easy say if it was because of prior > scheduling or scheduling in the past So, first the scheduler outputs some error and then calls the Debug function of the active class? > > > My preference is for option 2, since it is easy to extend and does not > > require any significant changes to the simulator. What do you think? > > > We used to have a reason that a class can only be scheduled once. This > so at a later time it will not be scheduled before the already scheduled > item. > I am inclined to have an extra identifier in the active class which > tells you if the class has to be scheduled uniquely or can be scheduled > more than once. There are a number of events which can be easily > scheduled more than once (source application is one). I think we should be very careful with this. So far, the errors from the scheduler have helped me to avoid some nasty bugs. Scheduling more than once should only be used if really necessary. For a source application, the next event can just as easily be scheduled in the current event function. Scheduling each class only once will also reduce the memory usage of the scheduler. > /Martijn > P.S. I have reworked sniffing quite a bit and added a log-file. We can > now even print to the logfile from anywhere in the code also to aide in > debugging. I hope to give you a sneak-peek this week (I started with the > 802.11 mac and it looks pretty clean with th enew sniffing :-) Nice! /Gerben |
|
From: Martijn K. <mk...@wi...> - 2003-12-15 16:11:09
|
On Mon, 2003-12-15 at 15:34, Gerben Kuijpers wrote: > Hi, >=20 > Currently, the scheduler will give a general warning when an event is > scheduled with a delay < 0 or when trying to schedule an event that is > already scheduled. No information is provided about the specific event. > Extra information will speed up debugging. This can be done in different > ways: >=20 > 1. An event-ID can be added to each event, with a unique identifier for > each event, so the scheduler can output which event caused a scheduling > problem. However, this means that more memory is used by each event and > specially for small active classes, this might be unacceptable. I was also thinking about adding a name/identifier for each class (as a static) so we can identify classes. This way if we get an assertion-failure or other weird error, we can produce adequate information where to look. > 2. Add two virtual functions to cActive (one for AlreadyScheduled and one > for ScheduledInPast). By default these functions are empty, but each > derived class that wants to add additional information can re-implement > the functions and add as much information as needed. The functions only > take up space once per active class and not per instance. How about a debug function, which prints out all kind of information of the class. The scheduler can easy say if it was because of prior scheduling or scheduling in the past > My preference is for option 2, since it is easy to extend and does not > require any significant changes to the simulator. What do you think? >=20 We used to have a reason that a class can only be scheduled once. This so at a later time it will not be scheduled before the already scheduled item.=20 I am inclined to have an extra identifier in the active class which tells you if the class has to be scheduled uniquely or can be scheduled more than once. There are a number of events which can be easily scheduled more than once (source application is one). /Martijn P.S. I have reworked sniffing quite a bit and added a log-file. We can now even print to the logfile from anywhere in the code also to aide in debugging. I hope to give you a sneak-peek this week (I started with the 802.11 mac and it looks pretty clean with th enew sniffing :-) |
|
From: Gerben K. <gk...@ko...> - 2003-12-15 15:34:14
|
Hi, Currently, the scheduler will give a general warning when an event is scheduled with a delay < 0 or when trying to schedule an event that is already scheduled. No information is provided about the specific event. Extra information will speed up debugging. This can be done in different ways: 1. An event-ID can be added to each event, with a unique identifier for each event, so the scheduler can output which event caused a scheduling problem. However, this means that more memory is used by each event and specially for small active classes, this might be unacceptable. 2. Add two virtual functions to cActive (one for AlreadyScheduled and one for ScheduledInPast). By default these functions are empty, but each derived class that wants to add additional information can re-implement the functions and add as much information as needed. The functions only take up space once per active class and not per instance. My preference is for option 2, since it is easy to extend and does not require any significant changes to the simulator. What do you think? /Gerben |
|
From: Gerben K. <gk...@ko...> - 2003-11-28 12:21:05
|
> Ok. But shouldn't this be in the cfg-file. You can easilly make a few
> bt-prots, with different variables. And/or override them in the network
> file. Perhaps you would like to override them in de scn-file.
> In that case the order would be:
> cfg-file
> nwk-file
> scn-file
> to parse all the parameters. (I am going to have to rewrite init anyway
> :-( )
Ok, think this belongs in the cfg-file. The list of parameters could get
quite long maybe, but this is probably no problem. Overriding parameters
in the scn-file would maybe be nice if we want to change parameters at a
certain time. For now I can not see any use for this, but maybe someone
would like it later.
Don't forget the comments when you rewrite cInit :)
> 1. So we need to derive cSniff from cList<cSniffElem>
> 2. Add a function to cSniffElem that call SniffOn(char *Id);
> 3. Add a function to cSniffElem that call SniffOff(char *Id);
> 4. cSniffElem should call a virtual function of cSniffElem that has to
> be reimplemented in every class to recognise the char *Id and do the
> right thing
> 5. When you sniff, you call your 'own' Sniff("Ready to talk about frame
> %d", pFrame->Id()) stuff. This function parses everything into a string
> and calls Sniff function in cSniff
> 6. cSniff prints the time, adds the string, adds '\n' and if needed
> flush. We should probably make two functions here that doe this. One
> which flushes and on that doesn't. We can then make cSniff call one
> function without checking (just set the address of the function to be
> called in Sniff).
>
> Anything else ... ?
Seems quite complete to me.
/Gerben
|
|
From: Martijn K. <mar...@lx...> - 2003-11-28 10:25:35
|
On Fri, 2003-11-28 at 07:54, Gerben Kuijpers wrote:
> > By masking the correct bit in an unsigned __int16 you actually have a
> > array of 16 bools of 1 bit.
> > Also nice, you can write things like
> > // unsigned __int16 SniffArray filled during initialisation
> > // SEND = 0x00;
> > // RECV = 0x01;
> > // DROP = 0x02;
> > // ACK = 0x04;
> > // ALL = 0xFF;
> >
> > if (SniffArray && (SEND|RECV|ACK))
> > pSniff->Sniff("something to write about");
> Ok, but do you want to put the check for each sniff event in the cSniff
> class or just in the class that calls the Sniff function? If you use the
> latter, you can add any checks you want and thus have as many different
> sniff-events as necessary. Moreover, where do we put the static __int16
> SniffArray? If we put it in cSniffLine, we will only have 16 sniff events
> for the whole simulator, so I guess it needs to be added to the
> derived class itself.
I was thinking about having two checks.
1. Should I bother checking the layer
2. If 1 == yes, check the layer
But I guess you are right. It is probably easier/faster to have it check
locally.
>
> > > > // Maybe we can add some static configuration stuff (can't think of
> > > > // any right now)
> > > I can. This could for example be some general protocol parameters that are
> > > the same for each node. Currently this is passed to each node using the
> > > cfg and nwk file. This information could be passed here instead. Another
> > > possibility would be to extend the prot-statement with some information
> > > that is passed only once to some information base of a specific protocol.
> > Hmm. I kind of like the cfg-file, exactly because you can specify
> > configurations there. What kind of information are you talking about?
> > Maybe I will understand it better...
> Typically information that currently is defined in .h files (using const's
> and #define's), but would be nice to be able to change without recompiling
> and are typically the same for all instances of a protocol/mechanism. Some
> examples:
>
> 802_11 MAC: RTS Threshold, which controls whether RTS/CTS is used or not
> (0 = use always, 2347 (default) = use never).
>
> Routing protocols: various protocol constants such as message intervals,
> time outs, which all have a default value, but for research purposes it
> can be nice to try to tune them.
>
> Bluetooth: e.g. beacon intervals, number of beacons, beacon spacing, sniff
> interval. However, currently the same values are used for all
> nodes/piconets, but this is not necessary, so maybe these parameters
> should still be configured using the network file.
Ok. But shouldn't this be in the cfg-file. You can easilly make a few
bt-prots, with different variables. And/or override them in the network
file. Perhaps you would like to override them in de scn-file.
In that case the order would be:
cfg-file
nwk-file
scn-file
to parse all the parameters. (I am going to have to rewrite init anyway
:-( )
>
> > I am in favour of breaking compatibility. We could/should write a small
> > shell-script to convert your old lines to new scenario-files.
> > scn-update scripts/examples.cfg scripts/bridge.nwk scripts/ping.scn
> > scripts/bridge.snf -mac -snk -drp -rt -snd -bt
> >
> > would
> > - rename ping.scn ping.scn.old
> > - create a new ping.scn with all the new-style files in it.
> >
> > This should not be too difficult to create and we can immediatelly clean
> > the simulator of old confusing code.
> Ok, after we made the changes, I can put together a Perl script to convert
> this, should not be any problem.
Deal :-)
Can we zoom in on a solution for the sniff-framework. The following
things are needed:
- a hook into the class to turn on/off sniffing (from the scn-file)
- a function that calls cSniff for the actual printing.
- we have to give each layer/class a name now (802_11 should be called
802.11, ...etc) This so you can say: 0.00 snf MAC 802.11 +ALL
- a list of all sniffable classes
1. So we need to derive cSniff from cList<cSniffElem>
2. Add a function to cSniffElem that call SniffOn(char *Id);
3. Add a function to cSniffElem that call SniffOff(char *Id);
4. cSniffElem should call a virtual function of cSniffElem that has to
be reimplemented in every class to recognise the char *Id and do the
right thing
5. When you sniff, you call your 'own' Sniff("Ready to talk about frame
%d", pFrame->Id()) stuff. This function parses everything into a string
and calls Sniff function in cSniff
6. cSniff prints the time, adds the string, adds '\n' and if needed
flush. We should probably make two functions here that doe this. One
which flushes and on that doesn't. We can then make cSniff call one
function without checking (just set the address of the function to be
called in Sniff).
Anything else ... ?
/Martijn
|
|
From: Gerben K. <gk...@ko...> - 2003-11-28 07:54:31
|
> By masking the correct bit in an unsigned __int16 you actually have a
> array of 16 bools of 1 bit.
> Also nice, you can write things like
> // unsigned __int16 SniffArray filled during initialisation
> // SEND = 0x00;
> // RECV = 0x01;
> // DROP = 0x02;
> // ACK = 0x04;
> // ALL = 0xFF;
>
> if (SniffArray && (SEND|RECV|ACK))
> pSniff->Sniff("something to write about");
Ok, but do you want to put the check for each sniff event in the cSniff
class or just in the class that calls the Sniff function? If you use the
latter, you can add any checks you want and thus have as many different
sniff-events as necessary. Moreover, where do we put the static __int16
SniffArray? If we put it in cSniffLine, we will only have 16 sniff events
for the whole simulator, so I guess it needs to be added to the
derived class itself.
> > > // Maybe we can add some static configuration stuff (can't think of
> > > // any right now)
> > I can. This could for example be some general protocol parameters that are
> > the same for each node. Currently this is passed to each node using the
> > cfg and nwk file. This information could be passed here instead. Another
> > possibility would be to extend the prot-statement with some information
> > that is passed only once to some information base of a specific protocol.
> Hmm. I kind of like the cfg-file, exactly because you can specify
> configurations there. What kind of information are you talking about?
> Maybe I will understand it better...
Typically information that currently is defined in .h files (using const's
and #define's), but would be nice to be able to change without recompiling
and are typically the same for all instances of a protocol/mechanism. Some
examples:
802_11 MAC: RTS Threshold, which controls whether RTS/CTS is used or not
(0 = use always, 2347 (default) = use never).
Routing protocols: various protocol constants such as message intervals,
time outs, which all have a default value, but for research purposes it
can be nice to try to tune them.
Bluetooth: e.g. beacon intervals, number of beacons, beacon spacing, sniff
interval. However, currently the same values are used for all
nodes/piconets, but this is not necessary, so maybe these parameters
should still be configured using the network file.
> I am in favour of breaking compatibility. We could/should write a small
> shell-script to convert your old lines to new scenario-files.
> scn-update scripts/examples.cfg scripts/bridge.nwk scripts/ping.scn
> scripts/bridge.snf -mac -snk -drp -rt -snd -bt
>
> would
> - rename ping.scn ping.scn.old
> - create a new ping.scn with all the new-style files in it.
>
> This should not be too difficult to create and we can immediatelly clean
> the simulator of old confusing code.
Ok, after we made the changes, I can put together a Perl script to convert
this, should not be any problem.
/Gerben
|
|
From: Gerben K. <gk...@ko...> - 2003-11-27 20:46:12
|
> > > Each class also needs a standard framework to store the > > > sniff-information. I guess that a __int16 would give you 16 different > > > sniff-event, which should be more than enough (since it is static for > > > all similair classes, it only takes 16 bits once). > > 65536 Sniff events in WIPSIM should be enough for everyone! :) > Nope, 16 events per class/protocol. Because you want to use each bit > from the __int16 as a boolean, so you can sniff more than 1 event from > bluetooth (send, recv, ...whatever, but up to 16). Ok, think this should be enough. Otherwise it is always possible to add another class just for sniffing more events. Another possibility would be to use an array of bools, similar to how this is used in cSniff today. The number of bools can than be varied according to which class is used. > > 3. Warnings and Errors: used to indicate (to both user and developer) that > > something might go wrong or went wrong. > Maybe we could add a weight to it. > For instance > -dbg or -dbg0 - write to stdout > -dbg1 - write to stderr > > For me it makes sense to have debug info send to stderr (prefix [DEBUG] > or something), because it is often this info together with the > warnings/errors will tell you what has happened. Let's write debug output to stderr. > Come to think of it: > It makes sense to me to have the .nwk, .cfg and .snf file mentioned in > the .scn file. Something like: > //---------------------------- > // This is the scenario-file > use cfg examples.cfg // optional > use nwk bridge.nwk > use snf bridge_out.txt //or whatever) > use seed 0x1234 // optional > snf MAC BT +ALL > snf MAC 802.11 +ALL > snf DLC 802.11 +ALL > snf APP ping +snd +rcv This would definitely be nice. Trying to get rid of as many command line parameters as possible. > // Maybe we can add some static configuration stuff (can't think of > // any right now) I can. This could for example be some general protocol parameters that are the same for each node. Currently this is passed to each node using the cfg and nwk file. This information could be passed here instead. Another possibility would be to extend the prot-statement with some information that is passed only once to some information base of a specific protocol. > // Followed by what we already have: > 0.000 app Ping ::1 ::2 1 > 50.00 stop > //---------------------------- > > This way you can start the simulator by: > ./wipsim bridge.scn -dbg > > Does this sound like a plan (yes, I really got tired of typing things > like: > ./src/wipsim scripts/examples.cfg scripts/bridge.nwk scripts/ping.scn > scripts/bridge.snf -mac -snk -drp -rt -snd -bt) > > The only parameters we have are then > scenario-file // No need to have special file extensions > -dbg[0/1] // debugging stuff > -df // direct flush all output > -info [filename] // make a info-file This sounds like a very good plan. Should we leave the old style command-line parameter passing in the simulator for a short while, so there's backward compatibility? /Gerben |
|
From: Martijn K. <mar...@lx...> - 2003-11-27 14:40:47
|
On Thu, 2003-11-27 at 14:02, Gerben Kuijpers wrote:
> Hi,
>
> Good idea to improve the sniff-framework. Had been thinking about that as
> well. Currently there are two different ways of writing information in the
> sniff-file:
>
> 1. Individual events, that are written to the sniff-file by calling one of
> the functions of cSniff.
These are the ones I want to put in the new framework
> 2. Combined statistics on e.g. control traffic in AODV, which is collected
> by local sniff modules. The sniff modules are typically implemented as a
> singleton class. At the end of the simulation the cSniff module calls all
> local sniff modules so they can write all the collected information to the
> sniff-file.
I don't want to touch these (for now at least).
> > I am becoming more in favour of a printf-like function.
> > Maybe somthing like
> > sniff(SEND,"Sending frame %d of length %f",cFrame->Id(),
> > cFrame->Size());
> This looks like a good idea to me. This way, the cSniff class does not
> need to have a large number of functions and more important, it does not
> need to know the details of the different protocols. Currently the cSniff
> class calls functions of cFrame, cPacket etc.
Ok, so we go this way...
> > Since the sniff function is a private-derived function of cSniffElem,
> > the class from where it is called can easilly convert this into this:
> > cSniff->Sniff("Sending frame 2 of length 24");
> Another advantage of having the class from where the sniff is called
> handle the details, is that you can more easily fine tune what is
> outputted to the sniff file on a per-event basis.
Exactly, make testing/debugging more easy for the developper.
> Normally C uses block I/O to write to files, meaning
> > only after some bytes (4096) are written to a file, the data will be
> > transfered to disk. We could force a data transfer each time by calling
> > fflush(), but this would slow things down, as disk access is a slow
> > process. Again, for this we could make an option (-df, direct flush).
> Although this can be nice for debugging purposes sometimes, this is IMO
> not a high priority feature. If you are debugging and need all output that
> is sent to the sniff file until you arrive at a breakpoint (or crash) you
> can always just output the sniff to STDOUT instead. At least that works
> fine for me.
As far as I know, stdout behaves just like a file...so maybe adding this
as a parameter would not hurt anyone. I guess we can do this in a smart
way, with a check ones and after that just use the function by its
pointer.
> > Each class also needs a standard framework to store the
> > sniff-information. I guess that a __int16 would give you 16 different
> > sniff-event, which should be more than enough (since it is static for
> > all similair classes, it only takes 16 bits once).
> 65536 Sniff events in WIPSIM should be enough for everyone! :)
Nope, 16 events per class/protocol. Because you want to use each bit
from the __int16 as a boolean, so you can sniff more than 1 event from
bluetooth (send, recv, ...whatever, but up to 16).
>
> > So instead of having all these command-line parameters, I would like to
> > propose to add the following statements to the scn-file.
> >
> > 0.00 snf MAC BT +ALL
> > would turn on all bluetooth sniffing (I guess that using MAC or DLC for
> > BT would have the same effect), and
> >
> > 0.00 snf MAC 802.11 +rcv
> > would turn on sniffing for all recv events of the 802.11 mac
> >
> > 1.00 snf MAC 802.11 -ALL
> > would turn off all sniffing for 802.11
> >
> > Similair you could switch on debugging info for for instance the ping
> > application by
> > 0.00 dbg app ping
> >
> > So what is the difference between dbg and snf?
> > Well, snf either goes to stdout or to the sniff-file, while sbg goes to
> > stderr (or to a dbg file if you wish, because I am not sure whether
> > windows has stderr).
> Windows has stderr as well.
Learn somethng new every time ...
> But I'm not sure we should send debug output to stderr. In my view there's
> three types of output of the simulator:
> 1. Sniff events: used to evaluate the performance of protocols, when
> running the simulator for its right purpose. This output can be used by
> users of the simulator and for developers to do functional tests of the
> implementation of a specific protocol (black box testing).
>
> 2. Debug output: used to check the implementation of specific protocols by
> the developers (white box testing). This output is not supposed to be used
> in stable versions of the simulator.
>
> 3. Warnings and Errors: used to indicate (to both user and developer) that
> something might go wrong or went wrong.
Maybe we could add a weight to it.
For instance
-dbg or -dbg0 - write to stdout
-dbg1 - write to stderr
For me it makes sense to have debug info send to stderr (prefix [DEBUG]
or something), because it is often this info together with the
warnings/errors will tell you what has happened.
> the 3rd type definitely should be sent to stderr, but I'm in doubt about
> number 2. Do we need seperate files for debug output / warning and errors?
I hope not, I am trying to reduce the number of parameters. So far we
already have some files:
.nwk, .cfg, .scn, .snf of which only .cfg is optional.
Come to think of it:
It makes sense to me to have the .nwk, .cfg and .snf file mentioned in
the .scn file. Something like:
//----------------------------
// This is the scenario-file
use cfg examples.cfg // optional
use nwk bridge.nwk
use snf bridge_out.txt //or whatever)
use seed 0x1234 // optional
snf MAC BT +ALL
snf MAC 802.11 +ALL
snf DLC 802.11 +ALL
snf APP ping +snd +rcv
// Maybe we can add some static configuration stuff (can't think of
// any right now)
// Followed by what we already have:
0.000 app Ping ::1 ::2 1
50.00 stop
//----------------------------
This way you can start the simulator by:
./wipsim bridge.scn -dbg
Does this sound like a plan (yes, I really got tired of typing things
like:
./src/wipsim scripts/examples.cfg scripts/bridge.nwk scripts/ping.scn
scripts/bridge.snf -mac -snk -drp -rt -snd -bt)
The only parameters we have are then
scenario-file // No need to have special file extensions
-dbg[0/1] // debugging stuff
-df // direct flush all output
-info [filename] // make a info-file
/Martijn
|
|
From: Gerben K. <gk...@ko...> - 2003-11-27 14:02:09
|
Hi,
Good idea to improve the sniff-framework. Had been thinking about that as
well. Currently there are two different ways of writing information in the
sniff-file:
1. Individual events, that are written to the sniff-file by calling one of
the functions of cSniff.
2. Combined statistics on e.g. control traffic in AODV, which is collected
by local sniff modules. The sniff modules are typically implemented as a
singleton class. At the end of the simulation the cSniff module calls all
local sniff modules so they can write all the collected information to the
sniff-file.
> I am becoming more in favour of a printf-like function.
> Maybe somthing like
> sniff(SEND,"Sending frame %d of length %f",cFrame->Id(),
> cFrame->Size());
This looks like a good idea to me. This way, the cSniff class does not
need to have a large number of functions and more important, it does not
need to know the details of the different protocols. Currently the cSniff
class calls functions of cFrame, cPacket etc.
The local sniff modules use a somewhat simular approach, where they can
write just about anything to the sniff-file, e.g:
sprintf(pStr, "Number of route discoveries:\t%d", mNumRouteDisc);
pSniff->SniffComment(pStr);
The SniffComment function only adds "\n//" in front of the comment that is
written to the sniff-file. Since this type of information is always
written at the end of the simulation, the time is not needed in this case.
> Since the sniff function is a private-derived function of cSniffElem,
> the class from where it is called can easilly convert this into this:
> cSniff->Sniff("Sending frame 2 of length 24");
Another advantage of having the class from where the sniff is called
handle the details, is that you can more easily fine tune what is
outputted to the sniff file on a per-event basis.
> Still the time will be put in front by cSniff, as well a '\n' will be
> added at the end. Normally C uses block I/O to write to files, meaning
> only after some bytes (4096) are written to a file, the data will be
> transfered to disk. We could force a data transfer each time by calling
> fflush(), but this would slow things down, as disk access is a slow
> process. Again, for this we could make an option (-df, direct flush).
Although this can be nice for debugging purposes sometimes, this is IMO
not a high priority feature. If you are debugging and need all output that
is sent to the sniff file until you arrive at a breakpoint (or crash) you
can always just output the sniff to STDOUT instead. At least that works
fine for me.
> Of course, only generate the string after checking locally if it needs
> to be sniffed!
>
> This means that every class that can sniff gets a few extra functions,
> like:
> void SetSniff(char *Event);
> void ClearSniff(char *Event);
> (No need for a get-function as the class can access the private
> variables directly)
>
> Each class also needs a standard framework to store the
> sniff-information. I guess that a __int16 would give you 16 different
> sniff-event, which should be more than enough (since it is static for
> all similair classes, it only takes 16 bits once).
65536 Sniff events in WIPSIM should be enough for everyone! :)
>
> So instead of having all these command-line parameters, I would like to
> propose to add the following statements to the scn-file.
>
> 0.00 snf MAC BT +ALL
> would turn on all bluetooth sniffing (I guess that using MAC or DLC for
> BT would have the same effect), and
>
> 0.00 snf MAC 802.11 +rcv
> would turn on sniffing for all recv events of the 802.11 mac
>
> 1.00 snf MAC 802.11 -ALL
> would turn off all sniffing for 802.11
>
> Similair you could switch on debugging info for for instance the ping
> application by
> 0.00 dbg app ping
>
> So what is the difference between dbg and snf?
> Well, snf either goes to stdout or to the sniff-file, while sbg goes to
> stderr (or to a dbg file if you wish, because I am not sure whether
> windows has stderr).
Windows has stderr as well.
But I'm not sure we should send debug output to stderr. In my view there's
three types of output of the simulator:
1. Sniff events: used to evaluate the performance of protocols, when
running the simulator for its right purpose. This output can be used by
users of the simulator and for developers to do functional tests of the
implementation of a specific protocol (black box testing).
2. Debug output: used to check the implementation of specific protocols by
the developers (white box testing). This output is not supposed to be used
in stable versions of the simulator.
3. Warnings and Errors: used to indicate (to both user and developer) that
something might go wrong or went wrong.
the 3rd type definitely should be sent to stderr, but I'm in doubt about
number 2. Do we need seperate files for debug output / warning and errors?
/Gerben
|
