[Thumbgps-devel] data collection

[Thumbgps-devel] data collection

[Dave Taht]

saw this (not related to the ntp project, but)..


http://theinstitute.ieee.org/technology-focus/technology-topic/new-tool-to-help-monitor-the-environment

and:

I was wondering how good the resolution was on the 'sharks with gps' app was?

But back to the network mapping front, one reason I'd chosen postgres
for a backend was the geography support, being able to calculate in
curves seemed like a good idea. I'm curious if anybody has other
thoughts for a backend to a global time slew database?

-- 
Dave Täht
SKYPE: davetaht
US Tel: 1-239-829-5608
http://www.bufferbloat.net

Re: [Thumbgps-devel] data collection

[tz]

One thing to note - a traceroute or something similar might be
necessary if we are measuring the network.
I'm down the street from Level 3, but use Comcast, and a Verizon mifi,
so packets are going to take different routes.
The GPS location is one thing, but a backbone map would also be
relevant if not required.

One thing which might help is if a major backbone vendor (cisco, arbor
networks) would adopt this technology into one of their high-end
switches.  They probably do something similar already to get somewhat
accurate time, but perhaps without the precision and they typically
aren't running stratum 1 servers on or a hop from the backbones which
might be the most interesting.

On Tue, Mar 13, 2012 at 10:55 AM, Dave Taht <dave.taht@gmail.com> wrote:
> But back to the network mapping front, one reason I'd chosen postgres
> for a backend was the geography support, being able to calculate in
> curves seemed like a good idea. I'm curious if anybody has other
> thoughts for a backend to a global time slew database?

Re: [Thumbgps-devel] data collection

[Dave Taht]

On Tue, Mar 13, 2012 at 3:21 PM, tz <thomas@mich.com> wrote:
> One thing to note - a traceroute or something similar might be
> necessary if we are measuring the network. ['s timekeeping ability]

I was planning on traceroutes between peers. One the projects I track
(and participated in until I got more busy 'fixing' the internet than
diagnosing it)
is projectbismark.net. Of late they've been adding diagnostic tools and a
test framework, in lua, that can run on this router,
they also have some interesting tools such as ditg and shaperprobe.

I haven't been paying close attention, but there have been quite
a few commits in their repositories of late.

https://github.com/bismark-devel

What I've been trying to do with cerowrt is establish a solid base for
edge network
exploration and experimentation, and I hope the upcoming release is going
to do that. After that stablizes I hope to be able to start layering the sorts
of tools we're discussing here, on top of it, and know to what extent the
results will be heisenbugged or not.

> I'm down the street from Level 3, but use Comcast, and a Verizon mifi,
> so packets are going to take different routes.

Heh. I recently (accidentally) introduced a equal cost multipath
situation on my testbed
in bloatlab #1...
except that of the two different paths, one had forwarding performance
of 260Mbit,
the other >800mbit. Was REALLY puzzling to figure that one out.

(basically IPv6 was doing equal cost multipath, IPv4 was not)

> The GPS location is one thing, but a backbone map would also be
> relevant if not required.

I liked the possible usage of the geoip database(s) combined with
postgres's geography extension, to try and get baseline values for
individual hops, vs reality, over time.

There are other network tomography tools of interest at CAIDA. Good
suggestions requested. I love visualizations like the ones from the
cybergeography project

http://personalpages.manchester.ac.uk/staff/m.dodge/cybergeography/atlas/geographic.html

http://www.wand.net.nz/scamper is of interest, I note that this
version of cerowrt has full iptables support for ecn over ipv6, and
that was one of the things that is thoroughly fixed in Linux-3.3 - or
so I hope - and works measurably better than non-ecn based AQM
methods. Steve Bauer over at MIT did a whole bunch of ECN tests last
year, I hope he (or someone) can build upon that work.

I'd looked hard at perfsonar only to note that it wasn't measuring
anything I cared about, and was based on an ancient kernel. I'd like
to look at it again to see what it isn't measuring, and to see what it
is mis-measuring.

And while I'm on the subject of visualisations, gource is just an
amazing way to look at commit logs....

 http://code.google.com/p/gource/wiki/Videos

showing projects evolve.

> One thing which might help is if a major backbone vendor (cisco, arbor
> networks) would adopt this technology into one of their high-end
> switches.  They probably do something similar already to get somewhat

I note that bufferbloat.net is co-located with isc.org, which is also
where ntp.org
is located... one of our servers is about  18 inches away from their rack.

> accurate time, but perhaps without the precision and they typically
> aren't running stratum 1 servers on or a hop from the backbones which
> might be the most interesting.

I would certainly like to see time made more accurate world wide.

>
> On Tue, Mar 13, 2012 at 10:55 AM, Dave Taht <dave.taht@gmail.com> wrote:
>> But back to the network mapping front, one reason I'd chosen postgres
>> for a backend was the geography support, being able to calculate in
>> curves seemed like a good idea. I'm curious if anybody has other
>> thoughts for a backend to a global time slew database?



-- 
Dave Täht
SKYPE: davetaht
US Tel: 1-239-829-5608
http://www.bufferbloat.net