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 _______________________________________________ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
