Received: with ECARTIS (v1.0.0; list netdev); Mon, 31 Jan 2005 03:56:11 -0800 (PST) Received: from neon.tcs.hut.fi (neon.tcs.hut.fi [130.233.215.20]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j0VBu3XU007736 for ; Mon, 31 Jan 2005 03:56:04 -0800 Received: from rhea.tcs.hut.fi (rhea.tcs.hut.fi [130.233.215.147]) by neon.tcs.hut.fi (Postfix) with ESMTP id DAD3380019F; Mon, 31 Jan 2005 13:55:57 +0200 (EET) Date: Mon, 31 Jan 2005 13:55:57 +0200 (EET) From: Ville Nuorvala To: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= Cc: rmk@arm.linux.org.uk, netdev@oss.sgi.com Subject: Re: ip -6 route shows incorrect route expiry times In-Reply-To: <20050131.013018.131301320.yoshfuji@linux-ipv6.org> Message-ID: References: <20050130160840.C25000@flint.arm.linux.org.uk> <20050131.012910.117562374.yoshfuji@linux-ipv6.org> <20050131.013018.131301320.yoshfuji@linux-ipv6.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=iso-2022-jp X-Virus-Scanned: ClamAV 0.80/650/Sun Jan 2 19:00:02 2005 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by oss.sgi.com id j0VBu3XU007736 X-archive-position: 1071 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: vnuorval@tcs.hut.fi Precedence: bulk X-list: netdev Content-Length: 1522 Lines: 36 On Mon, 31 Jan 2005, YOSHIFUJI Hideaki / [iso-2022-jp] µÈÆ£±ÑÌÀ wrote: > In article <20050131.012910.117562374.yoshfuji@linux-ipv6.org> (at Mon, 31 Jan 2005 01:29:10 +0900 (JST)), YOSHIFUJI Hideaki / µÈÆ£±ÑÌÀ says: > > > > It appears that the expiry seconds here are actually in units of > > > 10 seconds. Maybe someone's double-converting kernel Hz to user Hz? > > > > Kernel exports in USER_HZ. > > iproute2 seem to convert it again; workaround is to do "export HZ=100". > ~~~~~~~~~~~~~ > This is example. Of course, this depends on your arch. Please, couldn't the lifetimes be passed to userspace in a architecture indepentent unit like whole seconds? I don't think any routing protocols need a sub-second resolution for the lifetimes but if they do, why not use milliseconds? Better still, why not add a new attribute with a struct timespec or timeval to store the sub-second lifetimes for those who need them? Btw. we have the same HZ problem in many /proc files. Here too I would like to see a millisecond based interface in addition to the existing USER_HZ/jiffies/second based one. This especially applies to values like base_reachable_time and retrans_time, which are originally defined as millisecond values in the specification (RFC 2461). Regards, Ville -- Ville Nuorvala Research Assistant, Institute of Digital Communications, Helsinki University of Technology email: vnuorval@tcs.hut.fi, phone: +358 (0)9 451 5257