On Mon, 31 Jan 2005, YOSHIFUJI Hideaki / [iso-2022-jp] 吉藤英明 wrote:
> In article <20050131.012910.117562374.yoshfuji@xxxxxxxxxxxxxx> (at Mon, 31
> Jan 2005 01:29:10 +0900 (JST)), YOSHIFUJI Hideaki / 吉藤英明
> <yoshfuji@xxxxxxxxxxxxxx> 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@xxxxxxxxxx, phone: +358 (0)9 451 5257
|