From morgenro@ibr.cs.tu-bs.de Fri Jun 15 02:31:26 2012 Return-Path: X-Original-To: dtn-users@ietfa.amsl.com Delivered-To: dtn-users@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A17D821F85CD for ; Fri, 15 Jun 2012 02:31:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[BAYES_50=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GuhZk1F0hksN for ; Fri, 15 Jun 2012 02:31:25 -0700 (PDT) Received: from salvator.ibr.cs.tu-bs.de (salvator.ibr.cs.tu-bs.de [IPv6:2001:638:602:1181:21a:64ff:fed3:6c8c]) by ietfa.amsl.com (Postfix) with ESMTP id AD0F521F85C6 for ; Fri, 15 Jun 2012 02:31:22 -0700 (PDT) Received: from [IPv6:2001:638:602:1181:78f3:30f2:9eb9:47bc] (unknown [IPv6:2001:638:602:1181:78f3:30f2:9eb9:47bc]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: morgenro@salvator) by salvator.ibr.cs.tu-bs.de (Postfix) with ESMTPSA id 7409513F36; Fri, 15 Jun 2012 11:31:15 +0200 (CEST) Message-ID: <4FDB00E3.3040403@ibr.cs.tu-bs.de> Date: Fri, 15 Jun 2012 11:31:15 +0200 From: Johannes Morgenroth User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: ibr-dtn@ibr.cs.tu-bs.de, dtn-users@irtf.org X-Enigmail-Version: 1.5pre OpenPGP: id=53EF1303 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.97.3 at salvator X-Virus-Status: Clean Subject: [dtn-users] [ibr-dtn] IBR-DTN release 0.8.0 X-BeenThere: dtn-users@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The Delay-Tolerant Networking Research Group \(DTNRG\) - Users." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jun 2012 09:31:26 -0000 Hurray, a new release of IBR-DTN is available! Great features are: * PRoPHET Routing * DHT-based EID resolution / routing * Reactive Fragmentation support in TCPCL * Extended plaintext API (+ Java library) * and many more... The full changelog is available at: http://www.ibr.cs.tu-bs.de/trac/ibr-dtn/wiki/changelog Packages and install procedures are available for: - Ubuntu (9.04 and higher) / Debian (5.0 / 6.0) - OpenWRT Backfire 10.03.1 (x86 / ar71xx) - MacOS X (MacPorts) Additionally, we released *IBR-DTN for Android* to the Google Play Store. An API library and a how-to for the development of own DTN applications for smart-phones are available in the project wiki. But first you can play with two cool DTN Apps: Whisper and Talkie. For more information visit this page: http://www.ibr.cs.tu-bs.de/projects/ibr-dtn/ Kind regards, Johannes -- Johannes Morgenroth Institut fuer Betriebssysteme und Rechnerverbund Tel.: +49-531-391-3249 Muehlenpfordtstrasse 23 Fax.: +49-531-391-5936 TU Braunschweig D-38106 Braunschweig From ahmedelouadrhiri@gmail.com Sat Jun 16 10:38:56 2012 Return-Path: X-Original-To: dtn-users@ietfa.amsl.com Delivered-To: dtn-users@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D373721F84A0 for ; Sat, 16 Jun 2012 10:38:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.109 X-Spam-Level: X-Spam-Status: No, score=-2.109 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0LJBQtXInrWQ for ; Sat, 16 Jun 2012 10:38:55 -0700 (PDT) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by ietfa.amsl.com (Postfix) with ESMTP id C63F821F8475 for ; Sat, 16 Jun 2012 10:38:54 -0700 (PDT) Received: by obcni5 with SMTP id ni5so7390347obc.13 for ; Sat, 16 Jun 2012 10:38:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=F04m3WaogM25SFFFgp+Ex97kdd2tNOVoEw2v/gR5EWU=; b=ZVd2hIORiZwhOP4E/xwMzPpUQTY5dIrlrv6lfwPVbHbPhN8Sl+UabbDdKqw2CwqnI4 HS/8uGFeXuYOLBMXny9clptWAmRpz4BJKqg8p6r13nVcWo9uQsxO4GINLB1xWcrDFlPW xNJtLF1OH/EzGm9Tb5S5WI4plD/BSX/BMYUuQDUMrTQWcSLdOpY8xyvgphyVvy5WNLX8 Y/PLH8HpGe4vRJi12HQu2w4XrBbBsT9xuExnI0g7OteTTqIXB0A6xOoJj3zU9fgtqmQM iJAz1JCN8naPJhQZcGjdbyUcMYP8VfUk6Xpoji7vdEjBwp4yWjGR6izUy2mpWgxY56D6 85ng== MIME-Version: 1.0 Received: by 10.60.25.100 with SMTP id b4mr9942560oeg.64.1339868334267; Sat, 16 Jun 2012 10:38:54 -0700 (PDT) Received: by 10.60.137.162 with HTTP; Sat, 16 Jun 2012 10:38:54 -0700 (PDT) Date: Sat, 16 Jun 2012 17:38:54 +0000 Message-ID: From: ahmed elouadrhiri To: dtn-users@irtf.org Content-Type: multipart/alternative; boundary=e89a8ff251821c1d5304c29a681a Subject: [dtn-users] problem in runing DTN2 X-BeenThere: dtn-users@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The Delay-Tolerant Networking Research Group \(DTNRG\) - Users." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Jun 2012 17:38:56 -0000 --e89a8ff251821c1d5304c29a681a Content-Type: text/plain; charset=ISO-8859-1 Hi all; when i try : daemon/dtnd -c /home/fred/dtn/dtn.conf --init-db the error : daemon/dtnd: error while loading shared libraries: libdb-5.2.so: cannot open shared object file: No such file or directory help please, I searched the problem in the archive of the mailing list, I found the problem and I have not found the answer. Thank you for your Help. Ahmed Best Regards --e89a8ff251821c1d5304c29a681a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi all;

when i try :
daemon/dtnd -c /home/fred/dtn/dtn.conf --init-db
the error : 
daemon/dtnd: error =
while loading shared libraries: libdb-5.2.s=
o: cannot open shared object file: No such file or directory

help please, I searched the problem in the archive of the mailing list=
, I found the problem and I have not found the answer.

=

Thank you for your Help.
Ahmed
Best Regards


--e89a8ff251821c1d5304c29a681a-- From darren.long@mac.com Sat Jun 16 11:55:43 2012 Return-Path: X-Original-To: dtn-users@ietfa.amsl.com Delivered-To: dtn-users@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6904821F846A for ; Sat, 16 Jun 2012 11:55:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ry2YNBAvuYXO for ; Sat, 16 Jun 2012 11:55:42 -0700 (PDT) Received: from st11p00mm-asmtpout004.mac.com (st11p00mm-asmtp004.mac.com [17.172.81.3]) by ietfa.amsl.com (Postfix) with ESMTP id A07DC21F8466 for ; Sat, 16 Jun 2012 11:55:42 -0700 (PDT) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_4hmP7KMHNwWYwtLx2tIupg)" Received: from [192.168.1.28] (46-18-104-230.static.vivaciti.org [46.18.104.230]) by st11p00mm-asmtp004.mac.com (Oracle Communications Messaging Server 7u4-23.01(7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTPSA id <0M5Q006B44KR7E10@st11p00mm-asmtp004.mac.com> for dtn-users@irtf.org; Sat, 16 Jun 2012 18:55:41 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.7.7855,1.0.260,0.0.0000 definitions=2012-06-16_05:2012-06-15, 2012-06-16, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1012030000 definitions=main-1206160223 Message-id: <4FDCD6AA.8000407@mac.com> Date: Sat, 16 Jun 2012 19:55:38 +0100 From: Darren Long User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 To: ahmed elouadrhiri References: In-reply-to: Cc: dtn-users@irtf.org Subject: Re: [dtn-users] problem in runing DTN2 X-BeenThere: dtn-users@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The Delay-Tolerant Networking Research Group \(DTNRG\) - Users." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Jun 2012 18:55:43 -0000 This is a multi-part message in MIME format. --Boundary_(ID_4hmP7KMHNwWYwtLx2tIupg) Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT Hi Ahmed, You could try: sudo ldconfig That may help. Darren On 16/06/12 18:38, ahmed elouadrhiri wrote: > Hi all; > > when i try : > daemon/dtnd -c /home/fred/dtn/dtn.conf --init-db > the error : > daemon/dtnd: error while loading shared libraries: libdb-5.2.so : cannot open shared object file: No such file or directory > help please, I searched the problem in the archive of the mailing list, I found the problem and I have not found the answer. > Thank you for your Help. > Ahmed > Best Regards > > > _______________________________________________ > dtn-users mailing list > dtn-users@irtf.org > https://www.irtf.org/mailman/listinfo/dtn-users --Boundary_(ID_4hmP7KMHNwWYwtLx2tIupg) Content-type: text/html; CHARSET=US-ASCII Content-transfer-encoding: 7BIT Hi Ahmed,

You could try:

    sudo ldconfig

That may help.

Darren


On 16/06/12 18:38, ahmed elouadrhiri wrote:
Hi all;

when i try :
daemon/dtnd -c /home/fred/dtn/dtn.conf --init-db
the error : 
daemon/dtnd: error while loading shared libraries: libdb-5.2.so: cannot open shared object file: No such file or directory
help please, I searched the problem in the archive of the mailing list, I found the problem and I have not found the answer.

          
Thank you for your Help.

          
Ahmed

          
Best Regards

          

          

        

      

      

      

      

      
_______________________________________________
dtn-users mailing list
dtn-users@irtf.org
https://www.irtf.org/mailman/listinfo/dtn-users


    

    

  


--Boundary_(ID_4hmP7KMHNwWYwtLx2tIupg)--

From ahmedelouadrhiri@gmail.com  Sat Jun 16 12:10:13 2012
Return-Path: 
X-Original-To: dtn-users@ietfa.amsl.com
Delivered-To: dtn-users@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB1BE21F84A2 for ; Sat, 16 Jun 2012 12:10:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.854
X-Spam-Level: 
X-Spam-Status: No, score=-2.854 tagged_above=-999 required=5 tests=[AWL=0.744,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bKFvdc2bo4oL for ; Sat, 16 Jun 2012 12:10:13 -0700 (PDT)
Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by ietfa.amsl.com (Postfix) with ESMTP id DF6A721F84CF for ; Sat, 16 Jun 2012 12:10:12 -0700 (PDT)
Received: by obcni5 with SMTP id ni5so7509558obc.13 for ; Sat, 16 Jun 2012 12:10:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=zgBuY0Mf4kiSU0BA9VJvHckJ9M+DSGZ8PBj+D/3Yqvs=; b=pi9aBoJw92wonjGlFFNhW6wxZ/8y1ZWYQjpCnFFIiuZGOvJsXs3wKcgOLXWL9daJHi rc91BFnkYHKRlyyAqySmse9qWkr1qsM1xEdBWNy9aAd6rFGPkfeVCahJTNw0agqFcgWQ auMGY0hasDYJnbJ2DiiQu5q3/SivV2wzXhXnP4mt4C8XeCy3Mud9i9aq3vFtvlps57vx ImGYbe1Y1a0DDoUci3nkIu1guRN+8yBp/bGm+rtuKPihyhjKb10Qy0dwHlDmFjvS37gr IpS3yXJ+8jUneIeBY+uE6IFz/pjhL2q+6TXSfosnFFnhxBWz+1YdgL8c7AVqokU6xFnk rOsQ==
MIME-Version: 1.0
Received: by 10.182.207.106 with SMTP id lv10mr10213423obc.48.1339873812214; Sat, 16 Jun 2012 12:10:12 -0700 (PDT)
Received: by 10.60.137.162 with HTTP; Sat, 16 Jun 2012 12:10:12 -0700 (PDT)
In-Reply-To: <4FDCD6AA.8000407@mac.com>
References:  <4FDCD6AA.8000407@mac.com>
Date: Sat, 16 Jun 2012 19:10:12 +0000
Message-ID: 
From: ahmed elouadrhiri 
To: Darren Long 
Content-Type: multipart/alternative; boundary=e89a8f50390a9ef42704c29bae12
Cc: dtn-users@irtf.org
Subject: Re: [dtn-users] problem in runing DTN2
X-BeenThere: dtn-users@irtf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "The Delay-Tolerant Networking Research Group \(DTNRG\) - Users." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 16 Jun 2012 19:10:13 -0000

--e89a8f50390a9ef42704c29bae12
Content-Type: text/plain; charset=ISO-8859-1

thans a lot Darren;
but the problem remains


2012/6/16 Darren Long 

>  Hi Ahmed,
>
> You could try:
>
>     sudo ldconfig
>
> That may help.
>
> Darren
>
>
>
> On 16/06/12 18:38, ahmed elouadrhiri wrote:
>
> Hi all;
>
>  when i try :
>
> daemon/dtnd -c /home/fred/dtn/dtn.conf --init-db
>
> the error :
>
> daemon/dtnd: error while loading shared libraries: libdb-5.2.so: cannot open shared object file: No such file or directory
>
> help please, I searched the problem in the archive of the mailing list, I found the problem and I have not found the answer.
>
>  Thank you for your Help.
>
> Ahmed
>
> Best Regards
>
>
>
> _______________________________________________
> dtn-users mailing listdtn-users@irtf.orghttps://www.irtf.org/mailman/listinfo/dtn-users
>
>
>

--e89a8f50390a9ef42704c29bae12
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


thans a lot=A0Darren;
but the problem remains

<=
div>


2012/6/16 Darren Long &=
lt;darren.long@mac=
.com>


 =20
   =20
 =20
  

    Hi Ahmed,

    

    You could try:

    

    =A0=A0=A0 sudo ldconfig

    

    That may help.

    

    Darren


    

    

    On 16/06/12 18:38, ahmed elouadrhiri wrote:
    

      
Hi all;
        


        

        
when i try :

        

          
daemon/dtnd -c /home/fred/dtn/dtn.conf =
--init-db

          
the error : 

          
daemon/dtnd: error while loading sha=
red libraries: libdb-5.2.=
so: cannot open shared object file: No such file or directory

          
help please, I searched the problem in the archive of the ma=
iling list, I found the problem and I have not found the answer.

          

          
Thank you for your Help.

          
Ahmed

          
Best Regards

          

          

        

      

      

      

      

      
_______________________________________________
dtn-users mailing list
dtn-users@irtf.org<=
/a>
https://www.irtf.org/mailman/listinfo/dtn-users


    

    

  






--e89a8f50390a9ef42704c29bae12--

From alex.mcmahon@cs.tcd.ie  Mon Jun 18 04:00:32 2012
Return-Path: 
X-Original-To: dtn-users@ietfa.amsl.com
Delivered-To: dtn-users@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1E1F21F8599 for ; Mon, 18 Jun 2012 04:00:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.48
X-Spam-Level: 
X-Spam-Status: No, score=-1.48 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IP_ADDR=1.119]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T8l4jZBJLimj for ; Mon, 18 Jun 2012 04:00:31 -0700 (PDT)
Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id D7B3921F8589 for ; Mon, 18 Jun 2012 04:00:30 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 466C317152C; Mon, 18 Jun 2012 12:00:28 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:x-mailer:mime-version:message-id:date :organization:content-type:references:in-reply-to:reply-to:from :subject:received:received:x-virus-scanned; s=cs; t=1340017227; bh=xqAVOGPlqvfs6sqU2iaQeoJF+0JrDSMhrvN2VGMKf8c=; b=EDFhYhe50USA bX/uA1FcSHMBjcT0owZ8K2Dz0PdQMrSoo586aZvDqwtyjF8/+ks/OoZPPbZ0Boby 36mBx/tdTMM1RWveTn2XJcYmJslhre+iKM6wcVDljO0N2KwlVMU1TnZunVS4fm0e 9vguBkqjcyDqSAwe+VuKo2Wy861ZFfs4Qwk55+XRyHtJwpbLpywpzh6VIN0ad0Dt OR3L6XoMTRF3jc0EXg6ePI1r0WD6LpY3rMS1jcW3DwTFEfx1Zt1JA0qy+HfDADsY hj3VN6IvZUklmZrSJZ4HZAmPpoU6qP/+0ORIR2K8f9XGNMX39VFG4bPA7owdBBlQ ycS5+QuTlg==
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id schiFwEBFcWE; Mon, 18 Jun 2012 12:00:27 +0100 (IST)
Received: from [134.226.36.242] (oblong.dsg.cs.tcd.ie [134.226.36.242]) by smtp.scss.tcd.ie (Postfix) with ESMTP id 3B49917152D; Mon, 18 Jun 2012 12:00:27 +0100 (IST)
From: Alex McMahon 
To: ahmed elouadrhiri 
In-Reply-To: 
References:  <4FDCD6AA.8000407@mac.com> 
Content-Type: text/plain; charset="UTF-8"
Organization: Trinity College Dublin
Date: Mon, 18 Jun 2012 12:00:26 +0100
Message-ID: <1340017226.4266.9.camel@oblong>
Mime-Version: 1.0
X-Mailer: Evolution 2.28.3 
Content-Transfer-Encoding: 7bit
Cc: dtn-users@irtf.org
Subject: Re: [dtn-users] problem in runing DTN2
X-BeenThere: dtn-users@irtf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: alex.mcmahon@cs.tcd.ie
List-Id: "The Delay-Tolerant Networking Research Group \(DTNRG\) - Users." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 18 Jun 2012 11:00:32 -0000

Hi Ahmed, 


Can you confirm the development Berkeley Database Libraries for 5.2
present on your system ? 


Thanks

Alex




On Sat, 2012-06-16 at 19:10 +0000, ahmed elouadrhiri wrote:
> thans a lot Darren;
> but the problem remains
> 
> 
> 
> 2012/6/16 Darren Long 
>         Hi Ahmed,
>         
>         You could try:
>         
>             sudo ldconfig
> 
>         That may help.
>         
>         Darren
>         
>         
>         
>         On 16/06/12 18:38, ahmed elouadrhiri wrote: 
>         > Hi all; 
>         > 
>         > 
>         > when i try :
>         > daemon/dtnd -c /home/fred/dtn/dtn.conf --init-db
>         > the error : 
>         > daemon/dtnd: error while loading shared libraries: libdb-5.2.so: cannot open shared object file: No such file or directory
>         > help please, I searched the problem in the archive of the mailing list, I found the problem and I have not found the answer.
>         > Thank you for your Help.
>         > Ahmed
>         > Best Regards
>         > 
>         > 
>         > 
>         > _______________________________________________
>         > dtn-users mailing list
>         > dtn-users@irtf.org
>         > https://www.irtf.org/mailman/listinfo/dtn-users
>         
>         
> 
> 
> _______________________________________________
> dtn-users mailing list
> dtn-users@irtf.org
> https://www.irtf.org/mailman/listinfo/dtn-users



From yuanp1990@163.com  Mon Jun 18 19:09:42 2012
Return-Path: 
X-Original-To: dtn-users@ietfa.amsl.com
Delivered-To: dtn-users@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF6E211E80D0 for ; Mon, 18 Jun 2012 19:09:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.002
X-Spam-Level: 
X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HudIDh8PbK7G for ; Mon, 18 Jun 2012 19:09:42 -0700 (PDT)
Received: from m50-134.163.com (m50-134.163.com [123.125.50.134]) by ietfa.amsl.com (Postfix) with ESMTP id AC4CD11E8097 for ; Mon, 18 Jun 2012 19:09:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=163.com; s=s110527; h=Received:From:To:Subject:Date:Message-ID: MIME-Version:Content-Type:Thread-Index:Content-Language; bh=ulU+ Vb+xlqjNZo26tyoF8goMWDxmKmeFoMpl/RlqR0w=; b=X3GLzTIVVzcaN5Eqtskq QfwRHtY0mADB9OOKAZn6vkPYgfC+e4Ea+Fl1FmuWKH8XMkjO3HV5Ck/u6z6wDhIo wwm0HKNPcU7BJP3ctznaVZGo4aBDNRXUehq5rDZN4ClD+NTk69bGhF8+rKcg6xlg aDhHKZPUpu9IJ5JWSGZszYg=
Received: from PC201204021508 (unknown [219.223.240.32]) by smtp4 (Coremail) with SMTP id DtGowEAJw1pW399POEpLAQ--.38074S2; Tue, 19 Jun 2012 10:09:28 +0800 (CST)
From: "Yuanp" 
To: 
Date: Tue, 19 Jun 2012 10:09:41 +0800
Message-ID: <000a01cd4dc0$9874bf60$c95e3e20$@163.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_000B_01CD4E03.A69CE160"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: Ac1NS3HuRRIBzjfDRVClKQw31jxjTA==
Content-Language: zh-cn
X-CM-TRANSID: DtGowEAJw1pW399POEpLAQ--.38074S2
X-Coremail-Antispam: 1Uf129KBjDUn29KB7ZKAUJUUUUU529EdanIXcx71UUUUU7v73 VFW2AGmfu7bjvjm3AaLaJ3UbIYCTnIWIevJa73UjIFyTuYvjxUYAwsDUUUU
X-CM-SenderInfo: h1xd01arzziqqrwthudrp/1tbiDhbR709oy4aiHwABsw
Subject: [dtn-users] Time Synchronization in DTN
X-BeenThere: dtn-users@irtf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "The Delay-Tolerant Networking Research Group \(DTNRG\) - Users." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 19 Jun 2012 02:09:43 -0000

This is a multipart message in MIME format.

------=_NextPart_000_000B_01CD4E03.A69CE160
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Hi,

Recently I am working on time synchronization in DTN used for deep space
communication. But I am confused about the function of it. Atomic clocks
have been used in spacecraft, which are very precise. Then what does the
time synchronization architectural work for? 

Thanks for response.


------=_NextPart_000_000B_01CD4E03.A69CE160
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


Hi,
Recently I am working on time synchronization in DTN used =
for deep space communication. But I am confused about the function of =
it. Atomic clocks have been used in spacecraft, which are very precise. =
Then what does the time synchronization architectural work for? =

Thanks for =
response.

------=_NextPart_000_000B_01CD4E03.A69CE160--



From yuanp1990@163.com  Mon Jun 18 19:11:19 2012
Return-Path: 
X-Original-To: dtn-users@ietfa.amsl.com
Delivered-To: dtn-users@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B482011E80D7 for ; Mon, 18 Jun 2012 19:11:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.811
X-Spam-Level: **
X-Spam-Status: No, score=2.811 tagged_above=-999 required=5 tests=[AWL=-2.809,  BAYES_50=0.001, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001,  MIME_8BIT_HEADER=0.3, RELAY_IS_220=2.118]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MZIsKcgbMTy2 for ; Mon, 18 Jun 2012 19:11:19 -0700 (PDT)
Received: from m13-19.163.com (m13-19.163.com [220.181.13.19]) by ietfa.amsl.com (Postfix) with ESMTP id AE96411E80D0 for ; Mon, 18 Jun 2012 19:11:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=163.com; s=s110527; h=Received:Date:From:To:Subject:Content-Type: MIME-Version:Message-ID; bh=QYYRAIn3kE08Y4qyCkbcw02Irn8J6h3ltWjj +jX9b9Y=; b=mbxcPfAvnw68u9nPNZgmz4c6CUA0auxMQ15Z/QqKt5kDu54NXTAY di3+WoapeitG0ex6h3bT8yPENJX3FFxTno9YPr0IHOApdo+P9NMY5K0gUMDK6Mno yUyEpv/r59j5mWrc8c97eCG72h6KBzg5zfPrRZKJUGZVW+RmLWpjmNk=
Received: from yuanp1990$163.com ( [219.223.240.32] ) by ajax-webmail-wmsvr19 (Coremail) ; Tue, 19 Jun 2012 10:11:16 +0800 (CST)
X-Originating-IP: [219.223.240.32]
Date: Tue, 19 Jun 2012 10:11:16 +0800 (CST)
From: =?GBK?B?1KzF9A==?= 
To: dtn-users@irtf.org
X-Priority: 3
X-Mailer: Coremail Webmail Server Version SP_ntes V3.5 build 20120507(18390.4657.4663) Copyright (c) 2002-2012 www.mailtech.cn 163com
X-CM-CTRLDATA: Gry0qWZvb3Rlcl9odG09NzYwOjgx
Content-Type: multipart/alternative;  boundary="----=_Part_38472_15426046.1340071876282"
MIME-Version: 1.0
Message-ID: <7c3dc251.3850.138028216ba.Coremail.yuanp1990@163.com>
X-CM-TRANSID: E8GowGDpkELE399PAi1RAA--.17957W
X-CM-SenderInfo: h1xd01arzziqqrwthudrp/1tbiQBbS709ozzGu5wABs6
X-Coremail-Antispam: 1U5529EdanIXcx71UUUUU7vcSsGvfC2KfnxnUU==
Subject: [dtn-users] Time Synchronization in DTN
X-BeenThere: dtn-users@irtf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "The Delay-Tolerant Networking Research Group \(DTNRG\) - Users." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 19 Jun 2012 02:11:19 -0000

------=_Part_38472_15426046.1340071876282
Content-Type: text/plain; charset=GBK
Content-Transfer-Encoding: 7bit

Hi,

Recently I am working on time synchronization in DTN used for deep space communication. But I am confused about the function of it. Atomic clocks have been used in spacecraft, which are very precise. Then what does the time synchronization architectural work for?

Thanks for response.

 
Yuanp
------=_Part_38472_15426046.1340071876282
Content-Type: text/html; charset=GBK
Content-Transfer-Encoding: 7bit


Hi,


Recently I am working on time synchronization in DTN used for deep space communication. But I am confused about the function of it. Atomic clocks have been used in spacecraft, which are very precise. Then what does the time synchronization architectural work for? 


Thanks for response.


 


Yuanp



------=_Part_38472_15426046.1340071876282--


From dellard@bbn.com  Mon Jun 18 19:52:10 2012
Return-Path: 
X-Original-To: dtn-users@ietfa.amsl.com
Delivered-To: dtn-users@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61EB911E80EF for ; Mon, 18 Jun 2012 19:52:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xjijSCauifAo for ; Mon, 18 Jun 2012 19:52:10 -0700 (PDT)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id DF36E11E80DC for ; Mon, 18 Jun 2012 19:52:09 -0700 (PDT)
Received: from smp.bbn.com ([192.1.122.26]:15127) by smtp.bbn.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SgoXT-000MJt-Bf for dtn-users@irtf.org; Mon, 18 Jun 2012 22:51:31 -0400
Received: from or-67-237-97-32.sta.embarqhsd.net ([67.237.97.32]:58322 helo=senshu-bbn-com.local) by smp.bbn.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76 (FreeBSD)) (envelope-from ) id 1SgoY4-0003ob-TN for dtn-users@irtf.org; Mon, 18 Jun 2012 22:52:09 -0400
Message-ID: <4FDFE958.70003@bbn.com>
Date: Mon, 18 Jun 2012 22:52:08 -0400
From: Daniel Ellard 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: dtn-users@irtf.org
References: <7c3dc251.3850.138028216ba.Coremail.yuanp1990@163.com>
In-Reply-To: <7c3dc251.3850.138028216ba.Coremail.yuanp1990@163.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-Authenticated-User: dellard
Subject: Re: [dtn-users] Time Synchronization in DTN
X-BeenThere: dtn-users@irtf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "The Delay-Tolerant Networking Research Group \(DTNRG\) - Users." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 19 Jun 2012 02:52:10 -0000

On 6/18/12 10:11 PM, 袁鹏 wrote:
>
> Hi,
>
> Recently I am working on time synchronization in DTN used for deep
> space communication. But I am confused about the function of it.
> Atomic clocks have been used in spacecraft, which are very
> precise. Then what does the time synchronization architectural
> work for?
>
> Thanks for response.
>
>

If you have an accurate clock, and it has been set properly, then
the issues of time synchronization might not be relevant (although a
conservative position is that clocks, like anything else, can break
and when they do it's nice to have a backup).

The work on relative time and time synchronization is targeted at
deployments of DTN on systems that have unreliable or improperly
administered clocks -- cheap, low-power, low-reliability devices.

-Dan

-- 
Daniel Ellard, Ph.D.
Senior Scientist, Network Research
Raytheon BBN Technologies
dellard@bbn.com


From l.wood@surrey.ac.uk  Tue Jun 19 02:41:42 2012
Return-Path: 
X-Original-To: dtn-users@ietfa.amsl.com
Delivered-To: dtn-users@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95A6B21F854B for ; Tue, 19 Jun 2012 02:41:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.395
X-Spam-Level: 
X-Spam-Status: No, score=-2.395 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bJJR7HXto1Ix for ; Tue, 19 Jun 2012 02:41:41 -0700 (PDT)
Received: from mail1.bemta5.messagelabs.com (mail1.bemta5.messagelabs.com [195.245.231.130]) by ietfa.amsl.com (Postfix) with ESMTP id 3381621F851E for ; Tue, 19 Jun 2012 02:41:40 -0700 (PDT)
Received: from [195.245.231.67:60781] by server-3.bemta-5.messagelabs.com id 7F/A2-03367-35940EF4; Tue, 19 Jun 2012 09:41:39 +0000
X-Env-Sender: l.wood@surrey.ac.uk
X-Msg-Ref: server-8.tower-82.messagelabs.com!1340098896!32713848!20
X-Originating-IP: [131.227.200.31]
X-StarScan-Version: 6.5.10; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21233 invoked from network); 19 Jun 2012 09:41:38 -0000
Received: from unknown (HELO EXHT011P.surrey.ac.uk) (131.227.200.31) by server-8.tower-82.messagelabs.com with AES128-SHA encrypted SMTP; 19 Jun 2012 09:41:38 -0000
Received: from EXMB01CMS.surrey.ac.uk ([169.254.1.156]) by EXHT011P.surrey.ac.uk ([131.227.200.31]) with mapi; Tue, 19 Jun 2012 10:41:36 +0100
From: 
To: , 
Date: Tue, 19 Jun 2012 10:41:35 +0100
Thread-Topic: [dtn-users] Time Synchronization in DTN
Thread-Index: Ac1Nxoly8BXqgeoYRziI12OLkxFZ3AANQEvu
Message-ID: 
References: <7c3dc251.3850.138028216ba.Coremail.yuanp1990@163.com>, <4FDFE958.70003@bbn.com>
In-Reply-To: <4FDFE958.70003@bbn.com>
Accept-Language: en-US, en-GB
Content-Language: en-GB
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US, en-GB
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Subject: Re: [dtn-users] Time Synchronization in DTN
X-BeenThere: dtn-users@irtf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "The Delay-Tolerant Networking Research Group \(DTNRG\) - Users." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 19 Jun 2012 09:41:42 -0000

