This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
Re: Changing system timer resolution
- From: Gary Thomas <gthomas at redhat dot com>
- To: Jonathan Larmour <jlarmour at redhat dot com>
- Cc: Grant Edwards <grante at visi dot com>, Nick Garnett <nickg at redhat dot com>,eCos Discussion <ecos-discuss at sources dot redhat dot com>
- Date: 03 Dec 2001 10:17:10 -0700
- Subject: Re: [ECOS] Changing system timer resolution
- References: <NFBBJGOLDDDGJPLCMJKNCEIFCCAA.jura@intesis.hr><1006968670.7768.10.camel@hermes> <3C083779.1BA45145@redhat.com><wwgy9kkcz0r.fsf@balti.cambridge.redhat.com><20011203101036.A16245@visi.com> <3C0BA9AE.ADC09E41@redhat.com>
On Mon, 2001-12-03 at 09:34, Jonathan Larmour wrote:
> 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.
Actually, I would think the only thing that would need attention is:
net/tcpip/current/src/ecos/support.c: int hz = 100;
to make it work when the tick frequency is not 100Hz.
Was there some specific function/detail you were referring to?