Description: Ver: 0.0.2, 0.0.3, 0.0.4, 0.0.5, 0.0.6, 0.0.7, 0.0.8, 1.1.0
Zip File for above source code
This version 0.0.2 is used for test channel
throughput while RSSI value of the transmitting STA is varying.
Thus, it has 2 C programs as test_rx.c and test_tx.c. both program should be
synced with the 1second timer by a "SIGNAL"
test_rx.c
test_tx.c
rn1.dat
rn1.dat store 1000 random numbers between 1-1500. Actually, the channel will be
saturated when it goes to 400 packets per second. Thus, 1000 is enough and be
rotationally used.
test_tx.c is first sending a START signal to the receiving STA (10.0.0.1),after
1 second, it sending N packets per second periodically, RSSI value will vary
when I moving the STA (laptop).
test_rx.c is first started to wait for the START signal, after receive it, it
will prepare to record the number of received bytes.
Finally, both test_rx and test_tx program should terminate with a TEST_END
message.
The receiving program will terminate after receiving the "TEST_END" message or 1
second after the time duration expired.
the way to run test is described as below:
1. Start test_rx on receiving node first,
$test_rx
2. Start test_tx program on sending node then.
$ test_tx 530 10 10.0.0.7
the first parameter of the command above is the packets per second, each packet
has a length between 0 and 1500
the second parameter is about the time duration in seconds
the third parameter is the IP address of the receiving node
This version is using blocking socket recvfrom().
So, it has a major problem means that if there are no data coming more than 1
second, the recvfrom() function itself will block for >1 second, then it miss
the signal() change for once, and it miss the time count K, so finally it will
block and hang up because no data was sending and the recvfrom still blocks.
so, this version is not good.
Jan. 27 2003
version 0.0.3 has an advantage to version 0.0.2
it use select() function, eliminating a bug which is in 0.0.2.
The recvfrom() function in datagram server will no longer block the server
program (test_rx).
This version 0.0.3 is used for test channel throughput while RSSI value of the
transmitting
STA is varing.
Thus, it has 2 C programs as test_rx.c and test_tx.c
both program should be synced with the 1second timer by a "SIGNAL"
test_rx.c
test_tx.c
rn1.dat
rn1.dat store 10000 random numbers between 1-1500. Actually, the chanel will be
saturated when it goes to 400 packets per second. Thus, 1000 is enongh and be
rotationally used.
test_tx.c is first sending a START signal to the reciveing STA (10.0.0.1),after
1 second, it sending N packets per second periodically, RSSI value will vary
when I moving the STA (laptop).
test_rx.c is first started to wait for the START signal, after receive it, it
will prepare to record the number of received bytes.
Finally, both test_rx and test_tx program should terminate with a TEST_END
message.
The receving program will terminate after receving the "TEST_END" message or 1
second after the time duration expired.
(new change from v0.0.2 is to adding select() tp avoid socket blocking )
the way to run test is described as below:
1. Start test_rx on receiving node first,
$test_rx
2. Start test_tx program on sending node then.
$ test_tx 530 10 10.0.0.7
the first parameter of the command above is the packets per second, each packet
has a length between 0 and 1500
the second parameter is about the time duration in seconds
the third parameter is the IP address of the receiving node
tips to use select() and signal in the same program
------------------------------------------------------
signal and select() are both used in test_rx.c
thus, select will fail and return -1 when signal is caught.
In my program, the solution it's to ignore this error, and call select
repetitively.
however, the all parameters select used are lost when select fails. so we
re-assign
them every time when select() is called.
PKT_SCH_0.0.4
This version 0.0.4 is obsolete.
I had thought to use only select() to co-ordinate the 1 sec time period "signal"
or
"interrupt" to make 1-sec statistics.
However, select will re-start the timer whenever it receiving a packet, so it is
impossible to keep
socket behavior independent with the timer.
Thus, I have to use signal() although signal() may be caught to lead a select()
failure.
Finally, version 0.0.3 is still a better way to be robust to handle all
situations.
กก
version 0.0.5 is an improved version than 0.0.3
it could distinguish packets from different nodes such as 10.0.0.2 and 10.0.0.3,
and statisically them into flow.dat.
Version 0.0.6 is a different version from 0.0.5
both test_rx.c and test_tx.c are changed.
the test START message is no longer sent by the Tx node, but by the only one Rx
node instead.
This node sync all Tx_node by START message with parameters , one by one.
the parameters are stored in rx.conf file.
-----------------------------------------------------------------------------
the way to run test is described as below:
-------------------------------------------------------
1. Start test_tx on sending nodes first,
$test_tx
2. Start test_rx program on master (receiving) node then.
$ test_tx 10 rx.conf
the first parameter is about the time duration in seconds
the second parameter is the filename of configuration file
rx.conf is in the format below:
$cat rx.conf
10.0.0.2 100
10.0.0.3 100
10.0.0.4 150
$
the first item is the IP address of the sending node, the second item is the
packet_rate
distributed to this node.
กก
Version 0.0.7 is an improved version than 0.0.5
its major purpose is to distribute the packets uniformly in the 1-seond
time-duration.
In last version, packets are generated continuously and swarmed into the driver
program immediately after the "START" command.
Here, we adopt a new way to schedule , e.g. 100 10-ms timer to generate traffic.
The pps rate N is divide 1000, and we will using a timer value approximate to
the times of
10ms.
Another important modification is that I'm going to remove 1-sec time
preparation period in
this version.
It means Tx and Rx node will immediately send and recv packets after the "START"
message.
tips to use setitimer function
-------------------------------------------
here, when timer is due, it will generate a SIGALARM.
And the two timerval in the struct itimer is different, the first one is next
set value,
the second one is current timer_set. we set both as 10ms, then the timer will
repeat forever.
version 0.0.8 is an combination of 0.0.6 and
0.0.7.
From 0.0.7, packets are successfully distributed within the 1s period.
in 0.0.8, a central-control version is more suitable to test one rx---many tx
scenario.
also, rx_conf file is used to configuration the multiple nodes.
Feb.25,2003 Zhibin Wu
PKT_SCH_1.1.0
(Jan,27,2003)
Airo.c is performing an basic scheduling function as discarding long packets
with low RSSI value.
test_ap.c is the Rx program which calculating
the channel throughput.
In this version, test_ap program will first send "START" message to slave node
to negotiate with test parameters.
test_fn.c is the Tx program which is running
on the slave node who is sending unidirectional packets.
The slave node is synced with START message and the 1 sec SIGNAL in this program
to ensure the test period is ~60 seconds.
test_rn_gen.c is the C program who is
generating random numbers and store them in a file, because the rand() function
in C is requiring that each random number is produced every second, it is so
slow for real-time purpose, so we'd better have a handy RN table already.
กก