shivankaul / draft-andersdotter-rrm-for-rrt Goto Github PK

• Add venv env instructions
• Take in P=<double between 0 and 1> and Q=<double between 0 and 1> as command line args with default values
• Add help option

I have the below out from run_simulation(0.2, 0, 5, 50):

Here in tick 6, the bit starts spinning at v=1 as I would expect:

Tick:
6
Client ->
[1, 0, 0, 0, 0]
-> Server
Client <-
[0, 0, 0, 0, 0]
<- Server

In tick 7, another v=1 bit is added in the beginning of the client->server path:

Tick:
7
Client ->
[1, 1, 0, 0, 0]
-> Server
Client <-
[0, 0, 0, 0, 0]
<- Server

Here at tick 8 it's not obvious to me what's happening. The system remains in the same state as in tick 7, so 0.2 is doing something - but what?

Tick:
8
Client ->
[1, 1, 0, 0, 0]
-> Server
Client <-
[0, 0, 0, 0, 0]
<- Server

Here at tick 9 it looks as if the P=0.2 is making the middle of the path randomized somehow. I would expect to be seeing [1, 0, 1, 1, 0] in the C->S row, and to have seen [0, 1, 1, 0, 0] in tick 8.

Tick:
9
Client ->
[1, 1, 0, 1, 0]
-> Server
Client <-
[0, 0, 0, 0, 0]
<- Server

Here follow three repetitions of tick 9:

Tick:
10
Client ->
[1, 1, 0, 1, 0]
-> Server
Client <-
[0, 0, 0, 0, 0]
<- Server

Tick:
11
Client ->
[1, 1, 0, 1, 0]
-> Server
Client <-
[0, 0, 0, 0, 0]
<- Server

Tick:
12
Client ->
[1, 1, 0, 1, 0]
-> Server
Client <-
[0, 0, 0, 0, 0]
<- Server

Sometimes I can see the wrong index (not the 0th one) being changed in the path if P or Q > 0

I have the following output from trying to run_simulation.py

`Traceback (most recent call last):
File "run_simulation.py", line 47, in
run_simulation(0.8, 0, 5, 50)
File "run_simulation.py", line 44, in run_simulation
print("Final RTT is %.2f") % observer.measure_rtt()
TypeError: unsupported operand type(s) for %: 'NoneType' and 'int'

Compilation exited abnormally with code 1 at Tue Nov 5 10:05:50`

I can fix it my changing the print-statement to

print("Final RTT is", observer.measure_rtt())

but I'm guessing this is not a problem which is consistent over our python interfaces. Not sure what produces this error.

considering the potential of using RRM to have more than one bit assisting in latency measurement as per previous proposals