On Thu Nov 29 04:20:52 EST 2012, charles.fors...@gmail.com wrote:
> My problem is that the kernel is not currently capable of supplying
> what Erik defines, to the process level even internally, and even for
> his described applications (delays of a small interval, tiny
> retransmission times), it'
å¨ 2012å¹´11æ28æ¥ææä¸UTC+8ä¸å8æ¶22å30ç§ï¼Bence
Fábiánåéï¼
> but what is _most_ likely is that you really have them initialized two times.
> just do
> g '(op|et)names ?='
>
> you should find 4 initializations. just delete the redundant ones.
>
>
> 2012/11/28 Bence Fábiá
å¨ 2012å¹´11æ28æ¥ææä¸UTC+8ä¸å8æ¶48å09ç§ï¼erik
quanstromåéï¼
> you're right. a quick trip through sort|uniq -d says that FALL is listed
>
> twice.
>
>
>
> - erik
Thank you erik and Bence, it's a good lesson to learn.
å¨ 2012å¹´11æ28æ¥ææä¸UTC+8ä¸å8æ¶48å09ç§ï¼erik
quanstromåéï¼
> you're right. a quick trip through sort|uniq -d says that FALL is listed
>
> twice.
>
>
>
> - erik
Thank you erik, it's a good lesson.
My problem is that the kernel is not currently capable of supplying
what Erik defines, to the process level even internally,
and even for his described applications (delays of a small interval,
tiny retransmission times), it's not clear that the traditional sleep,
which has
*always* been sloppy, is
> Seems best to get rid of the fixed 100Hz clock and allow as
> fine a timer resolution (& accuracy) as a particular CPU +
> kernel combination can do.
So what this argues for is a query interface - hello mr. kernel, what can
you and your hardware do? In whatever units make sense. Then userspace
