Clock skew

[Mike]

While testing a gps interface, I found the system clock is slow by
approximately 150mS/S ( or losing one minute every 7 ). I was able to
use adjtimex (up to its limit) to reduce the skew to 45mS/S.

Has anyone else seen this issue?

Have any other means been used to eliminate the skew?

When spare time permits, I'll try to modify the adjtimex code to
permit greater adjustment (need an upper limit of approximately 15%
from the current 10% limit.

[biff...@yahoo.co.uk]

Maybe PIT_TICK_RATE is set wrong in include/linux/timex.h. Try
tweaking this value, however if you tweak it too much you may find
some peripherals magically stop working.

To be honest there was always doubt over whether this value was
appropriate for the RDC CPU and it seems it isn't. For the moment the
standard x86 value is used.

regards,
Biff.

[JWG]

I have seen this drifting as well, and other than frequent ntp
synchronization have not been able to manage it well. Please let me
know the exact adjtimex you are using. I am not sure how I got here,
but I have settled on "adjtimex -f -214748 -t 9990".

JG

[usul27]

I'm having the same problem after switching to the latest slackware. I
can't remember having this problem with the old OpenWRT distribution
(but I'm not sure). Could somebody check if there was a difference in
the timer settings of the OpenWRT and the Slackware kernels?

BTW: I'm loosing about 9 seconds every minute.:
root@darkstar:~# ntpdate -o 4 pool.ntp.org; sleep 60; ntpdate -o 4
pool.ntp.org
12 Dec 10:52:41 ntpdate[3021]: step time server 72.52.190.26 offset
2.239129 sec
12 Dec 10:53:52 ntpdate[3023]: step time server 72.18.205.157 offset
9.054759 sec

root@darkstar:~# ntpdate -o 4 pool.ntp.org; sleep 60; ntpdate -o 4
pool.ntp.org
12 Dec 10:54:02 ntpdate[3024]: step time server 72.46.65.130 offset
1.229085 sec
12 Dec 10:55:12 ntpdate[3026]: step time server 72.46.65.130 offset
9.010520 sec

[Mike]

Modified variable in arch/x86/include/asm/timex.h, choosing arbitrary
value of 1093182 from 1193182.
Kernel rebuild took 4ish hours. [ Don't forget to set the current
time so the compilation dependencies will take ]
I was then able to then use adjtimex -t 10497 to synchronize the clock
to a gps reference. The clock attained a drift of +/- 55uS/S.
This was probably an exaggerated range... will retest using alternate
method for measurement consistency.
Applied new variable value of 1041621 ( which is 1093182/10495*10000
ish ) which I expect should produce a near 0 drift.
Will retest and post results.

On Dec 11, 12:03 pm, "biffe...@yahoo.co.uk" <biffe...@yahoo.co.uk>
wrote:

[Marco Bauer]

Hi,

is there any plan to make a new Bifferboard Firmware with the actual
version of OpenWRT ?
I think this would give us a much smaller Firmware than Slackware.
I think the OpenWRT uses much less RAM of the Board.

Cu
Marco

[Marco Bauer]

Hi,

i got the 1.4 FW source, ans the compiling process works fine until i set
under Kernel-Modules the RT2870 (USB Wireless Dongle) to (M).

The make process give me the following error:

cp: cannot stat
`/home/marco/bifferboard/dev-neu-2.6.27-5/bifferboard/wrt/openwrt/build_dir/linux-bifferboard/linux-2.6.27.5/crypto/aead.ko':
No such file or directory
make[4]: ***
[/home/marco/bifferboard/dev-neu-2.6.27-5/bifferboard/wrt/openwrt/bin/packages/target-i386_uClibc-0.9.29/kmod-crypto-core_2.6.27.5-bifferboard-1_i386.ipk]
Error 1
make[4]: Leaving directory
`/home/marco/bifferboard/dev-neu-2.6.27-5/bifferboard/wrt/openwrt/package/kernel'
make[3]: *** [package/kernel/compile] Error 2
make[3]: Leaving directory
`/home/marco/bifferboard/dev-neu-2.6.27-5/bifferboard/wrt/openwrt'
make[2]: ***
[/home/marco/bifferboard/dev-neu-2.6.27-5/bifferboard/wrt/openwrt/staging_dir/target-i386_uClibc-0.9.29/stamp/.package_compile]
Error 2
make[2]: Leaving directory
`/home/marco/bifferboard/dev-neu-2.6.27-5/bifferboard/wrt/openwrt'
make[1]: *** [world] Error 2
make[1]: Leaving directory
`/home/marco/bifferboard/dev-neu-2.6.27-5/bifferboard/wrt/openwrt'
make: *** [remake] Error 2
marco@blackstar:~/bifferboard/dev-neu-2.6.27-5/bifferboard/wrt$


Does anybody how to fix this.
I do realy need this module for the 2.6.27-5.

Cu
Marco

[ma...@wtns.de]

[Andrew Scheller]

I've not tried it myself, but is this what you're looking for?
http://sites.google.com/site/bifferboard/openwrt-svn

Lurch

2009/12/15 Marco Bauer <ma...@wtns.de>:

> --
> You received this because you are subscribed to the "Bifferboard" Google group - honest!
> To unsubscribe from this group, send email to bifferboard...@googlegroups.com
>

[biff...@yahoo.co.uk]

OpenWrt is a system for allowing routers to run Linux from flash.
OpenWrt does not directly support USB-root systems, so this is trying
to fit a square peg in a round hole. Don't complain to me, complain
to the OpenWrt developers if you want them to support that! The hacks
required to make this possible are 'documented' in my 1.4 firmware
source, however nobody wants to work on them to bring them up to date
with the latest OpenWrt svn and I don't blame them.

A limited squashfs OpenWrt system is possible in about 2MB of flash,
but for the 1MB Bifferboard you can forget it. Slackware/Gentoo and
Debian start off being closer to what you need for a USB-root system,
and hence easier to support, although, yes they use more RAM.

I am hoping that with the new 8MB boards someone will help me out and
fix OpenWrt on them. For the moment you can select Bifferboard
profile, and at least get yourself a kernel compiled, and also a
squashfs image, however the flash detection code doesn't work and
gives an Ooops preventing it from working at the moment. It doesn't
look easy to figure out why, but you're welcome to look. That won't
be much use to you if you only have a 1MB board though.

regards,
Biff.

PS: You need an extra patch in the patches directory to allow
activation of the BB flash map, Florian hasn't applied that one yet:
PM me if you want that.

[Mike]

Set PIT_TICK_RATE 1041621
This was close, but the system clock was fast by 185uS/S.
Used adjtimex -t 9998 -f 819200 to produce a clock drift of +/- 2uS/S.
This is approximately equivalent to a PIT_TICK_RATE of 1041816

[d1savowed]

Biff is right on this, and getting things into OpenWRT is a pain and a
half... I built some of the new WRT stuff on S/F for the Bifferboard
and keeping it updated (especially with kernel version changes) is
difficult. Even now I run Debian on mine as its far simpler to
maintain.

I'm more than happy to help out getting WRT working with the latest
SVN, and as you know have been trying to get the latest 2.6.32 patches
ported over, but there are some in-kernel + gcc issues that are
causing problems. Hopefully these can be sorted soon enough so that a
single patch for the WRT svn can be used, and following that, proper
integration into the SVN.

Stu

On Dec 15, 3:37 pm, "biffe...@yahoo.co.uk" <biffe...@yahoo.co.uk>
wrote:

> On Dec 15, 2:45 pm, "Marco Bauer" <ma...@wtns.de> wrote:
>
> > Hi,
>
> > is there any plan to make a new Bifferboard Firmware with the actual
> > version ofOpenWRT?
> > I think this would give us a much smaller Firmware than Slackware.

> > I think theOpenWRTuses much less RAM of the Board.
>
> OpenWrtis a system for allowing routers to run Linux from flash.OpenWrtdoes not directly support USB-root systems, so this is trying

> to fit a square peg in a round hole.  Don't complain to me, complain

> to theOpenWrtdevelopers if you want them to support that!  The hacks

> required to make this possible are 'documented' in my 1.4 firmware
> source, however nobody wants to work on them to bring them up to date

> with the latestOpenWrtsvn and I don't blame them.
>
> A limited squashfsOpenWrtsystem is possible in about 2MB of flash,

> but for the 1MB Bifferboard you can forget it.  Slackware/Gentoo and
> Debian start off being closer to what you need for a USB-root system,
> and hence easier to support, although, yes they use more RAM.
>
> I am hoping that with the new 8MB boards someone will help me out and

> fixOpenWrton them.  For the moment you can select Bifferboard

[Mike]

Tested a second board using the previously quoted values.
The clock was fast by 0 to 6 uS/S

[Lukasz Sokol]

Hi Mike,

there is no escape from cheap quartz I'm afraid ;)

Maybe a future bifferboard could sport a battery backed RTC ;)

el es

[M P]

Well, even quartzs have problems in noisy environments anyway (like a
computer board ;-)), theres no escape from a GPS or a radio clock :>

Michael

[Mike]

Actually, when adjusted, clock is quite stable and is likely to be
stable among different boards. The issue was that the initial
PIT_TICK_RATE may not have been optimal for the slackware
distribution.

[JWG]

So one should use 1041816 ?

[biff...@yahoo.co.uk]

Patch added here:
https://bifferboard.svn.sourceforge.net/svnroot/bifferboard/slack/kernel/2.6.30.5/

Just building at the moment, so hope I got that right. If anyone
thinks another value would be more appropriate let me know.

thanks,
Biff

[Mike]

1041816 is the value for the PIT_TICK_RATE that worked for the two
boards that I have.
The results were measured using a precision GPS time reference.

As an additional note, the CTS serial line is available on I/O pin 2
and has been found capable of generating a serial input interrupt.
This means that it may be possible to create a GPS / PPS time
reference using a Garmin LVC 18x and an inverting level changer. I
have yet to experiment with gpsd and ntpd on this platform to verify
this presumption, but it appears possible

[Lukasz Sokol]

Well, I thought, the clock quartz can have up to +-20% difference between
individual devices, some are accurate only in about 30 centigrades (body temperature, watch crystal)

This is what I meant by "cheap quartz ;)" but I hope Biff didn't get them *that* cheap ;)
(no offense meant of course - finding a good deal is tough these days, I know)

el es

[biff...@yahoo.co.uk]

Just stumbled upon this:
http://mirror.celinuxforum.org/gitstat//commit-detail.php?commit=e1b4d1143651fb3838be1117785b6e0386fa151f

It mentions PIT_TICK_RATE=1041667, very close, but not identical to
the value you're using. Somebody decided that this was ugly so he
took it out Jan of last year.

[d1savowed]

Nice.. I just took a quick look at the 2.6.32.2 source code and the
quirk handling, but can't see any mention to the RDC chipset having a
different PIT_TICK_RATE. I wonder if this is an omission on Ingo's
part...

Stu

[biff...@yahoo.co.uk]

I believe the quirk handling is something to be done, so basically
taking out this fix was a backward step, with a vague thought that it
would be fixed sometime in the future. Since the run-time CPU
detection patch hasn't been applied, I'm not sure how they'd know when
to activate the quirk.