Is delay calculated right?

[buptmuye]

Happy holidays and happy new year!

Thanks for your guide, now I understood most of the code. Nevertheless, there is a small issue that I still can't figure it out. You are right that the delay for a path is then computed by subtracting the estimation of the delay to a switch (RTT/2). So I see the calculating function again. In "_handle_PacketIn" function:

payload = eval(ip_pck.payload) log.debug("Delay from switch %s to %s = %f"%(EthAddr(packet.src), EthAddr(packet.dst), timeRecv - payload.timeSent ))

"timeRecv - payload.timeSent" seems to be the path delay + RTT*2, not the path delay. I wonder to know how the switch-controller delay be recorded and subtracted. Then I found the "_handle_BarrierIn " function, it seems to calculate the RTT, but never be used.

[NvanAdrichem]

Thanks, the same to you.

You're right, the debug displays the delay from controller to switch A + the delay from the specific path (note that there can be multiple paths) from switch A to B, and the delay from switch B to controller. Furthermore, if the "from" and "to" switch are equal (such as the DPID of switch A), this line represents the delay from controller to switch A and back. I recall I have some code somewhere that computes this on-the-fly instead of printing it to a file for offline analysis, let me try to find it and add it to the repository after the holidays. If you're in a hurry you might also try to do that yourself, the IP source address of the monitoring packet contains the hash denoting the exact path so you can map the values back to the path if you're using multipath routing (in this exact config it does not, so you should also be save with the source and destination DPID stored in the Ethernet addresses). Also I should word the "delay from switch ...." phrase better as it represents a different intermediate value.

I removed the use of barriers in an early stage of development due to a high inaccurarcy of the results as a switch waits to return it until ALL preceding OpenFlow commands have been executed, hence the array barrier[] and callback function _handle_BarrierIn() may be removed. I will do that once I return to the office in the new year.

[buptmuye]

Thanks for your reply. Hope you can find it and add it to the repository :) In the meantime I will try to solve this,too.

Happy New Year !

2014-12-27 19:43 GMT+08:00 Niels van Adrichem notifications@github.com:

Thanks, the same to you.

You're right, the debug displays the delay from controller to switch A + the delay from the specific path (note that there can be multiple paths) from switch A to B, and the delay from switch B to controller. Furthermore, if the "from" and "to" switch are equal (such as the DPID of switch A), this line represents the delay from controller to switch A and back. I recall I have some code somewhere that computes this on-the-fly instead of printing it to a file for offline analysis, let me try to find it and add it to the repository after the holidays. If you're in a hurry you might also try to do that yourself, the IP source address of the monitoring packet contains the hash denoting the exact path so you can map the values back to the path if you're using multipath routing (in this exact config it does not, so you should also be save with the source and destination DPID stored in the Ethernet addresses). Also I should word the "delay from switch ...." phrase better as it rep resents a different intermediate value.

I removed the use of barriers in an early stage of development due to a high inaccurarcy of the results as a switch waits to return it until ALL preceding OpenFlow commands have been executed, hence the array barrier[] and callback function _handle_BarrierIn() may be removed. I will do that once I return to the office in the new year.

— Reply to this email directly or view it on GitHub https://github.com/TUDelftNAS/SDN-OpenNetMon/issues/3#issuecomment-68176201 .