J2NoZWFwLCBsb3cgcG93ZXIsIGxvdyByZWxpYWJpbGl0eSBkZXZpY2VzJyBpcyBhIGJpdCBvZiBh
IHNsdXIuIFRoZXJlJ3MgYSBsb3Qgb2YNCmV4cGVuc2l2ZSBtaWxpdGFyeSBzdHVmZiB0aGF0IHNw
ZW5kcyBhIGxvdCBvZiB0aW1lIGJlaW5nIHR1cm5lZCBvZmYgY29tcGxldGVseS4NCg0KVGhlIE5B
U0EgRGVlcCBJbXBhY3QvRVBPWEkgc3BhY2VjcmFmdCBpcyBhbiBleHBlbnNpdmUsIGhpZ2gtcmVs
aWFiaWxpdHksDQpjYXJlZnVsbHkgYWRtaW5pc3RlcmVkIGRldmljZSBleHBvc2VkIHRvIGV4dHJl
bWUgdGVtcGVyYXR1cmUgcmFuZ2VzIHRoYXQNCmNhdXNlIGNsb2NrcyB0byBzcGVlZCB1cCBhbmQg
c2xvdyBkb3duLg0KDQpJIHVuZGVyc3RhbmQgdGhhdCBpdHMgb25ib2FyZCBjbG9jayB3YXMgc3lu
Y2hyb25pc2VkIHdpdGggdGhlIGdyb3VuZCBiZWZvcmUNCmV2ZXJ5IERUTiBidW5kbGUgdGVzdCwg
dG8gcHJldmVudCB0aGUgYnVuZGxlIHByb3RvY29sIGNvbW11bmljYXRpb25zIGZyb20NCmJyZWFr
aW5nLiAoU2VlIGUuZy4gU2NvdHQgQnVybGVpZ2gncyBESU5FVCBwcmVzZW50YXRpb24gb2YgMjQg
TWFyY2ggMjAwOS4pDQoNClVzaW5nIGFuIGF0b21pYyBjbG9jayBpcyBhbiBleGFtcGxlIG9mIGZp
eGluZyBhIHNvZnR3YXJlIHByb2JsZW0gaW4gaGFyZHdhcmUuDQpUaG9zZSBjbG9ja3MgdGFrZSBz
cGFjZSwgdGhleSB0YWtlIG1hc3MsIHRoZXkgdGFrZSBtb25leS4gVGhleSdyZSBqdXN0aWZpZWQN
CmZvciBHUFMgYW5kIGZvciBzb21lIHNjaWVudGlmaWMgc3BhY2UgbWlzc2lvbnMuIFRoZXkgYXJl
IG5vdCBqdXN0aWZpZWQgZm9yIG1hbnkNCm90aGVycy4gTmVlZGluZyBhbiBhdG9taWMgY2xvY2sg
anVzdCBiZWNhdXNlIGEgc29mdHdhcmUgcHJvdG9jb2wgZXhwZWN0cw0KdGhhdCBsZXZlbCBvZiBj
bG9jayByZWxpYWJpbGl0eSBpcyBub3QgYSBnb29kIGVuZ2luZWVyaW5nIHRyYWRlb2ZmLg0KDQpN
b3JlIGdlbmVyYWxseSwgRFROIGludm9sdmVzIGRpc3J1cHRlZCBjb21tdW5pY2F0aW9uLCB3aGVy
ZSBvdXRhZ2VzIGFyZQ0KZXhwZWN0ZWQuIEFuZCBjbG9ja3MgY2Fubm90IGJlIHN5bmNocm9uaXNl
ZCBkdXJpbmcgdGhlc2Ugb3V0YWdlcy4gVGhleQ0KX3dpbGxfIGRyaWZ0LiBCdXQgYmVjYXVzZSBt
b3N0IGJ1bmRsZSBwcm90b2NvbCBkZXZlbG9wbWVudCBoYXMgYmVlbiBkb25lDQpvbiBpbnRlcm5l
dC1jb25uZWN0ZWQgY29tcHV0ZXJzIHdpdGggTlRQIHRvIHN5bmMgY2xvY2tzLCB1bHRpbWF0ZWx5
IHRvDQphdG9taWMgY2xvY2sgc291cmNlcywgaXQgaXMgYXNzdW1lZCB0aGF0IHRoYXQgaGF2aW5n
IGFjY3VyYXRlIHRpbWluZyBpcyB0aGUNCm5vcm0sIHJhdGhlciB0aGFuIHRoZSBleGNlcHRpb24u
IChUaGlzIGlzIGFsc28gd2h5IG1vc3QgYnVuZGxlcyBoYXZlDQpiZWVuIHNlbnQgb3ZlciBUQ1Au
IEJlY2F1c2UsIGhleSwgaW50ZXJuZXQtY29ubmVjdGVkIGNvbXB1dGVycy4pDQoNClRoZSByZWxh
dGl2ZSB0aW1lIHdvcmsgaXMgb25lIGNydXRjaCBmb3IgYSBwcm90b2NvbA0KdGhhdCBleHBlY3Rz
IHRvIGJlIHN0YW5kaW5nIG9uIHRoZSBsZWcgb2YgcGVyZmVjdCB0aW1la2VlcGluZywNCmFuZCBv
biB0aGUgbGVnIG9mIHBlcmZlY3QgdW5kZXJseWluZyBwcm90b2NvbCBhbmQgY29tbXVuaWNhdGlv
bnMNCnJlbGlhYmlsaXR5LiBJbiB0cnV0aCwgdGhlIGJ1bmRsZSBwcm90b2NvbCBoYXMgbm8gbGVn
cyB0byBzdGFuZCBvbi4NCg0KTGxveWQgV29vZA0KaHR0cDovL3NhdC1uZXQuY29tL0wuV29vZC9k
dG4NCg0KLi4ud2hpY2ggaXMgd2h5IHdlJ3JlIG5vdCB0cnlpbmcgdG8gY3V0IHRoZSBidW5kbGUg
cHJvdG9jb2wgb2ZmIGF0IGl0cyBrbmVlcy4NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fXw0KRnJvbTogZHRuLXVzZXJzLWJvdW5jZXNAaXJ0Zi5vcmcgW2R0bi11c2Vy
cy1ib3VuY2VzQGlydGYub3JnXSBPbiBCZWhhbGYgT2YgRGFuaWVsIEVsbGFyZCBbZGVsbGFyZEBi
Ym4uY29tXQ0KU2VudDogMTkgSnVuZSAyMDEyIDAzOjUyDQpUbzogZHRuLXVzZXJzQGlydGYub3Jn
DQpTdWJqZWN0OiBSZTogW2R0bi11c2Vyc10gVGltZSBTeW5jaHJvbml6YXRpb24gaW4gRFRODQoN
Ck9uIDYvMTgvMTIgMTA6MTEgUE0sINSsxfQgd3JvdGU6DQo+DQo+IEhpLA0KPg0KPiBSZWNlbnRs
eSBJIGFtIHdvcmtpbmcgb24gdGltZSBzeW5jaHJvbml6YXRpb24gaW4gRFROIHVzZWQgZm9yIGRl
ZXANCj4gc3BhY2UgY29tbXVuaWNhdGlvbi4gQnV0IEkgYW0gY29uZnVzZWQgYWJvdXQgdGhlIGZ1
bmN0aW9uIG9mIGl0Lg0KPiBBdG9taWMgY2xvY2tzIGhhdmUgYmVlbiB1c2VkIGluIHNwYWNlY3Jh
ZnQsIHdoaWNoIGFyZSB2ZXJ5DQo+IHByZWNpc2UuIFRoZW4gd2hhdCBkb2VzIHRoZSB0aW1lIHN5
bmNocm9uaXphdGlvbiBhcmNoaXRlY3R1cmFsDQo+IHdvcmsgZm9yPw0KPg0KPiBUaGFua3MgZm9y
IHJlc3BvbnNlLg0KPg0KPg0KDQpJZiB5b3UgaGF2ZSBhbiBhY2N1cmF0ZSBjbG9jaywgYW5kIGl0
IGhhcyBiZWVuIHNldCBwcm9wZXJseSwgdGhlbg0KdGhlIGlzc3VlcyBvZiB0aW1lIHN5bmNocm9u
aXphdGlvbiBtaWdodCBub3QgYmUgcmVsZXZhbnQgKGFsdGhvdWdoIGENCmNvbnNlcnZhdGl2ZSBw
b3NpdGlvbiBpcyB0aGF0IGNsb2NrcywgbGlrZSBhbnl0aGluZyBlbHNlLCBjYW4gYnJlYWsNCmFu
ZCB3aGVuIHRoZXkgZG8gaXQncyBuaWNlIHRvIGhhdmUgYSBiYWNrdXApLg0KDQpUaGUgd29yayBv
biByZWxhdGl2ZSB0aW1lIGFuZCB0aW1lIHN5bmNocm9uaXphdGlvbiBpcyB0YXJnZXRlZCBhdA0K
ZGVwbG95bWVudHMgb2YgRFROIG9uIHN5c3RlbXMgdGhhdCBoYXZlIHVucmVsaWFibGUgb3IgaW1w
cm9wZXJseQ0KYWRtaW5pc3RlcmVkIGNsb2NrcyAtLSBjaGVhcCwgbG93LXBvd2VyLCBsb3ctcmVs
aWFiaWxpdHkgZGV2aWNlcy4NCg0KLURhbg0KDQotLQ0KRGFuaWVsIEVsbGFyZCwgUGguRC4NClNl
bmlvciBTY2llbnRpc3QsIE5ldHdvcmsgUmVzZWFyY2gNClJheXRoZW9uIEJCTiBUZWNobm9sb2dp
ZXMNCmRlbGxhcmRAYmJuLmNvbQ0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fXw0KZHRuLXVzZXJzIG1haWxpbmcgbGlzdA0KZHRuLXVzZXJzQGlydGYub3Jn
DQpodHRwczovL3d3dy5pcnRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2R0bi11c2Vycw0K

From william.d.ivancic@nasa.gov  Tue Jun 19 05:27:26 2012
Return-Path: 
X-Original-To: dtn-users@ietfa.amsl.com
Delivered-To: dtn-users@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AD2821F85AC for ; Tue, 19 Jun 2012 05:27:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.753
X-Spam-Level: 
X-Spam-Status: No, score=-3.753 tagged_above=-999 required=5 tests=[AWL=-1.358, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dHlHJk-oHUMe for ; Tue, 19 Jun 2012 05:27:25 -0700 (PDT)
Received: from ndmsnpf03.ndc.nasa.gov (ndmsnpf03.ndc.nasa.gov [198.117.0.123]) by ietfa.amsl.com (Postfix) with ESMTP id 9EA2B21F85AF for ; Tue, 19 Jun 2012 05:27:24 -0700 (PDT)
Received: from ndmsppt03.ndc.nasa.gov (ndmsppt03.ndc.nasa.gov [198.117.0.102]) by ndmsnpf03.ndc.nasa.gov (Postfix) with ESMTP id 7D3332D8005; Tue, 19 Jun 2012 07:27:23 -0500 (CDT)
Received: from ndmshub05.ndc.nasa.gov (ndmshub05.ndc.nasa.gov [198.117.2.164]) by ndmsppt03.ndc.nasa.gov (8.14.5/8.14.5) with ESMTP id q5JCRN2L004983; Tue, 19 Jun 2012 07:27:23 -0500
Received: from NDJSSCC07.ndc.nasa.gov ([198.117.2.207]) by ndmshub05.ndc.nasa.gov ([198.117.2.164]) with mapi; Tue, 19 Jun 2012 07:27:23 -0500
From: "Ivancic, William D. (GRC-RHN0)" 
To: "" 
Date: Tue, 19 Jun 2012 07:27:26 -0500
Thread-Topic: [dtn-users] Time Synchronization in DTN
Thread-Index: Ac1OFuBqSLIp0XGhSL6uMxpYpQMsmQ==
Message-ID: <5ABCF6C9-C390-44F1-B644-8C79BA2EF67A@nasa.gov>
References: <7c3dc251.3850.138028216ba.Coremail.yuanp1990@163.com>, <4FDFE958.70003@bbn.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_5ABCF6C9C39044F1B6448C79BA2EF67Anasagov_"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.7.7855, 1.0.260, 0.0.0000 definitions=2012-06-19_04:2012-06-18, 2012-06-19, 1970-01-01 signatures=0
Cc: "dtn-users@irtf.org" 
Subject: Re: [dtn-users] Time Synchronization in DTN
X-BeenThere: dtn-users@irtf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "The Delay-Tolerant Networking Research Group \(DTNRG\) - Users." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 19 Jun 2012 12:27:26 -0000

--_000_5ABCF6C9C39044F1B6448C79BA2EF67Anasagov_
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64

TXkgY29sbGVhZ3VlIGF0IE5BU0Egc2V0IHVwIGEgdmVyeSBzbWFsbCB0ZXN0YmVkICBjb25zaXN0
aW5nIG9mICA1ICBjb21wdXRlcnMgKERUTiBub2RlcykgIHRvIGVtdWxhdGUgYSBNYXJzIHRvIEVh
cnRoIHZpYSAzIERlZXAgU3BhY2UgTmV0d29yayAoRFNOKSBub2RlcyBhbmQgYSBtaXNzaW9uIGNv
bnRyb2wgY2VudGVyIChNQ1MpLiAgSGUgaGFzIG5vIEludGVybmV0IGNvbm5lY3Rpdml0eSBpbiB0
aGlzIHBhcnRpY3VsYXIgbGFiIGFuZCBsaXR0bGUgbW9uZXkgc28gaGUgYmVnZ2VkIGFuZCBib3Jy
b3dlZCB0byBnZXQgbWFjaGluZXMuIEhlIHN5bmNocm9uaXplZCBhbGwgbWFjaGluZXMuICBXaGVu
IHBvd2VyIGN5Y2xlZCwgdGhlIG1hY2hpbmVzIHdlcmUgYWxsIG91dCBvZiBzeW5jIGJlY2F1c2Ug
dGhlIGNvbXB1dGVycyB3ZXJlIG9sZCBhbmQgdGhlIG9uLWNhcmQgYmF0dGVyaWVzIGhhZCBkaWVk
IG9uIGF0IGxlYXN0IG9uZSAoaXQgb25seSB0YWtlcyBvbmUpLiAgVGhlIHNvbHV0aW9uIHdhcyB0
byBsb2FkIE5UUCBvbiBhbGwgdGhlIG1hY2hpbmVzIGFuZCBrZWVwIHRoZW0gaW4gc3luYyBvbiBh
IGJhY2sgY2hhbm5lbCB1c2luZyB0aGUgb25lIGJhZCBtYWNoaW5lIGFzIHRoZSBOVFAgc2VydmVy
LiAgVGltZSBvbmx5IGhhZCB0byBiZSByZWxhdGl2ZSAtIHNvcnQgb2YuICBBbnl3aGVyZSAtIHRo
ZXJlIGlzIHlvdXIgc29sdXRpb24sIGp1c3QgcnVuIG9uZSBEVE4gbm9kZSB3aXRoIE5UUCBhbmQg
bWFrZSBzdXJlIGFsbCBkaXNjb25uZWN0ZWQgc3lzdGVtcyBhcmUgY29ubmVjdGVkIG9uIGEgYmFj
ayBjaGFubmVsLiAgU2ltcGxlLiAgOi0pDQoNCi0gV2lsbA0KDQoNCg0KDQpPbiBKdW4gMTksIDIw
MTIsIGF0IDU6NDEgQU0sIDxsLndvb2RAc3VycmV5LmFjLnVrPG1haWx0bzpsLndvb2RAc3VycmV5
LmFjLnVrPj4gd3JvdGU6DQoNCidjaGVhcCwgbG93IHBvd2VyLCBsb3cgcmVsaWFiaWxpdHkgZGV2
aWNlcycgaXMgYSBiaXQgb2YgYSBzbHVyLiBUaGVyZSdzIGEgbG90IG9mDQpleHBlbnNpdmUgbWls
aXRhcnkgc3R1ZmYgdGhhdCBzcGVuZHMgYSBsb3Qgb2YgdGltZSBiZWluZyB0dXJuZWQgb2ZmIGNv
bXBsZXRlbHkuDQoNClRoZSBOQVNBIERlZXAgSW1wYWN0L0VQT1hJIHNwYWNlY3JhZnQgaXMgYW4g
ZXhwZW5zaXZlLCBoaWdoLXJlbGlhYmlsaXR5LA0KY2FyZWZ1bGx5IGFkbWluaXN0ZXJlZCBkZXZp
Y2UgZXhwb3NlZCB0byBleHRyZW1lIHRlbXBlcmF0dXJlIHJhbmdlcyB0aGF0DQpjYXVzZSBjbG9j
a3MgdG8gc3BlZWQgdXAgYW5kIHNsb3cgZG93bi4NCg0KSSB1bmRlcnN0YW5kIHRoYXQgaXRzIG9u
Ym9hcmQgY2xvY2sgd2FzIHN5bmNocm9uaXNlZCB3aXRoIHRoZSBncm91bmQgYmVmb3JlDQpldmVy
eSBEVE4gYnVuZGxlIHRlc3QsIHRvIHByZXZlbnQgdGhlIGJ1bmRsZSBwcm90b2NvbCBjb21tdW5p
Y2F0aW9ucyBmcm9tDQpicmVha2luZy4gKFNlZSBlLmcuIFNjb3R0IEJ1cmxlaWdoJ3MgRElORVQg
cHJlc2VudGF0aW9uIG9mIDI0IE1hcmNoIDIwMDkuKQ0KDQpVc2luZyBhbiBhdG9taWMgY2xvY2sg
aXMgYW4gZXhhbXBsZSBvZiBmaXhpbmcgYSBzb2Z0d2FyZSBwcm9ibGVtIGluIGhhcmR3YXJlLg0K
VGhvc2UgY2xvY2tzIHRha2Ugc3BhY2UsIHRoZXkgdGFrZSBtYXNzLCB0aGV5IHRha2UgbW9uZXku
IFRoZXkncmUganVzdGlmaWVkDQpmb3IgR1BTIGFuZCBmb3Igc29tZSBzY2llbnRpZmljIHNwYWNl
IG1pc3Npb25zLiBUaGV5IGFyZSBub3QganVzdGlmaWVkIGZvciBtYW55DQpvdGhlcnMuIE5lZWRp
bmcgYW4gYXRvbWljIGNsb2NrIGp1c3QgYmVjYXVzZSBhIHNvZnR3YXJlIHByb3RvY29sIGV4cGVj
dHMNCnRoYXQgbGV2ZWwgb2YgY2xvY2sgcmVsaWFiaWxpdHkgaXMgbm90IGEgZ29vZCBlbmdpbmVl
cmluZyB0cmFkZW9mZi4NCg0KTW9yZSBnZW5lcmFsbHksIERUTiBpbnZvbHZlcyBkaXNydXB0ZWQg
Y29tbXVuaWNhdGlvbiwgd2hlcmUgb3V0YWdlcyBhcmUNCmV4cGVjdGVkLiBBbmQgY2xvY2tzIGNh
bm5vdCBiZSBzeW5jaHJvbmlzZWQgZHVyaW5nIHRoZXNlIG91dGFnZXMuIFRoZXkNCl93aWxsXyBk
cmlmdC4gQnV0IGJlY2F1c2UgbW9zdCBidW5kbGUgcHJvdG9jb2wgZGV2ZWxvcG1lbnQgaGFzIGJl
ZW4gZG9uZQ0Kb24gaW50ZXJuZXQtY29ubmVjdGVkIGNvbXB1dGVycyB3aXRoIE5UUCB0byBzeW5j
IGNsb2NrcywgdWx0aW1hdGVseSB0bw0KYXRvbWljIGNsb2NrIHNvdXJjZXMsIGl0IGlzIGFzc3Vt
ZWQgdGhhdCB0aGF0IGhhdmluZyBhY2N1cmF0ZSB0aW1pbmcgaXMgdGhlDQpub3JtLCByYXRoZXIg
dGhhbiB0aGUgZXhjZXB0aW9uLiAoVGhpcyBpcyBhbHNvIHdoeSBtb3N0IGJ1bmRsZXMgaGF2ZQ0K
YmVlbiBzZW50IG92ZXIgVENQLiBCZWNhdXNlLCBoZXksIGludGVybmV0LWNvbm5lY3RlZCBjb21w
dXRlcnMuKQ0KDQpUaGUgcmVsYXRpdmUgdGltZSB3b3JrIGlzIG9uZSBjcnV0Y2ggZm9yIGEgcHJv
dG9jb2wNCnRoYXQgZXhwZWN0cyB0byBiZSBzdGFuZGluZyBvbiB0aGUgbGVnIG9mIHBlcmZlY3Qg
dGltZWtlZXBpbmcsDQphbmQgb24gdGhlIGxlZyBvZiBwZXJmZWN0IHVuZGVybHlpbmcgcHJvdG9j
b2wgYW5kIGNvbW11bmljYXRpb25zDQpyZWxpYWJpbGl0eS4gSW4gdHJ1dGgsIHRoZSBidW5kbGUg
cHJvdG9jb2wgaGFzIG5vIGxlZ3MgdG8gc3RhbmQgb24uDQoNCkxsb3lkIFdvb2QNCmh0dHA6Ly9z
YXQtbmV0LmNvbS9MLldvb2QvZHRuDQoNCi4uLndoaWNoIGlzIHdoeSB3ZSdyZSBub3QgdHJ5aW5n
IHRvIGN1dCB0aGUgYnVuZGxlIHByb3RvY29sIG9mZiBhdCBpdHMga25lZXMuDQoNCl9fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkZyb206IGR0bi11c2Vycy1ib3VuY2Vz
QGlydGYub3JnIFtkdG4tdXNlcnMtYm91bmNlc0BpcnRmLm9yZ10gT24gQmVoYWxmIE9mIERhbmll
bCBFbGxhcmQgW2RlbGxhcmRAYmJuLmNvbV0NClNlbnQ6IDE5IEp1bmUgMjAxMiAwMzo1Mg0KVG86
IGR0bi11c2Vyc0BpcnRmLm9yZw0KU3ViamVjdDogUmU6IFtkdG4tdXNlcnNdIFRpbWUgU3luY2hy
b25pemF0aW9uIGluIERUTg0KDQpPbiA2LzE4LzEyIDEwOjExIFBNLCDUrMX0IHdyb3RlOg0KDQpI
aSwNCg0KUmVjZW50bHkgSSBhbSB3b3JraW5nIG9uIHRpbWUgc3luY2hyb25pemF0aW9uIGluIERU
TiB1c2VkIGZvciBkZWVwDQpzcGFjZSBjb21tdW5pY2F0aW9uLiBCdXQgSSBhbSBjb25mdXNlZCBh
Ym91dCB0aGUgZnVuY3Rpb24gb2YgaXQuDQpBdG9taWMgY2xvY2tzIGhhdmUgYmVlbiB1c2VkIGlu
IHNwYWNlY3JhZnQsIHdoaWNoIGFyZSB2ZXJ5DQpwcmVjaXNlLiBUaGVuIHdoYXQgZG9lcyB0aGUg
dGltZSBzeW5jaHJvbml6YXRpb24gYXJjaGl0ZWN0dXJhbA0Kd29yayBmb3I/DQoNClRoYW5rcyBm
b3IgcmVzcG9uc2UuDQoNCg0KDQpJZiB5b3UgaGF2ZSBhbiBhY2N1cmF0ZSBjbG9jaywgYW5kIGl0
IGhhcyBiZWVuIHNldCBwcm9wZXJseSwgdGhlbg0KdGhlIGlzc3VlcyBvZiB0aW1lIHN5bmNocm9u
aXphdGlvbiBtaWdodCBub3QgYmUgcmVsZXZhbnQgKGFsdGhvdWdoIGENCmNvbnNlcnZhdGl2ZSBw
b3NpdGlvbiBpcyB0aGF0IGNsb2NrcywgbGlrZSBhbnl0aGluZyBlbHNlLCBjYW4gYnJlYWsNCmFu
ZCB3aGVuIHRoZXkgZG8gaXQncyBuaWNlIHRvIGhhdmUgYSBiYWNrdXApLg0KDQpUaGUgd29yayBv
biByZWxhdGl2ZSB0aW1lIGFuZCB0aW1lIHN5bmNocm9uaXphdGlvbiBpcyB0YXJnZXRlZCBhdA0K
ZGVwbG95bWVudHMgb2YgRFROIG9uIHN5c3RlbXMgdGhhdCBoYXZlIHVucmVsaWFibGUgb3IgaW1w
cm9wZXJseQ0KYWRtaW5pc3RlcmVkIGNsb2NrcyAtLSBjaGVhcCwgbG93LXBvd2VyLCBsb3ctcmVs
aWFiaWxpdHkgZGV2aWNlcy4NCg0KLURhbg0KDQotLQ0KRGFuaWVsIEVsbGFyZCwgUGguRC4NClNl
bmlvciBTY2llbnRpc3QsIE5ldHdvcmsgUmVzZWFyY2gNClJheXRoZW9uIEJCTiBUZWNobm9sb2dp
ZXMNCmRlbGxhcmRAYmJuLmNvbQ0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fXw0KZHRuLXVzZXJzIG1haWxpbmcgbGlzdA0KZHRuLXVzZXJzQGlydGYub3Jn
DQpodHRwczovL3d3dy5pcnRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2R0bi11c2Vycw0KX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCmR0bi11c2VycyBtYWls
aW5nIGxpc3QNCmR0bi11c2Vyc0BpcnRmLm9yZw0KaHR0cHM6Ly93d3cuaXJ0Zi5vcmcvbWFpbG1h
bi9saXN0aW5mby9kdG4tdXNlcnMNCg0KKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqDQpX
aWxsaWFtIEQuIEl2YW5jaWMNClBob25lIDIxNi00MzMtMzQ5NA0KRmF4IDIxNi00MzMtODcwNQ0K
TmV0d29ya2luZyBMYWIgMjE2LTQzMy0yNjIwDQpNb2JpbGUgNDQwLTUwMy00ODkyDQpodHRwOi8v
cm9sYW5kLmdyYy5uYXNhLmdvdi9+aXZhbmNpYw0KDQo=

--_000_5ABCF6C9C39044F1B6448C79BA2EF67Anasagov_
Content-Type: text/html; charset="gb2312"
Content-Transfer-Encoding: quoted-printable

My colleague at NASA set u=
p a very small testbed  consisting of  5  computers (DT=
N nodes)  to emulate a Mars to Earth via 3 Deep Space Network (DSN) no=
des and a mission control center (MCS).  He has no Internet connectivi=
ty in this particular lab and little money so he begged and borrowed to get=
 machines. He synchronized all machines.  When power cycled, the machi=
nes were all out of sync because the computers were old and the on-card bat=
teries had died on at least one (it only takes one).  The solution was=
 to load NTP on all the machines and keep them in sync on a back channel us=
ing the one bad machine as the NTP server.  Time only had to be relati=
ve - sort of.  Anywhere - there is your solution, just run one DTN nod=
e with NTP and make sure all disconnected systems are connected on a back c=
hannel.  Simple.  :-)

- Will

=




On Jun 19, 2012, at =
5:41 AM, <l.wood@surrey.ac.uk=
> wrote:

'cheap, low power, low reliability devices' is a bit of a sl=
ur. There's a lot of
expensive military stuff that spends a lot of time =
being turned off completely.

The NASA Deep Impact/EPOXI spacecraft i=
s an expensive, high-reliability,
carefully administered device exposed =
to extreme temperature ranges that
cause clocks to speed up and slow dow=
n.

I understand that its onboard clock was synchronised with the gro=
und before
every DTN bundle test, to prevent the bundle protocol communi=
cations from
breaking. (See e.g. Scott Burleigh's DINET presentation of =
24 March 2009.)

Using an atomic clock is an example of fixing a soft=
ware problem in hardware.
Those clocks take space, they take mass, they =
take money. They're justified
for GPS and for some scientific space miss=
ions. They are not justified for many
others. Needing an atomic clock ju=
st because a software protocol expects
that level of clock reliability i=
s not a good engineering tradeoff.

More generally, DTN involves disr=
upted communication, where outages are
expected. And clocks cannot be sy=
nchronised during these outages. They
_will_ drift. But because most bun=
dle protocol development has been done
on internet-connected computers w=
ith NTP to sync clocks, ultimately to
atomic clock sources, it is assume=
d that that having accurate timing is the
norm, rather than the exceptio=
n. (This is also why most bundles have
been sent over TCP. Because, hey,=
 internet-connected computers.)

The relative time work is one crutch=
 for a protocol
that expects to be standing on the leg of perfect timeke=
eping,
and on the leg of perfect underlying protocol and communications<=
br>reliability. In truth, the bundle protocol has no legs to stand on.
<=
br>Lloyd Wood
http://sat-net.c=
om/L.Wood/dtn

...which is why we're not trying to cut the bundle=
 protocol off at its knees.

________________________________________=

From: dtn-users-bounces@irtf.org [dtn-users-bounces@irtf.org] On Behalf=
 Of Daniel Ellard [dellard@bbn.com]
Sent: 19 June 2012 03:52
To: dtn-=
users@irtf.org
Subject: Re: [dtn-users] Time Synchronization in DTN
<=
br>On 6/18/12 10:11 PM, =D4=AC=C5=F4 wrote:
Hi,

Recently I am workin=
g on time synchronization in DTN used for deep
space communication. But I am confused about the function of =
it.
Atomic clocks have been used =
in spacecraft, which are very
pre=
cise. Then what does the time synchronization architectural
work for?

Thanks for response.



