Dan Drown

Beaglebone Black NTP/GPS server

Goals I wanted to experiment with using temperature measurement to augment a NTP stratum 1 server. I started with a very similiar setup to this one [https://web.archive.org/web/20131209092059/http://the8thlayerof.net/2013/12/08/adafruit-ultimate-gps-cape-creating-custom-beaglebone-black-device-tree-overlay-file/] . [Edit: the8thlayerof.net is gone, link changed to archive.org]. This

Stratum 2 NTP over a Cable Modem

Goals I have a Stratum 1 NTP server at home, and ideally I'd like to join the ntp pool as a server. The problem is, my home connection isn't up to this task. My IP is dynamic, there's an asymmetric latency built in, and

Measuring Asymmetric latency via NTP, part 3

Part 1 [https://blog.dan.drown.org/measuring-asymmetric-latency-via-ntp/], Part 2 [https://blog.dan.drown.org/measuring-asymmetric-latency-via-ntp-part-2/] Varying round trip times Asymmetric latency changes NTP's calculated clock offsets. What do the offsets look like when two clocks are in sync (or always within ~200us) and the latency varies? SMQ

Measuring Asymmetric latency via NTP, part 2

See the first part for the math [https://blog.dan.drown.org/measuring-asymmetric-latency-via-ntp/] Let's use a third party (stratum 2) observer to compare the stratum 1 NTP clocks. Round trip times First, a graph of the $rtt times from the third party to various stratum 1 NTP clocks.

Measuring Asymmetric latency via NTP

Goal Learn more about the latency characteristics of my cable connection. Starting point I have a stratum 1 NTP server at home. Below is a graph of its performance. The offset between the GPS clock and the server's clock is in red. The two clocks are within +/-

Time Warner 300/20 service

Before (50M/5M) After (300M/20M) Other notes DG1670A Firmware Version was updated from 8.0.89 to 8.0.120. SW_REV: 8.0.120.SIP.PC20.TW IPv6 $ iperf -f m -i 1 -V -c 2605:6000:x:x -r ------------------------------------------------------------ Server listening on TCP port 5001 TCP

New Time Warner router: Arris DG1670A

See also: Comparison of the Arris SB6183 vs Arris DG1670A [https://blog.dan.drown.org/sb6183-vs-dg1670a-latency/], and SB6183 dropping IPv6 traffic [https://blog.dan.drown.org/sb6183-dropping-ipv6-traffic/] As part of TWC's upgraded speeds (300M/20M coming in August), I needed a 16x4 channel DOCSIS 3.0 modem. Since

ARM router forwarding rates

The goal for this project is 300mbit/s forwarding with full size packets and nat enabled. There's problems with this hardware: see "Problems" section below. test setup Router hardware: Utilite Standard [http://utilite-computer.com/web/utilite-models] (note: see the Problems section) Network eth0 - "inside&

mosh/Android build VM

To Download the VM image: docker pull ddrown/mosh-build To build mosh binaries: OUTPUTDIR=~/target mkdir $OUTPUTDIR docker run -v $OUTPUTDIR:/target ddrown/mosh-build This will create 6 binaries in $OUTPUTDIR/bin: mosh-client.arm.nopie, mosh-client.arm.pie, mosh-client.x86.nopie, mosh-client.x86.pie, mosh-client.mips.nopie, and mosh-client.mips.

Busybox/Android build VM

I took the Android Cross Compile VM [https://blog.dan.drown.org/android-cross-compile-environment/] and created a docker VM image for just building busybox. To Download the VM image: docker pull ddrown/busybox-build To build busybox binaries: OUTPUTDIR=~/target mkdir $OUTPUTDIR docker run -v $OUTPUTDIR:/target ddrown/busybox-build This will create