On Mon, 12 Oct 1998 04:36:23 -0700 Andrew Philip Bell wrote:
> On Mon, 12 Oct 1998, Glynn Clements wrote:
> > Andrea Arcangeli wrote:
> >
> > > > > So I thougt the defined HZ has to be changed as a 1000 (as you know,
> > > > > 100 is a default).
> > > >
> > > > If you change the value of HZ, bad things may happen.
> > >
> > > If bad things will happen you' ll found a bug in the kernel.
> >
> > That depends upon what you change it to, I guess. I wouldn't expect to
> > be able to set HZ to 1E9 and still have a functioning system.
>
> Of course you wouldn't.
>
> > > Sure a too high value could stall the machine (bad thing ;-) and a too low
> > > one could decrease too much the scheduling frequency causing some strange
> > > (not bad) things.
> >
> > Would this include flip buffers overflowing? (I thought that was
> > sync'd to HZ).
>
> What's a flip bluffer? Do you mean a flip-flop?
I think they mean the same thing. I picked up the term flip buffer while mucking
around in the file system/scsi driver/memory mangement code. Since I wasn't able
to find it with a grep just now, it must have been in documentation. Probably
the ext2 web pages or one on the kernel.
>
> > > > > to implement a exact delay time.
> > > >
> > > > You can't implement an exact delay time. You'll have to live with
> > > > whatever delay you get, or switch to using a real-time OS.
> > >
> > > Or use udelay() or use the rdtsc to measure how much cycles are passed.
> > >
> > > Something like:
> > >
> > > timeout = rdtsc() + 2000cycles;
> > > while (rdtsc() < timout);
> > >
> > > This would delay exactly 2000 cycles. This way you can get the precision
> > > of the frequency of the CPU.
> >
> > Yeah, but the poster wanted to delay for 125ms. Doing this (regularly)
> > using a busy wait sounds like it would starve user-space processes of
> > CPU time (or am I overlooking something?)
>
> Perhaps you are both overlooking something. Unless this rdtsc() call
> overrides the kernel's scheduler somehow (note: I couldn't find any info on
> rdtsc()), then several context switches could (and would) throw off this
check.
> I think that you can really only achieve a lower bound for your delay.
>
> BTW, when in the hell will 2.2 get here?! I'm losing my patience. I've got a
> short fuse as is, and this long wait is killing me.
What's 2.2?
I think this requirement is stretching if not beyond the boundary which current
exists between multi-tasking and rt. IMHO when determinism is introduced into
the equation we are over the edge.
However, if a device driver has the highest priority (see irqtune docs) with an
external clock source..... I think I'll file this one under "Schouda, Wouda,
Coulda".
Regards,
david
--
David Ross
[EMAIL PROTECTED]
Toad Technologies
"I'll be good! I will, I will !"
---------------------------------------------------
70% of American women have never had an emotionally satisfying
relationship with a Republican.
-TV Nation Poll