If you have an accurate clock, and it has been set =
properly, then
the issues of time synchronization might not be relevant =
(although a
conservative position is that clocks, like anything else, ca=
n break
and when they do it's nice to have a backup).

The work on=
 relative time and time synchronization is targeted at
deployments of DT=
N on systems that have unreliable or improperly
administered clocks -- c=
heap, low-power, low-reliability devices.

-Dan

--
Daniel E=
llard, Ph.D.
Senior Scientist, Network Research
Raytheon BBN Technolo=
gies
dellard@bbn.com

____________________________________________=
___
dtn-users mailing list
dtn-users@irtf.org
https://www.irtf.org=
/mailman/listinfo/dtn-users
____________________________________________=
___
dtn-users mailing list
dtn-users@irtf.org
https://www.irtf.org=
/mailman/listinfo/dtn-users



******************************
William D. Ivancic
Phone 216-433-3494
Fax 216-433-8705
Ne=
tworking Lab 216-433-2620
Mobile =
440-503-4892
http://roland.grc.nasa.gov/~ivancic




=

--_000_5ABCF6C9C39044F1B6448C79BA2EF67Anasagov_--

From scott.c.burleigh@jpl.nasa.gov  Tue Jun 19 08:41:44 2012
Return-Path: 
X-Original-To: dtn-users@ietfa.amsl.com
Delivered-To: dtn-users@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2759221F8437 for ; Tue, 19 Jun 2012 08:41:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.395
X-Spam-Level: 
X-Spam-Status: No, score=-2.395 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NqEjWKDz0GKH for ; Tue, 19 Jun 2012 08:41:42 -0700 (PDT)
Received: from mail.jpl.nasa.gov (mailhost.jpl.nasa.gov [128.149.139.109]) by ietfa.amsl.com (Postfix) with ESMTP id 8426A21F8473 for ; Tue, 19 Jun 2012 08:41:42 -0700 (PDT)
Received: from mail.jpl.nasa.gov (ap-ehub-sp01.jpl.nasa.gov [128.149.137.148]) by smtp.jpl.nasa.gov (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q5JFfeBi015700 (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits) verified NO); Tue, 19 Jun 2012 08:41:41 -0700
Received: from AP-EMBX-SP20.RES.AD.JPL ([169.254.8.233]) by ap-ehub-sp01.RES.AD.JPL ([169.254.3.250]) with mapi id 14.02.0298.004; Tue, 19 Jun 2012 08:41:40 -0700
From: "Burleigh, Scott C (313B)" 
To: "Ivancic, William D. (GRC-RHN0)" , "" 
Thread-Topic: [dtn-users] Time Synchronization in DTN
Thread-Index: AQHNTcaJMeNnSdcREUiM+zMda5eOYJcB2TqAgAAuVgD//7jXMA==
Date: Tue, 19 Jun 2012 15:41:39 +0000
Message-ID: 
References: <7c3dc251.3850.138028216ba.Coremail.yuanp1990@163.com>, <4FDFE958.70003@bbn.com>  <5ABCF6C9-C390-44F1-B644-8C79BA2EF67A@nasa.gov>
In-Reply-To: <5ABCF6C9-C390-44F1-B644-8C79BA2EF67A@nasa.gov>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [128.149.137.26]
Content-Type: multipart/alternative; boundary="_000_A5BEAD028815CB40A32A5669CF737C3B079BDDapembxsp20RESADJP_"
MIME-Version: 1.0
X-Source-Sender: scott.c.burleigh@jpl.nasa.gov
X-AUTH: Authorized
Cc: "dtn-users@irtf.org" 
Subject: Re: [dtn-users] Time Synchronization in DTN
X-BeenThere: dtn-users@irtf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "The Delay-Tolerant Networking Research Group \(DTNRG\) - Users." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 19 Jun 2012 15:41:44 -0000

--_000_A5BEAD028815CB40A32A5669CF737C3B079BDDapembxsp20RESADJP_
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64

T25lIG5vdGUgb2YgY2xhcmlmaWNhdGlvbjogSaGvbSBwcmV0dHkgc3VyZSBub2JvZHkgaXMgcHJv
cG9zaW5nIHRoYXQgYXRvbWljIGNsb2NrcyBtdXN0IGJlIHB1dCBvbiBzcGFjZWNyYWZ0IGJlY2F1
c2UgdGhlIEJ1bmRsZSBQcm90b2NvbCBuZWVkcyBpdC4gIFdlIHB1dCBhdG9taWMgY2xvY2tzIG9u
IHNwYWNlY3JhZnQgYmVjYXVzZSB0aGUgc3BhY2VjcmFmdCBuZWVkIGhpZ2hseSBzdGFibGUgYW5k
IHJlbGlhYmxlIHRpbWUgcmVmZXJlbmNlcyBmb3IgYSB2YXJpZXR5IG9mIG9wZXJhdGlvbmFsIHB1
cnBvc2VzLCBzdWNoIGFzIGFjY3VyYXRlbHkgdGltZS10YWdnaW5nIGluc3RydW1lbnQgb2JzZXJ2
YXRpb25zIGFuZCBwZXJmb3JtaW5nIHRyYWplY3RvcnkgY29ycmVjdGlvbiBtYW5ldXZlcnMgYXQg
dGhlIHRpbWVzIGF0IHdoaWNoIHRoZXkgbXVzdCBvY2N1ciBpbiBvcmRlciB0byBoYXZlIHRoZSBk
ZXNpcmVkIGVmZmVjdCBvbiB0cmFqZWN0b3J5LiAgVGhlIEJ1bmRsZSBQcm90b2NvbCwgbGlrZSBt
YW55IG90aGVyIGVsZW1lbnRzIG9mIGZsaWdodCBzb2Z0d2FyZSBhbmQgaGFyZHdhcmUsIGV4cGxv
aXRzIHRoaXMgcmVzb3VyY2UgdG8gbWFrZSBpdHMgb3BlcmF0aW9ucyBzaW1wbGVyIGFuZCBtb3Jl
IHJlbGlhYmxlLg0KDQpBdCB0aGUgc2FtZSB0aW1lLCBJIGRvbqGvdCB0aGluayB0aGVyZaGvcyBh
bnkgc2VyaW91cyBvcHBvc2l0aW9uIHRvIHRoZSBpZGVhIG9mIGFkZGluZyBjdW11bGF0aXZlIGJ1
bmRsZSBhZ2UgYXMgYW4gYWx0ZXJuYXRpdmUgYmFzaXMgZm9yIGJ1bmRsZSBleHBpcmF0aW9uLCBm
b3IgZW52aXJvbm1lbnRzIGluIHdoaWNoIGFjY3VyYXRlIGNsb2NrcyBjYW5ub3QgYmUgY29uc3Vs
dGVkLiAgQW4gSW50ZXJuZXQgRHJhZnQgZGVmaW5pbmcgdGhhdCBtZWNoYW5pc20gd2FzIGluIHRo
ZSB3b3JrcyB0d28geWVhcnMgYWdvOyBpdCBzZWVtcyB0byBoYXZlIGZhZGVkIGF3YXkgZm9yIGxh
Y2sgb2YgdXJnZW5jeSwgYnV0IHRoZSBpZGVhIGlzIHN0aWxsIHZlcnkgbXVjaCBhbGl2ZS4gIFRo
aXMgaXMgYSBub24taXNzdWUuDQoNCkFzIGZvciBESU5FVDogd2UgdXBsb2FkZWQgc29mdHdhcmUg
VVRDIGNvcnJlY3Rpb24gb2Zmc2V0cyB0byBFUE9YSSBldmVyeSBmZXcgZGF5cyBhcyBwYXJ0IG9m
IG91ciByb3V0aW5lIGV4cGVyaW1lbnQgb3BlcmF0aW9uczsgdGhlIHNwYWNlY3JhZnQgY2xvY2sg
aXRzZWxmIHdhcyBuZXZlciBhZGp1c3RlZC4gIFRoZSBwdXJwb3NlIG9mIHRoZXNlIGNvcnJlY3Rp
b24gb2Zmc2V0cyB3YXMgdG8gb3B0aW1pemUgdHJhY2tpbmcgcGFzcyB1dGlsaXphdGlvbiwgdG8g
ZW5hYmxlIGFzIG11Y2ggZGF0YSB0byBiZSB0cmFuc21pdHRlZCBhbmQgcmVjZWl2ZWQgYXMgcG9z
c2libGUsIGNlcnRhaW5seSBub3QgdG8gcHJldmVudCBidW5kbGUgcHJvdG9jb2wgY29tbXVuaWNh
dGlvbnMgZnJvbSChsGJyZWFraW5nLqGxICBEVE4gd2FzIHF1aXRlIGNvbWZvcnRhYmxlIHdpdGgg
bGVzcyB0aGFuIHBlcmZlY3QgdGltZWtlZXBpbmcsIGFuZCBvZiBjb3Vyc2UgaXQgd2FzIGFsc28g
cXVpdGUgY29tZm9ydGFibGUgd2l0aCBsZXNzIHRoYW4gcGVyZmVjdCB1bmRlcmx5aW5nIHByb3Rv
Y29sIGFuZCBjb21tdW5pY2F0aW9ucyByZWxpYWJpbGl0eS4NCg0KU2NvdHQNCg0KRnJvbTogZHRu
LXVzZXJzLWJvdW5jZXNAaXJ0Zi5vcmcgW21haWx0bzpkdG4tdXNlcnMtYm91bmNlc0BpcnRmLm9y
Z10gT24gQmVoYWxmIE9mIEl2YW5jaWMsIFdpbGxpYW0gRC4gKEdSQy1SSE4wKQ0KU2VudDogVHVl
c2RheSwgSnVuZSAxOSwgMjAxMiA1OjI3IEFNDQpUbzogPGwud29vZEBzdXJyZXkuYWMudWs+DQpD
YzogZHRuLXVzZXJzQGlydGYub3JnDQpTdWJqZWN0OiBSZTogW2R0bi11c2Vyc10gVGltZSBTeW5j
aHJvbml6YXRpb24gaW4gRFRODQoNCk15IGNvbGxlYWd1ZSBhdCBOQVNBIHNldCB1cCBhIHZlcnkg
c21hbGwgdGVzdGJlZCAgY29uc2lzdGluZyBvZiAgNSAgY29tcHV0ZXJzIChEVE4gbm9kZXMpICB0
byBlbXVsYXRlIGEgTWFycyB0byBFYXJ0aCB2aWEgMyBEZWVwIFNwYWNlIE5ldHdvcmsgKERTTikg
bm9kZXMgYW5kIGEgbWlzc2lvbiBjb250cm9sIGNlbnRlciAoTUNTKS4gIEhlIGhhcyBubyBJbnRl
cm5ldCBjb25uZWN0aXZpdHkgaW4gdGhpcyBwYXJ0aWN1bGFyIGxhYiBhbmQgbGl0dGxlIG1vbmV5
IHNvIGhlIGJlZ2dlZCBhbmQgYm9ycm93ZWQgdG8gZ2V0IG1hY2hpbmVzLiBIZSBzeW5jaHJvbml6
ZWQgYWxsIG1hY2hpbmVzLiAgV2hlbiBwb3dlciBjeWNsZWQsIHRoZSBtYWNoaW5lcyB3ZXJlIGFs
bCBvdXQgb2Ygc3luYyBiZWNhdXNlIHRoZSBjb21wdXRlcnMgd2VyZSBvbGQgYW5kIHRoZSBvbi1j
YXJkIGJhdHRlcmllcyBoYWQgZGllZCBvbiBhdCBsZWFzdCBvbmUgKGl0IG9ubHkgdGFrZXMgb25l
KS4gIFRoZSBzb2x1dGlvbiB3YXMgdG8gbG9hZCBOVFAgb24gYWxsIHRoZSBtYWNoaW5lcyBhbmQg
a2VlcCB0aGVtIGluIHN5bmMgb24gYSBiYWNrIGNoYW5uZWwgdXNpbmcgdGhlIG9uZSBiYWQgbWFj
aGluZSBhcyB0aGUgTlRQIHNlcnZlci4gIFRpbWUgb25seSBoYWQgdG8gYmUgcmVsYXRpdmUgLSBz
b3J0IG9mLiAgQW55d2hlcmUgLSB0aGVyZSBpcyB5b3VyIHNvbHV0aW9uLCBqdXN0IHJ1biBvbmUg
RFROIG5vZGUgd2l0aCBOVFAgYW5kIG1ha2Ugc3VyZSBhbGwgZGlzY29ubmVjdGVkIHN5c3RlbXMg
YXJlIGNvbm5lY3RlZCBvbiBhIGJhY2sgY2hhbm5lbC4gIFNpbXBsZS4gIDotKQ0KDQotIFdpbGwN
Cg0KDQoNCg0KT24gSnVuIDE5LCAyMDEyLCBhdCA1OjQxIEFNLCA8bC53b29kQHN1cnJleS5hYy51
azxtYWlsdG86bC53b29kQHN1cnJleS5hYy51az4+IHdyb3RlOg0KDQoNCidjaGVhcCwgbG93IHBv
d2VyLCBsb3cgcmVsaWFiaWxpdHkgZGV2aWNlcycgaXMgYSBiaXQgb2YgYSBzbHVyLiBUaGVyZSdz
IGEgbG90IG9mDQpleHBlbnNpdmUgbWlsaXRhcnkgc3R1ZmYgdGhhdCBzcGVuZHMgYSBsb3Qgb2Yg
dGltZSBiZWluZyB0dXJuZWQgb2ZmIGNvbXBsZXRlbHkuDQoNClRoZSBOQVNBIERlZXAgSW1wYWN0
L0VQT1hJIHNwYWNlY3JhZnQgaXMgYW4gZXhwZW5zaXZlLCBoaWdoLXJlbGlhYmlsaXR5LA0KY2Fy
ZWZ1bGx5IGFkbWluaXN0ZXJlZCBkZXZpY2UgZXhwb3NlZCB0byBleHRyZW1lIHRlbXBlcmF0dXJl
IHJhbmdlcyB0aGF0DQpjYXVzZSBjbG9ja3MgdG8gc3BlZWQgdXAgYW5kIHNsb3cgZG93bi4NCg0K
SSB1bmRlcnN0YW5kIHRoYXQgaXRzIG9uYm9hcmQgY2xvY2sgd2FzIHN5bmNocm9uaXNlZCB3aXRo
IHRoZSBncm91bmQgYmVmb3JlDQpldmVyeSBEVE4gYnVuZGxlIHRlc3QsIHRvIHByZXZlbnQgdGhl
IGJ1bmRsZSBwcm90b2NvbCBjb21tdW5pY2F0aW9ucyBmcm9tDQpicmVha2luZy4gKFNlZSBlLmcu
IFNjb3R0IEJ1cmxlaWdoJ3MgRElORVQgcHJlc2VudGF0aW9uIG9mIDI0IE1hcmNoIDIwMDkuKQ0K
DQpVc2luZyBhbiBhdG9taWMgY2xvY2sgaXMgYW4gZXhhbXBsZSBvZiBmaXhpbmcgYSBzb2Z0d2Fy
ZSBwcm9ibGVtIGluIGhhcmR3YXJlLg0KVGhvc2UgY2xvY2tzIHRha2Ugc3BhY2UsIHRoZXkgdGFr
ZSBtYXNzLCB0aGV5IHRha2UgbW9uZXkuIFRoZXkncmUganVzdGlmaWVkDQpmb3IgR1BTIGFuZCBm
b3Igc29tZSBzY2llbnRpZmljIHNwYWNlIG1pc3Npb25zLiBUaGV5IGFyZSBub3QganVzdGlmaWVk
IGZvciBtYW55DQpvdGhlcnMuIE5lZWRpbmcgYW4gYXRvbWljIGNsb2NrIGp1c3QgYmVjYXVzZSBh
IHNvZnR3YXJlIHByb3RvY29sIGV4cGVjdHMNCnRoYXQgbGV2ZWwgb2YgY2xvY2sgcmVsaWFiaWxp
dHkgaXMgbm90IGEgZ29vZCBlbmdpbmVlcmluZyB0cmFkZW9mZi4NCg0KTW9yZSBnZW5lcmFsbHks
IERUTiBpbnZvbHZlcyBkaXNydXB0ZWQgY29tbXVuaWNhdGlvbiwgd2hlcmUgb3V0YWdlcyBhcmUN
CmV4cGVjdGVkLiBBbmQgY2xvY2tzIGNhbm5vdCBiZSBzeW5jaHJvbmlzZWQgZHVyaW5nIHRoZXNl
IG91dGFnZXMuIFRoZXkNCl93aWxsXyBkcmlmdC4gQnV0IGJlY2F1c2UgbW9zdCBidW5kbGUgcHJv
dG9jb2wgZGV2ZWxvcG1lbnQgaGFzIGJlZW4gZG9uZQ0Kb24gaW50ZXJuZXQtY29ubmVjdGVkIGNv
bXB1dGVycyB3aXRoIE5UUCB0byBzeW5jIGNsb2NrcywgdWx0aW1hdGVseSB0bw0KYXRvbWljIGNs
b2NrIHNvdXJjZXMsIGl0IGlzIGFzc3VtZWQgdGhhdCB0aGF0IGhhdmluZyBhY2N1cmF0ZSB0aW1p
bmcgaXMgdGhlDQpub3JtLCByYXRoZXIgdGhhbiB0aGUgZXhjZXB0aW9uLiAoVGhpcyBpcyBhbHNv
IHdoeSBtb3N0IGJ1bmRsZXMgaGF2ZQ0KYmVlbiBzZW50IG92ZXIgVENQLiBCZWNhdXNlLCBoZXks
IGludGVybmV0LWNvbm5lY3RlZCBjb21wdXRlcnMuKQ0KDQpUaGUgcmVsYXRpdmUgdGltZSB3b3Jr
IGlzIG9uZSBjcnV0Y2ggZm9yIGEgcHJvdG9jb2wNCnRoYXQgZXhwZWN0cyB0byBiZSBzdGFuZGlu
ZyBvbiB0aGUgbGVnIG9mIHBlcmZlY3QgdGltZWtlZXBpbmcsDQphbmQgb24gdGhlIGxlZyBvZiBw
ZXJmZWN0IHVuZGVybHlpbmcgcHJvdG9jb2wgYW5kIGNvbW11bmljYXRpb25zDQpyZWxpYWJpbGl0
eS4gSW4gdHJ1dGgsIHRoZSBidW5kbGUgcHJvdG9jb2wgaGFzIG5vIGxlZ3MgdG8gc3RhbmQgb24u
DQoNCkxsb3lkIFdvb2QNCmh0dHA6Ly9zYXQtbmV0LmNvbS9MLldvb2QvZHRuDQoNCi4uLndoaWNo
IGlzIHdoeSB3ZSdyZSBub3QgdHJ5aW5nIHRvIGN1dCB0aGUgYnVuZGxlIHByb3RvY29sIG9mZiBh
dCBpdHMga25lZXMuDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N
CkZyb206IGR0bi11c2Vycy1ib3VuY2VzQGlydGYub3JnPG1haWx0bzpkdG4tdXNlcnMtYm91bmNl
c0BpcnRmLm9yZz4gW2R0bi11c2Vycy1ib3VuY2VzQGlydGYub3JnXSBPbiBCZWhhbGYgT2YgRGFu
aWVsIEVsbGFyZCBbZGVsbGFyZEBiYm4uY29tXQ0KU2VudDogMTkgSnVuZSAyMDEyIDAzOjUyDQpU
bzogZHRuLXVzZXJzQGlydGYub3JnPG1haWx0bzpkdG4tdXNlcnNAaXJ0Zi5vcmc+DQpTdWJqZWN0
OiBSZTogW2R0bi11c2Vyc10gVGltZSBTeW5jaHJvbml6YXRpb24gaW4gRFRODQoNCk9uIDYvMTgv
MTIgMTA6MTEgUE0sINSsxfQgd3JvdGU6DQoNCg0KSGksDQoNClJlY2VudGx5IEkgYW0gd29ya2lu
ZyBvbiB0aW1lIHN5bmNocm9uaXphdGlvbiBpbiBEVE4gdXNlZCBmb3IgZGVlcA0Kc3BhY2UgY29t
bXVuaWNhdGlvbi4gQnV0IEkgYW0gY29uZnVzZWQgYWJvdXQgdGhlIGZ1bmN0aW9uIG9mIGl0Lg0K
QXRvbWljIGNsb2NrcyBoYXZlIGJlZW4gdXNlZCBpbiBzcGFjZWNyYWZ0LCB3aGljaCBhcmUgdmVy
eQ0KcHJlY2lzZS4gVGhlbiB3aGF0IGRvZXMgdGhlIHRpbWUgc3luY2hyb25pemF0aW9uIGFyY2hp
dGVjdHVyYWwNCndvcmsgZm9yPw0KDQpUaGFua3MgZm9yIHJlc3BvbnNlLg0KDQoNCg0KSWYgeW91
IGhhdmUgYW4gYWNjdXJhdGUgY2xvY2ssIGFuZCBpdCBoYXMgYmVlbiBzZXQgcHJvcGVybHksIHRo
ZW4NCnRoZSBpc3N1ZXMgb2YgdGltZSBzeW5jaHJvbml6YXRpb24gbWlnaHQgbm90IGJlIHJlbGV2
YW50IChhbHRob3VnaCBhDQpjb25zZXJ2YXRpdmUgcG9zaXRpb24gaXMgdGhhdCBjbG9ja3MsIGxp
a2UgYW55dGhpbmcgZWxzZSwgY2FuIGJyZWFrDQphbmQgd2hlbiB0aGV5IGRvIGl0J3MgbmljZSB0
byBoYXZlIGEgYmFja3VwKS4NCg0KVGhlIHdvcmsgb24gcmVsYXRpdmUgdGltZSBhbmQgdGltZSBz
eW5jaHJvbml6YXRpb24gaXMgdGFyZ2V0ZWQgYXQNCmRlcGxveW1lbnRzIG9mIERUTiBvbiBzeXN0
ZW1zIHRoYXQgaGF2ZSB1bnJlbGlhYmxlIG9yIGltcHJvcGVybHkNCmFkbWluaXN0ZXJlZCBjbG9j
a3MgLS0gY2hlYXAsIGxvdy1wb3dlciwgbG93LXJlbGlhYmlsaXR5IGRldmljZXMuDQoNCi1EYW4N
Cg0KLS0NCkRhbmllbCBFbGxhcmQsIFBoLkQuDQpTZW5pb3IgU2NpZW50aXN0LCBOZXR3b3JrIFJl
c2VhcmNoDQpSYXl0aGVvbiBCQk4gVGVjaG5vbG9naWVzDQpkZWxsYXJkQGJibi5jb208bWFpbHRv
OmRlbGxhcmRAYmJuLmNvbT4NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX18NCmR0bi11c2VycyBtYWlsaW5nIGxpc3QNCmR0bi11c2Vyc0BpcnRmLm9yZzxt
YWlsdG86ZHRuLXVzZXJzQGlydGYub3JnPg0KaHR0cHM6Ly93d3cuaXJ0Zi5vcmcvbWFpbG1hbi9s
aXN0aW5mby9kdG4tdXNlcnMNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fDQpkdG4tdXNlcnMgbWFpbGluZyBsaXN0DQpkdG4tdXNlcnNAaXJ0Zi5vcmc8bWFp
bHRvOmR0bi11c2Vyc0BpcnRmLm9yZz4NCmh0dHBzOi8vd3d3LmlydGYub3JnL21haWxtYW4vbGlz
dGluZm8vZHRuLXVzZXJzDQoNCioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKg0KV2lsbGlh
bSBELiBJdmFuY2ljDQpQaG9uZSAyMTYtNDMzLTM0OTQNCkZheCAyMTYtNDMzLTg3MDUNCk5ldHdv
cmtpbmcgTGFiIDIxNi00MzMtMjYyMA0KTW9iaWxlIDQ0MC01MDMtNDg5Mg0KaHR0cDovL3JvbGFu
ZC5ncmMubmFzYS5nb3Yvfml2YW5jaWMNCg0K

--_000_A5BEAD028815CB40A32A5669CF737C3B079BDDapembxsp20RESADJP_
Content-Type: text/html; charset="gb2312"
Content-Transfer-Encoding: quoted-printable











One note of clarification=
: I=A1=AFm pretty sure nobody is proposing that atomic clocks must be put o=
n spacecraft because the Bundle Protocol needs it.  We put atomic
 clocks on spacecraft because the spacecraft need highly stable and reliabl=
e time references for a variety of operational purposes, such as accurately=
 time-tagging instrument observations and performing trajectory correction =
maneuvers at the times at which
 they must occur in order to have the desired effect on trajectory.  T=
he Bundle Protocol, like many other elements of flight software and hardwar=
e, exploits this resource to make its operations simpler and more reliable.=



 <=
/p>

At the same time, I don=
=A1=AFt think there=A1=AFs any serious opposition to the idea of adding cum=
ulative bundle age as an alternative basis for bundle expiration, for
 environments in which accurate clocks cannot be consulted.  An Intern=
et Draft defining that mechanism was in the works two years ago; it seems t=
o have faded away for lack of urgency, but the idea is still very much aliv=
e.  This is a non-issue.


 <=
/p>

As for DINET: we uploaded=
 software UTC correction offsets to EPOXI every few days as part of our rou=
tine experiment operations; the spacecraft clock itself
 was never adjusted.  The purpose of these correction offsets was to o=
ptimize tracking pass utilization, to enable as much data to be transmitted=
 and received as possible, certainly not to prevent bundle protocol communi=
cations from =A1=B0breaking.=A1=B1  DTN was quite
 comfortable with less than perfect timekeeping, and of course it was also =
quite comfortable with less than perfect underlying protocol and communicat=
ions reliability.


 <=
/p>

Scott

 <=
/p>





From: dtn-user=
s-bounces@irtf.org [mailto:dtn-users-bounces@irtf.org]
On Behalf Of Ivancic, William D. (GRC-RHN0)

Sent: Tuesday, June 19, 2012 5:27 AM

To: <l.wood@surrey.ac.uk>

Cc: dtn-users@irtf.org

Subject: Re: [dtn-users] Time Synchronization in DTN






 


My colleague at NASA set up a very small testbed&nbs=
p; consisting of  5  computers (DTN nodes)  to emulate =
a Mars to Earth via 3 Deep Space Network (DSN) nodes and a mission control =
center (MCS).  He has no Internet connectivity in this particular
 lab and little money so he begged and borrowed to get machines. He synchro=
nized all machines.  When power cycled, the machines were all out of s=
ync because the computers were old and the on-card batteries had died on at=
 least one (it only takes one).  The
 solution was to load NTP on all the machines and keep them in sync on a ba=
ck channel using the one bad machine as the NTP server.  Time only had=
 to be relative - sort of.  Anywhere - there is your solution, just ru=
n one DTN node with NTP and make sure all
 disconnected systems are connected on a back channel.  Simple.  =
:-)




 






- Will






 






 






 






 






On Jun 19, 2012, at 5:41 AM, <l.wood@surrey.ac.uk> wrote:













'cheap, low power, low reliability devices' is a bit=
 of a slur. There's a lot of

expensive military stuff that spends a lot of time being turned off complet=
ely.



The NASA Deep Impact/EPOXI spacecraft is an expensive, high-reliability,
carefully administered device exposed to extreme temperature ranges that
cause clocks to speed up and slow down.



I understand that its onboard clock was synchronised with the ground before=


