[ntp:questions] Advice for a (LAN-interconnected) WLAN Testbed w/ ARM nodes

Florian Sesser floml at cosetrain.com
Mon Aug 2 20:10:15 UTC 2010


Dear experts!

I am conducting a series of experiments in a testbed created for
measuring the performance of WLAN mesh routing algorithms (and
everything distantly related) [1].

Having (partially) implemented IPMP [2], synchronised clocks would be of
great help: Every IPMP-enabled node appends a so-called "Path Record" (a
system-time-derived time stamp and an IP Address) into the payload of an
(IPMP) echo packet. If I get the mesh nodes' system clocks accuracy to
=< 1 ms, I could save quite some effort on the post-processing of the data.

I have not conducted in-depth analysis of the ntpd clocks as of now, but
 had one node exhibit an offset of 7.5 ms (after having run ISC ntpd for
ca 24 hours).  That's too much to be useful, I need one order of
magnitude more accuracy.

Do you have advice for me how to improve the accuracy on the nodes to
the order of 1 ms (or below)? I have googled quite a bit, but the amount
of information is overwhelming, and I cannot afford nor attach GPS or
other external clock sources to the nodes. (In fact, I cannot change the
cabling or HW setup in any way.)

Here is some information about the setup:

The network only has one "server" machine (Xeon 8 core, 8 GB RAM or so),
which also acts as firewall to the campus network (ie, I cannot easily
place lots of dedicated NTPd machines into the network, but maybe make
use of the ntpd broadcast feature?). It runs a stratum 2 ISC ntpd server.

The nodes are Avila GW-2348 (ixp4xx platform, Datasheet: [3]), running
OpenWRT Linux 8.09. They are equipped with one wired (100 MBit Ethernet)
and two wireless (54 a / g) interfaces. Note that the wired interface is
not solely used for ntp traffic, but pretty much for everything (which
is, during experiments, not awful much, but its not nothing either).
There are three different subnets: One with 8, another with 12 and a
third with about 30 nodes.

The nodes have a GW2348-4 RTC [4] connected by I2C. I can access the
clock with the hwclock utility, but I do not know if I can make any use
of it for my "improve accuracy" quest.

> # cat /sys/devices/system/clocksource/clocksource0/available_clocksource
> OSTS jiffies 
> # cat /sys/devices/system/clocksource/clocksource0/current_clocksource
> OSTS 

Excerpts from the kernel's .config:
> # Linux kernel version: 2.6.26.8
[...]
> CONFIG_TICK_ONESHOT=y
> # CONFIG_NO_HZ is not set
> CONFIG_HIGH_RES_TIMERS=y
> CONFIG_GENERIC_CLOCKEVENTS_BUILD=y
> # CONFIG_PREEMPT is not set
> CONFIG_HZ=100

We are running ISC ntpd 4.2.4p6. Here's our ntp.conf config
(omitting #comments):
> restrict 127.0.0.1
> driftfile  /tmp/ntp.drift
> server 172.17.255.254 iburst

So the ntpd setup is quite simple at the moment.

I am willing to try any patches to the kernel / ntpd, I just don't know
where to go at the moment. Maybe there is much lower hanging fruit, but
being the ntp newbie I am, I cannot see it. If I absolutely need more
ntpd stratum 2 servers in the network, I can maybe lobby to get some,
but any easier option is of course preferred (what about that broadcast
option again? does it only reduce load or also improve accuracy?)

Simple RTFM links appreciated as well.

Thank you very much!

Flo

[1] http://bowl.net.t-labs.tu-berlin.de/
[2] http://www.pamconf.net/2002/IPMP_IP_Measurement_Protocol.pdf
[3] http://www.gateworks.com/products/avila/datasheets/gw2348-4ds.pdf
[4] http://www.maxim-ic.com/datasheet/index.mvp/id/2750



More information about the questions mailing list