Hi

I am not exactly sure if your problem is

a) Get the clock synchronized „enough“, so that your applications work b) Or whether you want reliable/precise measurements how many seconds/minutes a bundle really was in transit

For the first case, if you do not use any of the IBR-DTN time synchronization functionalities, the time IBR-DTN uses really is the system time (i.e. the output form „date“ maybe +/- some hours to whatever the Linux system thinks UTC is). When you use IBR-DTNs time-sync features (simplest setup: one node with RTC should be master, all others slaves) , IBR-DTN manages an internal offset. This might be a good way to make things „just work“, but it will be hard to do good measurements, because IBR-DTNs internal offset might change upon each contact and time synchronization

If it is about measuring precisely what happens in the network, things are a little bit more complicated. Things we know/did:

1. Obviously good RTCs that get synchronised via NTP during the beginning of a measurement might work. But that is not always possible with mobile or outdoor nodes 2. If source and destination are fixed, maybe it is enough to give only those nodes a good time. Pro-Tip: For mobile nodes without Internet a GPS receiver can provide highly precise time 3. If precise measurements on a hop-by-hop base are enough: dtnd can be started with the —timestamp option, which gives Unix timestamps in the logs. Combined with the -v option you can see exactly how long it takes form queuing a bundle to delivering or forwarding it. 4. In a simulation/emulation setup we redirected the output from all virtual nodes' syslog to a central server which did the timestamping. Thus the logs of the whole network are within the same time reference, no matter what nodes think. Of course this means every node needs a low (or at least fixed) latency link with enough bandwidth to a central logging server. That is hard in a real deployment (if your network is like this, you might not need DTN in the frist place :) )

If your dtnping between some nodes only works with --lifetime paramter it means - your clocks are drifting too much (i.e. if a couple of minutes are enough to make it work) - some of your nodes operating systems are configured differently regarding timezones. they do not agree waht UTC is with repsect to their configured timezone. (when you need a lifetime of at least an hour or a couple of hours)

Starting your dtn daemons with -v should give some output when bundles are expired or rejected because they are deemed too old.

MfG

Sebastian

On 25 Jun 2014, at 13:39, Luís Carlos Guedes duarte_d10@hotmail.com wrote:

Hello,

I would like to know if there is a way to know the date/time of the application in IBRDTN (not the local date). I want to know the time it takes to send a file from one (wireless) node to a server on the Internet. The problem is that if the boards are not synchronized, so I get results that are probably not correspondent to reality.

I defined two nodes connected to the Internet as masters and the other as slaves, the problem is that I am working with different devices on multiple networks, all in a testbed, they are not all in direct contact with each other (or in direct contact with the master nodes) but there is an end-to-end path. So, I should be able to ping with dtnping end-to-end but it does not work.

In between some nodes the dtnping works but in between some others it does not (I need to add the option --lifetime, but when this happens the results are not correspondent with reality). If you know some way to help me I would appreciate.

Thank you. Best regards, Luís Guedes

-- !! This message is brought to you via the `ibr-dtn' mailing list. !! Please do not reply to this message to unsubscribe. To unsubscribe or adjust !! your settings, send a mail message to ibr-dtn-request@ibr.cs.tu-bs.de !! or look at https://mail.ibr.cs.tu-bs.de/listinfo/ibr-dtn.