every DTN bundle test, to prevent the bundle protocol communications from
breaking. (See e.g. Scott Burleigh's DINET presentation of 24 March 2009.)<=
br>


Using an atomic clock is an example of fixing a software problem in hardwar=
e.

Those clocks take space, they take mass, they take money. They're justified=


for GPS and for some scientific space missions. They are not justified for =
many

others. Needing an atomic clock just because a software protocol expects
that level of clock reliability is not a good engineering tradeoff.



More generally, DTN involves disrupted communication, where outages are

expected. And clocks cannot be synchronised during these outages. They

_will_ drift. But because most bundle protocol development has been done
on internet-connected computers with NTP to sync clocks, ultimately to

atomic clock sources, it is assumed that that having accurate timing is the=


norm, rather than the exception. (This is also why most bundles have

been sent over TCP. Because, hey, internet-connected computers.)



The relative time work is one crutch for a protocol

that expects to be standing on the leg of perfect timekeeping,

and on the leg of perfect underlying protocol and communications

reliability. In truth, the bundle protocol has no legs to stand on.



Lloyd Wood

http://sat-net.com/L.Wood/dtn=




...which is why we're not trying to cut the bundle protocol off at its knee=
s.



________________________________________

From: dtn-users-bounces@irtf.=
org [dtn-users-bounces@irtf.org] On Behalf Of Daniel Ellard [dellard@bb=
n.com]

Sent: 19 June 2012 03:52

To: dtn-users@irtf.org

Subject: Re: [dtn-users] Time Synchronization in DTN



On 6/18/12 10:11 PM, =D4=AC=C5=F4 wrote:






 




Hi,






 






Recently I am working on time synchronization in DTN=
 used for deep






space communication. But I am confused about the fun=
ction of it.






Atomic clocks have been used in spacecraft, which ar=
e very






precise. Then what does the time synchronization arc=
hitectural






work for?






 






Thanks for response.






 






 






If you have an accurate clock, and it has been set properly, then

the issues of time synchronization might not be relevant (although a

conservative position is that clocks, like anything else, can break

and when they do it's nice to have a backup).



The work on relative time and time synchronization is targeted at

deployments of DTN on systems that have unreliable or improperly

administered clocks -- cheap, low-power, low-reliability devices.



-Dan



--

Daniel Ellard, Ph.D.

Senior Scientist, Network Research

Raytheon BBN Technologies

dellard@bbn.com



_______________________________________________

dtn-users mailing list

dtn-users@irtf.org

https://www.irt=
f.org/mailman/listinfo/dtn-users

_______________________________________________

dtn-users mailing list

dtn-users@irtf.org

https://www.irt=
f.org/mailman/listinfo/dtn-users






 








******************************

William D. Ivancic

Phone 216-433-3494

Fax 216-433-8705

Networking Lab 216-433-2620

Mobile 440-503-4892

http://roland.grc.nasa.gov/~ivancic








 












--_000_A5BEAD028815CB40A32A5669CF737C3B079BDDapembxsp20RESADJP_--

From david.a.zoller@nasa.gov  Fri Jun 29 07:25:32 2012
Return-Path: 
X-Original-To: dtn-users@ietfa.amsl.com
Delivered-To: dtn-users@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB93E21F8734 for ; Fri, 29 Jun 2012 07:25:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.669
X-Spam-Level: 
X-Spam-Status: No, score=-5.669 tagged_above=-999 required=5 tests=[AWL=-0.930, BAYES_20=-0.74, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zvdkg4lNiNL5 for ; Fri, 29 Jun 2012 07:25:24 -0700 (PDT)
Received: from ndmsnpf03.ndc.nasa.gov (ndmsnpf03.ndc.nasa.gov [198.117.0.123]) by ietfa.amsl.com (Postfix) with ESMTP id EFDA621F86DE for ; Fri, 29 Jun 2012 07:25:23 -0700 (PDT)
Received: from ndmsppt05.ndc.nasa.gov (ndmsppt05.ndc.nasa.gov [198.117.0.104]) by ndmsnpf03.ndc.nasa.gov (Postfix) with ESMTP id 111062D8106; Fri, 29 Jun 2012 09:25:23 -0500 (CDT)
Received: from ndmshub01.ndc.nasa.gov (ndmshub01-pub.ndc.nasa.gov [198.117.0.160]) by ndmsppt05.ndc.nasa.gov (8.14.5/8.14.5) with ESMTP id q5TEPMhP003462;  Fri, 29 Jun 2012 09:25:22 -0500
Received: from NDMSSCC05.ndc.nasa.gov ([198.117.2.174]) by ndmshub01.ndc.nasa.gov ([192.168.0.111]) with mapi; Fri, 29 Jun 2012 09:25:23 -0500
From: "Zoller, David A. (MSFC-EO60)[HOSC SERVICES CONTRACT]" 
To: "ahennes1@math.umd.edu" 
Date: Fri, 29 Jun 2012 09:25:01 -0500
Thread-Topic: Re: [dtn-users] Improving performance in DTN2
Thread-Index: Ac1V+FEFO5BE0XoASo6VOyOKu/SAZA==
Message-ID: <04E3D99A62496240BCD6A576813E6E318405E30822@NDMSSCC05.ndc.nasa.gov>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_04E3D99A62496240BCD6A576813E6E318405E30822NDMSSCC05ndcn_"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.7.7855, 1.0.260, 0.0.0000 definitions=2012-06-29_04:2012-06-29, 2012-06-29, 1970-01-01 signatures=0
Cc: "dtn-users@irtf.org" 
Subject: Re: [dtn-users] Improving performance in DTN2
X-BeenThere: dtn-users@irtf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "The Delay-Tolerant Networking Research Group \(DTNRG\) - Users." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 29 Jun 2012 14:25:32 -0000

--_000_04E3D99A62496240BCD6A576813E6E318405E30822NDMSSCC05ndcn_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Angela,
I just joined the dtn-users mailing list yesterday and discovered that I've=
 been working in a vacuum. We've been working on implementing Aggregate Cus=
tody Signals (ACS) in the DTN2 source code so that we can catch up with the=
 ION version updated by the University of Colorado at Boulder and get back =
into the DTN network with their experiments. As I've been in the DTN2 sourc=
e code, I have also been working on improving the throughput with the goal =
of streaming video via DTN. I am currently working on an ACS patch to submi=
t for the reference implementation and am including some of the performance=
 enhancements in it as a bonus.

I just concluded a 22 hour test piping 167 frames[bundles with a 1316 byte =
payload] per second through two DTN nodes with custody transfer and ACS pro=
cessing. It processed 13,605,622 bundles and only lost 6 frames on the fron=
t end [missed UDP packets that never made it to the receiver that feeds the=
 first DTN node] which were probably not related to the DTN node's performa=
nce. This is using the reference implementation with the ACS patches. In me=
mory, the dtnd process has grown to 2.1GB due to timers that have been canc=
eled but have not yet expired since I use a 24 hour expiration time. I have=
 a reaper thread that periodically clears the canceled timers that I was no=
t planning on including in the ACS patch since it requires a coordinated up=
date to the oasys package but I think I'll go ahead and include it seeing t=
hat there is an interest.

On my development machine, our in-house version tops out at about 340 bundl=
es/second and I haven't tested the patched reference implementation to that=
 extent. Our in-house version has more extensive infrastructure changes tha=
t may not be suitable for a reference implementation since the goal was per=
formance for our needs and some of the changes may have broken some of the =
nuances of the BP specification which I have not studied in depth. We'll ch=
eck to see if there is a way to make it available to the community for eval=
uation as there may be some mods that can be cherry picked for adapting int=
o the reference implementation.

In the meantime, here are some things we've run across:

* Configure and build oasys with the --disable-debug-locking option

* You might gain improvements using the--disable-debug option when configur=
ing both oasys and dtn2 but I haven't bothered to do that yet as the debug =
is still useful to me

* BundleDaemon is a single thread. I've broken this into multiple threads: =
Input, Output, Storage, ACS and everything else in the original BD thread. =
The BD currently manages the oasys::TimerSystem which I changed to crank up=
 the oasys::TimerThread to offload that work.

* BundleDaemon::find_duplicate() bogs down significantly as you approach 15=
,000 bundles in the pending_bundles_ list.
     !!Ha!! My intent was to use a std::multimap for the pending bundles bu=
t I just saw that I used a std::map instead. I'll have to go back and chang=
e that. Anyway, std::map is better suited for this than the std::list and a=
 change to std::multimap should be even better to allow detection and reten=
tion of duplicates if so configured.

* CustodyTimers do not release the reference to the bundle until they expir=
e which keeps freed bundles from being removed as well as the timers. I use=
 a reaper thread to periodically remove the canceled timers from the oasys:=
:TimerSystem but I think adding an overridable onCancel() method to the oas=
ys::Timer class would be good way to trigger processing that could free the=
 bundle reference and allow the bundle to be freed quicker.

* I'm using the BerkeleyDB on a Solid State Drive.

* Payload storage to disk - the more files in the directory the longer it t=
akes to add a bundle to the database. I changed the payload directory struc=
ture to a tiered layout with 10,000 bundle payload per directory.

* AdminRegistration and PingRegistration do not update the bundle fwdlog to=
 delivered so they don't get deleted until they expire. Minor unless you ha=
ve tons of custody signals hanging around but the leaner the memory usage t=
he better :)

Hope this helps,
DZ


David Zoller
COLSA Corporation
Marshall Space Flight Center

--_000_04E3D99A62496240BCD6A576813E6E318405E30822NDMSSCC05ndcn_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


Angela,
I just joined the dtn-users mailing list yesterd=
ay and discovered that I’ve been working in a vacuum. We’ve bee=
n working on implementing Aggregate Custody Signals (ACS) in the DTN2 sourc=
e code so that we can catch up with the ION version updated by the Universi=
ty of Colorado at Boulder and get back into the DTN network with their expe=
riments. As I’ve been in the DTN2 source code, I have also been worki=
ng on improving the throughput with the goal of streaming video via DTN. I =
am currently working on an ACS patch to submit for the reference implementa=
tion and am including some of the performance enhancements in it as a bonus=
. 
 
I just concluded a 22 hour test piping 167 frames[bundles with a 1316 =
byte payload] per second through two DTN nodes with custody transfer and AC=
S processing. It processed 13,605,622 bundles and only lost 6 frames on the=
 front end [missed UDP packets that never made it to the receiver that feed=
s the first DTN node] which were probably not related to the DTN node’=
;s performance. This is using the reference implementation with the ACS pat=
ches. In memory, the dtnd process has grown to 2.1GB due to timers that hav=
e been canceled but have not yet expired since I use a 24 hour expiration t=
ime. I have a reaper thread that periodically clears the canceled timers th=
at I was not planning on including in the ACS patch since it requires a coo=
rdinated update to the oasys package but I think I’ll go ahead and in=
clude it seeing that there is an interest.
 
On my development machine, our=
 in-house version tops out at about 340 bundles/second and I haven’t =
tested the patched reference implementation to that extent. Our in-house ve=
rsion has more extensive infrastructure changes that may not be suitable fo=
r a reference implementation since the goal was performance for our needs a=
nd some of the changes may have broken some of the nuances of the BP specif=
ication which I have not studied in depth. We’ll check to see if ther=
e is a way to make it available to the community for evaluation as there ma=
y be some mods that can be cherry picked for adapting into the reference im=
plementation.
 
In the meantime, here are some things we’ve run acros=
s:
 
* Configure and build oasys with the --disable-debug-locking option
 
=
* You might gain improvements using the--disable-debug option when configur=
ing both oasys and dtn2 but I haven’t bothered to do that yet as the =
debug is still useful to me
 <=
/o:p>
* BundleDaemon is a single thread. I’ve=
 broken this into multiple threads: Input, Output, Storage, ACS and everyth=
ing else in the original BD thread. The BD currently manages the oasys::Tim=
erSystem which I changed to crank up the oasys::TimerThread to offload that=
 work.
 
* BundleDaemon::find_duplicate() bogs down significantly as you ap=
proach 15,000 bundles in the pending_bundles_ list. 
     !!Ha!! My intent was to use a st=
d::multimap for the pending bundles but I just saw that I used a std::map i=
nstead. I’ll have to go back and change that. Anyway, std::map is bet=
ter suited for this than the std::list and a change to std::multimap should=
 be even better to allow detection and retention of duplicates if so config=
ured.
 
* CustodyTimers do not release the reference to the bundle until th=
ey expire which keeps freed bundles from being removed as well as the timer=
s. I use a reaper thread to periodically remove the canceled timers from th=
e oasys::TimerSystem but I think adding an overridable onCancel() method to=
 the oasys::Timer class would be good way to trigger processing that could =
free the bundle reference and allow the bundle to be freed quicker.
 
* I&#=
8217;m using the BerkeleyDB on a Solid State Drive.
 
* Payload storage to=
 disk – the more files in the directory the longer it takes to add a =
bundle to the database. I changed the payload directory structure to a tier=
ed layout with 10,000 bundle payload per directory.
 
* AdminRegistration =
and PingRegistration do not update the bundle fwdlog to delivered so they d=
on’t get deleted until they expire. Minor unless you have tons of cus=
tody signals hanging around but the leaner the memory usage the better J
 
Hope this helps,
DZ
 
 
D=
avid Zoller
COLSA Corporation
Marshall =
Space Flight Center<=
/p>
=

--_000_04E3D99A62496240BCD6A576813E6E318405E30822NDMSSCC05ndcn_--

From william.d.ivancic@nasa.gov  Fri Jun 29 07:35:15 2012
Return-Path: 
X-Original-To: dtn-users@ietfa.amsl.com
Delivered-To: dtn-users@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0BAA21F86F2 for ; Fri, 29 Jun 2012 07:35:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.05
X-Spam-Level: 
X-Spam-Status: No, score=-5.05 tagged_above=-999 required=5 tests=[AWL=0.664,  BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001,  RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mPXIfgsusIbs for ; Fri, 29 Jun 2012 07:35:10 -0700 (PDT)
Received: from ndmsnpf02.ndc.nasa.gov (ndmsnpf02.ndc.nasa.gov [198.117.0.122]) by ietfa.amsl.com (Postfix) with ESMTP id 39EE721F867F for ; Fri, 29 Jun 2012 07:35:10 -0700 (PDT)
Received: from ndjsppt03.ndc.nasa.gov (ndjsppt04.ndc.nasa.gov [198.117.1.103]) by ndmsnpf02.ndc.nasa.gov (Postfix) with ESMTP id 921081087E6; Fri, 29 Jun 2012 09:35:09 -0500 (CDT)
Received: from ndjshub06.ndc.nasa.gov (ndjshub06.ndc.nasa.gov [198.117.4.165]) by ndjsppt04.ndc.nasa.gov (8.14.5/8.14.5) with ESMTP id q5TEZ8qw010714; Fri, 29 Jun 2012 09:35:08 -0500
Received: from NDJSSCC07.ndc.nasa.gov ([198.117.4.178]) by ndjshub06.ndc.nasa.gov ([198.117.4.165]) with mapi; Fri, 29 Jun 2012 09:35:07 -0500
From: "Ivancic, William D. (GRC-RHN0)" 
To: "Zoller, David A. (MSFC-EO60)[HOSC SERVICES CONTRACT]" 
Date: Fri, 29 Jun 2012 09:35:07 -0500
Thread-Topic: [dtn-users] Improving performance in DTN2
Thread-Index: Ac1WBGFDldhSb/XAT9SZn+m2zgq6sg==
Message-ID: 
References: <04E3D99A62496240BCD6A576813E6E318405E30822@NDMSSCC05.ndc.nasa.gov>
In-Reply-To: <04E3D99A62496240BCD6A576813E6E318405E30822@NDMSSCC05.ndc.nasa.gov>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_E2E2F6579C7D43FF82BBB22906D34EBFnasagov_"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.7.7855, 1.0.260, 0.0.0000 definitions=2012-06-29_04:2012-06-29, 2012-06-29, 1970-01-01 signatures=0
Cc: "dtn-users@irtf.org" , "ahennes1@math.umd.edu" 
Subject: Re: [dtn-users] Improving performance in DTN2
X-BeenThere: dtn-users@irtf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "The Delay-Tolerant Networking Research Group \(DTNRG\) - Users." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 29 Jun 2012 14:35:15 -0000

--_000_E2E2F6579C7D43FF82BBB22906D34EBFnasagov_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

How long were your periods of disconnection while streaming?

How many bundle where buffered during disconnection?

Also, what routing protocol was used - or just static routes over IP?

- Will Ivancic

On Jun 29, 2012, at 10:25 AM, Zoller, David A. (MSFC-EO60)[HOSC SERVICES CO=
NTRACT] wrote:

Angela,
I just joined the dtn-users mailing list yesterday and discovered that I=92=
ve been working in a vacuum. We=92ve been working on implementing Aggregate=
 Custody Signals (ACS) in the DTN2 source code so that we can catch up with=
 the ION version updated by the University of Colorado at Boulder and get b=
ack into the DTN network with their experiments. As I=92ve been in the DTN2=
 source code, I have also been working on improving the throughput with the=
 goal of streaming video via DTN. I am currently working on an ACS patch to=
 submit for the reference implementation and am including some of the perfo=
rmance enhancements in it as a bonus.

I just concluded a 22 hour test piping 167 frames[bundles with a 1316 byte =
payload] per second through two DTN nodes with custody transfer and ACS pro=
cessing. It processed 13,605,622 bundles and only lost 6 frames on the fron=
t end [missed UDP packets that never made it to the receiver that feeds the=
 first DTN node] which were probably not related to the DTN node=92s perfor=
mance. This is using the reference implementation with the ACS patches. In =
memory, the dtnd process has grown to 2.1GB due to timers that have been ca=
nceled but have not yet expired since I use a 24 hour expiration time. I ha=
ve a reaper thread that periodically clears the canceled timers that I was =
not planning on including in the ACS patch since it requires a coordinated =
update to the oasys package but I think I=92ll go ahead and include it seei=
ng that there is an interest.

On my development machine, our in-house version tops out at about 340 bundl=
es/second and I haven=92t tested the patched reference implementation to th=
at extent. Our in-house version has more extensive infrastructure changes t=
hat may not be suitable for a reference implementation since the goal was p=
erformance for our needs and some of the changes may have broken some of th=
e nuances of the BP specification which I have not studied in depth. We=92l=
l check to see if there is a way to make it available to the community for =
evaluation as there may be some mods that can be cherry picked for adapting=
 into the reference implementation.

In the meantime, here are some things we=92ve run across:

* Configure and build oasys with the --disable-debug-locking option

* You might gain improvements using the--disable-debug option when configur=
ing both oasys and dtn2 but I haven=92t bothered to do that yet as the debu=
g is still useful to me

* BundleDaemon is a single thread. I=92ve broken this into multiple threads=
: Input, Output, Storage, ACS and everything else in the original BD thread=
. The BD currently manages the oasys::TimerSystem which I changed to crank =
up the oasys::TimerThread to offload that work.

* BundleDaemon::find_duplicate() bogs down significantly as you approach 15=
,000 bundles in the pending_bundles_ list.
     !!Ha!! My intent was to use a std::multimap for the pending bundles bu=
t I just saw that I used a std::map instead. I=92ll have to go back and cha=
nge that. Anyway, std::map is better suited for this than the std::list and=
 a change to std::multimap should be even better to allow detection and ret=
ention of duplicates if so configured.

* CustodyTimers do not release the reference to the bundle until they expir=
e which keeps freed bundles from being removed as well as the timers. I use=
 a reaper thread to periodically remove the canceled timers from the oasys:=
:TimerSystem but I think adding an overridable onCancel() method to the oas=
ys::Timer class would be good way to trigger processing that could free the=
 bundle reference and allow the bundle to be freed quicker.

* I=92m using the BerkeleyDB on a Solid State Drive.

* Payload storage to disk =96 the more files in the directory the longer it=
 takes to add a bundle to the database. I changed the payload directory str=
ucture to a tiered layout with 10,000 bundle payload per directory.

* AdminRegistration and PingRegistration do not update the bundle fwdlog to=
 delivered so they don=92t get deleted until they expire. Minor unless you =
have tons of custody signals hanging around but the leaner the memory usage=
 the better :)

Hope this helps,
DZ


David Zoller
COLSA Corporation
Marshall Space Flight Center
_______________________________________________
dtn-users mailing list
dtn-users@irtf.org
https://www.irtf.org/mailman/listinfo/dtn-users



--_000_E2E2F6579C7D43FF82BBB22906D34EBFnasagov_
Content-Type: text/html; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable


Angela,
I just joined the dtn-users mailing list yesterday and discovered tha=
t I=92ve been working in a vacuum. We=92ve been working on implementing Agg=
regate Custody Signals (ACS) in the DTN2 source code so that we can catch u=
p with the ION version updated by the University of Colorado at Boulder and=
 get back into the DTN network with their experiments. As I=92ve been in th=
e DTN2 source code, I have also been working on improving the throughput wi=
th the goal of streaming video via DTN. I am currently working on an ACS pa=
tch to submit for the reference implementation and am including some of the=
 performance enhancements in it as a bonus.
 
=
I just concluded a 22 hour test piping 167 frames[bundles with a 1316 byte =
payload] per second through two DTN nodes with custody transfer and ACS pro=
cessing. It processed 13,605,622 bundles and only lost 6 frames on the fron=
t end [missed UDP packets that never made it to the receiver that feeds the=
 first DTN node] which were probably not related to the DTN node=92s perfor=
mance. This is using the reference implementation with the ACS patches. In =
memory, the dtnd process has grown to 2.1GB due to timers that have been ca=
nceled but have not yet expired since I use a 24 hour expiration time. I ha=
ve a reaper thread that periodically clears the canceled timers that I was =
not planning on including in the ACS patch since it requires a coordinated =
update to the oasys package but I think I=92ll go ahead and include it seei=
ng that there is an interest.
 
On my developm=
ent machine, our in-house version tops out at about 340 bundles/second and =
I haven=92t tested the patched reference implementation to that extent. Our=
 in-house version has more extensive infrastructure changes that may not be=
 suitable for a reference implementation since the goal was performance for=
 our needs and some of the changes may have broken some of the nuances of t=
he BP specification which I have not studied in depth. We=92ll check to see=
 if there is a way to make it available to the community for evaluation as =
there may be some mods that can be cherry picked for adapting into the refe=
rence implementation.
 
In the meantime, here =
are some things we=92ve run across:
 
* Config=
ure and build oasys with the --disable-debug-locking option
 
* You might gain improvements using the--disable-debug opti=
on when configuring both oasys and dtn2 but I haven=92t bothered to do that=
 yet as the debug is still useful to me
 
=

* Bu=
ndleDaemon is a single thread. I=92ve broken this into multiple threads: In=
put, Output, Storage, ACS and everything else in the original BD thread. Th=
e BD currently manages the oasys::TimerSystem which I changed to crank up t=
he oasys::TimerThread to offload that work.
 
=
* BundleDaemon::find_duplicate() bogs down significantly as you approach 15=
,000 bundles in the pending_bundles_ list.
   &n=
bsp; !!Ha!! My intent was to use a std::multimap for the pending bundl=
es but I just saw that I used a std::map instead. I=92ll have to go back an=
d change that. Anyway, std::map is better suited for this than the std::lis=
t and a change to std::multimap should be even better to allow detection an=
d retention of duplicates if so configured.
 
=
* CustodyTimers do not release the reference to the bundle until they expir=
e which keeps freed bundles from being removed as well as the timers. I use=
 a reaper thread to periodically remove the canceled timers from the oasys:=
:TimerSystem but I think adding an overridable onCancel() method to the oas=
ys::Timer class would be good way to trigger processing that could free the=
 bundle reference and allow the bundle to be freed quicker.
 
* I=92m using the BerkeleyDB on a Solid State Drive.
 
* Payload storage to disk =96 the more files in th=
e directory the longer it takes to add a bundle to the database. I changed =
the payload directory structure to a tiered layout with 10,000 bundle paylo=
ad per directory.
 
* AdminRegistration and Pi=
ngRegistration do not update the bundle fwdlog to delivered so they don=92t=
 get deleted until they expire. Minor unless you have tons of custody signa=
ls hanging around but the leaner the memory usage the better  
Hope this helps,
=

DZ
 
 
David Zoll=
er
COLSA C=
orporation
Marshall Space Flight Center<=
/span>
_______________________________________________
dtn-users mailing lis=
t
dtn-users@irtf.org
https://www.irtf.org/mailman/listinfo/dtn-users




=

--_000_E2E2F6579C7D43FF82BBB22906D34EBFnasagov_--

From david.a.zoller@nasa.gov  Fri Jun 29 07:55:37 2012
Return-Path: 
X-Original-To: dtn-users@ietfa.amsl.com
Delivered-To: dtn-users@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F9A321F8659 for ; Fri, 29 Jun 2012 07:55:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.134
X-Spam-Level: 
X-Spam-Status: No, score=-6.134 tagged_above=-999 required=5 tests=[AWL=0.465,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UM45vMBKqqoP for ; Fri, 29 Jun 2012 07:55:33 -0700 (PDT)
Received: from ndjsnpf02.ndc.nasa.gov (ndjsnpf02.ndc.nasa.gov [198.117.1.122]) by ietfa.amsl.com (Postfix) with ESMTP id 0F78A21F8697 for ; Fri, 29 Jun 2012 07:55:33 -0700 (PDT)
Received: from ndmsppt05.ndc.nasa.gov (ndmsppt05.ndc.nasa.gov [198.117.0.104]) by ndjsnpf02.ndc.nasa.gov (Postfix) with ESMTP id 45A77A8A7B; Fri, 29 Jun 2012 09:55:32 -0500 (CDT)
Received: from ndmshub02.ndc.nasa.gov (ndmshub02-pub.ndc.nasa.gov [198.117.0.161]) by ndmsppt05.ndc.nasa.gov (8.14.5/8.14.5) with ESMTP id q5TEtVJV005668;  Fri, 29 Jun 2012 09:55:31 -0500
Received: from NDMSSCC05.ndc.nasa.gov ([198.117.2.174]) by ndmshub02.ndc.nasa.gov ([198.117.2.161]) with mapi; Fri, 29 Jun 2012 09:55:32 -0500
From: "Zoller, David A. (MSFC-EO60)[HOSC SERVICES CONTRACT]" 
To: "Ivancic, William D. (GRC-RHN0)" 
Date: Fri, 29 Jun 2012 09:55:10 -0500
Thread-Topic: [dtn-users] Improving performance in DTN2
Thread-Index: Ac1WBGFDldhSb/XAT9SZn+m2zgq6sgAAADDQ
Message-ID: <04E3D99A62496240BCD6A576813E6E318405E3086F@NDMSSCC05.ndc.nasa.gov>
References: <04E3D99A62496240BCD6A576813E6E318405E30822@NDMSSCC05.ndc.nasa.gov> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_04E3D99A62496240BCD6A576813E6E318405E3086FNDMSSCC05ndcn_"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.7.7855, 1.0.260, 0.0.0000 definitions=2012-06-29_04:2012-06-29, 2012-06-29, 1970-01-01 signatures=0
Cc: "dtn-users@irtf.org" , "ahennes1@math.umd.edu" 
Subject: Re: [dtn-users] Improving performance in DTN2
X-BeenThere: dtn-users@irtf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "The Delay-Tolerant Networking Research Group \(DTNRG\) - Users." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 29 Jun 2012 14:55:37 -0000

--_000_04E3D99A62496240BCD6A576813E6E318405E3086FNDMSSCC05ndcn_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

This is using static routes over IP with no disconnection. The Aggregate Cu=
stody Signals are configured for 30 seconds, so every 30 seconds the first =
node takes a hit while it is releasing about 5000 bundles from custody. Ing=
est stops for a second or so and then as it catches up it processes at abou=
t 400 bundles per second.

David Zoller
COLSA Corporation
Marshall Space Flight Center

From: Ivancic, William D. (GRC-RHN0)
Sent: Friday, June 29, 2012 9:35 AM
To: Zoller, David A. (MSFC-EO60)[HOSC SERVICES CONTRACT]
Cc: ahennes1@math.umd.edu; dtn-users@irtf.org
Subject: Re: [dtn-users] Improving performance in DTN2

How long were your periods of disconnection while streaming?

How many bundle where buffered during disconnection?

Also, what routing protocol was used - or just static routes over IP?

- Will Ivancic

On Jun 29, 2012, at 10:25 AM, Zoller, David A. (MSFC-EO60)[HOSC SERVICES CO=
NTRACT] wrote:


Angela,
I just joined the dtn-users mailing list yesterday and discovered that I've=
 been working in a vacuum. We've been working on implementing Aggregate Cus=
tody Signals (ACS) in the DTN2 source code so that we can catch up with the=
 ION version updated by the University of Colorado at Boulder and get back =
into the DTN network with their experiments. As I've been in the DTN2 sourc=
e code, I have also been working on improving the throughput with the goal =
of streaming video via DTN. I am currently working on an ACS patch to submi=
t for the reference implementation and am including some of the performance=
 enhancements in it as a bonus.

I just concluded a 22 hour test piping 167 frames[bundles with a 1316 byte =
payload] per second through two DTN nodes with custody transfer and ACS pro=
cessing. It processed 13,605,622 bundles and only lost 6 frames on the fron=
t end [missed UDP packets that never made it to the receiver that feeds the=
 first DTN node] which were probably not related to the DTN node's performa=
nce. This is using the reference implementation with the ACS patches. In me=
mory, the dtnd process has grown to 2.1GB due to timers that have been canc=
eled but have not yet expired since I use a 24 hour expiration time. I have=
 a reaper thread that periodically clears the canceled timers that I was no=
t planning on including in the ACS patch since it requires a coordinated up=
date to the oasys package but I think I'll go ahead and include it seeing t=
hat there is an interest.

On my development machine, our in-house version tops out at about 340 bundl=
es/second and I haven't tested the patched reference implementation to that=
 extent. Our in-house version has more extensive infrastructure changes tha=
t may not be suitable for a reference implementation since the goal was per=
formance for our needs and some of the changes may have broken some of the =
nuances of the BP specification which I have not studied in depth. We'll ch=
eck to see if there is a way to make it available to the community for eval=
uation as there may be some mods that can be cherry picked for adapting int=
o the reference implementation.

In the meantime, here are some things we've run across:

* Configure and build oasys with the --disable-debug-locking option

* You might gain improvements using the--disable-debug option when configur=
ing both oasys and dtn2 but I haven't bothered to do that yet as the debug =
is still useful to me

* BundleDaemon is a single thread. I've broken this into multiple threads: =
Input, Output, Storage, ACS and everything else in the original BD thread. =
The BD currently manages the oasys::TimerSystem which I changed to crank up=
 the oasys::TimerThread to offload that work.

* BundleDaemon::find_duplicate() bogs down significantly as you approach 15=
,000 bundles in the pending_bundles_ list.
     !!Ha!! My intent was to use a std::multimap for the pending bundles bu=
t I just saw that I used a std::map instead. I'll have to go back and chang=
e that. Anyway, std::map is better suited for this than the std::list and a=
 change to std::multimap should be even better to allow detection and reten=
tion of duplicates if so configured.

* CustodyTimers do not release the reference to the bundle until they expir=
e which keeps freed bundles from being removed as well as the timers. I use=
 a reaper thread to periodically remove the canceled timers from the oasys:=
:TimerSystem but I think adding an overridable onCancel() method to the oas=
ys::Timer class would be good way to trigger processing that could free the=
 bundle reference and allow the bundle to be freed quicker.

* I'm using the BerkeleyDB on a Solid State Drive.

* Payload storage to disk - the more files in the directory the longer it t=
akes to add a bundle to the database. I changed the payload directory struc=
ture to a tiered layout with 10,000 bundle payload per directory.

* AdminRegistration and PingRegistration do not update the bundle fwdlog to=
 delivered so they don't get deleted until they expire. Minor unless you ha=
ve tons of custody signals hanging around but the leaner the memory usage t=
he better :)

Hope this helps,
DZ


David Zoller
COLSA Corporation
Marshall Space Flight Center
_______________________________________________
dtn-users mailing list
dtn-users@irtf.org
https://www.irtf.org/mailman/listinfo/dtn-users



--_000_04E3D99A62496240BCD6A576813E6E318405E3086FNDMSSCC05ndcn_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


This is u=
sing static routes over IP with no disconnection. The Aggregate Custody Sig=
nals are configured for 30 seconds, so every 30 seconds the first node take=
s a hit while it is releasing about 5000 bundles from custody. Ingest stops=
 for a second or so and then as it catches up it processes at about 400 bun=
dles per second.
&nbs=
p;
David Zoller
COL=
SA Corporation
Marshall Space Flight Center
 
From: Ivancic, William D. (GRC-RHN0) 
Sent: Friday, June 29, 2012 9:3=
5 AM
To: Zoller, David A. (MSFC-EO60)[HOSC SERVICES CONTRACT]
=
Cc: ahennes1@math.umd.edu; dtn-users@irtf.org
Subject: Re:=
 [dtn-users] Improving performance in DTN2
 
How long we=
re your periods of disconnection while streaming?  
 
=
How many bundle where buffered during disconnection?  
<=
/div>
 
Also, what routing protocol was used - or just static routes over =
IP?
 
- Will Ivancic
 
On Jun 29=
, 2012, at 10:25 AM, Zoller, David A. (MSFC-EO60)[HOSC SERVICES CONTRACT] w=
rote:


=

Angela,
I =
just joined the dtn-users mailing list yesterday and discovered that I̵=
7;ve been working in a vacuum. We’ve been working on implementing Agg=
regate Custody Signals (ACS) in the DTN2 source code so that we can catch u=
p with the ION version updated by the University of Colorado at Boulder and=
 get back into the DTN network with their experiments. As I’ve been i=
n the DTN2 source code, I have also been working on improving the throughpu=
t with the goal of streaming video via DTN. I am currently working on an AC=
S patch to submit for the reference implementation and am including some of=
 the performance enhancements in it as a bonus.
=

 
I j=
ust concluded a 22 hour test piping 167 frames[bundles with a 1316 byte pay=
load] per second through two DTN nodes with custody transfer and ACS proces=
sing. It processed 13,605,622 bundles and only lost 6 frames on the front e=
nd [missed UDP packets that never made it to the receiver that feeds the fi=
rst DTN node] which were probably not related to the DTN node’s perfo=
rmance. This is using the reference implementation with the ACS patches. In=
 memory, the dtnd process has grown to 2.1GB due to timers that have been c=
anceled but have not yet expired since I use a 24 hour expiration time. I h=
ave a reaper thread that periodically clears the canceled timers that I was=
 not planning on including in the ACS patch since it requires a coordinated=
 update to the oasys package but I think I’ll go ahead and include it=
 seeing that there is an interest.
 
On my developmen=
t machine, our in-house version tops out at about 340 bundles/second and I =
haven’t tested the patched reference implementation to that extent. O=
ur in-house version has more extensive infrastructure changes that may not =
be suitable for a reference implementation since the goal was performance f=
or our needs and some of the changes may have broken some of the nuances of=
 the BP specification which I have not studied in depth. We’ll check =
to see if there is a way to make it available to the community for evaluati=
on as there may be some mods that can be cherry picked for adapting into th=
e reference implementation.
&=
nbsp;
In the meantime, here a=
re some things we’ve run across:
 
* Configure =
and build oasys with the --disable-debug-locking option
 
* You might gain improvements using the--disable-debug option when co=
nfiguring both oasys and dtn2 but I haven’t bothered to do that yet a=
s the debug is still useful to me
 
* BundleDaemon i=
s a single thread. I’ve broken this into multiple threads: Input, Out=
put, Storage, ACS and everything else in the original BD thread. The BD cur=
rently manages the oasys::TimerSystem which I changed to crank up the oasys=
::TimerThread to offload that work.
 
* BundleDaemon:=
:find_duplicate() bogs down significantly as you approach 15,000 bundles in=
 the pending_bundles_ list.
&=
nbsp;    !!Ha!! My intent was to use a std::multimap fo=
r the pending bundles but I just saw that I used a std::map instead. I̵=
7;ll have to go back and change that. Anyway, std::map is better suited for=
 this than the std::list and a change to std::multimap should be even bette=
r to allow detection and retention of duplicates if so configured.
 
* CustodyTimers do not release the reference to the bundle =
until they expire which keeps freed bundles from being removed as well as t=
he timers. I use a reaper thread to periodically remove the canceled timers=
 from the oasys::TimerSystem but I think adding an overridable onCancel() m=
ethod to the oasys::Timer class would be good way to trigger processing tha=
t could free the bundle reference and allow the bundle to be freed quicker.=

 
=

* I’m using the BerkeleyDB on a Solid State =
Drive.
 
* Payload storage to disk – the more f=
iles in the directory the longer it takes to add a bundle to the database. =
I changed the payload directory structure to a tiered layout with 10,000 bu=
ndle payload per directory.
&=
nbsp;
* AdminRegistration and=
 PingRegistration do not update the bundle fwdlog to delivered so they don&=
#8217;t get deleted until they expire. Minor unless you have tons of custod=
y signals hanging around but the leaner the memory usage the better J
 
Hope this helps,=

DZ
 
 =

David Zoller
COLSA Corporation
Marshall Space Flig=
ht Center
______________________=
_________________________
dtn-users mailing list
dtn-users@irtf.org
https://www.irtf.org/mailman/listinfo/dtn-user=
s
 
=
 
=

--_000_04E3D99A62496240BCD6A576813E6E318405E3086FNDMSSCC05ndcn_--

From david.a.zoller@nasa.gov  Fri Jun 29 08:21:51 2012
Return-Path: 
X-Original-To: dtn-users@ietfa.amsl.com
Delivered-To: dtn-users@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CEAD21F8769 for ; Fri, 29 Jun 2012 08:21:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.288
X-Spam-Level: 
X-Spam-Status: No, score=-6.288 tagged_above=-999 required=5 tests=[AWL=0.310,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bz8yMJGdBAGI for ; Fri, 29 Jun 2012 08:21:44 -0700 (PDT)
Received: from ndmsnpf02.ndc.nasa.gov (ndmsnpf02.ndc.nasa.gov [198.117.0.122]) by ietfa.amsl.com (Postfix) with ESMTP id 0ACDA21F8768 for ; Fri, 29 Jun 2012 08:21:43 -0700 (PDT)
Received: from ndmsppt05.ndc.nasa.gov (ndmsppt05.ndc.nasa.gov [198.117.0.104]) by ndmsnpf02.ndc.nasa.gov (Postfix) with ESMTP id 1DDDD1085EF; Fri, 29 Jun 2012 10:21:43 -0500 (CDT)
Received: from ndmshub03.ndc.nasa.gov (ndmshub03-pub.ndc.nasa.gov [198.117.0.42]) by ndmsppt05.ndc.nasa.gov (8.14.5/8.14.5) with ESMTP id q5TFLgln004532;  Fri, 29 Jun 2012 10:21:42 -0500
Received: from NDMSSCC05.ndc.nasa.gov ([198.117.2.174]) by ndmshub03.ndc.nasa.gov ([198.117.2.162]) with mapi; Fri, 29 Jun 2012 10:21:43 -0500
From: "Zoller, David A. (MSFC-EO60)[HOSC SERVICES CONTRACT]" 
To: "Durst, Robert C." 
Date: Fri, 29 Jun 2012 10:21:21 -0500
Thread-Topic: Re: [dtn-users] Improving performance in DTN2
Thread-Index: Ac1V+FEFO5BE0XoASo6VOyOKu/SAZAAC0LvQAADn1mA=
Message-ID: <04E3D99A62496240BCD6A576813E6E318405E308AE@NDMSSCC05.ndc.nasa.gov>
References: <04E3D99A62496240BCD6A576813E6E318405E30822@NDMSSCC05.ndc.nasa.gov> <7A1B9532DA609B46927331283910A4C40BE3576A@IMCMBX02.MITRE.ORG>
In-Reply-To: <7A1B9532DA609B46927331283910A4C40BE3576A@IMCMBX02.MITRE.ORG>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_04E3D99A62496240BCD6A576813E6E318405E308AENDMSSCC05ndcn_"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.7.7855, 1.0.260, 0.0.0000 definitions=2012-06-29_04:2012-06-29, 2012-06-29, 1970-01-01 signatures=0
Cc: "dtn-users@irtf.org" 
Subject: Re: [dtn-users] Improving performance in DTN2
X-BeenThere: dtn-users@irtf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "The Delay-Tolerant Networking Research Group \(DTNRG\) - Users." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 29 Jun 2012 15:21:52 -0000

--_000_04E3D99A62496240BCD6A576813E6E318405E308AENDMSSCC05ndcn_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Bob,
I like to lurk in the background but you may have run across Lee Pitts as h=
e is my front man :)

I just completed applying the patches to the latest sourceforge version yes=
terday morning and fired it up so I don't have long term results yet. I'll =
let it run over the weekend and check the memory usage. I believe that it w=
ill stabilize as I did run some valgrind testing (on our version) and most =
of the accumulating memory was due to timers and bundles not getting freed =
until expiration. I did fix one memory leak (fixed in the patch) but can't =
say positively that there is not another lurking in there somewhere.

The std::multimap change would help some but not too much in this particula=
r test since the pending bundle list never grows beyond 5000 bundles. It wo=
uld significantly help in the tests proposed by Will as the disconnects wou=
ld result in lots of bundles accumulating in the first node.

We will be doing further testing with at least a 4-node architecture in the=
 future.

Thanks and best regards,
DZ

David Zoller
COLSA Corporation
Marshall Space Flight Center

From: Durst, Robert C. [mailto:durst@mitre.org]
Sent: Friday, June 29, 2012 9:37 AM
To: Zoller, David A. (MSFC-EO60)[HOSC SERVICES CONTRACT]
Subject: RE: Re: [dtn-users] Improving performance in DTN2

David,

I don't think I know you, but this is awesome.  Thanks!

Do you have a sense of whether, after 24 hours, memory usage would stabiliz=
e (under constant load)?  Any plans to do a more extended test?  Also, do y=
ou have a sense of whether the change to use std::multimap will positively =
affect the bundle throughput rate?  Finally, is there any need, desire, pla=
n to do a three- (or more) node test?

This is great work in understanding what needs to be done to use DTN2 in a =
"production" context.  Thanks for sharing it.

Best regards,
Bob Durst
The MITRE Corporation

From: dtn-users-bounces@irtf.org [mailto=
:dtn-users-bounces@irtf.org] On=
 Behalf Of Zoller, David A. (MSFC-EO60)[HOSC SERVICES CONTRACT]
Sent: Friday, June 29, 2012 10:25 AM
To: ahennes1@math.umd.edu
Cc: dtn-users@irtf.org
Subject: Re: [dtn-users] Improving performance in DTN2

Angela,
I just joined the dtn-users mailing list yesterday and discovered that I've=
 been working in a vacuum. We've been working on implementing Aggregate Cus=
tody Signals (ACS) in the DTN2 source code so that we can catch up with the=
 ION version updated by the University of Colorado at Boulder and get back =
into the DTN network with their experiments. As I've been in the DTN2 sourc=
e code, I have also been working on improving the throughput with the goal =
of streaming video via DTN. I am currently working on an ACS patch to submi=
t for the reference implementation and am including some of the performance=
 enhancements in it as a bonus.

I just concluded a 22 hour test piping 167 frames[bundles with a 1316 byte =
payload] per second through two DTN nodes with custody transfer and ACS pro=
cessing. It processed 13,605,622 bundles and only lost 6 frames on the fron=
t end [missed UDP packets that never made it to the receiver that feeds the=
 first DTN node] which were probably not related to the DTN node's performa=
nce. This is using the reference implementation with the ACS patches. In me=
mory, the dtnd process has grown to 2.1GB due to timers that have been canc=
eled but have not yet expired since I use a 24 hour expiration time. I have=
 a reaper thread that periodically clears the canceled timers that I was no=
t planning on including in the ACS patch since it requires a coordinated up=
date to the oasys package but I think I'll go ahead and include it seeing t=
hat there is an interest.

On my development machine, our in-house version tops out at about 340 bundl=
es/second and I haven't tested the patched reference implementation to that=
 extent. Our in-house version has more extensive infrastructure changes tha=
t may not be suitable for a reference implementation since the goal was per=
formance for our needs and some of the changes may have broken some of the =
nuances of the BP specification which I have not studied in depth. We'll ch=
eck to see if there is a way to make it available to the community for eval=
uation as there may be some mods that can be cherry picked for adapting int=
o the reference implementation.

In the meantime, here are some things we've run across:

* Configure and build oasys with the --disable-debug-locking option

* You might gain improvements using the--disable-debug option when configur=
ing both oasys and dtn2 but I haven't bothered to do that yet as the debug =
is still useful to me

* BundleDaemon is a single thread. I've broken this into multiple threads: =
Input, Output, Storage, ACS and everything else in the original BD thread. =
The BD currently manages the oasys::TimerSystem which I changed to crank up=
 the oasys::TimerThread to offload that work.

* BundleDaemon::find_duplicate() bogs down significantly as you approach 15=
,000 bundles in the pending_bundles_ list.
     !!Ha!! My intent was to use a std::multimap for the pending bundles bu=
t I just saw that I used a std::map instead. I'll have to go back and chang=
e that. Anyway, std::map is better suited for this than the std::list and a=
 change to std::multimap should be even better to allow detection and reten=
tion of duplicates if so configured.

* CustodyTimers do not release the reference to the bundle until they expir=
e which keeps freed bundles from being removed as well as the timers. I use=
 a reaper thread to periodically remove the canceled timers from the oasys:=
:TimerSystem but I think adding an overridable onCancel() method to the oas=
ys::Timer class would be good way to trigger processing that could free the=
 bundle reference and allow the bundle to be freed quicker.

* I'm using the BerkeleyDB on a Solid State Drive.

* Payload storage to disk - the more files in the directory the longer it t=
akes to add a bundle to the database. I changed the payload directory struc=
ture to a tiered layout with 10,000 bundle payload per directory.

* AdminRegistration and PingRegistration do not update the bundle fwdlog to=
 delivered so they don't get deleted until they expire. Minor unless you ha=
ve tons of custody signals hanging around but the leaner the memory usage t=
he better :)

Hope this helps,
DZ


David Zoller
COLSA Corporation
Marshall Space Flight Center

--_000_04E3D99A62496240BCD6A576813E6E318405E308AENDMSSCC05ndcn_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


Bob,
I like to lurk in the background but you may have run acros=
s Lee Pitts as he is my front man J<=
/p>
 
I just completed =
applying the patches to the latest sourceforge version yesterday morning an=
d fired it up so I don’t have long term results yet. I’ll let i=
t run over the weekend and check the memory usage. I believe that it will s=
tabilize as I did run some valgrind testing (on our version) and most of th=
e accumulating memory was due to timers and bundles not getting freed until=
 expiration. I did fix one memory leak (fixed in the patch) but can’t=
 say positively that there is not another lurking in there somewhere.<=
/o:p>
&nb=
sp;
The =
std::multimap change would help some but not too much in this particular te=
st since the pending bundle list never grows beyond 5000 bundles. It would =
significantly help in the tests proposed by Will as the disconnects would r=
esult in lots of bundles accumulating in the first node.<=
/p>
 
We will be doing =
further testing with at least a 4-node architecture in the future.
 =

Thanks =
and best regards,
DZ
 
D=
avid Zoller
COLSA Corporation
Marshall Space Flight Center
 
From: Durst, Robert C. [mailt=
o:durst@mitre.org] 
Sent: Friday, June 29, 2012 9:37 AM
To:=
 Zoller, David A. (MSFC-EO60)[HOSC SERVICES CONTRACT]
Subject: RE: Re: [dtn-users] Improving performance in DTN2
 
David,
 
I don’t think I know you, but thi=
s is awesome.  Thanks!  
 
Do you have a sense of whether, after 2=
4 hours, memory usage would stabilize (under constant load)?  Any plan=
s to do a more extended test?  Also, do you have a sense of whether th=
e change to use std::multimap will positively affect the bundle throughput =
rate?  Finally, is there any need, desire, plan to do a three- (or mor=
e) node test?
 
This is great work in understanding what needs to be done to=
 use DTN2 in a “production” context.  Thanks for sharing i=
t.  
 
Best regards,
Bob Durst
<=
span style=3D'color:#1F497D'>The MITRE Corporation 
 
From:=
 dtn-users-bounces@irtf.org [mailto:dtn-users-bounces=
@irtf.org] On Behalf Of Zoller, David A. (MSFC-EO60)[HOSC SERVIC=
ES CONTRACT]
Sent: Friday, June 29, 2012 10:25 AM
To: <=
a href=3D"mailto:ahennes1@math.umd.edu">ahennes1@math.umd.edu
Cc:=
 dtn-users@irtf.org
Sub=
ject: Re: [dtn-users] Improving performance in DTN2
 
Angela,<=
/p>
I just joined the dtn-us=
ers mailing list yesterday and discovered that I’ve been working in a=
 vacuum. We’ve been working on implementing Aggregate Custody Signals=
 (ACS) in the DTN2 source code so that we can catch up with the ION version=
 updated by the University of Colorado at Boulder and get back into the DTN=
 network with their experiments. As I’ve been in the DTN2 source code=
, I have also been working on improving the throughput with the goal of str=
eaming video via DTN. I am currently working on an ACS patch to submit for =
the reference implementation and am including some of the performance enhan=
cements in it as a bonus. 
 
I just concluded a 22 hour test piping 167 frames[bundles with a 13=
16 byte payload] per second through two DTN nodes with custody transfer and=
 ACS processing. It processed 13,605,622 bundles and only lost 6 frames on =
the front end [missed UDP packets that never made it to the receiver that f=
eeds the first DTN node] which were probably not related to the DTN node=
217;s performance. This is using the reference implementation with the ACS =
patches. In memory, the dtnd process has grown to 2.1GB due to timers that =
have been canceled but have not yet expired since I use a 24 hour expiratio=
n time. I have a reaper thread that periodically clears the canceled timers=
 that I was not planning on including in the ACS patch since it requires a =
coordinated update to the oasys package but I think I’ll go ahead and=
 include it seeing that there is an interest.
 
On my development machine, our in-house version =
tops out at about 340 bundles/second and I haven’t tested the patched=
 reference implementation to that extent. Our in-house version has more ext=
ensive infrastructure changes that may not be suitable for a reference impl=
ementation since the goal was performance for our needs and some of the cha=
nges may have broken some of the nuances of the BP specification which I ha=
ve not studied in depth. We’ll check to see if there is a way to make=
 it available to the community for evaluation as there may be some mods tha=
t can be cherry picked for adapting into the reference implementation.=

 =

In the meantime, here a=
re some things we’ve run across:
 
* Configure and build oasys with the --disable-debug-=
locking option
 
* Yo=
u might gain improvements using the--disable-debug option when configuring =
both oasys and dtn2 but I haven’t bothered to do that yet as the debu=
g is still useful to me
 
* BundleDaemon is a single thread. I’ve broken this into multipl=
e threads: Input, Output, Storage, ACS and everything else in the original =
BD thread. The BD currently manages the oasys::TimerSystem which I changed =
to crank up the oasys::TimerThread to offload that work.
 
* BundleDaemon::find_duplicate() bo=
gs down significantly as you approach 15,000 bundles in the pending_bundles=
_ list. 
&nbs=
p;    !!Ha!! My intent was to use a std::multimap for t=
he pending bundles but I just saw that I used a std::map instead. I’l=
l have to go back and change that. Anyway, std::map is better suited for th=
is than the std::list and a change to std::multimap should be even better t=
o allow detection and retention of duplicates if so configured.<=
/p>
 
* CustodyTimers do not release=
 the reference to the bundle until they expire which keeps freed bundles fr=
om being removed as well as the timers. I use a reaper thread to periodical=
ly remove the canceled timers from the oasys::TimerSystem but I think addin=
g an overridable onCancel() method to the oasys::Timer class would be good =
way to trigger processing that could free the bundle reference and allow th=
e bundle to be freed quicker.
 
* I’m using the BerkeleyDB on a Solid State Drive.
 
* Payload storage to disk =
– the more files in the directory the longer it takes to add a bundle=
 to the database. I changed the payload directory structure to a tiered lay=
out with 10,000 bundle payload per directory.
 
* AdminRegistration and PingRegistration do not =
update the bundle fwdlog to delivered so they don’t get deleted until=
 they expire. Minor unless you have tons of custody signals hanging around =
but the leaner the memory usage the better J
 
Hope=
 this helps,
=
DZ
 =
;
 
David Zoller
COLSA Corporation
Marshall Space Flight Center
=

--_000_04E3D99A62496240BCD6A576813E6E318405E308AENDMSSCC05ndcn_--

From david.a.zoller@nasa.gov  Fri Jun 29 08:33:24 2012
Return-Path: 
X-Original-To: dtn-users@ietfa.amsl.com
Delivered-To: dtn-users@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C65321F86C3 for ; Fri, 29 Jun 2012 08:33:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.366
X-Spam-Level: 
X-Spam-Status: No, score=-6.366 tagged_above=-999 required=5 tests=[AWL=0.232,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zFK+XiMmQ9HW for ; Fri, 29 Jun 2012 08:33:17 -0700 (PDT)
Received: from ndmsnpf02.ndc.nasa.gov (ndmsnpf02.ndc.nasa.gov [198.117.0.122]) by ietfa.amsl.com (Postfix) with ESMTP id B764121F8715 for ; Fri, 29 Jun 2012 08:33:16 -0700 (PDT)
Received: from ndmsppt03.ndc.nasa.gov (ndmsppt03.ndc.nasa.gov [198.117.0.102]) by ndmsnpf02.ndc.nasa.gov (Postfix) with ESMTP id 522541480BF for ; Fri, 29 Jun 2012 10:33:16 -0500 (CDT)
Received: from ndmshub03.ndc.nasa.gov (ndmshub03-pub.ndc.nasa.gov [198.117.0.42]) by ndmsppt03.ndc.nasa.gov (8.14.5/8.14.5) with ESMTP id q5TFXF0k013976 for ; Fri, 29 Jun 2012 10:33:16 -0500
Received: from NDMSSCC05.ndc.nasa.gov ([198.117.2.174]) by ndmshub03.ndc.nasa.gov ([198.117.2.162]) with mapi; Fri, 29 Jun 2012 10:33:16 -0500
From: "Zoller, David A. (MSFC-EO60)[HOSC SERVICES CONTRACT]" 
To: "Ivancic, William D. (GRC-RHN0)" 
Date: Fri, 29 Jun 2012 10:32:54 -0500
Thread-Topic: [dtn-users] Improving performance in DTN2
Thread-Index: Ac1WB91ojfZpp4GVTjaIUik/DFMZqwAAw9Jg
Message-ID: <04E3D99A62496240BCD6A576813E6E318405E308CD@NDMSSCC05.ndc.nasa.gov>
References: <04E3D99A62496240BCD6A576813E6E318405E30822@NDMSSCC05.ndc.nasa.gov>  <04E3D99A62496240BCD6A576813E6E318405E3086F@NDMSSCC05.ndc.nasa.gov> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_04E3D99A62496240BCD6A576813E6E318405E308CDNDMSSCC05ndcn_"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.7.7855, 1.0.260, 0.0.0000 definitions=2012-06-29_04:2012-06-29, 2012-06-29, 1970-01-01 signatures=0
Cc: "dtn-users@irtf.org" 
Subject: Re: [dtn-users] Improving performance in DTN2
X-BeenThere: dtn-users@irtf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "The Delay-Tolerant Networking Research Group \(DTNRG\) - Users." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 29 Jun 2012 15:33:24 -0000

--_000_04E3D99A62496240BCD6A576813E6E318405E308CDNDMSSCC05ndcn_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

I'm sure this implementation will bog down during the disconnects as bundle=
s accumulate in the pending queue which impacts the find_duplicate() mentio=
ned below but I'll try to squeeze in some testing for you some time. What r=
outing do you use for the disconnects or should I  just pull the network ca=
ble?
DZ


David Zoller
COLSA Corporation
Marshall Space Flight Center

From: Ivancic, William D. (GRC-RHN0)
Sent: Friday, June 29, 2012 10:00 AM
To: Zoller, David A. (MSFC-EO60)[HOSC SERVICES CONTRACT]
Subject: Re: [dtn-users] Improving performance in DTN2

Add disconnection for 30 sec, 1 min, 5 min and 30 min and see what happens.

- Will

On Jun 29, 2012, at 10:55 AM, Zoller, David A. (MSFC-EO60)[HOSC SERVICES CO=
NTRACT] wrote:


This is using static routes over IP with no disconnection. The Aggregate Cu=
stody Signals are configured for 30 seconds, so every 30 seconds the first =
node takes a hit while it is releasing about 5000 bundles from custody. Ing=
est stops for a second or so and then as it catches up it processes at abou=
t 400 bundles per second.

David Zoller
COLSA Corporation
Marshall Space Flight Center

From: Ivancic, William D. (GRC-RHN0)
Sent: Friday, June 29, 2012 9:35 AM
To: Zoller, David A. (MSFC-EO60)[HOSC SERVICES CONTRACT]
Cc: ahennes1@math.umd.edu; dtn-users@irtf.org=

Subject: Re: [dtn-users] Improving performance in DTN2

How long were your periods of disconnection while streaming?

How many bundle where buffered during disconnection?

Also, what routing protocol was used - or just static routes over IP?

- Will Ivancic

On Jun 29, 2012, at 10:25 AM, Zoller, David A. (MSFC-EO60)[HOSC SERVICES CO=
NTRACT] wrote:



Angela,
I just joined the dtn-users mailing list yesterday and discovered that I've=
 been working in a vacuum. We've been working on implementing Aggregate Cus=
tody Signals (ACS) in the DTN2 source code so that we can catch up with the=
 ION version updated by the University of Colorado at Boulder and get back =
into the DTN network with their experiments. As I've been in the DTN2 sourc=
e code, I have also been working on improving the throughput with the goal =
of streaming video via DTN. I am currently working on an ACS patch to submi=
t for the reference implementation and am including some of the performance=
 enhancements in it as a bonus.

I just concluded a 22 hour test piping 167 frames[bundles with a 1316 byte =
payload] per second through two DTN nodes with custody transfer and ACS pro=
cessing. It processed 13,605,622 bundles and only lost 6 frames on the fron=
t end [missed UDP packets that never made it to the receiver that feeds the=
 first DTN node] which were probably not related to the DTN node's performa=
nce. This is using the reference implementation with the ACS patches. In me=
mory, the dtnd process has grown to 2.1GB due to timers that have been canc=
eled but have not yet expired since I use a 24 hour expiration time. I have=
 a reaper thread that periodically clears the canceled timers that I was no=
t planning on including in the ACS patch since it requires a coordinated up=
date to the oasys package but I think I'll go ahead and include it seeing t=
hat there is an interest.

On my development machine, our in-house version tops out at about 340 bundl=
es/second and I haven't tested the patched reference implementation to that=
 extent. Our in-house version has more extensive infrastructure changes tha=
t may not be suitable for a reference implementation since the goal was per=
formance for our needs and some of the changes may have broken some of the =
nuances of the BP specification which I have not studied in depth. We'll ch=
eck to see if there is a way to make it available to the community for eval=
uation as there may be some mods that can be cherry picked for adapting int=
o the reference implementation.

In the meantime, here are some things we've run across:

* Configure and build oasys with the --disable-debug-locking option

* You might gain improvements using the--disable-debug option when configur=
ing both oasys and dtn2 but I haven't bothered to do that yet as the debug =
is still useful to me

* BundleDaemon is a single thread. I've broken this into multiple threads: =
Input, Output, Storage, ACS and everything else in the original BD thread. =
The BD currently manages the oasys::TimerSystem which I changed to crank up=
 the oasys::TimerThread to offload that work.

* BundleDaemon::find_duplicate() bogs down significantly as you approach 15=
,000 bundles in the pending_bundles_ list.
     !!Ha!! My intent was to use a std::multimap for the pending bundles bu=
t I just saw that I used a std::map instead. I'll have to go back and chang=
e that. Anyway, std::map is better suited for this than the std::list and a=
 change to std::multimap should be even better to allow detection and reten=
tion of duplicates if so configured.

* CustodyTimers do not release the reference to the bundle until they expir=
e which keeps freed bundles from being removed as well as the timers. I use=
 a reaper thread to periodically remove the canceled timers from the oasys:=
:TimerSystem but I think adding an overridable onCancel() method to the oas=
ys::Timer class would be good way to trigger processing that could free the=
 bundle reference and allow the bundle to be freed quicker.

* I'm using the BerkeleyDB on a Solid State Drive.

* Payload storage to disk - the more files in the directory the longer it t=
akes to add a bundle to the database. I changed the payload directory struc=
ture to a tiered layout with 10,000 bundle payload per directory.

* AdminRegistration and PingRegistration do not update the bundle fwdlog to=
 delivered so they don't get deleted until they expire. Minor unless you ha=
ve tons of custody signals hanging around but the leaner the memory usage t=
he better :)

Hope this helps,
DZ


David Zoller
COLSA Corporation
Marshall Space Flight Center
_______________________________________________
dtn-users mailing list
dtn-users@irtf.org
https://www.irtf.org/mailman/listinfo/dtn-users



******************************
William D. Ivancic
Phone 216-433-3494
Fax 216-433-8705
Networking Lab 216-433-2620
Mobile 440-503-4892
http://roland.grc.nasa.gov/~ivancic


--_000_04E3D99A62496240BCD6A576813E6E318405E308CDNDMSSCC05ndcn_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


I’m=
 sure this implementation will bog down during the disconnects as bundles a=
ccumulate in the pending queue which impacts the find_duplicate() mentioned=
 below but I’ll try to squeeze in some testing for you some time. Wha=
t routing do you use for the disconnects or should I  just pull the ne=
twork cable? 
DZ
 
 
=
David Zoller
<=
span style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";color:#1F49=
7D'>COLSA Corporation
Marshall Space Flight Center
 
<=
p class=3DMsoNormal>From: Ivancic, William D. (GRC-RHN0) 
Sent: Fri=
day, June 29, 2012 10:00 AM
To: Zoller, David A. (MSFC-EO60)[HOSC=
 SERVICES CONTRACT]
Subject: Re: [dtn-users] Improving performanc=
e in DTN2
 =

Add disconnection for 30 sec, 1 min, 5 min a=
nd 30 min and see what happens.
 
- Will
 
On Jun 29, 2012, at 10:55 AM, Zoller, David A. (MSFC-EO60)[HOSC SERVIC=
ES CONTRACT] wrote:


<=
/o:p>
This is using static routes =
over IP with no disconnection. The Aggregate Custody Signals are configured=
 for 30 seconds, so every 30 seconds the first node takes a hit while it is=
 releasing about 5000 bundles from custody. Ingest stops for a second or so=
 and then as it catches up it processes at about 400 bundles per second.
 
David Zoller
COLSA Corporation
Marshall Space Flig=
ht Center
&nbs=
p;
From: Ivancic, William D. (GRC-RHN0) 
Sent: =
Friday, June 29, 2012 9:35 AM
To: Zoller, David A. (MSFC-EO60)[HOSC SERVICES CONTRACT=
]
Cc: ahennes1@math.umd.edu; dtn-use=
rs@irtf.org
Subject: =
;Re: [dtn-users] Improving performance in DTN2
=

 
How long were your periods of disconnection while str=
eaming?  
 
How many bundle wher=
e buffered during disconnection?  
 
Also, what routing protocol was used - or just static routes o=
ver IP?
 
- Will Ivancic
 
On Jun 29, 2012, at 10:25 AM, Zoller=
, David A. (MSFC-EO60)[HOSC SERVICES CONTRACT] wrote:
<=
/div>



<=
div>
Angela,
I just joined the dtn-users mailing list yesterday and discovered t=
hat I’ve been working in a vacuum. We’ve been working on implem=
enting Aggregate Custody Signals (ACS) in the DTN2 source code so that we c=
an catch up with the ION version updated by the University of Colorado at B=
oulder and get back into the DTN network with their experiments. As I’=
;ve been in the DTN2 source code, I have also been working on improving the=
 throughput with the goal of streaming video via DTN. I am currently workin=
g on an ACS patch to submit for the reference implementation and am includi=
ng some of the performance enhancements in it as a bonus.=

 
<=
/div>
I just concluded a 22 hour test piping 167 fra=
mes[bundles with a 1316 byte payload] per second through two DTN nodes with=
 custody transfer and ACS processing. It processed 13,605,622 bundles and o=
nly lost 6 frames on the front end [missed UDP packets that never made it t=
o the receiver that feeds the first DTN node] which were probably not relat=
ed to the DTN node’s performance. This is using the reference impleme=
ntation with the ACS patches. In memory, the dtnd process has grown to 2.1G=
B due to timers that have been canceled but have not yet expired since I us=
e a 24 hour expiration time. I have a reaper thread that periodically clear=
s the canceled timers that I was not planning on including in the ACS patch=
 since it requires a coordinated update to the oasys package but I think I&=
#8217;ll go ahead and include it seeing that there is an interest.
 
On my development machine, our in-hou=
se version tops out at about 340 bundles/second and I haven’t tested =
the patched reference implementation to that extent. Our in-house version h=
as more extensive infrastructure changes that may not be suitable for a ref=
erence implementation since the goal was performance for our needs and some=
 of the changes may have broken some of the nuances of the BP specification=
 which I have not studied in depth. We’ll check to see if there is a =
way to make it available to the community for evaluation as there may be so=
me mods that can be cherry picked for adapting into the reference implement=
ation.
 
In the meantime, here =
are some things we’ve run across:
 
* Configure and build oasys with the --disable-debug-locking opt=
ion
 <=
o:p>
* You might gain improvem=
ents using the--disable-debug option when configuring both oasys and dtn2 b=
ut I haven’t bothered to do that yet as the debug is still useful to =
me
 
* BundleDaemon is a single=
 thread. I’ve broken this into multiple threads: Input, Output, Stora=
ge, ACS and everything else in the original BD thread. The BD currently man=
ages the oasys::TimerSystem which I changed to crank up the oasys::TimerThr=
ead to offload that work.
 
* B=
undleDaemon::find_duplicate() bogs down significantly as you approach 15,00=
0 bundles in the pending_bundles_ list.
     !!Ha!! My intent was to=
 use a std::multimap for the pending bundles but I just saw that I used a s=
td::map instead. I’ll have to go back and change that. Anyway, std::m=
ap is better suited for this than the std::list and a change to std::multim=
ap should be even better to allow detection and retention of duplicates if =
so configured.
&nb=
sp;
* CustodyTimer=
s do not release the reference to the bundle until they expire which keeps =
freed bundles from being removed as well as the timers. I use a reaper thre=
ad to periodically remove the canceled timers from the oasys::TimerSystem b=
ut I think adding an overridable onCancel() method to the oasys::Timer clas=
s would be good way to trigger processing that could free the bundle refere=
nce and allow the bundle to be freed quicker.
 
* I’m using the BerkeleyDB on a Solid State Drive.
 =

* Payload storage to disk =
211; the more files in the directory the longer it takes to add a bundle to=
 the database. I changed the payload directory structure to a tiered layout=
 with 10,000 bundle payload per directory.
 
=

* AdminRegistration and PingRegistration do not update the bu=
ndle fwdlog to delivered so they don’t get deleted until they expire.=
 Minor unless you have tons of custody signals hanging around but the leane=
r the memory usage the better J
 
Hope this helps,
DZ
 
 
David Zoller
COLSA Corporation
=

Marshall Space Flight Center
____________________________________=
___________
dtn-users mailing list
dtn-users@irtf.org
https://www.irtf.org/mailman/listinfo/dtn-users
 <=
/p>
 
 
******************************
William D. Ivan=
cic
Phone 216-433-3494
<=
span class=3Dapple-style-span>Fax 216-433-8705
Networking Lab 216-433-2620
Mobile 440-503-4892
http://roland.grc.nasa.gov/~ivanci=
c
 
=

--_000_04E3D99A62496240BCD6A576813E6E318405E308CDNDMSSCC05ndcn_--

From robert.l.pitts@nasa.gov  Fri Jun 29 08:51:39 2012
Return-Path: 
X-Original-To: dtn-users@ietfa.amsl.com
Delivered-To: dtn-users@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4EB121F87C6 for ; Fri, 29 Jun 2012 08:51:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.598
X-Spam-Level: 
X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cQN7XDkDFa6O for ; Fri, 29 Jun 2012 08:51:33 -0700 (PDT)
Received: from ndjsnpf02.ndc.nasa.gov (ndjsnpf02.ndc.nasa.gov [198.117.1.122]) by ietfa.amsl.com (Postfix) with ESMTP id 48F8C21F86C9 for ; Fri, 29 Jun 2012 08:51:33 -0700 (PDT)
Received: from ndmsppt03.ndc.nasa.gov (ndmsppt03.ndc.nasa.gov [198.117.0.102]) by ndjsnpf02.ndc.nasa.gov (Postfix) with ESMTP id B27F3A8A83; Fri, 29 Jun 2012 10:51:32 -0500 (CDT)
Received: from ndmshub05.ndc.nasa.gov (ndmshub05.ndc.nasa.gov [198.117.2.164]) by ndmsppt03.ndc.nasa.gov (8.14.5/8.14.5) with ESMTP id q5TFpWxb001961; Fri, 29 Jun 2012 10:51:32 -0500
Received: from NDMSSCC07.ndc.nasa.gov ([198.117.2.178]) by ndmshub05.ndc.nasa.gov ([198.117.2.164]) with mapi; Fri, 29 Jun 2012 10:51:32 -0500
From: "Pitts, Robert L. (MSFC-EO60)[HOSC SERVICES CONTRACT]" 
To: "Zoller, David A. (MSFC-EO60)[HOSC SERVICES CONTRACT]" , "Durst, Robert C." 
Date: Fri, 29 Jun 2012 10:50:17 -0500
Thread-Topic: Re: [dtn-users] Improving performance in DTN2
Thread-Index: Ac1V+FEFO5BE0XoASo6VOyOKu/SAZAAC0LvQAADn1mAAAcVBkA==
Message-ID: 
References: <04E3D99A62496240BCD6A576813E6E318405E30822@NDMSSCC05.ndc.nasa.gov> <7A1B9532DA609B46927331283910A4C40BE3576A@IMCMBX02.MITRE.ORG> <04E3D99A62496240BCD6A576813E6E318405E308AE@NDMSSCC05.ndc.nasa.gov>
In-Reply-To: <04E3D99A62496240BCD6A576813E6E318405E308AE@NDMSSCC05.ndc.nasa.gov>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_FDD724529494FF4595F7C6BD415BB76341BE113D1ENDMSSCC07ndcn_"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.7.7855, 1.0.260, 0.0.0000 definitions=2012-06-29_04:2012-06-29, 2012-06-29, 1970-01-01 signatures=0
Cc: "dtn-users@irtf.org" 
Subject: Re: [dtn-users] Improving performance in DTN2
X-BeenThere: dtn-users@irtf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "The Delay-Tolerant Networking Research Group \(DTNRG\) - Users." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 29 Jun 2012 15:53:06 -0000

--_000_FDD724529494FF4595F7C6BD415BB76341BE113D1ENDMSSCC07ndcn_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Bob,

                David has been working the DTN project with me at MSFC as p=
art of NASA's project.   Our first implementation was with 2.7 and when we =
decided to step-up and do ACS and supported the DTN video at CCSDS we knew =
we had to do better.  This was done with some MSFC management funds as well=
 as with the DTN project.  David's extensions are making our deployment thi=
s fall much less risky.

Lee

From: dtn-users-bounces@irtf.org [mailto:dtn-users-bounces@irtf.org] On Beh=
alf Of Zoller, David A. (MSFC-EO60)[HOSC SERVICES CONTRACT]
Sent: Friday, June 29, 2012 10:21 AM
To: Durst, Robert C.
Cc: dtn-users@irtf.org
Subject: Re: [dtn-users] Improving performance in DTN2

Bob,
I like to lurk in the background but you may have run across Lee Pitts as h=
e is my front man :)

