IBR-DTN performance with big files and small bundle-fragments
Hi,
I want to transfer 500MB, using proactive fragmentation of 100K bundle_size.
I have changed the parameters in the configuration file of the sender as below:
option limit_payload 100K option fragmentation yes option limit_lifetime 60000 option bundles_in_transit 1000
So, with above options, I would expect around 5000 bundles of 100K stored in the temporary folder of my device. Observing the logs, I could see in the daemon of the sender 4207 'TransferCompletedEvent' and 4212 'BundleReceivedEvent' in the daemon of the receiver. After some time that the experiment was running smoothly, 'TransferAbortedEvent' were triggered at the sender and 'BundleExpiredEvent's were triggered in the receiver. As a result, the already stored bundles in the receiver side started to being deleted.
Any guess of why there is such a behavior? The option 'limit_lifetime' is expressed in secs, correct? Can you explain what is defined with option bundles_in_transit?
Thanks, Theodoros
Am 06.03.2014 11:31, schrieb Theodoros Bourchas:
So, with above options, I would expect around 5000 bundles of 100K stored in the temporary folder of my device. Observing the logs, I could see in the daemon of the sender 4207 'TransferCompletedEvent' and 4212 'BundleReceivedEvent' in the daemon of the receiver. After some time that the experiment was running smoothly, 'TransferAbortedEvent' were triggered at the sender and 'BundleExpiredEvent's were triggered in the receiver. As a result, the already stored bundles in the receiver side started to being deleted. Any guess of why there is such a behavior?
Sound like your bundle lifetime is too short to reach the destination on time.
The option 'limit_lifetime' is expressed in secs, correct?
Yes.
Can you explain what is defined with option bundles_in_transit?
This defines the amount of bundles queued at once for transmission. A change of that value is not necessary in most of the cases.
Kind regards, Johannes Morgenroth
Hi,
For applying the change of limit_lifetime, should I add this parameter also at the /usr/share/ibrdtn/build-config.sh as I did with the option limit_payload?
So, the queue is big enough to keep all the bundles that we create?
Thanks, Theodoros
On Thu, Mar 6, 2014 at 11:46 AM, Johannes Morgenroth < morgenroth@ibr.cs.tu-bs.de> wrote:
Am 06.03.2014 11:31, schrieb Theodoros Bourchas:
So, with above options, I would expect around 5000 bundles of 100K stored in the temporary folder of my device. Observing the logs, I could see in the daemon of the sender 4207 'TransferCompletedEvent' and 4212 'BundleReceivedEvent' in the daemon of the receiver. After some time that the experiment was running smoothly, 'TransferAbortedEvent' were triggered at the sender and 'BundleExpiredEvent's were triggered in the receiver. As a result, the already stored bundles in the receiver side started to being deleted. Any guess of why there is such a behavior?
Sound like your bundle lifetime is too short to reach the destination on time.
The option 'limit_lifetime' is expressed in secs, correct?
Yes.
Can you explain what is defined with option bundles_in_transit?
This defines the amount of bundles queued at once for transmission. A change of that value is not necessary in most of the cases.
Kind regards, Johannes Morgenroth
-- Johannes Morgenroth Institut fuer Betriebssysteme und Rechnerverbund Tel.: +49-531-391-3249 Muehlenpfordtstrasse 23 Fax.: +49-531-391-5936 TU Braunschweig D-38106 Braunschweig -- !! 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.
Hi again,
You had mentioned that the bundle lifetime was too short to reach the destination. I set the limit_lifetime to be 60000 seconds, which is around 16 hours. But our experiment runs for less than an hour before we see the bundles expiring. Shouldn't the bundles be transferred to the destination without expiration with such a high lifetime?
Thanks, Theo
On Thu, Mar 6, 2014 at 11:53 AM, Theodoros Bourchas bourchast@gmail.comwrote:
Hi,
For applying the change of limit_lifetime, should I add this parameter also at the /usr/share/ibrdtn/build-config.sh as I did with the option limit_payload?
So, the queue is big enough to keep all the bundles that we create?
Thanks, Theodoros
On Thu, Mar 6, 2014 at 11:46 AM, Johannes Morgenroth < morgenroth@ibr.cs.tu-bs.de> wrote:
Am 06.03.2014 11:31, schrieb Theodoros Bourchas:
So, with above options, I would expect around 5000 bundles of 100K stored in the temporary folder of my device. Observing the logs, I could see in the daemon of the sender 4207 'TransferCompletedEvent' and 4212 'BundleReceivedEvent' in the daemon of the receiver. After some time that the experiment was running smoothly, 'TransferAbortedEvent' were triggered at the sender and 'BundleExpiredEvent's were triggered in the receiver. As a result, the already stored bundles in the receiver side started to being deleted. Any guess of why there is such a behavior?
Sound like your bundle lifetime is too short to reach the destination on time.
The option 'limit_lifetime' is expressed in secs, correct?
Yes.
Can you explain what is defined with option bundles_in_transit?
This defines the amount of bundles queued at once for transmission. A change of that value is not necessary in most of the cases.
Kind regards, Johannes Morgenroth
-- Johannes Morgenroth Institut fuer Betriebssysteme und Rechnerverbund Tel.: +49-531-391-3249 Muehlenpfordtstrasse 23 Fax.: +49-531-391-5936 TU Braunschweig D-38106 Braunschweig -- !! 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.
Am 06.03.2014 12:10, schrieb Theodoros Bourchas:
You had mentioned that the bundle lifetime was too short to reach the destination. I set the limit_lifetime to be 60000 seconds, which is around 16 hours. But our experiment runs for less than an hour before we see the bundles expiring. Shouldn't the bundles be transferred to the destination without expiration with such a high lifetime?
The lifetime of bundles are not configured in the daemon. Instead it is set on creation.
$ dtnsend --help -- dtnsend (IBR-DTN) -- Syntax: dtnsend [options] <dst> <filename> <dst> set the destination eid (e.g. dtn://node/filetransfer) <filename> the file to transfer * optional parameters * -h|--help display this text --src <name> set the source application name (e.g. filetransfer) -p <0..2> set the bundle priority (0 = low, 1 = normal, 2 = high) -g receiver is a destination group --lifetime <seconds> set the lifetime of outgoing bundles; default: 3600 -U <socket> use UNIX domain sockets -n <copies> create <copies> bundle copies --encrypt request encryption on the bundle layer --sign request signature on the bundle layer --custody request custody transfer of the bundle --compression request compression of the payload
Am 06.03.2014 11:53, schrieb Theodoros Bourchas:
For applying the change of limit_lifetime, should I add this parameter also at the /usr/share/ibrdtn/build-config.sh as I did with the option limit_payload?
Why do you think you need that option? It just restricts incoming bundles with a lifetime larger than the defined value.
So, the queue is big enough to keep all the bundles that we create?
The queue mentioned here is just temporary for bundles in transit between router and convergence-layer. The queue you think of does not exist. The daemon always consider all bundles in the storage to transmit.
participants (2)
-
Johannes Morgenroth -
Theodoros Bourchas