[TICTOC] Memory for per-client state on server
Hal Murray <hmurray@megapathdsl.net> Thu, 24 March 2016 10:45 UTC
Return-Path: <hmurray@megapathdsl.net>
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 BA3D112D6E9 for <tictoc@ietfa.amsl.com>; Thu, 24 Mar 2016 03:45:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.043
X-Spam-Level: *
X-Spam-Status: No, score=1.043 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_DYNAMIC_IPADDR=1.951, RDNS_DYNAMIC=0.982, T_HDRS_LCASE=0.01] autolearn=no 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 wF8P8-LFlXVn for <tictoc@ietfa.amsl.com>; Thu, 24 Mar 2016 03:45:06 -0700 (PDT)
Received: from ip-64-139-1-69.sjc.megapath.net (ip-64-139-1-69.sjc.megapath.net [64.139.1.69]) by ietfa.amsl.com (Postfix) with ESMTP id 9558112D6E3 for <tictoc@ietf.org>; Thu, 24 Mar 2016 03:45:06 -0700 (PDT)
Received: from shuksan (localhost [127.0.0.1]) by ip-64-139-1-69.sjc.megapath.net (Postfix) with ESMTP id 47856406063; Thu, 24 Mar 2016 03:45:04 -0700 (PDT)
X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.3
To: Dieter Sibold <dieter.sibold@ptb.de>
From: Hal Murray <hmurray@megapathdsl.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Thu, 24 Mar 2016 03:45:04 -0700
Message-Id: <20160324104504.47856406063@ip-64-139-1-69.sjc.megapath.net>
Archived-At: <http://mailarchive.ietf.org/arch/msg/tictoc/uCn0rE0OizsVTVfhfcVoR4kQctw>
Cc: ntpwg@lists.ntp.org, Hal Murray <hmurray@megapathdsl.net>, tictoc@ietf.org
Subject: [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 10:45:07 -0000
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.
- [TICTOC] Memory for per-client state on server Hal Murray
- Re: [TICTOC] Memory for per-client state on server Dieter Sibold