I just completed applying the patches to the latest sourceforge version yes=
terday morning and fired it up so I don't have long term results yet. I'll =
let it run over the weekend and check the memory usage. I believe that it w=
ill stabilize as I did run some valgrind testing (on our version) and most =
of the accumulating memory was due to timers and bundles not getting freed =
until expiration. I did fix one memory leak (fixed in the patch) but can't =
say positively that there is not another lurking in there somewhere.

The std::multimap change would help some but not too much in this particula=
r test since the pending bundle list never grows beyond 5000 bundles. It wo=
uld significantly help in the tests proposed by Will as the disconnects wou=
ld result in lots of bundles accumulating in the first node.

We will be doing further testing with at least a 4-node architecture in the=
 future.

Thanks and best regards,
DZ

David Zoller
COLSA Corporation
Marshall Space Flight Center

From: Durst, Robert C. [mailto:durst@mitre.org]
Sent: Friday, June 29, 2012 9:37 AM
To: Zoller, David A. (MSFC-EO60)[HOSC SERVICES CONTRACT]
Subject: RE: Re: [dtn-users] Improving performance in DTN2

David,

I don't think I know you, but this is awesome.  Thanks!

Do you have a sense of whether, after 24 hours, memory usage would stabiliz=
e (under constant load)?  Any plans to do a more extended test?  Also, do y=
ou have a sense of whether the change to use std::multimap will positively =
affect the bundle throughput rate?  Finally, is there any need, desire, pla=
n to do a three- (or more) node test?

This is great work in understanding what needs to be done to use DTN2 in a =
"production" context.  Thanks for sharing it.

Best regards,
Bob Durst
The MITRE Corporation

From: dtn-users-bounces@irtf.org [mailto=
:dtn-users-bounces@irtf.org] On=
 Behalf Of Zoller, David A. (MSFC-EO60)[HOSC SERVICES CONTRACT]
Sent: Friday, June 29, 2012 10:25 AM
To: ahennes1@math.umd.edu
Cc: dtn-users@irtf.org
Subject: Re: [dtn-users] Improving performance in DTN2

Angela,
I just joined the dtn-users mailing list yesterday and discovered that I've=
 been working in a vacuum. We've been working on implementing Aggregate Cus=
tody Signals (ACS) in the DTN2 source code so that we can catch up with the=
 ION version updated by the University of Colorado at Boulder and get back =
into the DTN network with their experiments. As I've been in the DTN2 sourc=
e code, I have also been working on improving the throughput with the goal =
of streaming video via DTN. I am currently working on an ACS patch to submi=
t for the reference implementation and am including some of the performance=
 enhancements in it as a bonus.

I just concluded a 22 hour test piping 167 frames[bundles with a 1316 byte =
payload] per second through two DTN nodes with custody transfer and ACS pro=
cessing. It processed 13,605,622 bundles and only lost 6 frames on the fron=
t end [missed UDP packets that never made it to the receiver that feeds the=
 first DTN node] which were probably not related to the DTN node's performa=
nce. This is using the reference implementation with the ACS patches. In me=
mory, the dtnd process has grown to 2.1GB due to timers that have been canc=
eled but have not yet expired since I use a 24 hour expiration time. I have=
 a reaper thread that periodically clears the canceled timers that I was no=
t planning on including in the ACS patch since it requires a coordinated up=
date to the oasys package but I think I'll go ahead and include it seeing t=
hat there is an interest.

On my development machine, our in-house version tops out at about 340 bundl=
es/second and I haven't tested the patched reference implementation to that=
 extent. Our in-house version has more extensive infrastructure changes tha=
t may not be suitable for a reference implementation since the goal was per=
formance for our needs and some of the changes may have broken some of the =
nuances of the BP specification which I have not studied in depth. We'll ch=
eck to see if there is a way to make it available to the community for eval=
uation as there may be some mods that can be cherry picked for adapting int=
o the reference implementation.

In the meantime, here are some things we've run across:

* Configure and build oasys with the --disable-debug-locking option

* You might gain improvements using the--disable-debug option when configur=
ing both oasys and dtn2 but I haven't bothered to do that yet as the debug =
is still useful to me

