IETF Logo Mail Archive

Re: [TICTOC] Memory for per-client state on server

Dieter Sibold <dieter.sibold@ptb.de> Thu, 24 March 2016 11:07 UTC

Return-Path: <dieter.sibold@ptb.de>
X-Original-To: tictoc@ietfa.amsl.com
Delivered-To: tictoc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A284612D9F1 for <tictoc@ietfa.amsl.com>; Thu, 24 Mar 2016 04:07:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S8czRmUXTKh7 for <tictoc@ietfa.amsl.com>; Thu, 24 Mar 2016 04:07:54 -0700 (PDT)
Received: from mx1.bs.ptb.de (mx1.bs.ptb.de [192.53.103.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8582912D7DA for <tictoc@ietf.org>; Thu, 24 Mar 2016 04:07:26 -0700 (PDT)
Received: from smtp-hub.bs.ptb.de (smtpint01.bs.ptb.de [141.25.87.32]) by mx1.bs.ptb.de with ESMTP id u2OB7OLU017853-u2OB7OLW017853 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 24 Mar 2016 12:07:24 +0100
Received: from lotus.bs.ptb.de (lotus.bs.ptb.de [141.25.85.200]) by smtp-hub.bs.ptb.de (Postfix) with ESMTP id 9F1353D45C; Thu, 24 Mar 2016 12:07:24 +0100 (CET)
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
X-Pgp-Agent: GPGMail 2.6b2
From: Dieter Sibold <dieter.sibold@ptb.de>
In-Reply-To: <20160324104504.47856406063@ip-64-139-1-69.sjc.megapath.net>
Date: Thu, 24 Mar 2016 12:07:16 +0100
Message-Id: <D0B7AB0B-BC6B-45CA-BBEA-8233BA6F7B32@ptb.de>
References: <20160324104504.47856406063@ip-64-139-1-69.sjc.megapath.net>
To: Hal Murray <hmurray@megapathdsl.net>
Content-Type: multipart/signed; boundary="Apple-Mail=_4894C159-2DC4-42EA-9D68-5BB9E98631A9"; protocol="application/pgp-signature"; micalg="pgp-sha512"
Archived-At: <http://mailarchive.ietf.org/arch/msg/tictoc/gyyhX24sl3Rhx2cpKI6iqvi6wBg>
Cc: ntpwg@lists.ntp.org, tictoc@ietf.org
Subject: Re: [TICTOC] Memory for per-client state on server
X-BeenThere: tictoc@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Timing over IP Connection and Transfer of Clock BOF <tictoc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tictoc>, <mailto:tictoc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tictoc/>
List-Post: <mailto:tictoc@ietf.org>
List-Help: <mailto:tictoc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tictoc>, <mailto:tictoc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 24 Mar 2016 11:07:55 -0000

Hello Hal,

thanks for the suggestion. I’m going to check this.
Dieter

> Am 24.03.2016 um 11:45 schrieb Hal Murray <hmurray@megapathdsl.net>:
> 
> 
> dieter.sibold@ptb.de said:
>> Yes, this is true. But the capabilities of NTP to keep track of the states
>> are very limited. Our NTP servers with the most current NTPD are only able
>> to store about 12000 records, in which the oldest records are about 10 to
>> 60 seconds old. They even cannot guarantee to memorize the state of a
>> client when it is in iburst mode. Perhaps the implementation can be
>> adjusted to allow for even more state information. ...
> 
> Please check the mru configuration option.  It's in html/miscopt.html
> 
> Ignoring NTS, I'd like to know if you run out of memory before you can keep
> track of all your clients.
> 
> I'm not trying to fight stateless approaches, but I'm not sure we should
> discard a suggestion because it requires state.
> 
> Let's play with the back of an envelope.  Suppose we allocate a gigabyte for
> holding state and each client needs 1000 bytes.  That's a million clients.
> 
> 
> --
> These are my opinions.  I hate spam.
> 
> 
>

v2.23.0 | Report a Bug | By Email