This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
Re: Changing system timer resolution
- From: Jonathan Larmour <jlarmour at redhat dot com>
- To: Grant Edwards <grante at visi dot com>
- Cc: Nick Garnett <nickg at redhat dot com>, ecos-discuss at sources dot redhat dot com
- Date: Mon, 03 Dec 2001 16:34:54 +0000
- Subject: Re: [ECOS] Changing system timer resolution
- Organization: Red Hat UK Ltd.
- References: <NFBBJGOLDDDGJPLCMJKNCEIFCCAA.jura@intesis.hr> <1006968670.7768.10.camel@hermes> <3C083779.1BA45145@redhat.com> <wwgy9kkcz0r.fsf@balti.cambridge.redhat.com> <20011203101036.A16245@visi.com>
Grant Edwards wrote:
>
> On Mon, Dec 03, 2001 at 11:40:36AM +0000, Nick Garnett wrote:
>
> > They should work now. Any TCP/DHCP code that relies on times should be
> > using the timing facilities provided in the network or POSIX APIs( e.g.
> > select() nanosleep() etc.).
>
> Excellent! My source tree is getting old and I hadn't realized this had been
> done. Last time I looked at TCP stuff I think there was a hard-wired
> definition of HZ, and I thought that changing the tick period would break
> things. At one point (a long time ago) I did have my system tick at 1ms for
> a while, but I wasn't doing any network stuff at the time.
I think the idea is that the stack can be presented with something that
looks like HZ == 100, but it actually isn't.
But looking closer, I'm not sure this has been fixed:
net/tcpip/current/src/ecos/timeout.c doesn't scale the number of ticks at
all.
Jifl
--
Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223) 271062
Maybe this world is another planet's Hell -Aldous Huxley || Opinions==mine