* BundleDaemon is a single thread. I've broken this into multiple threads: =
Input, Output, Storage, ACS and everything else in the original BD thread. =
The BD currently manages the oasys::TimerSystem which I changed to crank up=
 the oasys::TimerThread to offload that work.

* BundleDaemon::find_duplicate() bogs down significantly as you approach 15=
,000 bundles in the pending_bundles_ list.
     !!Ha!! My intent was to use a std::multimap for the pending bundles bu=
t I just saw that I used a std::map instead. I'll have to go back and chang=
e that. Anyway, std::map is better suited for this than the std::list and a=
 change to std::multimap should be even better to allow detection and reten=
tion of duplicates if so configured.

* CustodyTimers do not release the reference to the bundle until they expir=
e which keeps freed bundles from being removed as well as the timers. I use=
 a reaper thread to periodically remove the canceled timers from the oasys:=
:TimerSystem but I think adding an overridable onCancel() method to the oas=
ys::Timer class would be good way to trigger processing that could free the=
 bundle reference and allow the bundle to be freed quicker.

* I'm using the BerkeleyDB on a Solid State Drive.

* Payload storage to disk - the more files in the directory the longer it t=
akes to add a bundle to the database. I changed the payload directory struc=
ture to a tiered layout with 10,000 bundle payload per directory.

* AdminRegistration and PingRegistration do not update the bundle fwdlog to=
 delivered so they don't get deleted until they expire. Minor unless you ha=
ve tons of custody signals hanging around but the leaner the memory usage t=
he better :)

Hope this helps,
DZ


David Zoller
COLSA Corporation
Marshall Space Flight Center

--_000_FDD724529494FF4595F7C6BD415BB76341BE113D1ENDMSSCC07ndcn_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


Bob,
 
         &=
nbsp;      David has been working the DTN project =
with me at MSFC as part of NASA’s project.   Our first impl=
ementation was with 2.7 and when we decided to step-up and do ACS and suppo=
rted the DTN video at CCSDS we knew we had to do better.  This was don=
e with some MSFC management funds as well as with the DTN project.  Da=
vid’s extensions are making our deployment this fall much less risky.=

 
Lee
 
From: dtn-u=
sers-bounces@irtf.org [mailto:dtn-users-bounces@irtf.org] On Behalf Of <=
/b>Zoller, David A. (MSFC-EO60)[HOSC SERVICES CONTRACT]
Sent: Fri=
day, June 29, 2012 10:21 AM
To: Durst, Robert C.
Cc: dt=
n-users@irtf.org
Subject: Re: [dtn-users] Improving performance i=
n DTN2
 
Bob,
I like to lurk =
in the background but you may have run across Lee Pitts as he is my front m=
an J
 
I just completed applying the patches to the lat=
est sourceforge version yesterday morning and fired it up so I don’t =
have long term results yet. I’ll let it run over the weekend and chec=
k the memory usage. I believe that it will stabilize as I did run some valg=
rind testing (on our version) and most of the accumulating memory was due t=
o timers and bundles not getting freed until expiration. I did fix one memo=
ry leak (fixed in the patch) but can’t say positively that there is n=
ot another lurking in there somewhere.
 
The std::multimap change would help=
 some but not too much in this particular test since the pending bundle lis=
t never grows beyond 5000 bundles. It would significantly help in the tests=
 proposed by Will as the disconnects would result in lots of bundles accumu=
lating in the first node.
 
We will be doing further testing with at least a=
 4-node architecture in the future.
 
Thanks and best regards,
DZ
 
David Zoller<=
o:p>
COLSA Corporation
=
Marshall Space Flight Center
 
<=
p class=3DMsoNormal>From: Durst, Robert C. [mailto:durst@mitre.org] 
Sent: Friday, June 29, 20=
12 9:37 AM
To: Zoller, David A. (MSFC-EO60)[HOSC SERVICES CONTRAC=
T]
Subject: RE: Re: [dtn-users] Improving performance in DTN2
 
David,
 
I don’t think=
 I know you, but this is awesome.  Thanks!  
 
Do you have a sense=
 of whether, after 24 hours, memory usage would stabilize (under constant l=
oad)?  Any plans to do a more extended test?  Also, do you have a=
 sense of whether the change to use std::multimap will positively affect th=
e bundle throughput rate?  Finally, is there any need, desire, plan to=
 do a three- (or more) node test?
 
This is great work in understanding what=
 needs to be done to use DTN2 in a “production” context.  =
Thanks for sharing it.  
 
Best regards,
Bob Durst
<=
p class=3DMsoNormal>The MITRE Corporation 
=
 
From: dtn-users-bounc=
es@irtf.org [mai=
lto:dtn-users-bounces@irtf.org] On Behalf Of Zoller, David A. (M=
SFC-EO60)[HOSC SERVICES CONTRACT]
Sent: Friday, June 29, 2012 10:=
25 AM
To: ahennes1@math.=
umd.edu
Cc: dtn-users@i=
rtf.org
Subject: Re: [dtn-users] Improving performance in DTN=
2
 
Angela,
I j=
ust joined the dtn-users mailing list yesterday and discovered that I’=
;ve been working in a vacuum. We’ve been working on implementing Aggr=
egate Custody Signals (ACS) in the DTN2 source code so that we can catch up=
 with the ION version updated by the University of Colorado at Boulder and =
get back into the DTN network with their experiments. As I’ve been in=
 the DTN2 source code, I have also been working on improving the throughput=
 with the goal of streaming video via DTN. I am currently working on an ACS=
 patch to submit for the reference implementation and am including some of =
the performance enhancements in it as a bonus. 
 
I just concluded a 22 hour test piping 167 fra=
mes[bundles with a 1316 byte payload] per second through two DTN nodes with=
 custody transfer and ACS processing. It processed 13,605,622 bundles and o=
nly lost 6 frames on the front end [missed UDP packets that never made it t=
o the receiver that feeds the first DTN node] which were probably not relat=
ed to the DTN node’s performance. This is using the reference impleme=
ntation with the ACS patches. In memory, the dtnd process has grown to 2.1G=
B due to timers that have been canceled but have not yet expired since I us=
e a 24 hour expiration time. I have a reaper thread that periodically clear=
s the canceled timers that I was not planning on including in the ACS patch=
 since it requires a coordinated update to the oasys package but I think I&=
#8217;ll go ahead and include it seeing that there is an interest.
 
=

On my development machine, =
our in-house version tops out at about 340 bundles/second and I haven’=
;t tested the patched reference implementation to that extent. Our in-house=
 version has more extensive infrastructure changes that may not be suitable=
 for a reference implementation since the goal was performance for our need=
s and some of the changes may have broken some of the nuances of the BP spe=
cification which I have not studied in depth. We’ll check to see if t=
here is a way to make it available to the community for evaluation as there=
 may be some mods that can be cherry picked for adapting into the reference=
 implementation.
 
In=
 the meantime, here are some things we’ve run across:
<=
p class=3DMsoNormal style=3D'margin-left:.5in'> 
* Configure and build oasys with t=
he --disable-debug-locking option
 
* You might gain improvements using the--disable-debug opti=
on when configuring both oasys and dtn2 but I haven’t bothered to do =
that yet as the debug is still useful to me
 
* BundleDaemon is a single thread. I’ve brok=
en this into multiple threads: Input, Output, Storage, ACS and everything e=
lse in the original BD thread. The BD currently manages the oasys::TimerSys=
tem which I changed to crank up the oasys::TimerThread to offload that work=
.
 =

* BundleDaemon::f=
ind_duplicate() bogs down significantly as you approach 15,000 bundles in t=
he pending_bundles_ list. 
     !!Ha!! My intent was to use a s=
td::multimap for the pending bundles but I just saw that I used a std::map =
instead. I’ll have to go back and change that. Anyway, std::map is be=
tter suited for this than the std::list and a change to std::multimap shoul=
d be even better to allow detection and retention of duplicates if so confi=
gured.
&=
nbsp;
* CustodyTim=
ers do not release the reference to the bundle until they expire which keep=
s freed bundles from being removed as well as the timers. I use a reaper th=
read to periodically remove the canceled timers from the oasys::TimerSystem=
 but I think adding an overridable onCancel() method to the oasys::Timer cl=
ass would be good way to trigger processing that could free the bundle refe=
rence and allow the bundle to be freed quicker.
 
* I’m using the BerkeleyDB on a Solid St=
ate Drive.
 
* Payloa=
d storage to disk – the more files in the directory the longer it tak=
es to add a bundle to the database. I changed the payload directory structu=
re to a tiered layout with 10,000 bundle payload per directory.<=
/p>
 
* AdminRegistration and PingRe=
gistration do not update the bundle fwdlog to delivered so they don’t=
 get deleted until they expire. Minor unless you have tons of custody signa=
ls hanging around but the leaner the memory usage the better J
 
Hope this helps,
DZ
 
 
=
David Zoller
COLSA Corporation
Marshall Space Flight Ce=
nter
=

--_000_FDD724529494FF4595F7C6BD415BB76341BE113D1ENDMSSCC07ndcn_--

From James.R.Wright@colorado.edu  Fri Jun 29 10:31:36 2012
Return-Path: 
X-Original-To: dtn-users@ietfa.amsl.com
Delivered-To: dtn-users@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2940021F87BE for ; Fri, 29 Jun 2012 10:31:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.598
X-Spam-Level: 
X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2sxFtG9J8AIA for ; Fri, 29 Jun 2012 10:31:35 -0700 (PDT)
Received: from ipmx2.colorado.edu (ipmx2.colorado.edu [128.138.128.232]) by ietfa.amsl.com (Postfix) with ESMTP id 7349421F87DC for ; Fri, 29 Jun 2012 10:31:35 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ao0HAPDl7U/AqBGb/2dsb2JhbABCA4Z1sGiCGQEFeRACAQgEAToHMhQRAQEEDgWICwGzH4kEjiCCQWADiEqcbIJ+
X-IronPort-AV: E=Sophos;i="4.77,498,1336370400"; d="scan'208,217";a="2585765"
Received: from omr-raz-2-priv.int.colorado.edu ([192.168.17.155]) by ipmx2-priv.int.colorado.edu with ESMTP; 29 Jun 2012 11:31:34 -0600
Received: from exhub1-pub.colorado.edu (EHLO exhub1.ad.colorado.edu) ([128.138.123.207]) by omr-raz-2-priv.int.colorado.edu (MOS 4.1.10-GA FastPath queued) with ESMTP id DRA72457; Fri, 29 Jun 2012 11:31:34 -0600 (MDT)
Received: from exc4.ad.colorado.edu ([fe80::884c:d8ff:be51:8b4f]) by exhub1.ad.colorado.edu ([::1]) with mapi; Fri, 29 Jun 2012 11:31:33 -0600
From: Jim Wright 
To: "Zoller, David A. (MSFC-EO60)[HOSC SERVICES CONTRACT]" 
Date: Fri, 29 Jun 2012 11:31:54 -0600
Thread-Topic: [dtn-users] Improving performance in DTN2
Thread-Index: Ac1WHQbWGHGWB88uSGqkR1vrsOhKuw==
Message-ID: 
References: <04E3D99A62496240BCD6A576813E6E318405E30822@NDMSSCC05.ndc.nasa.gov> <7A1B9532DA609B46927331283910A4C40BE3576A@IMCMBX02.MITRE.ORG> <04E3D99A62496240BCD6A576813E6E318405E308AE@NDMSSCC05.ndc.nasa.gov>
In-Reply-To: <04E3D99A62496240BCD6A576813E6E318405E308AE@NDMSSCC05.ndc.nasa.gov>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_F7E29C11111E430385512E87CFE5CD50coloradoedu_"
MIME-Version: 1.0
Cc: "dtn-users@irtf.org" 
Subject: Re: [dtn-users] Improving performance in DTN2
X-BeenThere: dtn-users@irtf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "The Delay-Tolerant Networking Research Group \(DTNRG\) - Users." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 29 Jun 2012 17:31:36 -0000

--_000_F7E29C11111E430385512E87CFE5CD50coloradoedu_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

David, Wireshark 1.8 has just been released. It contains enhancements to th=
e Bundle Protocol dissection that I added recently. The main focus of the w=
ork was adding the ability to handle ACS, CTEB and ECOS. Hope this helps!


Jim Wright
BioServe Space Technologies
james.r.wright@colorado.edu
303-492-1579


--_000_F7E29C11111E430385512E87CFE5CD50coloradoedu_
Content-Type: text/html; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable



Jim Wright
BioServe Space Tec=
hnologies
303-492-1579




=

--_000_F7E29C11111E430385512E87CFE5CD50coloradoedu_--

From william.d.ivancic@nasa.gov  Fri Jun 29 10:37:25 2012
Return-Path: 
X-Original-To: dtn-users@ietfa.amsl.com
Delivered-To: dtn-users@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E475321F880D for ; Fri, 29 Jun 2012 10:37:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.603
X-Spam-Level: 
X-Spam-Status: No, score=-5.603 tagged_above=-999 required=5 tests=[AWL=0.995,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Easi-052T0zQ for ; Fri, 29 Jun 2012 10:37:24 -0700 (PDT)
Received: from ndmsnpf03.ndc.nasa.gov (ndmsnpf03.ndc.nasa.gov [198.117.0.123]) by ietfa.amsl.com (Postfix) with ESMTP id DC6DE21F8806 for ; Fri, 29 Jun 2012 10:37:23 -0700 (PDT)
Received: from ndjsppt03.ndc.nasa.gov (ndjsppt03.ndc.nasa.gov [198.117.1.102]) by ndmsnpf03.ndc.nasa.gov (Postfix) with ESMTP id 299872D8B1E for ; Fri, 29 Jun 2012 12:37:23 -0500 (CDT)
Received: from ndjshub04.ndc.nasa.gov (ndjshub04-pub.ndc.nasa.gov [198.117.1.34]) by ndjsppt03.ndc.nasa.gov (8.14.5/8.14.5) with ESMTP id q5THbMCB023209 for ; Fri, 29 Jun 2012 12:37:22 -0500
Received: from NDJSSCC07.ndc.nasa.gov ([198.117.4.178]) by ndjshub04.ndc.nasa.gov ([10.202.202.163]) with mapi; Fri, 29 Jun 2012 12:37:22 -0500
From: "Ivancic, William D. (GRC-RHN0)" 
To: "Zoller, David A. (MSFC-EO60)[HOSC SERVICES CONTRACT]" 
Date: Fri, 29 Jun 2012 12:37:20 -0500
Thread-Topic: [dtn-users] Improving performance in DTN2
Thread-Index: Ac1WHda9NVMPNEtqTTKFXdojbmnG9w==
Message-ID: <9C1F96BD-8EB2-4B46-8EAD-25F245DB24AF@nasa.gov>
References: <04E3D99A62496240BCD6A576813E6E318405E30822@NDMSSCC05.ndc.nasa.gov>  <04E3D99A62496240BCD6A576813E6E318405E3086F@NDMSSCC05.ndc.nasa.gov>  <04E3D99A62496240BCD6A576813E6E318405E308CD@NDMSSCC05.ndc.nasa.gov>
In-Reply-To: <04E3D99A62496240BCD6A576813E6E318405E308CD@NDMSSCC05.ndc.nasa.gov>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_9C1F96BD8EB24B468EAD25F245DB24AFnasagov_"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.7.7855, 1.0.260, 0.0.0000 definitions=2012-06-29_05:2012-06-29, 2012-06-29, 1970-01-01 signatures=0
Cc: "dtn-users@irtf.org" 
Subject: Re: [dtn-users] Improving performance in DTN2
X-BeenThere: dtn-users@irtf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "The Delay-Tolerant Networking Research Group \(DTNRG\) - Users." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 29 Jun 2012 17:37:26 -0000

--_000_9C1F96BD8EB24B468EAD25F245DB24AFnasagov_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

You can disconnect in a number of ways:
netem
pull cable (but not very repeatable timing wise)
modify ip-table script or link up/down script (probably the easiest and cau=
ses the least strain on the CPU).
put a channel emulator in between DTN nodes.

The point is, you're streaming in a disconnected environment otherwise ther=
e is no reason to use DTN.  So you need to test the storage, not just the f=
orwarding.

You probably should also put in some other bundle source/destination pairs =
with various lifetimes.

You need to see where it breaks and how fragile (or not) the system is.  Tu=
ning a configuration to get something to work is just the start.


- Will

On Jun 29, 2012, at 11:32 AM, Zoller, David A. (MSFC-EO60)[HOSC SERVICES CO=
NTRACT] wrote:

I=92m sure this implementation will bog down during the disconnects as bund=
les accumulate in the pending queue which impacts the find_duplicate() ment=
ioned below but I=92ll try to squeeze in some testing for you some time. Wh=
at routing do you use for the disconnects or should I  just pull the networ=
k cable?
DZ


David Zoller
COLSA Corporation
Marshall Space Flight Center

From: Ivancic, William D. (GRC-RHN0)
Sent: Friday, June 29, 2012 10:00 AM
To: Zoller, David A. (MSFC-EO60)[HOSC SERVICES CONTRACT]
Subject: Re: [dtn-users] Improving performance in DTN2

Add disconnection for 30 sec, 1 min, 5 min and 30 min and see what happens.

- Will

On Jun 29, 2012, at 10:55 AM, Zoller, David A. (MSFC-EO60)[HOSC SERVICES CO=
NTRACT] wrote:


This is using static routes over IP with no disconnection. The Aggregate Cu=
stody Signals are configured for 30 seconds, so every 30 seconds the first =
node takes a hit while it is releasing about 5000 bundles from custody. Ing=
est stops for a second or so and then as it catches up it processes at abou=
t 400 bundles per second.

David Zoller
COLSA Corporation
Marshall Space Flight Center

From: Ivancic, William D. (GRC-RHN0)
Sent: Friday, June 29, 2012 9:35 AM
To: Zoller, David A. (MSFC-EO60)[HOSC SERVICES CONTRACT]
Cc: ahennes1@math.umd.edu; dtn-users@irtf.org=

Subject: Re: [dtn-users] Improving performance in DTN2

How long were your periods of disconnection while streaming?

How many bundle where buffered during disconnection?

Also, what routing protocol was used - or just static routes over IP?

- Will Ivancic

On Jun 29, 2012, at 10:25 AM, Zoller, David A. (MSFC-EO60)[HOSC SERVICES CO=
NTRACT] wrote:



Angela,
I just joined the dtn-users mailing list yesterday and discovered that I=92=
ve been working in a vacuum. We=92ve been working on implementing Aggregate=
 Custody Signals (ACS) in the DTN2 source code so that we can catch up with=
 the ION version updated by the University of Colorado at Boulder and get b=
ack into the DTN network with their experiments. As I=92ve been in the DTN2=
 source code, I have also been working on improving the throughput with the=
 goal of streaming video via DTN. I am currently working on an ACS patch to=
 submit for the reference implementation and am including some of the perfo=
rmance enhancements in it as a bonus.

I just concluded a 22 hour test piping 167 frames[bundles with a 1316 byte =
payload] per second through two DTN nodes with custody transfer and ACS pro=
cessing. It processed 13,605,622 bundles and only lost 6 frames on the fron=
t end [missed UDP packets that never made it to the receiver that feeds the=
 first DTN node] which were probably not related to the DTN node=92s perfor=
mance. This is using the reference implementation with the ACS patches. In =
memory, the dtnd process has grown to 2.1GB due to timers that have been ca=
nceled but have not yet expired since I use a 24 hour expiration time. I ha=
ve a reaper thread that periodically clears the canceled timers that I was =
not planning on including in the ACS patch since it requires a coordinated =
update to the oasys package but I think I=92ll go ahead and include it seei=
ng that there is an interest.

On my development machine, our in-house version tops out at about 340 bundl=
es/second and I haven=92t tested the patched reference implementation to th=
at extent. Our in-house version has more extensive infrastructure changes t=
hat may not be suitable for a reference implementation since the goal was p=
erformance for our needs and some of the changes may have broken some of th=
e nuances of the BP specification which I have not studied in depth. We=92l=
l check to see if there is a way to make it available to the community for =
evaluation as there may be some mods that can be cherry picked for adapting=
 into the reference implementation.

In the meantime, here are some things we=92ve run across:

* Configure and build oasys with the --disable-debug-locking option

* You might gain improvements using the--disable-debug option when configur=
ing both oasys and dtn2 but I haven=92t bothered to do that yet as the debu=
g is still useful to me

* BundleDaemon is a single thread. I=92ve broken this into multiple threads=
: Input, Output, Storage, ACS and everything else in the original BD thread=
. The BD currently manages the oasys::TimerSystem which I changed to crank =
up the oasys::TimerThread to offload that work.

* BundleDaemon::find_duplicate() bogs down significantly as you approach 15=
,000 bundles in the pending_bundles_ list.
     !!Ha!! My intent was to use a std::multimap for the pending bundles bu=
t I just saw that I used a std::map instead. I=92ll have to go back and cha=
nge that. Anyway, std::map is better suited for this than the std::list and=
 a change to std::multimap should be even better to allow detection and ret=
ention of duplicates if so configured.

* CustodyTimers do not release the reference to the bundle until they expir=
e which keeps freed bundles from being removed as well as the timers. I use=
 a reaper thread to periodically remove the canceled timers from the oasys:=
:TimerSystem but I think adding an overridable onCancel() method to the oas=
ys::Timer class would be good way to trigger processing that could free the=
 bundle reference and allow the bundle to be freed quicker.

* I=92m using the BerkeleyDB on a Solid State Drive.

* Payload storage to disk =96 the more files in the directory the longer it=
 takes to add a bundle to the database. I changed the payload directory str=
ucture to a tiered layout with 10,000 bundle payload per directory.

* AdminRegistration and PingRegistration do not update the bundle fwdlog to=
 delivered so they don=92t get deleted until they expire. Minor unless you =
have tons of custody signals hanging around but the leaner the memory usage=
 the better :)

Hope this helps,
DZ


David Zoller
COLSA Corporation
Marshall Space Flight Center
_______________________________________________
dtn-users mailing list
dtn-users@irtf.org
https://www.irtf.org/mailman/listinfo/dtn-users



******************************
William D. Ivancic
Phone 216-433-3494
Fax 216-433-8705
Networking Lab 216-433-2620
Mobile 440-503-4892
http://roland.grc.nasa.gov/~ivancic


******************************
William D. Ivancic
Phone 216-433-3494
Fax 216-433-8705
Networking Lab 216-433-2620
Mobile 440-503-4892
http://roland.grc.nasa.gov/~ivancic


--_000_9C1F96BD8EB24B468EAD25F245DB24AFnasagov_
Content-Type: text/html; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable


I=92m sure this implementation will bog down during the dis=
connects as bundles accumulate in the pending queue which impacts the find_=
duplicate() mentioned below but I=92ll try to squeeze in some testing for y=
ou some time. What routing do you use for the disconnects or should I  =
;just pull the network cable?
DZ<=
o:p>
 
 
David Z=
oller
COLS=
A Corporation
Marshall Space Flight Center
 
=
From:=
 Ivancic, William D. (GRC=
-RHN0) 
Sent: Friday, June 29, 2012 10:0=
0 AM
To: Zoller=
, David A. (MSFC-EO60)[HOSC SERVICES CONTRACT]
Subject: Re: [dtn-users] Improving performa=
nce in DTN2
 
Add=
 disconnection for 30 sec, 1 min, 5 min and 30 min and see what happens.
 
- Will
 
On Jun 29, 2012, at 10:55 =
AM, Zoller, David A. (MSFC-EO60)[HOSC SERVICES CONTRACT] wrote:<=
/div>
This is u=
sing static routes over IP with no disconnection. The Aggregate Custody Sig=
nals are configured for 30 seconds, so every 30 seconds the first node take=
s a hit while it is releasing about 5000 bundles from custody. Ingest stops=
 for a second or so and then as it catches up it processes at about 400 bun=
dles per second.
 =
;
David Zoller
COLSA Corporation
Marshall Space Flight Center=

 
From: Ivancic=
, William D. (GRC-RHN0) <=
br>Sent: Friday, J=
une 29, 2012 9:35 AM
To:&nb=
sp;Zoller, David A. (MSFC-EO60)[HOSC SERVICES CONTRACT]
Cc: ahenn=
es1@math.umd.edu; dtn-users@irtf.org
Subject: Re: [dtn-users] Improving performance in DTN2<=
/span>
 
How long were your periods of disconnection while streaming?  <=
o:p>
 
How many bundle where buffered during disconnection?  <=
/div>
 
A=
lso, what routing protocol was used - or just static routes over IP?
 
- Will Ivancic
 =

On Jun 29, 2012, at 10:25 AM, Zoller, David A. =
(MSFC-EO60)[HOSC SERVICES CONTRACT] wrote:
Angela,
I just joined the dtn-users mailing list yesterday and di=
scovered that I=92ve been working in a vacuum. We=92ve been working on impl=
ementing Aggregate Custody Signals (ACS) in the DTN2 source code so that we=
 can catch up with the ION version updated by the University of Colorado at=
 Boulder and get back into the DTN network with their experiments. As I=92v=
e been in the DTN2 source code, I have also been working on improving the t=
hroughput with the goal of streaming video via DTN. I am currently working =
on an ACS patch to submit for the reference implementation and am including=
 some of the performance enhancements in it as a bonus.
 
I just co=
ncluded a 22 hour test piping 167 frames[bundles with a 1316 byte payload] =
per second through two DTN nodes with custody transfer and ACS processing. =
It processed 13,605,622 bundles and only lost 6 frames on the front end [mi=
ssed UDP packets that never made it to the receiver that feeds the first DT=
N node] which were probably not related to the DTN node=92s performance. Th=
is is using the reference implementation with the ACS patches. In memory, t=
he dtnd process has grown to 2.1GB due to timers that have been canceled bu=
t have not yet expired since I use a 24 hour expiration time. I have a reap=
er thread that periodically clears the canceled timers that I was not plann=
ing on including in the ACS patch since it requires a coordinated update to=
 the oasys package but I think I=92ll go ahead and include it seeing that t=
here is an interest.
 
On my development machine, our in-house vers=
ion tops out at about 340 bundles/second and I haven=92t tested the patched=
 reference implementation to that extent. Our in-house version has more ext=
ensive infrastructure changes that may not be suitable for a reference impl=
ementation since the goal was performance for our needs and some of the cha=
nges may have broken some of the nuances of the BP specification which I ha=
ve not studied in depth. We=92ll check to see if there is a way to make it =
available to the community for evaluation as there may be some mods that ca=
n be cherry picked for adapting into the reference implementation.
 
 
* Con=
figure and build oasys with the --disable-debug-locking option<=
/o:p>
 
<=
div>
* =
You might gain improvements using the--disable-debug option when configurin=
g both oasys and dtn2 but I haven=92t bothered to do that yet as the debug =
is still useful to me
 <=
o:p>
* BundleDaemon is a single thread. I=92ve b=
roken this into multiple threads: Input, Output, Storage, ACS and everythin=
g else in the original BD thread. The BD currently manages the oasys::Timer=
System which I changed to crank up the oasys::TimerThread to offload that w=
ork.
 
<=
/div>
* BundleDaemon::find_duplicate() bogs down significantly as =
you approach 15,000 bundles in the pending_bundles_ list.=

     !!Ha!! My intent was to=
 use a std::multimap for the pending bundles but I just saw that I used a s=
td::map instead. I=92ll have to go back and change that. Anyway, std::map i=
s better suited for this than the std::list and a change to std::multimap s=
hould be even better to allow detection and retention of duplicates if so c=
onfigured.
 <=
/div>
* CustodyTimers do not release the reference to the bu=
ndle until they expire which keeps freed bundles from being removed as well=
 as the timers. I use a reaper thread to periodically remove the canceled t=
imers from the oasys::TimerSystem but I think adding an overridable onCance=
l() method to the oasys::Timer class would be good way to trigger processin=
g that could free the bundle reference and allow the bundle to be freed qui=
cker.
 
=

* I=92m using the BerkeleyDB on a Solid State Drive.=

 
=

* Payload storage to disk =96 the more files in the directory the longe=
r it takes to add a bundle to the database. I changed the payload directory=
 structure to a tiered layout with 10,000 bundle payload per directory.
 
* AdminRegistration and PingRegistration do not update the bundle fw=
dlog to delivered so they don=92t get deleted until they expire. Minor unle=
ss you have tons of custody signals hanging around but the leaner the memor=
y usage the better J
 
Hope=
 this helps,
DZ
 
 
David Zoller
COLSA Corporatio=
n
Marshall Sp=
ace Flight Center
___________________=
____________________________
dtn-users mailing list
dt=
n-users@irtf.org
https://www.ir=
tf.org/mailman/listinfo/dtn-users
 
 
 
**=
****************************
William D. I=
vancic
Phone 216-433-3494=

Fax 216-433-8705
Networking Lab 216-433-2620
Mobile 440-503-4892
http://roland.grc.nasa.gov/~ivancic
 <=
/o:p>



******************************
William D. Ivancic
Phone 216-433-3494
Fax 216-433-8705
Ne=
tworking Lab 216-433-2620
Mobile =
440-503-4892
http://roland.grc.nasa.gov/~ivancic




=

--_000_9C1F96BD8EB24B468EAD25F245DB24AFnasagov_--

From david.a.zoller@nasa.gov  Fri Jun 29 11:08:56 2012
Return-Path: 
X-Original-To: dtn-users@ietfa.amsl.com
Delivered-To: dtn-users@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52DE421F881C for ; Fri, 29 Jun 2012 11:08:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.413
X-Spam-Level: 
X-Spam-Status: No, score=-6.413 tagged_above=-999 required=5 tests=[AWL=0.186,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id umfCCRQy37V0 for ; Fri, 29 Jun 2012 11:08:54 -0700 (PDT)
Received: from ndjsnpf02.ndc.nasa.gov (ndjsnpf02.ndc.nasa.gov [198.117.1.122]) by ietfa.amsl.com (Postfix) with ESMTP id 70DAA21F8757 for ; Fri, 29 Jun 2012 11:08:54 -0700 (PDT)
Received: from ndmsppt04.ndc.nasa.gov (ndmsppt04.ndc.nasa.gov [198.117.0.103]) by ndjsnpf02.ndc.nasa.gov (Postfix) with ESMTP id 949FDA8A88; Fri, 29 Jun 2012 13:08:53 -0500 (CDT)
Received: from ndmshub01.ndc.nasa.gov (ndmshub01-pub.ndc.nasa.gov [198.117.0.160]) by ndmsppt04.ndc.nasa.gov (8.14.5/8.14.5) with ESMTP id q5TI8rQD006055;  Fri, 29 Jun 2012 13:08:53 -0500
Received: from NDMSSCC05.ndc.nasa.gov ([198.117.2.174]) by ndmshub01.ndc.nasa.gov ([192.168.0.111]) with mapi; Fri, 29 Jun 2012 13:08:53 -0500
From: "Zoller, David A. (MSFC-EO60)[HOSC SERVICES CONTRACT]" 
To: "ahennes1@math.umd.edu" 
Date: Fri, 29 Jun 2012 13:08:31 -0500
Thread-Topic: [dtn-users] Improving performance in DTN2
Thread-Index: Ac1WFZPGIIN2HbyFQwmR3vPyF087jgAANxUA
Message-ID: <04E3D99A62496240BCD6A576813E6E318405E309ED@NDMSSCC05.ndc.nasa.gov>
References: <04E3D99A62496240BCD6A576813E6E318405E30822@NDMSSCC05.ndc.nasa.gov>  <04E3D99A62496240BCD6A576813E6E318405E3086F@NDMSSCC05.ndc.nasa.gov> <7f1c32f16683f53d1d76ae575dc9bceb.squirrel@webmail.math.umd.edu>
In-Reply-To: <7f1c32f16683f53d1d76ae575dc9bceb.squirrel@webmail.math.umd.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.7.7855, 1.0.260, 0.0.0000 definitions=2012-06-29_05:2012-06-29, 2012-06-29, 1970-01-01 signatures=0
Cc: "gjohnson@ltsnet.net" , "dtn-users@irtf.org" 
Subject: Re: [dtn-users] Improving performance in DTN2
X-BeenThere: dtn-users@irtf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "The Delay-Tolerant Networking Research Group \(DTNRG\) - Users." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 29 Jun 2012 18:08:56 -0000

Angela,
Thanks and good questions...

1) I believe the 340 bundles/second is the API performance rather than the =
network performance. I have an app on the front end which reads a socket an=
d passes the data as a payload to the dtn_send() method on the first node. =
The counter increments after each return from the dtn_send() call. On the b=
ack end of the other node, I have the counterpart app (similar to dtnsink) =
which accepts delivery of bundles as fast as it can and reports its bundles=
/second.

Thinking about it , when I said that it "tops out", I really mean that the =
input rate to the first node is sustained fairly smoothly at that rate. If =
I take the rate higher, then the input rate gets choppy and UDP packets get=
 dropped (I have a sequence counter in the data). This was just an informal=
 run out of curiosity, and as I recall, the output from the second node was=
 probably pretty choppy. The second system does not perform as well as the =
