Hi,
Anouk Ahamitet <> [20080624 17:41:27 -0000]:
>
> --- In Eddie Dawydiuk <> wrote:
> >
> > Seeing as though the 10ms delay is not hardware specific, but rather
> > kernel specific
>
> Which brings up a question... While researching different ways to do
> various precision waits in linux, I found several mentions that the
> default 'jiffie' in the 2.6 kernel is 1ms, and approx one jiffie is the
> worst-case time that usleep() will take. So why did Technologic choose
> to use a 10ms jiffie in ts-linux? Is the ARM (ot specifically the TS
> board) hardware not capable of using the 1ms setting? The x86 board
> we're also using has a 2.6 kernel and usleep() never takes longer than
> 1ms (unless we ask it to).
>
1000Hz on x86...100Hz on everything else (including ARM) if I remember
correctly. You can only get better really with High Resolution Timers and
dyntick enabled (whilst avoiding clobbering the scheduler). The orion
chipset the TS-7800 uses does give up to 1ns resolution.
Of course I could be completely wrong on this, my 2.6.24 sparc64 box is at
100Hz though :-)
> > I didn't add any comments. In my opinion comments explaining how the
> > Linux scheduler works don't belong in the ts7800ctl utility source code.
> > If I would have added a comment stating each sleep may sleep for as long
> > as 10ms, the comment would have been misleading. As the comment would
> > have made the assumption the kernel tick rate was set to 100Hz.
>
> We can agree to disagree on that one. Since we're talking about code to
> talk to your particular implementation of the hardware, comments
> explaining the hardware's timing requirements (or lack thereof) would
> seem to be quite appropriate. Especially since usleep() is called with
> two apparently very different values (1 and 100), the code is very
> misleading as it is because it indicates that the short time may be
> necessary for part of the conversation, when that is not generally true.
>
My £0.02, this is the first thing you read about when thinking about doing
anything vaguely RT under Linux.
http://elinux.org/High_Resolution_Timers
It could be argued that "you should have known". What I will side on you
though, TS might have wanted to do a little more legwork on the RT side of
things before declaring things "great and prosperous"[1]. Also if they fixed
that damn trivial bug in TS-BOOTROM to pass the real platform ID would have
been nice without the world having to resort to ugly hacks[2] :-/
...but I digress.
> [snipped]
>
> Lastly, has anyone else's TS-7800 been running (use the ts-7800ctl
> odometer) for under -16,000,000 hours?
>
Yeah, that was my first hint that ts7800ctl had some 'fruity' logic in it
and might have not been as well tested as one hoped :)
Fortunately I bought mine for the hardware and not the software on it, thats
great for me but its nothing short of a complete arse for you guys :-/
Cheers
Alex
[1] http://www.embeddedarm.com/about/resource.php?item=343
[2] http://nas-central.org/index.php/Orion_NAS_customisation_guide#Booting
--
_______________________________________
/ A full belly makes a dull brain. \
| |
| -- Ben Franklin |
| |
\ [and the local candy machine man. Ed] /
---------------------------------------
\ ^__^
\ (oo)\_______
(__)\ )\/\
||----w |
|| ||
------------------------------------
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/ts-7000/
<*> Your email settings:
Individual Email | Traditional
<*> To change settings online go to:
http://groups.yahoo.com/group/ts-7000/join
(Yahoo! ID required)
<*> To change settings via email:
<*> To unsubscribe from this group, send an email to:
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
|