Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 24 May 2001 00:01:53 -0700
From:      Peter Wemm <peter@wemm.org>
To:        Greg Lehey <grog@lemis.com>
Cc:        arch@FreeBSD.ORG
Subject:   Re: http://uptime.netcraft.com/up/accuracy.html#cycle 
Message-ID:  <20010524070153.6DECA3811@overcee.netplex.com.au>
In-Reply-To: <20010524094750.A74859@wantadilla.lemis.com> 

next in thread | previous in thread | raw e-mail | index | archive | help
Greg Lehey wrote:
> On Wednesday, 23 May 2001 at 19:43:32 +1000, Bruce Evans wrote:
> > On Wed, 23 May 2001, Greg Lehey wrote:
> >
> >> Comments?
> >>
> >> Greg
> >>
> >> ----- Forwarded message from Richard Wendland <richard@starburst.demon.co.
    uk> -----
> >>
> >>> Date: Tue, 22 May 2001 21:51:02 +0100 (BST)
> >>> From: Richard Wendland <richard@starburst.demon.co.uk>
> >>> To: grog@FreeBSD.org (Greg Lehey)
> >>> Cc: webmaster@netcraft.com
> >>> Subject: Re: http://uptime.netcraft.com/up/accuracy.html#cycle
> >>> X-Mailer: ELM [version 2.5 PL2]
> >>>
> >>>> At this link, you claim:
> >>>>
> >>>>   Additionally HP-UX, Linux, Solaris and recent releases of FreeBSD
> >>>>   cycle back to zero after 497 days, exactly as if the machine had
> >>>>   been rebooted at that precise point. Thus it is not possible to see
> >>>>   a HP-UX, Linux or Solaris system with an uptime measurement above
> >>>>   497 days.
> >>>>
> >>>> FreeBSD does not suffer from this problem.  You'll notice that you
> >>>> have a large number of FreeBSD systems with uptimes of over 497 days.
> >>>> I'd appreciate if you would correct this statement.
> >>>
> >>> Hi Greg,
> >>>
> >>> I think that statement is accurate.  Note that we're not talking about
> >>> the FreeBSD 'uptime' command, but our ability to ascertain uptime remotel
    y
> >>> by decoding the TCP timestamp option.
> >>>
> >>> Prior to FreeBSD 3 the TCP timestamp option was incremented every 500ms,
> >>> as is traditional with BSD.  From FreeBSD 3 it was incremented every
> >>> 10ms, presumably to improve RTT measurement.  But it does have the
> >>> consequence that the 32-bit TCP timestamp wraps around at 497.1 days.
> >>> Hence, with our current method at least, we don't detect uptimes above
> >>> this for FreeBSD 3 and later.
> >>>
> >>> So the FreeBSD systems listed > 497 days are running FreeBSD 2.
> >>> Once everyone has upgraded from FreeBSD 2, FreeBSD will no longer get
> >>> in that top uptimes list!
> >
> > The TCP timestamp is actually incremented every 1/hz seconds, so it
> > overflows after every 48.5 days on alphas (and on i386's with
> > "options HZ=1024").
> 
> So what's Richard talking about?

I think it means that we need to run a timer on it at a fixed 20hz so that
our uptime values double. ;-)  Actually, I dont think that will help because
they check over several days to determine the CC count rate.  But we should
probably use a fixed rate since people do change their HZ values in certain
situations.

netcraft's uptime counter looks at the RFC1323 timestamp option (which we
have off by default now, so it is academic :-( ) and detects the 500ms
update rate or the 10ms update rate for FreeBSD systems.  It can use this to
determine the uptime 'remotely' by fingerprinting the system.

See:
 http://uptime.netcraft.co.uk/up/graph?site=www.freebsd.org

Incidently, we should turn TCP_EXTENSIONS (rfc1323) back on by default.
Linux has had it on for a while now and has "cleared the way" for us.

Cheers,
-Peter
--
Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au
"All of this is for nothing if we don't go to the stars" - JMS/B5


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010524070153.6DECA3811>