development system so I don't know if it was the culprit or if there are so=
me inefficiencies in the output side of the first node.

Before too long, I'll be able to set up tests with 4 similar systems. I can=
 see that there are a lot of variations and quantifying to be done and so f=
ew hours per day :)

2) Thanks for pointing out the --disable-debug-memory option. After finding=
 the first, I hadn't thought to look for others.

3) The "multi-threaded BundleDaemon" will not be part of the ACS patch as t=
hat is what I think might introduce some non-conformant behavior. One for i=
nstance, a colleague told me that he tested the reference implementation us=
ing two opportunistic routes for an EID and found that it only delivered bu=
ndles on the first route even though both were available which is what he w=
anted. I have not tried it but I think that this behavior would be changed =
and the bundles would be delivered to both routes. I have not dug into the =
spec to determine the correct behavior.=20

4) find_duplicate - The map/multimap will not be part of the ACS patch beca=
use that starts snowballing into pulling in additional changes needed it to=
 support it. I use the GbofId  string as the key into the map so there is n=
o need to iterate through the list to see if the bundle is in it.=20

5) When a bundle is added to the BundleStorage, everything but the payload =
is actually stored in the database. The payload for each bundle is written =
to disk in its own file in the $dbdir/bundles directory in the default conf=
iguration. The more files there are in that bundles directory, the longer i=
t takes the operating system to open a new file in it. On my system, I was =
able to detect noticeable slowdown when there were around 15-20,000 files. =
I changed the BundlePayload to write the first 10000 payloads to $dbdir/bun=
dles/0/,  the next 10000 in $dbdir/bundles/1/, etc.

I was not planning on including the directory changes in the ACS patch but =
it is pretty self-contained and not too difficult to add.=20


I'm not sure who makes the call as to what ends up in the official referenc=
e implementation but you have my condolences. :)
DZ



David Zoller
COLSA Corporation
HOSC / M103=A0=20
/Office: (256)=A0544-1820
(EMail: david.a.zoller@nasa.gov


-----Original Message-----
From: ahennes1@math.umd.edu [mailto:ahennes1@math.umd.edu]=20
Sent: Friday, June 29, 2012 11:38 AM
To: Zoller, David A. (MSFC-EO60)[HOSC SERVICES CONTRACT]
Cc: Ivancic, William D. (GRC-RHN0); brenton@cs.wisc.edu; gjohnson@ltsnet.ne=
t
Subject: RE: [dtn-users] Improving performance in DTN2

David,

Thanks very much for all the information! That would be great if you're abl=
e to release some of the performance improvements as part of the patch.
 If you don't mind, I have a few questions/comments:

You mentioned that DTN2 tops out at about 340 bundles/second. What exactly =
are you measuring here? Is it just the network throughput, or are you also =
measuring the API performance?

We also found that the --disable-debug-locking flag helps with performance,=
 as well as the --disable-debug-memory flag.

I don't quite understand how you made BundleDaemon into multiple threads, w=
ill this be part of the code release you mentioned?

That's interesting that you mentioned BundleDaemon::find_duplicate. That fu=
nction showed up in our profile testing as well. I rewrote that as a hash m=
ap and it made a little difference, about 5% if I remember correctly. I'm n=
ot quite sure how a multimap would be better here, could you explain this a=
 little more? And will this be part of the code release as well?

You're note about custody timers is really interesting, this isn't somethin=
g we looked at, so I'll have to spend some time looking into this.

I'm also confused about the payload directory structure you mentioned, coul=
d you describe this a little more as well?


Thanks again for all the info, it's great to hear other people are interest=
ed in this as well!


-Angela



Agnela Hennessy
Laboratory for Telecommunications Sciences (LTS)
301-422-5287



> This is using static routes over IP with no disconnection. The=20
> Aggregate Custody Signals are configured for 30 seconds, so every 30=20
> seconds the first node takes a hit while it is releasing about 5000=20
> bundles from custody. Ingest stops for a second or so and then as it=20
> catches up it processes at about 400 bundles per second.
>
> David Zoller
> COLSA Corporation
> Marshall Space Flight Center
>
> From: Ivancic, William D. (GRC-RHN0)
> Sent: Friday, June 29, 2012 9:35 AM
> To: Zoller, David A. (MSFC-EO60)[HOSC SERVICES CONTRACT]
> Cc: ahennes1@math.umd.edu; dtn-users@irtf.org
> Subject: Re: [dtn-users] Improving performance in DTN2
>
> How long were your periods of disconnection while streaming?
>
> How many bundle where buffered during disconnection?
>
> Also, what routing protocol was used - or just static routes over IP?
>
> - Will Ivancic
>
> On Jun 29, 2012, at 10:25 AM, Zoller, David A. (MSFC-EO60)[HOSC=20
> SERVICES CONTRACT] wrote:
>
>
> Angela,
> I just joined the dtn-users mailing list yesterday and discovered that=20
> I've been working in a vacuum. We've been working on implementing=20
> Aggregate Custody Signals (ACS) in the DTN2 source code so that we can=20
> catch up with the ION version updated by the University of Colorado at=20
> Boulder and get back into the DTN network with their experiments. As=20
> I've been in the DTN2 source code, I have also been working on=20
> improving the throughput with the goal of streaming video via DTN. I=20
> am currently working on an ACS patch to submit for the reference=20
> implementation and am including some of the performance enhancements in i=
t as a bonus.
>
> I just concluded a 22 hour test piping 167 frames[bundles with a 1316=20
> byte payload] per second through two DTN nodes with custody transfer=20
> and ACS processing. It processed 13,605,622 bundles and only lost 6=20
> frames on the front end [missed UDP packets that never made it to the=20
> receiver that feeds the first DTN node] which were probably not=20
> related to the DTN node's performance. This is using the reference=20
> implementation with the ACS patches. In memory, the dtnd process has=20
> grown to 2.1GB due to timers that have been canceled but have not yet=20
> expired since I use a 24 hour expiration time. I have a reaper thread=20
> that periodically clears the canceled timers that I was not planning=20
> on including in the ACS patch since it requires a coordinated update=20
> to the oasys package but I think I'll go ahead and include it seeing that=
 there is an interest.
>
> On my development machine, our in-house version tops out at about 340=20
> bundles/second and I haven't tested the patched reference=20
> implementation to that extent. Our in-house version has more extensive=20
> infrastructure changes that may not be suitable for a reference=20
> implementation since the goal was performance for our needs and some=20
> of the changes may have broken some of the nuances of the BP=20
> specification which I have not studied in depth. We'll check to see if=20
> there is a way to make it available to the community for evaluation as=20
> there may be some mods that can be cherry picked for adapting into the re=
ference implementation.
>
> In the meantime, here are some things we've run across:
>
> * Configure and build oasys with the --disable-debug-locking option
>
> * You might gain improvements using the--disable-debug option when=20
> configuring both oasys and dtn2 but I haven't bothered to do that yet=20
> as the debug is still useful to me
>
> * BundleDaemon is a single thread. I've broken this into multiple threads=
:
> Input, Output, Storage, ACS and everything else in the original BD thread=
.
> The BD currently manages the oasys::TimerSystem which I changed to=20
> crank up the oasys::TimerThread to offload that work.
>
> * BundleDaemon::find_duplicate() bogs down significantly as you=20
> approach
> 15,000 bundles in the pending_bundles_ list.
>      !!Ha!! My intent was to use a std::multimap for the pending=20
> bundles but I just saw that I used a std::map instead. I'll have to go=20
> back and change that. Anyway, std::map is better suited for this than=20
> the std::list and a change to std::multimap should be even better to=20
> allow detection and retention of duplicates if so configured.
>
> * CustodyTimers do not release the reference to the bundle until they=20
> expire which keeps freed bundles from being removed as well as the timers=
.
> I use a reaper thread to periodically remove the canceled timers from=20
> the oasys::TimerSystem but I think adding an overridable onCancel()=20
> method to the oasys::Timer class would be good way to trigger=20
> processing that could free the bundle reference and allow the bundle to b=
e freed quicker.
>
> * I'm using the BerkeleyDB on a Solid State Drive.
>
> * Payload storage to disk - the more files in the directory the longer=20
> it takes to add a bundle to the database. I changed the payload=20
> directory structure to a tiered layout with 10,000 bundle payload per dir=
ectory.
>
> * AdminRegistration and PingRegistration do not update the bundle=20
> fwdlog to delivered so they don't get deleted until they expire. Minor=20
> unless you have tons of custody signals hanging around but the leaner=20
> the memory usage the better :)
>
> Hope this helps,
> DZ
>
>
> David Zoller
> COLSA Corporation
> Marshall Space Flight Center
> _______________________________________________
> dtn-users mailing list
> dtn-users@irtf.org
> https://www.irtf.org/mailman/listinfo/dtn-users
>
>
>


From david.a.zoller@nasa.gov  Fri Jun 29 11:19:28 2012
Return-Path: 
X-Original-To: dtn-users@ietfa.amsl.com
Delivered-To: dtn-users@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E01B21F882E for ; Fri, 29 Jun 2012 11:19:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.443
X-Spam-Level: 
X-Spam-Status: No, score=-6.443 tagged_above=-999 required=5 tests=[AWL=0.155,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6gBI64VlzGWi for ; Fri, 29 Jun 2012 11:19:27 -0700 (PDT)
Received: from ndjsnpf02.ndc.nasa.gov (ndjsnpf02.ndc.nasa.gov [198.117.1.122]) by ietfa.amsl.com (Postfix) with ESMTP id 2588821F882C for ; Fri, 29 Jun 2012 11:19:27 -0700 (PDT)
Received: from ndmsppt05.ndc.nasa.gov (ndmsppt05.ndc.nasa.gov [198.117.0.104]) by ndjsnpf02.ndc.nasa.gov (Postfix) with ESMTP id 7AE75A8B56; Fri, 29 Jun 2012 13:19:26 -0500 (CDT)
Received: from ndmshub02.ndc.nasa.gov (ndmshub02-pub.ndc.nasa.gov [198.117.0.161]) by ndmsppt05.ndc.nasa.gov (8.14.5/8.14.5) with ESMTP id q5TIJQ0W002524;  Fri, 29 Jun 2012 13:19:26 -0500
Received: from NDMSSCC05.ndc.nasa.gov ([198.117.2.174]) by ndmshub02.ndc.nasa.gov ([198.117.2.161]) with mapi; Fri, 29 Jun 2012 13:19:26 -0500
From: "Zoller, David A. (MSFC-EO60)[HOSC SERVICES CONTRACT]" 
To: Jim Wright 
Date: Fri, 29 Jun 2012 13:19:04 -0500
Thread-Topic: [dtn-users] Improving performance in DTN2
Thread-Index: Ac1WHQbWGHGWB88uSGqkR1vrsOhKuwABjFIg
Message-ID: <04E3D99A62496240BCD6A576813E6E318405E30A0B@NDMSSCC05.ndc.nasa.gov>
References: <04E3D99A62496240BCD6A576813E6E318405E30822@NDMSSCC05.ndc.nasa.gov> <7A1B9532DA609B46927331283910A4C40BE3576A@IMCMBX02.MITRE.ORG> <04E3D99A62496240BCD6A576813E6E318405E308AE@NDMSSCC05.ndc.nasa.gov> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_04E3D99A62496240BCD6A576813E6E318405E30A0BNDMSSCC05ndcn_"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.7.7855, 1.0.260, 0.0.0000 definitions=2012-06-29_05:2012-06-29, 2012-06-29, 1970-01-01 signatures=0
Cc: "dtn-users@irtf.org" 
Subject: Re: [dtn-users] Improving performance in DTN2
X-BeenThere: dtn-users@irtf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "The Delay-Tolerant Networking Research Group \(DTNRG\) - Users." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 29 Jun 2012 18:19:28 -0000

--_000_04E3D99A62496240BCD6A576813E6E318405E30A0BNDMSSCC05ndcn_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Awesome! Thanks, Jim, I will be downloading a copy very shortly as that wil=
l definitely be useful.

David Zoller
COLSA Corporation
Marshall Space Flight Center

From: Jim Wright [mailto:James.R.Wright@Colorado.EDU]
Sent: Friday, June 29, 2012 12:32 PM
To: Zoller, David A. (MSFC-EO60)[HOSC SERVICES CONTRACT]
Cc: Durst, Robert C.; dtn-users@irtf.org
Subject: Re: [dtn-users] Improving performance in DTN2

David, Wireshark 1.8 has just been released. It contains enhancements to th=
e Bundle Protocol dissection that I added recently. The main focus of the w=
ork was adding the ability to handle ACS, CTEB and ECOS. Hope this helps!

Jim Wright
BioServe Space Technologies
james.r.wright@colorado.edu
303-492-1579


--_000_04E3D99A62496240BCD6A576813E6E318405E30A0BNDMSSCC05ndcn_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


Awesome! =
Thanks, Jim, I will be downloading a copy very shortly as that will definit=
ely be useful.
 =

David Zoller<=
o:p>
COLSA Corporation
Marshall Space Flight Ce=
nter
<=
o:p> 
From: Jim Wrigh=
t [mailto:James.R.Wright@Colorado.EDU] 
Sent: Friday, June 29, 20=
12 12:32 PM
To: Zoller, David A. (MSFC-EO60)[HOSC SERVICES CONTRA=
CT]
Cc: Durst, Robert C.; dtn-users@irtf.org
Subject: R=
e: [dtn-users] Improving performance in DTN2
 
David, Wireshark 1.8 has just been released. It conta=
ins enhancements to the Bundle Protocol dissection that I added recently. T=
he main focus of the work was adding the ability to handle ACS, CTEB and EC=
OS. Hope this helps!

<=
span style=3D'font-size:13.5pt;font-family:"Helvetica","sans-serif";color:b=
lack'>Jim Wright
BioServe Space Technologies
303-492-1579
 
=

--_000_04E3D99A62496240BCD6A576813E6E318405E30A0BNDMSSCC05ndcn_--

From david.a.zoller@nasa.gov  Fri Jun 29 11:37:49 2012
Return-Path: 
X-Original-To: dtn-users@ietfa.amsl.com
Delivered-To: dtn-users@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47A5121F867D for ; Fri, 29 Jun 2012 11:37:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.465
X-Spam-Level: 
X-Spam-Status: No, score=-6.465 tagged_above=-999 required=5 tests=[AWL=0.133,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zkdgnXSy+MUT for ; Fri, 29 Jun 2012 11:37:40 -0700 (PDT)
Received: from ndjsnpf03.ndc.nasa.gov (ndjsnpf03.ndc.nasa.gov [198.117.1.123]) by ietfa.amsl.com (Postfix) with ESMTP id 7BF4D21F866B for ; Fri, 29 Jun 2012 11:37:40 -0700 (PDT)
Received: from ndmsppt04.ndc.nasa.gov (ndmsppt04.ndc.nasa.gov [198.117.0.103]) by ndjsnpf03.ndc.nasa.gov (Postfix) with ESMTP id 8E74E2D8AFC for ; Fri, 29 Jun 2012 13:37:37 -0500 (CDT)
Received: from ndmshub04.ndc.nasa.gov (ndmshub04-pub.ndc.nasa.gov [198.117.0.43]) by ndmsppt04.ndc.nasa.gov (8.14.5/8.14.5) with ESMTP id q5TIbbMf004209 for ; Fri, 29 Jun 2012 13:37:37 -0500
Received: from NDMSSCC05.ndc.nasa.gov ([198.117.2.174]) by ndmshub04.ndc.nasa.gov ([198.117.2.163]) with mapi; Fri, 29 Jun 2012 13:37:37 -0500
From: "Zoller, David A. (MSFC-EO60)[HOSC SERVICES CONTRACT]" 
To: "Ivancic, William D. (GRC-RHN0)" 
Date: Fri, 29 Jun 2012 13:37:13 -0500
Thread-Topic: [dtn-users] Improving performance in DTN2
Thread-Index: Ac1WHda9NVMPNEtqTTKFXdojbmnG9wABfs9Q
Message-ID: <04E3D99A62496240BCD6A576813E6E318405E30A2A@NDMSSCC05.ndc.nasa.gov>
References: <04E3D99A62496240BCD6A576813E6E318405E30822@NDMSSCC05.ndc.nasa.gov>  <04E3D99A62496240BCD6A576813E6E318405E3086F@NDMSSCC05.ndc.nasa.gov>  <04E3D99A62496240BCD6A576813E6E318405E308CD@NDMSSCC05.ndc.nasa.gov> <9C1F96BD-8EB2-4B46-8EAD-25F245DB24AF@nasa.gov>
In-Reply-To: <9C1F96BD-8EB2-4B46-8EAD-25F245DB24AF@nasa.gov>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_04E3D99A62496240BCD6A576813E6E318405E30A2ANDMSSCC05ndcn_"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.7.7855, 1.0.260, 0.0.0000 definitions=2012-06-29_05:2012-06-29, 2012-06-29, 1970-01-01 signatures=0
Cc: "dtn-users@irtf.org" 
Subject: Re: [dtn-users] Improving performance in DTN2
X-BeenThere: dtn-users@irtf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "The Delay-Tolerant Networking Research Group \(DTNRG\) - Users." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 29 Jun 2012 18:37:49 -0000

--_000_04E3D99A62496240BCD6A576813E6E318405E30A2ANDMSSCC05ndcn_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Will,
Good point. I've got my blinders on as I'm the ground receipt node for a do=
wnlink and the nodes I transmit to are almost always online. I'll have to e=
xpand my horizons and testing. A script should be no problem. I've heard ti=
dbits of being able to schedule connect times for nodes and suspected that =
there might be a router type that implemented a schedule but haven't taken =
the time to research it yet and thought you might have been referring to th=
at for the disconnects.
Thanks,
DZ

David Zoller
COLSA Corporation
Marshall Space Flight Center

From: Ivancic, William D. (GRC-RHN0)
Sent: Friday, June 29, 2012 12:37 PM
To: Zoller, David A. (MSFC-EO60)[HOSC SERVICES CONTRACT]
Cc: dtn-users@irtf.org
Subject: Re: [dtn-users] Improving performance in DTN2

You can disconnect in a number of ways:
netem
pull cable (but not very repeatable timing wise)
modify ip-table script or link up/down script (probably the easiest and cau=
ses the least strain on the CPU).
put a channel emulator in between DTN nodes.

The point is, you're streaming in a disconnected environment otherwise ther=
e is no reason to use DTN.  So you need to test the storage, not just the f=
orwarding.

You probably should also put in some other bundle source/destination pairs =
with various lifetimes.

You need to see where it breaks and how fragile (or not) the system is.  Tu=
ning a configuration to get something to work is just the start.


- Will

On Jun 29, 2012, at 11:32 AM, Zoller, David A. (MSFC-EO60)[HOSC SERVICES CO=
NTRACT] wrote:


I'm sure this implementation will bog down during the disconnects as bundle=
s accumulate in the pending queue which impacts the find_duplicate() mentio=
ned below but I'll try to squeeze in some testing for you some time. What r=
outing do you use for the disconnects or should I  just pull the network ca=
ble?
DZ


David Zoller
COLSA Corporation
Marshall Space Flight Center

From: Ivancic, William D. (GRC-RHN0)
Sent: Friday, June 29, 2012 10:00 AM
To: Zoller, David A. (MSFC-EO60)[HOSC SERVICES CONTRACT]
Subject: Re: [dtn-users] Improving performance in DTN2

Add disconnection for 30 sec, 1 min, 5 min and 30 min and see what happens.

- Will

On Jun 29, 2012, at 10:55 AM, Zoller, David A. (MSFC-EO60)[HOSC SERVICES CO=
NTRACT] wrote:



This is using static routes over IP with no disconnection. The Aggregate Cu=
stody Signals are configured for 30 seconds, so every 30 seconds the first =
node takes a hit while it is releasing about 5000 bundles from custody. Ing=
est stops for a second or so and then as it catches up it processes at abou=
t 400 bundles per second.

David Zoller
COLSA Corporation
Marshall Space Flight Center

From: Ivancic, William D. (GRC-RHN0)
Sent: Friday, June 29, 2012 9:35 AM
To: Zoller, David A. (MSFC-EO60)[HOSC SERVICES CONTRACT]
Cc: ahennes1@math.umd.edu; dtn-users@irtf.org=

Subject: Re: [dtn-users] Improving performance in DTN2

How long were your periods of disconnection while streaming?

How many bundle where buffered during disconnection?

Also, what routing protocol was used - or just static routes over IP?

- Will Ivancic

On Jun 29, 2012, at 10:25 AM, Zoller, David A. (MSFC-EO60)[HOSC SERVICES CO=
NTRACT] wrote:




Angela,
I just joined the dtn-users mailing list yesterday and discovered that I've=
 been working in a vacuum. We've been working on implementing Aggregate Cus=
tody Signals (ACS) in the DTN2 source code so that we can catch up with the=
 ION version updated by the University of Colorado at Boulder and get back =
into the DTN network with their experiments. As I've been in the DTN2 sourc=
e code, I have also been working on improving the throughput with the goal =
of streaming video via DTN. I am currently working on an ACS patch to submi=
t for the reference implementation and am including some of the performance=
 enhancements in it as a bonus.

I just concluded a 22 hour test piping 167 frames[bundles with a 1316 byte =
payload] per second through two DTN nodes with custody transfer and ACS pro=
cessing. It processed 13,605,622 bundles and only lost 6 frames on the fron=
t end [missed UDP packets that never made it to the receiver that feeds the=
 first DTN node] which were probably not related to the DTN node's performa=
nce. This is using the reference implementation with the ACS patches. In me=
mory, the dtnd process has grown to 2.1GB due to timers that have been canc=
eled but have not yet expired since I use a 24 hour expiration time. I have=
 a reaper thread that periodically clears the canceled timers that I was no=
t planning on including in the ACS patch since it requires a coordinated up=
date to the oasys package but I think I'll go ahead and include it seeing t=
hat there is an interest.

On my development machine, our in-house version tops out at about 340 bundl=
es/second and I haven't tested the patched reference implementation to that=
 extent. Our in-house version has more extensive infrastructure changes tha=
t may not be suitable for a reference implementation since the goal was per=
formance for our needs and some of the changes may have broken some of the =
nuances of the BP specification which I have not studied in depth. We'll ch=
eck to see if there is a way to make it available to the community for eval=
uation as there may be some mods that can be cherry picked for adapting int=
o the reference implementation.

In the meantime, here are some things we've run across:

* Configure and build oasys with the --disable-debug-locking option

* You might gain improvements using the--disable-debug option when configur=
ing both oasys and dtn2 but I haven't bothered to do that yet as the debug =
is still useful to me

* BundleDaemon is a single thread. I've broken this into multiple threads: =
Input, Output, Storage, ACS and everything else in the original BD thread. =
The BD currently manages the oasys::TimerSystem which I changed to crank up=
 the oasys::TimerThread to offload that work.

* BundleDaemon::find_duplicate() bogs down significantly as you approach 15=
,000 bundles in the pending_bundles_ list.
     !!Ha!! My intent was to use a std::multimap for the pending bundles bu=
t I just saw that I used a std::map instead. I'll have to go back and chang=
e that. Anyway, std::map is better suited for this than the std::list and a=
 change to std::multimap should be even better to allow detection and reten=
tion of duplicates if so configured.

* CustodyTimers do not release the reference to the bundle until they expir=
e which keeps freed bundles from being removed as well as the timers. I use=
 a reaper thread to periodically remove the canceled timers from the oasys:=
:TimerSystem but I think adding an overridable onCancel() method to the oas=
ys::Timer class would be good way to trigger processing that could free the=
 bundle reference and allow the bundle to be freed quicker.

* I'm using the BerkeleyDB on a Solid State Drive.

* Payload storage to disk - the more files in the directory the longer it t=
akes to add a bundle to the database. I changed the payload directory struc=
ture to a tiered layout with 10,000 bundle payload per directory.

* AdminRegistration and PingRegistration do not update the bundle fwdlog to=
 delivered so they don't get deleted until they expire. Minor unless you ha=
ve tons of custody signals hanging around but the leaner the memory usage t=
he better :)

Hope this helps,
DZ


David Zoller
COLSA Corporation
Marshall Space Flight Center
_______________________________________________
dtn-users mailing list
dtn-users@irtf.org
https://www.irtf.org/mailman/listinfo/dtn-users



******************************
William D. Ivancic
Phone 216-433-3494
Fax 216-433-8705
Networking Lab 216-433-2620
Mobile 440-503-4892
http://roland.grc.nasa.gov/~ivancic


******************************
William D. Ivancic
Phone 216-433-3494
Fax 216-433-8705
Networking Lab 216-433-2620
Mobile 440-503-4892
http://roland.grc.nasa.gov/~ivancic


--_000_04E3D99A62496240BCD6A576813E6E318405E30A2ANDMSSCC05ndcn_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


Will, 
Good point. I’ve got m=
y blinders on as I’m the ground receipt node for a downlink and the n=
odes I transmit to are almost always online. I’ll have to expand my h=
orizons and testing. A script should be no problem. I’ve heard tidbit=
s of being able to schedule connect times for nodes and suspected that ther=
e might be a router type that implemented a schedule but haven’t take=
n the time to research it yet and thought you might have been referring to =
that for the disconnects.
=
Thanks,
DZ
 
David Zoller
COLSA Corporation
Marshall Space Flight Center=

 
From: Ivancic, William D. (GRC-RHN0) 
=
Sent: Friday, June 29, 2012 12:37 PM
To: Zoller, David A. (MS=
FC-EO60)[HOSC SERVICES CONTRACT]
Cc: dtn-users@irtf.org
Sub=
ject: Re: [dtn-users] Improving performance in DTN2
 
You can disconnect in a number of ways:
netem
pull cable (but =
not very repeatable timing wise)
modify ip-table script or link up/down script (probably the easiest and=
 causes the least strain on the CPU).
put a channel emulator in between DTN nodes.
<=
div>
 
The point is, you're streaming in a disconnected environment otherwise t=
here is no reason to use DTN.  So you need to test the storage, not ju=
st the forwarding.
 =
;
You probably should also put in =
some other bundle source/destination pairs with various lifetimes.
 
You need to see where it breaks and how fragile (or not) th=
e system is.  Tuning a configuration to get something to work is just =
the start.
 <=
/p>
 
- Will
&nbs=
p;
On Jun 29, 2012, at 11:32 AM, Zo=
ller, David A. (MSFC-EO60)[HOSC SERVICES CONTRACT] wrote:


I’m sure this implementation will bog down during the disco=
nnects as bundles accumulate in the pending queue which impacts the find_du=
plicate() mentioned below but I’ll try to squeeze in some testing for=
 you some time. What routing do you use for the disconnects or should I &nb=
sp;just pull the network cable?
DZ
 
&nb=
sp;
David =
Zoller
COLSA Corp=
oration
Marshall =
Space Flight Center
 
From: Ivancic, William D. (GRC-RHN0) 
Sent: Friday, June 29, 2012 10:00 AM
To: Zoller, David A. (MSFC-EO60)[HOSC =
SERVICES CONTRACT]
Subject:&n=
bsp;Re: [dtn-users] Improving performance in DTN2<=
/p>
 
<=
div>
Add disconnection for 30 sec, 1 min, 5 min and 30 =
min and see what happens.
 
- Will
 
On Jun 29, 2012, at 10:55 AM, Zo=
ller, David A. (MSFC-EO60)[HOSC SERVICES CONTRACT] wrote:



This is using static routes over IP wit=
h no disconnection. The Aggregate Custody Signals are configured for 30 sec=
onds, so every 30 seconds the first node takes a hit while it is releasing =
about 5000 bundles from custody. Ingest stops for a second or so and then a=
s it catches up it processes at about 400 bundles per second.
 
David Zolle=
r
COLS=
A Corporation
Marshall Space Flight Center
 
From: Ivancic, William D. (GRC-RHN0) 
Sent: Friday, June 29, 2012 9:35 AM
To:<=
span class=3Dapple-converted-space> Zoller, David A. (MSFC-EO60=
)[HOSC SERVICES CONTRACT]
Cc:=
 ahennes1@math.umd.edu=
; dtn-users@irtf.org
Subject: Re: [dtn-users] Improving performance in DT=
N2
 
How lon=
g were your periods of disconnection while streaming?  
=

 
=

How many bundle where buffe=
red during disconnection?  
=

 
=

Also, what routing protocol was used - or just st=
atic routes over IP?
 
- Will Ivancic
 
=

On Jun 29, 2012, at 10:25 AM, Zoller, David A. (MSFC-E=
O60)[HOSC SERVICES CONTRACT] wrote:




Angela,
I just joined the dtn-users mailing list yesterd=
ay and discovered that I’ve been working in a vacuum. We’ve bee=
n working on implementing Aggregate Custody Signals (ACS) in the DTN2 sourc=
e code so that we can catch up with the ION version updated by the Universi=
ty of Colorado at Boulder and get back into the DTN network with their expe=
riments. As I’ve been in the DTN2 source code, I have also been worki=
ng on improving the throughput with the goal of streaming video via DTN. I =
am currently working on an ACS patch to submit for the reference implementa=
tion and am including some of the performance enhancements in it as a bonus=
.
 =
;
I jus=
t concluded a 22 hour test piping 167 frames[bundles with a 1316 byte paylo=
ad] per second through two DTN nodes with custody transfer and ACS processi=
ng. It processed 13,605,622 bundles and only lost 6 frames on the front end=
 [missed UDP packets that never made it to the receiver that feeds the firs=
t DTN node] which were probably not related to the DTN node’s perform=
ance. This is using the reference implementation with the ACS patches. In m=
emory, the dtnd process has grown to 2.1GB due to timers that have been can=
celed but have not yet expired since I use a 24 hour expiration time. I hav=
e a reaper thread that periodically clears the canceled timers that I was n=
ot planning on including in the ACS patch since it requires a coordinated u=
pdate to the oasys package but I think I’ll go ahead and include it s=
eeing that there is an interest.
 
On my development machine, our in-house version t=
ops out at about 340 bundles/second and I haven’t tested the patched =
reference implementation to that extent. Our in-house version has more exte=
nsive infrastructure changes that may not be suitable for a reference imple=
mentation since the goal was performance for our needs and some of the chan=
ges may have broken some of the nuances of the BP specification which I hav=
e not studied in depth. We’ll check to see if there is a way to make =
it available to the community for evaluation as there may be some mods that=
 can be cherry picked for adapting into the reference implementation.
 
In the meant=
ime, here are some things we’ve run across:
 
* Configure and build oasys with=
 the --disable-debug-locking option
=

 
=

* You might gain improvements using the--disab=
le-debug option when configuring both oasys and dtn2 but I haven’t bo=
thered to do that yet as the debug is still useful to me<=
/p>
 <=
/p>
* BundleDaemon is a singl=
e thread. I’ve broken this into multiple threads: Input, Output, Stor=
age, ACS and everything else in the original BD thread. The BD currently ma=
nages the oasys::TimerSystem which I changed to crank up the oasys::TimerTh=
read to offload that work.
 
* BundleDaemon::find_duplicate() bogs down significantl=
y as you approach 15,000 bundles in the pending_bundles_ list.<=
/o:p>
   =
  !!Ha!! My intent was to use a std::multimap for the pending bun=
dles but I just saw that I used a std::map instead. I’ll have to go b=
ack and change that. Anyway, std::map is better suited for this than the st=
d::list and a change to std::multimap should be even better to allow detect=
ion and retention of duplicates if so configured.
 
* CustodyTimers do not release t=
he reference to the bundle until they expire which keeps freed bundles from=
 being removed as well as the timers. I use a reaper thread to periodically=
 remove the canceled timers from the oasys::TimerSystem but I think adding =
an overridable onCancel() method to the oasys::Timer class would be good wa=
y to trigger processing that could free the bundle reference and allow the =
bundle to be freed quicker.
 
* I’m using the BerkeleyDB on a Solid State Driv=
e.
&nbs=
p;
* Pa=
yload storage to disk – the more files in the directory the longer it=
 takes to add a bundle to the database. I changed the payload directory str=
ucture to a tiered layout with 10,000 bundle payload per directory.<=
o:p>
 <=
o:p>
* AdminRegistr=
ation and PingRegistration do not update the bundle fwdlog to delivered so =
they don’t get deleted until they expire. Minor unless you have tons =
of custody signals hanging around but the leaner the memory usage the bette=
r J
 
Hope this helps,
DZ
 
 
David Zoller<=
/o:p>
COLSA =
Corporation
Marshall Space Flight Center
<=
/div>
______________________________________=
_________
dtn-users mailing list
dtn-users@irtf.org
https://www.irtf.org/mailman/listinfo/dtn-users
 
 
<=
/div>
 
************************=
******
William D. Ivancic
Phone 216-433-3494
Fax=
 216-433-8705
Networking Lab 216-4=
33-2620
Mobile 440-503-4892=

http://roland.grc.nasa.gov/~ivancic
 
 
******************************
William D. Ivancic
Phone 216-43=
3-3494
Fax 216-433-8705
=
Networking Lab 216-433-2620
Mobile 440-503-4892
http://roland.gr=
c.nasa.gov/~ivancic
 
=

--_000_04E3D99A62496240BCD6A576813E6E318405E30A2ANDMSSCC05ndcn_--

From william.d.ivancic@nasa.gov  Fri Jun 29 12:06:47 2012
Return-Path: 
X-Original-To: dtn-users@ietfa.amsl.com
Delivered-To: dtn-users@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7F8321F889F for ; Fri, 29 Jun 2012 12:06:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.852
X-Spam-Level: 
X-Spam-Status: No, score=-5.852 tagged_above=-999 required=5 tests=[AWL=0.746,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DD1fD-QQbSuX for ; Fri, 29 Jun 2012 12:06:45 -0700 (PDT)
Received: from ndjsnpf03.ndc.nasa.gov (ndjsnpf03.ndc.nasa.gov [198.117.1.123]) by ietfa.amsl.com (Postfix) with ESMTP id 41EDC21F88A9 for ; Fri, 29 Jun 2012 12:06:44 -0700 (PDT)
Received: from ndjsppt02.ndc.nasa.gov (ndjsppt02.ndc.nasa.gov [198.117.1.101]) by ndjsnpf03.ndc.nasa.gov (Postfix) with ESMTP id DD0112D8120 for ; Fri, 29 Jun 2012 14:06:43 -0500 (CDT)
Received: from ndjshub05.ndc.nasa.gov (ndjshub05.ndc.nasa.gov [198.117.4.164]) by ndjsppt02.ndc.nasa.gov (8.14.5/8.14.5) with ESMTP id q5TJ6hGZ030203 for ; Fri, 29 Jun 2012 14:06:43 -0500
Received: from NDJSSCC07.ndc.nasa.gov ([198.117.4.178]) by ndjshub05.ndc.nasa.gov ([198.117.4.164]) with mapi; Fri, 29 Jun 2012 14:06:43 -0500
From: "Ivancic, William D. (GRC-RHN0)" 
To: "Zoller, David A. (MSFC-EO60)[HOSC SERVICES CONTRACT]" 
Date: Fri, 29 Jun 2012 14:06:42 -0500
Thread-Topic: [dtn-users] Improving performance in DTN2
Thread-Index: Ac1WKlJfDZDLokNERna0gtt8IYzZqg==
Message-ID: <43C4D49B-96F5-427D-9769-A7A6D289695B@nasa.gov>
References: <04E3D99A62496240BCD6A576813E6E318405E30822@NDMSSCC05.ndc.nasa.gov>  <04E3D99A62496240BCD6A576813E6E318405E3086F@NDMSSCC05.ndc.nasa.gov>  <04E3D99A62496240BCD6A576813E6E318405E308CD@NDMSSCC05.ndc.nasa.gov> <9C1F96BD-8EB2-4B46-8EAD-25F245DB24AF@nasa.gov> <04E3D99A62496240BCD6A576813E6E318405E30A2A@NDMSSCC05.ndc.nasa.gov>
In-Reply-To: <04E3D99A62496240BCD6A576813E6E318405E30A2A@NDMSSCC05.ndc.nasa.gov>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_43C4D49B96F5427D9769A7A6D289695Bnasagov_"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.7.7855, 1.0.260, 0.0.0000 definitions=2012-06-29_05:2012-06-29, 2012-06-29, 1970-01-01 signatures=0
Cc: "dtn-users@irtf.org" 
Subject: Re: [dtn-users] Improving performance in DTN2
X-BeenThere: dtn-users@irtf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "The Delay-Tolerant Networking Research Group \(DTNRG\) - Users." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 29 Jun 2012 19:06:47 -0000

--_000_43C4D49B96F5427D9769A7A6D289695Bnasagov_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

If your talking ION than contact graph routing (CGR) is there. As a first o=
rder approximation, you can of think of CGR as dynamic static routing (but =
it is a quite a bit more than that). In CGR you basically schedule contact =
times as would be done in predictive contacts such as space system (Orbital=
 Dynamics).  With CGR  you could tell the system when to send and stop  as =
a way to emulate disconnection.

I do not believe CGR is implemented in DTN2.

- Will

On Jun 29, 2012, at 2:37 PM, Zoller, David A. (MSFC-EO60)[HOSC SERVICES CON=
TRACT] wrote:

Will,
Good point. I=92ve got my blinders on as I=92m the ground receipt node for =
a downlink and the nodes I transmit to are almost always online. I=92ll hav=
e to expand my horizons and testing. A script should be no problem. I=92ve =
heard tidbits of being able to schedule connect times for nodes and suspect=
ed that there might be a router type that implemented a schedule but haven=
=92t taken the time to research it yet and thought you might have been refe=
rring to that for the disconnects.
Thanks,
DZ

David Zoller
COLSA Corporation
Marshall Space Flight Center

From: Ivancic, William D. (GRC-RHN0)
Sent: Friday, June 29, 2012 12:37 PM
To: Zoller, David A. (MSFC-EO60)[HOSC SERVICES CONTRACT]
Cc: dtn-users@irtf.org
Subject: Re: [dtn-users] Improving performance in DTN2

You can disconnect in a number of ways:
netem
pull cable (but not very repeatable timing wise)
modify ip-table script or link up/down script (probably the easiest and cau=
ses the least strain on the CPU).
put a channel emulator in between DTN nodes.

The point is, you're streaming in a disconnected environment otherwise ther=
e is no reason to use DTN.  So you need to test the storage, not just the f=
orwarding.

You probably should also put in some other bundle source/destination pairs =
with various lifetimes.

You need to see where it breaks and how fragile (or not) the system is.  Tu=
ning a configuration to get something to work is just the start.


- Will

On Jun 29, 2012, at 11:32 AM, Zoller, David A. (MSFC-EO60)[HOSC SERVICES CO=
NTRACT] wrote:


I=92m sure this implementation will bog down during the disconnects as bund=
les accumulate in the pending queue which impacts the find_duplicate() ment=
ioned below but I=92ll try to squeeze in some testing for you some time. Wh=
at routing do you use for the disconnects or should I  just pull the networ=
k cable?
DZ


David Zoller
COLSA Corporation
Marshall Space Flight Center

From: Ivancic, William D. (GRC-RHN0)
Sent: Friday, June 29, 2012 10:00 AM
To: Zoller, David A. (MSFC-EO60)[HOSC SERVICES CONTRACT]
Subject: Re: [dtn-users] Improving performance in DTN2

Add disconnection for 30 sec, 1 min, 5 min and 30 min and see what happens.

- Will

On Jun 29, 2012, at 10:55 AM, Zoller, David A. (MSFC-EO60)[HOSC SERVICES CO=
NTRACT] wrote:



This is using static routes over IP with no disconnection. The Aggregate Cu=
stody Signals are configured for 30 seconds, so every 30 seconds the first =
node takes a hit while it is releasing about 5000 bundles from custody. Ing=
est stops for a second or so and then as it catches up it processes at abou=
t 400 bundles per second.

David Zoller
COLSA Corporation
Marshall Space Flight Center

From: Ivancic, William D. (GRC-RHN0)
Sent: Friday, June 29, 2012 9:35 AM
To: Zoller, David A. (MSFC-EO60)[HOSC SERVICES CONTRACT]
Cc: ahennes1@math.umd.edu; dtn-users@irtf.org=

Subject: Re: [dtn-users] Improving performance in DTN2

How long were your periods of disconnection while streaming?

How many bundle where buffered during disconnection?

Also, what routing protocol was used - or just static routes over IP?

- Will Ivancic

On Jun 29, 2012, at 10:25 AM, Zoller, David A. (MSFC-EO60)[HOSC SERVICES CO=
NTRACT] wrote:




Angela,
I just joined the dtn-users mailing list yesterday and discovered that I=92=
ve been working in a vacuum. We=92ve been working on implementing Aggregate=
 Custody Signals (ACS) in the DTN2 source code so that we can catch up with=
 the ION version updated by the University of Colorado at Boulder and get b=
ack into the DTN network with their experiments. As I=92ve been in the DTN2=
 source code, I have also been working on improving the throughput with the=
 goal of streaming video via DTN. I am currently working on an ACS patch to=
 submit for the reference implementation and am including some of the perfo=
rmance enhancements in it as a bonus.

I just concluded a 22 hour test piping 167 frames[bundles with a 1316 byte =
payload] per second through two DTN nodes with custody transfer and ACS pro=
cessing. It processed 13,605,622 bundles and only lost 6 frames on the fron=
t end [missed UDP packets that never made it to the receiver that feeds the=
 first DTN node] which were probably not related to the DTN node=92s perfor=
mance. This is using the reference implementation with the ACS patches. In =
memory, the dtnd process has grown to 2.1GB due to timers that have been ca=
nceled but have not yet expired since I use a 24 hour expiration time. I ha=
ve a reaper thread that periodically clears the canceled timers that I was =
not planning on including in the ACS patch since it requires a coordinated =
update to the oasys package but I think I=92ll go ahead and include it seei=
ng that there is an interest.

On my development machine, our in-house version tops out at about 340 bundl=
es/second and I haven=92t tested the patched reference implementation to th=
at extent. Our in-house version has more extensive infrastructure changes t=
hat may not be suitable for a reference implementation since the goal was p=
erformance for our needs and some of the changes may have broken some of th=
e nuances of the BP specification which I have not studied in depth. We=92l=
l check to see if there is a way to make it available to the community for =
evaluation as there may be some mods that can be cherry picked for adapting=
 into the reference implementation.

In the meantime, here are some things we=92ve run across:

* Configure and build oasys with the --disable-debug-locking option

* You might gain improvements using the--disable-debug option when configur=
ing both oasys and dtn2 but I haven=92t bothered to do that yet as the debu=
g is still useful to me

* BundleDaemon is a single thread. I=92ve broken this into multiple threads=
: Input, Output, Storage, ACS and everything else in the original BD thread=
. The BD currently manages the oasys::TimerSystem which I changed to crank =
up the oasys::TimerThread to offload that work.

* BundleDaemon::find_duplicate() bogs down significantly as you approach 15=
,000 bundles in the pending_bundles_ list.
     !!Ha!! My intent was to use a std::multimap for the pending bundles bu=
t I just saw that I used a std::map instead. I=92ll have to go back and cha=
nge that. Anyway, std::map is better suited for this than the std::list and=
 a change to std::multimap should be even better to allow detection and ret=
ention of duplicates if so configured.

* CustodyTimers do not release the reference to the bundle until they expir=
e which keeps freed bundles from being removed as well as the timers. I use=
 a reaper thread to periodically remove the canceled timers from the oasys:=
:TimerSystem but I think adding an overridable onCancel() method to the oas=
ys::Timer class would be good way to trigger processing that could free the=
 bundle reference and allow the bundle to be freed quicker.

* I=92m using the BerkeleyDB on a Solid State Drive.

* Payload storage to disk =96 the more files in the directory the longer it=
 takes to add a bundle to the database. I changed the payload directory str=
ucture to a tiered layout with 10,000 bundle payload per directory.

* AdminRegistration and PingRegistration do not update the bundle fwdlog to=
 delivered so they don=92t get deleted until they expire. Minor unless you =
have tons of custody signals hanging around but the leaner the memory usage=
 the better :)

Hope this helps,
DZ


David Zoller
COLSA Corporation
Marshall Space Flight Center
_______________________________________________
dtn-users mailing list
dtn-users@irtf.org
https://www.irtf.org/mailman/listinfo/dtn-users



******************************
William D. Ivancic
Phone 216-433-3494
Fax 216-433-8705
Networking Lab 216-433-2620
Mobile 440-503-4892
http://roland.grc.nasa.gov/~ivancic


******************************
William D. Ivancic
Phone 216-433-3494
Fax 216-433-8705
Networking Lab 216-433-2620
Mobile 440-503-4892
http://roland.grc.nasa.gov/~ivancic


******************************
William D. Ivancic
Phone 216-433-3494
Fax 216-433-8705
Networking Lab 216-433-2620
Mobile 440-503-4892
http://roland.grc.nasa.gov/~ivancic


--_000_43C4D49B96F5427D9769A7A6D289695Bnasagov_
Content-Type: text/html; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable


Will,
Good point. I=92ve got my blinders on as I=92m the ground receipt =
node for a downlink and the nodes I transmit to are almost always online. I=
=92ll have to expand my horizons and testing. A script should be no problem=
. I=92ve heard tidbits of being able to schedule connect times for nodes an=
d suspected that there might be a router type that implemented a schedule b=
ut haven=92t taken the time to research it yet and thought you might have b=
een referring to that for the disconnects.
Thanks,
DZ
David Zoller
COLSA Corporation
Marshall Space Flight Center
 
=

From: Ivancic, Wi=
lliam D. (GRC-RHN0) 
<=
b>Sent: Friday, June =
29, 2012 12:37 PM
To: =
Zoller, David A. (MSFC-EO60)[HOSC SERVICES CONTRACT]
Cc: dtn-users@i=
rtf.org
Subject: <=
/span>Re: [dtn-users] Improving performance in DTN2
=

 
You can disconnect in a number of ways=
:
netem
pull cable (but n=
ot very repeatable timing wise)
modify ip-table=
 script or link up/down script (probably the easiest and causes the least s=
train on the CPU).
put a channel emulator in be=
tween DTN nodes.
 
<=
div>
The point is, you're streaming in a disconnected environment otherwise=
 there is no reason to use DTN.  So you need to test the storage, not =
just the forwarding.
 
You probably should also put in some other bundle source/destinati=
on pairs with various lifetimes.
 
You need to see where it breaks and how fragile (or no=
t) the system is.  Tuning a configuration to get something to work is =
just the start.
 
 
- Will
<=
o:p> 
On Jun 29, 2012, at 11:32 AM, Zoller, Davi=
d A. (MSFC-EO60)[HOSC SERVICES CONTRACT] wrote:

=

I=92m sure this implement=
ation will bog down during the disconnects as bundles accumulate in the pen=
ding queue which impacts the find_duplicate() mentioned below but I=92ll tr=
y to squeeze in some testing for you some time. What routing do you use for=
 the disconnects or should I  just pull the network cable?=

DZ
<=
div>
 
 
Dav=
id Zoller
COLSA Corporat=
ion
Marshall Space Fligh=
t Center
 <=
/span>
From: =
;Ivancic, William D. (GRC-RHN0)=
 
Sent: Friday, June 29, 2012 10:00 AM
To: Zoller, David A. (MSFC-EO60)[HOSC SERVICES CONTRAC=
T]
Subject: Re:=
 [dtn-users] Improving performance in DTN2
 
Add disconnection for 30 =
sec, 1 min, 5 min and 30 min and see what happens.
 
- Will
 
On J=
un 29, 2012, at 10:55 AM, Zoller, David A. (MSFC-EO60)[HOSC SERVICES CONTRA=
CT] wrote:



<=
/div>
This is using static routes over IP =
with no disconnection. The Aggregate Custody Signals are configured for 30 =
seconds, so every 30 seconds the first node takes a hit while it is releasi=
ng about 5000 bundles from custody. Ingest stops for a second or so and the=
n as it catches up it processes at about 400 bundles per second.
 
David Zoller
COLSA Corporation
Marshall Sp=
ace Flight Center
 
From: <=
/span>Ivancic, William D. (GRC-RHN0)&n=
bsp;
Sent: Friday, June 29, 2012 9:35 AM
To: Zoller, David A. (MSFC-EO60)[HOSC SERVICES CONTRACT]<=
br>Cc: ahennes1@math.umd.edu;&nbs=
p;dtn-users@irtf.org
Subject: Re: [dtn-users] Improving performa=
nce in DTN2
 =
;
How long were your periods of disc=
onnection while streaming?  
How many bundle=
 where buffered during disconnection?  
 
 
- Will Ivancic
 
<=
div style=3D"margin-top: 0in; margin-right: 0in; margin-left: 0in; margin-b=
ottom: 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; ">=
On Jun 29, 2012, at 10:25 AM, Zoller, David A. (MSFC-EO60)[HOSC SERVICES CO=
NTRACT] wrote:



Angela,
=

I just joined the dtn-users mailing list yesterd=
ay and discovered that I=92ve been working in a vacuum. We=92ve been workin=
g on implementing Aggregate Custody Signals (ACS) in the DTN2 source code s=
o that we can catch up with the ION version updated by the University of Co=
lorado at Boulder and get back into the DTN network with their experiments.=
 As I=92ve been in the DTN2 source code, I have also been working on improv=
ing the throughput with the goal of streaming video via DTN. I am currently=
 working on an ACS patch to submit for the reference implementation and am =
including some of the performance enhancements in it as a bonus.
 
I just concluded a 22 hour test piping 167 frames[bun=
dles with a 1316 byte payload] per second through two DTN nodes with custod=
y transfer and ACS processing. It processed 13,605,622 bundles and only los=
t 6 frames on the front end [missed UDP packets that never made it to the r=
eceiver that feeds the first DTN node] which were probably not related to t=
he DTN node=92s performance. This is using the reference implementation wit=
h the ACS patches. In memory, the dtnd process has grown to 2.1GB due to ti=
mers that have been canceled but have not yet expired since I use a 24 hour=
 expiration time. I have a reaper thread that periodically clears the cance=
led timers that I was not planning on including in the ACS patch since it r=
equires a coordinated update to the oasys package but I think I=92ll go ahe=
ad and include it seeing that there is an interest.
=

 
=

On my development machine, our in-house version tops out at about =
340 bundles/second and I haven=92t tested the patched reference implementat=
ion to that extent. Our in-house version has more extensive infrastructure =
changes that may not be suitable for a reference implementation since the g=
oal was performance for our needs and some of the changes may have broken s=
ome of the nuances of the BP specification which I have not studied in dept=
h. We=92ll check to see if there is a way to make it available to the commu=
nity for evaluation as there may be some mods that can be cherry picked for=
 adapting into the reference implementation.
<=
/div>
 
 
* Configure and build oasys with the --disable-debug-locki=
ng option
 
* You might gain improvements usi=
ng the--disable-debug option when configuring both oasys and dtn2 but I hav=
en=92t bothered to do that yet as the debug is still useful to me
 
* BundleDaemon is a single thread. I=92ve broken thi=
s into multiple threads: Input, Output, Storage, ACS and everything else in=
 the original BD thread. The BD currently manages the oasys::TimerSystem wh=
ich I changed to crank up the oasys::TimerThread to offload that work.
 
* BundleDaemon::find_duplicate() bogs down sign=
ificantly as you approach 15,000 bundles in the pending_bundles_ list.
     =
;!!Ha!! My intent was to use a std::multimap for the pending bundles but I =
just saw that I used a std::map instead. I=92ll have to go back and change =
that. Anyway, std::map is better suited for this than the std::list and a c=
hange to std::multimap should be even better to allow detection and retenti=
on of duplicates if so configured.
 
<=
span style=3D"font-size: 11pt; font-family: Calibri, sans-serif; ">* Custod=
yTimers do not release the reference to the bundle until they expire which =
keeps freed bundles from being removed as well as the timers. I use a reape=
r thread to periodically remove the canceled timers from the oasys::TimerSy=
stem but I think adding an overridable onCancel() method to the oasys::Time=
r class would be good way to trigger processing that could free the bundle =
reference and allow the bundle to be freed quicker.
=

 
=

* I=92m using the BerkeleyDB on a Solid State Drive.
 
* Payload storage to disk =96 the more files in the dire=
ctory the longer it takes to add a bundle to the database. I changed the pa=
yload directory structure to a tiered layout with 10,000 bundle payload per=
 directory.
 =

* AdminRegistration and PingReg=
istration do not update the bundle fwdlog to delivered so they don=92t get =
deleted until they expire. Minor unless you have tons of custody signals ha=
nging around but the leaner the memory usage the better J
<=
div>
&n=
bsp;
Hope this helps,
DZ
=

 
=

 
David Zoller
COLSA Corporation
Marshall Space Flight Center
_______________________________=
________________
dtn-users mailing list
dtn-users@irtf=
.org
https://www.irtf.org/mailm=
an/listinfo/dtn-users
 
 
 
******************************<=
span style=3D"font-size: 10pt; color: rgb(31, 73, 125); ">
William D. Ivancic
Phone 216-433-3494
Fax =
216-433-8705
Networking Lab 216-=
433-2620
Mobile 440-503-4892
http://rol=
and.grc.nasa.gov/~ivancic
 
 <=
/o:p>
******************************<=
/span>William D. Ivancic
Phone 216-433-3494
Fax 216-433-8705
Networ=
king Lab 216-433-2620
Mobile 440=
-503-4892



=

--_000_43C4D49B96F5427D9769A7A6D289695Bnasagov_--

From stephen.farrell@cs.tcd.ie  Fri Jun 29 14:41:18 2012
Return-Path: 
X-Original-To: dtn-users@ietfa.amsl.com
Delivered-To: dtn-users@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05F9911E8079 for ; Fri, 29 Jun 2012 14:41:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XL-H1Fbk5JsC for ; Fri, 29 Jun 2012 14:41:11 -0700 (PDT)
Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id 7E9B411E8072 for ; Fri, 29 Jun 2012 14:41:06 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 7EEA917185E; Fri, 29 Jun 2012 22:41:04 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1341006063; bh=VPvG0IS/w3uyk6 y79V+J6H3nQnYMHO83njxu5Nsx6Fg=; b=PW3eWwVk4eJTSL8G/lsLkXOySTrb2I S/8xg9JVnHeoGblnx4uLwYBdNrMsmjvohRsC8RKN7OYyQ8PN4Xu+049LUzWJpZQu 9yUwq6TQD33/sMhIVpwD5lhvfJfmoh/T//IBPybm0AJyKOJV4CkTfcgLiasavAtM o7e8mjOHzZ3vMWA94qDrn6CqAWrLtPFrwe3jOsvxHNPvDXb3tNg1D9u9US9xj3Cl fgMnquxvGFm1iX4n5uNtIqsx1lf0zpJ4Z2mlBcFE3jj12tUmkRXEhoY9w2eEXa/x 77r4yib/JBi4lJ+rYu2hqT9yAjZjRCINSWAUQKhySyO/lShFM3+jT+ZA==
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id vant6CLPQ63U; Fri, 29 Jun 2012 22:41:03 +0100 (IST)
Received: from [10.87.48.11] (unknown [86.44.71.57]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 6D7E817185D; Fri, 29 Jun 2012 22:41:01 +0100 (IST)
Message-ID: <4FEE20ED.9030309@cs.tcd.ie>
Date: Fri, 29 Jun 2012 22:41:01 +0100
From: Stephen Farrell 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1
MIME-Version: 1.0
To: "Ivancic, William D. (GRC-RHN0)" 
References: <04E3D99A62496240BCD6A576813E6E318405E30822@NDMSSCC05.ndc.nasa.gov>  <04E3D99A62496240BCD6A576813E6E318405E3086F@NDMSSCC05.ndc.nasa.gov>  <04E3D99A62496240BCD6A576813E6E318405E308CD@NDMSSCC05.ndc.nasa.gov> <9C1F96BD-8EB2-4B46-8EAD-25F245DB24AF@nasa.gov> <04E3D99A62496240BCD6A576813E6E318405E30A2A@NDMSSCC05.ndc.nasa.gov> <43C4D49B-96F5-427D-9769-A7A6D289695B@nasa.gov>
In-Reply-To: <43C4D49B-96F5-427D-9769-A7A6D289695B@nasa.gov>
X-Enigmail-Version: 1.4.2
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 8bit
Cc: "dtn-users@irtf.org" 
Subject: Re: [dtn-users] Improving performance in DTN2
X-BeenThere: dtn-users@irtf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "The Delay-Tolerant Networking Research Group \(DTNRG\) - Users." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 29 Jun 2012 21:41:18 -0000

If you use the LTPCL via LTPlib you can also do that and we've
gotten interop with ION working here.

(Having said that, my LTPlib code's pretty crap so might mess
up any performance. OTOH, if you're in the mood for fixing things...:-)

S

On 06/29/2012 08:06 PM, Ivancic, William D. (GRC-RHN0) wrote:
> If your talking ION than contact graph routing (CGR) is there. As a first order approximation, you can of think of CGR as dynamic static routing (but it is a quite a bit more than that). In CGR you basically schedule contact times as would be done in predictive contacts such as space system (Orbital Dynamics).  With CGR  you could tell the system when to send and stop  as a way to emulate disconnection.
> 
> I do not believe CGR is implemented in DTN2.
> 
> - Will
> 
> On Jun 29, 2012, at 2:37 PM, Zoller, David A. (MSFC-EO60)[HOSC SERVICES CONTRACT] wrote:
> 
> Will,
> Good point. Ive got my blinders on as Im the ground receipt node for a downlink and the nodes I transmit to are almost always online. Ill have to expand my horizons and testing. A script should be no problem. Ive heard tidbits of being able to schedule connect times for nodes and suspected that there might be a router type that implemented a schedule but havent taken the time to research it yet and thought you might have been referring to that for the disconnects.
> Thanks,
> DZ
> 
> David Zoller
> COLSA Corporation
> Marshall Space Flight Center
> 
> From: Ivancic, William D. (GRC-RHN0)
> Sent: Friday, June 29, 2012 12:37 PM
> To: Zoller, David A. (MSFC-EO60)[HOSC SERVICES CONTRACT]
> Cc: dtn-users@irtf.org
> Subject: Re: [dtn-users] Improving performance in DTN2
> 
> You can disconnect in a number of ways:
> netem
> pull cable (but not very repeatable timing wise)
> modify ip-table script or link up/down script (probably the easiest and causes the least strain on the CPU).
> put a channel emulator in between DTN nodes.
> 
> The point is, you're streaming in a disconnected environment otherwise there is no reason to use DTN.  So you need to test the storage, not just the forwarding.
> 
> You probably should also put in some other bundle source/destination pairs with various lifetimes.
> 
> You need to see where it breaks and how fragile (or not) the system is.  Tuning a configuration to get something to work is just the start.
> 
> 
> - Will
> 
> On Jun 29, 2012, at 11:32 AM, Zoller, David A. (MSFC-EO60)[HOSC SERVICES CONTRACT] wrote:
> 
> 
> Im sure this implementation will bog down during the disconnects as bundles accumulate in the pending queue which impacts the find_duplicate() mentioned below but Ill try to squeeze in some testing for you some time. What routing do you use for the disconnects or should I  just pull the network cable?
> DZ
> 
> 
> David Zoller
> COLSA Corporation
> Marshall Space Flight Center
> 
> From: Ivancic, William D. (GRC-RHN0)
> Sent: Friday, June 29, 2012 10:00 AM
> To: Zoller, David A. (MSFC-EO60)[HOSC SERVICES CONTRACT]
> Subject: Re: [dtn-users] Improving performance in DTN2
> 
> Add disconnection for 30 sec, 1 min, 5 min and 30 min and see what happens.
> 
> - Will
> 
> On Jun 29, 2012, at 10:55 AM, Zoller, David A. (MSFC-EO60)[HOSC SERVICES CONTRACT] wrote:
> 
> 
> 
> This is using static routes over IP with no disconnection. The Aggregate Custody Signals are configured for 30 seconds, so every 30 seconds the first node takes a hit while it is releasing about 5000 bundles from custody. Ingest stops for a second or so and then as it catches up it processes at about 400 bundles per second.
> 
> David Zoller
> COLSA Corporation
> Marshall Space Flight Center
> 
> From: Ivancic, William D. (GRC-RHN0)
> Sent: Friday, June 29, 2012 9:35 AM
> To: Zoller, David A. (MSFC-EO60)[HOSC SERVICES CONTRACT]
> Cc: ahennes1@math.umd.edu; dtn-users@irtf.org
> Subject: Re: [dtn-users] Improving performance in DTN2
> 
> How long were your periods of disconnection while streaming?
> 
> How many bundle where buffered during disconnection?
> 
> Also, what routing protocol was used - or just static routes over IP?
> 
> - Will Ivancic
> 
> On Jun 29, 2012, at 10:25 AM, Zoller, David A. (MSFC-EO60)[HOSC SERVICES CONTRACT] wrote:
> 
> 
> 
> 
> Angela,
> I just joined the dtn-users mailing list yesterday and discovered that Ive been working in a vacuum. Weve been working on implementing Aggregate Custody Signals (ACS) in the DTN2 source code so that we can catch up with the ION version updated by the University of Colorado at Boulder and get back into the DTN network with their experiments. As Ive been in the DTN2 source code, I have also been working on improving the throughput with the goal of streaming video via DTN. I am currently working on an ACS patch to submit for the reference implementation and am including some of the performance enhancements in it as a bonus.
> 
> I just concluded a 22 hour test piping 167 frames[bundles with a 1316 byte payload] per second through two DTN nodes with custody transfer and ACS processing. It processed 13,605,622 bundles and only lost 6 frames on the front end [missed UDP packets that never made it to the receiver that feeds the first DTN node] which were probably not related to the DTN nodes performance. This is using the reference implementation with the ACS patches. In memory, the dtnd process has grown to 2.1GB due to timers that have been canceled but have not yet expired since I use a 24 hour expiration time. I have a reaper thread that periodically clears the canceled timers that I was not planning on including in the ACS patch since it requires a coordinated update to the oasys package but I think Ill go ahead and include it seeing that there is an interest.
> 
> On my development machine, our in-house version tops out at about 340 bundles/second and I havent tested the patched reference implementation to that extent. Our in-house version has more extensive infrastructure changes that may not be suitable for a reference implementation since the goal was performance for our needs and some of the changes may have broken some of the nuances of the BP specification which I have not studied in depth. Well check to see if there is a way to make it available to the community for evaluation as there may be some mods that can be cherry picked for adapting into the reference implementation.
> 
> In the meantime, here are some things weve run across:
> 
> * Configure and build oasys with the --disable-debug-locking option
> 
> * You might gain improvements using the--disable-debug option when configuring both oasys and dtn2 but I havent bothered to do that yet as the debug is still useful to me
> 
> * BundleDaemon is a single thread. Ive broken this into multiple threads: Input, Output, Storage, ACS and everything else in the original BD thread. The BD currently manages the oasys::TimerSystem which I changed to crank up the oasys::TimerThread to offload that work.
> 
> * BundleDaemon::find_duplicate() bogs down significantly as you approach 15,000 bundles in the pending_bundles_ list.
>      !!Ha!! My intent was to use a std::multimap for the pending bundles but I just saw that I used a std::map instead. Ill have to go back and change that. Anyway, std::map is better suited for this than the std::list and a change to std::multimap should be even better to allow detection and retention of duplicates if so configured.
> 
> * CustodyTimers do not release the reference to the bundle until they expire which keeps freed bundles from being removed as well as the timers. I use a reaper thread to periodically remove the canceled timers from the oasys::TimerSystem but I think adding an overridable onCancel() method to the oasys::Timer class would be good way to trigger processing that could free the bundle reference and allow the bundle to be freed quicker.
> 
> * Im using the BerkeleyDB on a Solid State Drive.
> 
> * Payload storage to disk  the more files in the directory the longer it takes to add a bundle to the database. I changed the payload directory structure to a tiered layout with 10,000 bundle payload per directory.
> 
> * AdminRegistration and PingRegistration do not update the bundle fwdlog to delivered so they dont get deleted until they expire. Minor unless you have tons of custody signals hanging around but the leaner the memory usage the better :)
> 
> Hope this helps,
> DZ
> 
> 
> David Zoller
> COLSA Corporation
> Marshall Space Flight Center
> _______________________________________________
> dtn-users mailing list
> dtn-users@irtf.org
> https://www.irtf.org/mailman/listinfo/dtn-users
> 
> 
> 
> ******************************
> William D. Ivancic
> Phone 216-433-3494
> Fax 216-433-8705
> Networking Lab 216-433-2620
> Mobile 440-503-4892
> http://roland.grc.nasa.gov/~ivancic
> 
> 
> ******************************
> William D. Ivancic
> Phone 216-433-3494
> Fax 216-433-8705
> Networking Lab 216-433-2620
> Mobile 440-503-4892
> http://roland.grc.nasa.gov/~ivancic
> 
> 
> ******************************
> William D. Ivancic
> Phone 216-433-3494
> Fax 216-433-8705
> Networking Lab 216-433-2620
> Mobile 440-503-4892
> http://roland.grc.nasa.gov/~ivancic
> 
> 
> 
> 
> _______________________________________________
> dtn-users mailing list
> dtn-users@irtf.org
> https://www.irtf.org/mailman/listinfo/dtn-users
>