Preliminary results of using GPS to look for clock skew

Preliminary results of using GPS to look for clock skew

[Eric Raymond]

As a step toward implementation of Dave's Cosmic Background
Bufferbloat Detector, I took on the job of employing GPS as a reliable
local time source to check whether an NTP-assisted system clock has
significant skew from GPS.

Towards this end, I've just spent a couple of days rebuilding and 
improving the latency-profiling machinery in GPSD.  What this allows
me to do is collate the following pieces of data:

* The GPS's time of a fix in properly leapsecond-corrected UTC (Call this T)

* The NTP-corrected system time at which the first burst of
  fix data from the device wakes up gpsd's select(2).  Call this
  S (Start of reporting cycle) 

* When the daemon has received and processed the entire burst of packets
  constituting a reporting cycle and is about to ship JSON to the client. 
  Call this E (End of reporting cycle).
  
* When the client recieves the report.  (R = receipt time).

What's interesting is to plot the deltas S - T, E - S, and R - S as a 
stacked-impulse graph.  I can do this at will now.  More importantly,
so can anyone with my software and GPSD.  We have a working GPSD port to
CeroWRT, so our test routers can be instrumented.

The entire height R-T approximates the entire fix latency. I say 
"approximates" because, of course, T is on a different timebase than
R, S, and E, and NTP's 10ms fuzz is an issue.  But S-T gives us an
idea of the atomic-clock-vs-system-clock time.

There's nothing surprising about my setup - FIOS to an N600 running a
recent OpenWRT build to a 2.66GHz Intel Core Duo 2 machine running Ubuntu
10.04 LTS. 

Over runs of 20-100 fixes, S-T (the clock-skew figure) ranges from 66
to 76 milliseconds.  Total latency R-T is steady at about 0.38
seconds.  R-S vanishes - it's close to 0.9 milliseconds.  Total fix
latency is completely dominated by E-S, the time for gpsd to receive
and process the fix data from the GPS.  And I'm not seeing a lot of
bursty variation in these measurements.

I'm going to investigate further.  In particular, I'm going to try to
either measure or compute how much of E-S is I/O time.  My suspicion is that 
almost all of it is, and that gpsd's actual computation time is negligible
by comparison.

But preliminary indications are that NTP is in fact doing a pretty good
job of keeping my system clock conditioned. I'm not seeing bufferbloat
effects on time service.

However, I'd welcome having my code and assumptions checked. This kind
of profiling is tricky work, with large vulnerabilities to small
mistakes in detail. That's the main reason I'm describing these
results as 'preliminary'; some skeptical review is needed to soliudify
and verify them.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Let us hope our weapons are never needed --but do not forget what 
the common people knew when they demanded the Bill of Rights: An 
armed citizenry is the first defense, the best defense, and the 
final defense against tyranny.
   If guns are outlawed, only the government will have guns. Only 
the police, the secret police, the military, the hired servants of 
our rulers.  Only the government -- and a few outlaws.  I intend to 
be among the outlaws.
        -- Edward Abbey, "Abbey's Road", 1979

Re: Preliminary results of using GPS to look for clock skew

[Dave Taht]

Eric:

It is comforting to know that ntp is working well in your case, and, using GPS,
we have a verifiable means with decent error bars of checking against
ntp's algos independently!

Two ideas here:

1) Run the router WITHOUT ntp enabled at all
   (and/or testing against CLOCK_REALTIME)
   It would be good to know how much the base clock drift is, without
correction.

2) ReRun all tests under load (example: netperf -l 3600 -H the_router)

The followon test to this is to actually start collecting and parsing
ntp rawstats statistics, which can be easily turned on and collected
on the router. It's getting-those-stats-somewhere coupled with the
need to periodically delete these statistic files that's a problem at
the moment, and really only the former...

The bufferbloat signal (if it exists) is in the noise that ntp is
currently (successfully in your case) rejecting.

There are a couple rawstats parsers floating about, I have part of
one, hal has another. I committed a major overdesign
sin in mine by wanting to put it all into a postgres db, ran into
major data representation problems (time on postgres is different than
time inside of ntp), and put the work aside (it's on github in the
same pieces I left it in)

To enable rawstats collection on the router, modify /etc/ntp.conf to contain:

statsdir /tmp
statistics rawstats
filegen rawstats file rawstats type day enable

and restart ntp

on a system protected by apparmor - like ubuntu - it's mildly trickier
as you need to add
a

whereverthelogdiris/rawstats* rwl

to the /etc/apparmor.d/usr.sbin.ntpd

The final bit of the cbbd is to actually collect port numbers - so
stuff on ephemeral ports is known to be from
natted devices and stuff on 123

but I'm getting way ahead of myself here.


On Wed, Sep 21, 2011 at 4:02 PM, Eric Raymond <esr@snark.thyrsus.com> wrote:
> As a step toward implementation of Dave's Cosmic Background
> Bufferbloat Detector, I took on the job of employing GPS as a reliable
> local time source to check whether an NTP-assisted system clock has
> significant skew from GPS.
>
> Towards this end, I've just spent a couple of days rebuilding and
> improving the latency-profiling machinery in GPSD.  What this allows
> me to do is collate the following pieces of data:
>
> * The GPS's time of a fix in properly leapsecond-corrected UTC (Call this T)
>
> * The NTP-corrected system time at which the first burst of
>  fix data from the device wakes up gpsd's select(2).  Call this
>  S (Start of reporting cycle)
>
> * When the daemon has received and processed the entire burst of packets
>  constituting a reporting cycle and is about to ship JSON to the client.
>  Call this E (End of reporting cycle).
>
> * When the client recieves the report.  (R = receipt time).
>
> What's interesting is to plot the deltas S - T, E - S, and R - S as a
> stacked-impulse graph.  I can do this at will now.  More importantly,
> so can anyone with my software and GPSD.  We have a working GPSD port to
> CeroWRT, so our test routers can be instrumented.
>
> The entire height R-T approximates the entire fix latency. I say
> "approximates" because, of course, T is on a different timebase than
> R, S, and E, and NTP's 10ms fuzz is an issue.  But S-T gives us an
> idea of the atomic-clock-vs-system-clock time.
>
> There's nothing surprising about my setup - FIOS to an N600 running a
> recent OpenWRT build to a 2.66GHz Intel Core Duo 2 machine running Ubuntu
> 10.04 LTS.
>
> Over runs of 20-100 fixes, S-T (the clock-skew figure) ranges from 66
> to 76 milliseconds.  Total latency R-T is steady at about 0.38
> seconds.  R-S vanishes - it's close to 0.9 milliseconds.  Total fix
> latency is completely dominated by E-S, the time for gpsd to receive
> and process the fix data from the GPS.  And I'm not seeing a lot of
> bursty variation in these measurements.
>
> I'm going to investigate further.  In particular, I'm going to try to
> either measure or compute how much of E-S is I/O time.  My suspicion is that
> almost all of it is, and that gpsd's actual computation time is negligible
> by comparison.
>
> But preliminary indications are that NTP is in fact doing a pretty good
> job of keeping my system clock conditioned. I'm not seeing bufferbloat
> effects on time service.
>
> However, I'd welcome having my code and assumptions checked. This kind
> of profiling is tricky work, with large vulnerabilities to small
> mistakes in detail. That's the main reason I'm describing these
> results as 'preliminary'; some skeptical review is needed to soliudify
> and verify them.
> --
>                <a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
>
> Let us hope our weapons are never needed --but do not forget what
> the common people knew when they demanded the Bill of Rights: An
> armed citizenry is the first defense, the best defense, and the
> final defense against tyranny.
>   If guns are outlawed, only the government will have guns. Only
> the police, the secret police, the military, the hired servants of
> our rulers.  Only the government -- and a few outlaws.  I intend to
> be among the outlaws.
>        -- Edward Abbey, "Abbey's Road", 1979
>



-- 
Dave Täht
SKYPE: davetaht
US Tel: 1-239-829-5608
http://the-edge.blogspot.com

Re: Preliminary results of using GPS to look for clock skew

[Eric Raymond]

Dave Taht <dave.taht@gmail.com>:
> It is comforting to know that ntp is working well in your case, and, using
> GPS, we have a verifiable means with decent error bars of checking against
> ntp's algos independently!

Yup.  It'll get better as I refine my profiling and gain more insight
into the numbers.  My next task is to compute a lower bound for RS-232
transmission time and subtract that from E-S so we know how much of the
dominant component in fix latency is processing time.

Er, for other bloat-dev members: I should have said up front that I've
volunteered to be the bufferbloat project's go-to guy on reliable time
sources for network performance profiling.  This is a completely
natural extension of the work I've been doing on GPSD since 2005.  GPS
gives us atomic-clock time with $40 hardware (provided we're below 60
drgress N or S latitude and can string an antenna somewhere with a
decent skyview).  I know almost everything there is to know about
extracting data from these sensors, and what I don't know my two senior
lieutenants on the GPSD project *do* know.

> Two ideas here:
> 
> 1) Run the router WITHOUT ntp enabled at all
>    (and/or testing against CLOCK_REALTIME)
>    It would be good to know how much the base clock drift is, without
> correction.

One of the things I don't know, and need to understand, is what the
relationships are among the different realtime clocks. The clock_gettime(3)
manual page is not hugely helpful.  It says:

       CLOCK_REALTIME
              System-wide real-time clock.  Setting this clock requires appro‐
              priate privileges.

       CLOCK_MONOTONIC
              Clock  that  cannot  be  set and represents monotonic time since
              some unspecified starting point.

       CLOCK_MONOTONIC_RAW (since Linux 2.6.28; Linux-specific)
              Similar to CLOCK_MONOTONIC, but provides access to a  raw  hard‐
              ware-based time that is not subject to NTP adjustments.

       CLOCK_PROCESS_CPUTIME_ID
              High-resolution per-process timer from the CPU.

       CLOCK_THREAD_CPUTIME_ID
              Thread-specific CPU-time clock.

Er, so what exactly is the relationship between the CLOCK_REALTIME clock
and the time(2) clock?  Are they the same?  If they're different, how 
are they different?

It says the CLOCK_MONOTONIC clock isn't settable, but the CLOCK_MONOTONIC_RAW
text implies that the former may get NTP adjustments.  And it doesn.t specify
whether the per-process timers are NTP-corrected...I'd guess not, but who's 
to know from the above.

Can anyone point me to better documentation on these facilities?

> 2) ReRun all tests under load (example: netperf -l 3600 -H the_router)

I'll do this, for completeness, but I predict it's not going to make
any measurable difference.  The indications so far are that neither of
the means of time delivery I have available to check are compute-bound
or disk-I/O bound at any point in their delivery chains.  

So I think they're just going to shrug off any load short of
machine-thrashing-its-guts-out.  But part of the point of what I'm
doing is that soon we'll have the test tools to know for *sure* that's
true.

> The followon test to this is to actually start collecting and parsing
> ntp rawstats statistics, which can be easily turned on and collected
> on the router. It's getting-those-stats-somewhere coupled with the
> need to periodically delete these statistic files that's a problem at
> the moment, and really only the former...
> 
> The bufferbloat signal (if it exists) is in the noise that ntp is
> currently (successfully in your case) rejecting.
> 
> There are a couple rawstats parsers floating about, I have part of
> one, hal has another. I committed a major overdesign
> sin in mine by wanting to put it all into a postgres db, ran into
> major data representation problems (time on postgres is different than
> time inside of ntp), and put the work aside (it's on github in the
> same pieces I left it in)
> 
> To enable rawstats collection on the router, modify /etc/ntp.conf to contain:
> 
> statsdir /tmp
> statistics rawstats
> filegen rawstats file rawstats type day enable
> 
> and restart ntp
> 
> on a system protected by apparmor - like ubuntu - it's mildly trickier
> as you need to add
> a
> 
> whereverthelogdiris/rawstats* rwl
> 
> to the /etc/apparmor.d/usr.sbin.ntpd
> 
> The final bit of the cbbd is to actually collect port numbers - so
> stuff on ephemeral ports is known to be from
> natted devices and stuff on 123
> 
> but I'm getting way ahead of myself here.

Agreed.  I also think you're complicating life unnecessarily. 

If we need rawstats in a form for real-time monitoring, why not modify
NTP to optionally multicast them and avoid all this going to disk?  I
have good relations with the NTP guys, and they wouldn't be likely to
resist a feature request with a network-health-monitoring use case
even if we didn't. Let's *use* that zorch for something, rather than
fielding a fragile pile of hacks.


-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: Preliminary results of using GPS to look for clock skew

[Jonathan Morton]

On 22 Sep, 2011, at 5:11 am, Eric Raymond wrote:

>> 2) ReRun all tests under load (example: netperf -l 3600 -H the_router)
> 
> I'll do this, for completeness, but I predict it's not going to make
> any measurable difference.  The indications so far are that neither of
> the means of time delivery I have available to check are compute-bound
> or disk-I/O bound at any point in their delivery chains.  
> 
> So I think they're just going to shrug off any load short of
> machine-thrashing-its-guts-out.  But part of the point of what I'm
> doing is that soon we'll have the test tools to know for *sure* that's
> true.

When the *network* is loaded, the latency to the NTP server changes.  That is likely to confuse ntpd - it certainly did when I lived on an analogue modem.

 - Jonathan Morton

Re: Preliminary results of using GPS to look for clock skew

[Eric Raymond]

Jonathan Morton <chromatix99@gmail.com>:
> When the *network* is loaded, the latency to the NTP server changes.
> That is likely to confuse ntpd - it certainly did when I lived on an
> analogue modem.

Ah.  Yes, that's plausible.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: Preliminary results of using GPS to look for clock skew

[Jan Ceuleers]

On 09/22/2011 04:24 AM, Jonathan Morton wrote:
> When the *network* is loaded, the latency to the NTP server changes. 
> That is likely to confuse ntpd - it certainly did when I lived on an 
> analogue modem.
Look at the huff'n'puff filter for how ntpd addresses this concern.

http://www.eecis.udel.edu/~mills/ntp/html/huffpuff.html

Jan

Re: Preliminary results of using GPS to look for clock skew

[Dave Taht]

On Fri, Sep 23, 2011 at 2:09 AM, Jan Ceuleers <jan.ceuleers@gmail.com> wrote:
> On 09/22/2011 04:24 AM, Jonathan Morton wrote:
>>
>> When the *network* is loaded, the latency to the NTP server changes. That
>> is likely to confuse ntpd - it certainly did when I lived on an analogue
>> modem.
>
> Look at the huff'n'puff filter for how ntpd addresses this concern.
>
> http://www.eecis.udel.edu/~mills/ntp/html/huffpuff.html

In the case of the cosmic background bufferbloat detector idea, I'm
interested in collecting the data
that ntp is currently *filtering away* as a means to measure various
delays across a wide base of machines,
thus collecting rawstats on the client seems like the best approach.
The point is not to derive accurate time
from multiple, possibly badly varying, data sources, but to see how
badly varying the data sources are!

It would be best to be doing so passively, however, at the server, and
I've been toying with the idea of
creating a new ntp message type to do so. With clients often behind
nat there is no good way to
supply what a ntp host thinks is the current time to a data collecting
server elsewhere.

The huff n puff filter is a great idea, however I note it relies on
ntp running for a long time, and many (most?)
clients restart ntp on every interface change (example, a dhcp
refresh, or wakeup from suspend)

Secondly, adding the refclock with noselect keyword seems like a
useful means of comparison.

Thirdly - as much as I would like to get a PPS signal, that seems
impossible with the hardware we are
currently playing with. That said, delays/variations of 10ms are not a
real problem as the bufferbloat signal
can often be measured in close order of seconds.

>
> Jan
> _______________________________________________
> Bloat-devel mailing list
> Bloat-devel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat-devel
>



-- 
Dave Täht
SKYPE: davetaht
US Tel: 1-239-829-5608
http://the-edge.blogspot.com

Re: Preliminary results of using GPS to look for clock skew

[Jan Ceuleers]

On 09/23/2011 11:38 AM, Dave Taht wrote:
> Thirdly - as much as I would like to get a PPS signal, that seems
> impossible with the hardware we are
> currently playing with. That said, delays/variations of 10ms are not a
> real problem as the bufferbloat signal
> can often be measured in close order of seconds.
>
The cheapest GPS timing receiver, which includes a PPS signal, that I am 
aware of is the Garmin GPS18LVC. It requires soldering to a serial port 
connector, and also needs a +5VDC power source such as can be obtained 
from a USB port, but it is a very capable device.

Note that it needs to be the LVC variant - other variants of the GPS18 
lack the PPS signal.

Re: Preliminary results of using GPS to look for clock skew

[Rick]

On Fri, Sep 23, 2011 at 8:10 AM, Jan Ceuleers <jan.ceuleers@gmail.com> wrote:
> On 09/23/2011 11:38 AM, Dave Taht wrote:
> The cheapest GPS timing receiver, which includes a PPS signal, that I am
> aware of is the Garmin GPS18LVC. It requires soldering to a serial port
> connector, and also needs a +5VDC power source such as can be obtained from
> a USB port, but it is a very capable device.
>
> Note that it needs to be the LVC variant - other variants of the GPS18 lack
> the PPS signal.

A very nice HOWTO using that part: http://time.qnan.org/

-- 
Religion is regarded by the common people as true,
by the wise as false,
and by the rulers as useful.

— Lucius Annæus Seneca.

Terrorism, the new religion.

Re: Preliminary results of using GPS to look for clock skew

[Jan Ceuleers]

On 09/23/2011 02:50 PM, Rick wrote:
> A very nice HOWTO using that part: http://time.qnan.org/
>
Overkill, I think. No need for a breadboard nor a fuse. USB ports are 
power-limited already.

Re: Preliminary results of using GPS to look for clock skew

[Dave Taht]

On Wed, Sep 21, 2011 at 7:11 PM, Eric Raymond <esr@thyrsus.com> wrote:
> Dave Taht <dave.taht@gmail.com>:

>> 1) Run the router WITHOUT ntp enabled at all
>>    (and/or testing against CLOCK_REALTIME)
>>    It would be good to know how much the base clock drift is, without
>> correction.
>

My bad. I meant to say CLOCK_MONOTONIC

> One of the things I don't know, and need to understand, is what the
> relationships are among the different realtime clocks. The clock_gettime(3)
> manual page is not hugely helpful.  It says:
>
>       CLOCK_REALTIME
>              System-wide real-time clock.  Setting this clock requires appro‐
>              priate privileges.
>
>       CLOCK_MONOTONIC
>              Clock  that  cannot  be  set and represents monotonic time since
>              some unspecified starting point.
>
>       CLOCK_MONOTONIC_RAW (since Linux 2.6.28; Linux-specific)
>              Similar to CLOCK_MONOTONIC, but provides access to a  raw  hard‐
>              ware-based time that is not subject to NTP adjustments.
>
>       CLOCK_PROCESS_CPUTIME_ID
>              High-resolution per-process timer from the CPU.
>
>       CLOCK_THREAD_CPUTIME_ID
>              Thread-specific CPU-time clock.
>
> Er, so what exactly is the relationship between the CLOCK_REALTIME clock
> and the time(2) clock?  Are they the same?  If they're different, how
> are they different?
>
> It says the CLOCK_MONOTONIC clock isn't settable, but the CLOCK_MONOTONIC_RAW
> text implies that the former may get NTP adjustments.  And it doesn.t specify
> whether the per-process timers are NTP-corrected...I'd guess not, but who's
> to know from the above.
>
> Can anyone point me to better documentation on these facilities?
>
>> 2) ReRun all tests under load (example: netperf -l 3600 -H the_router)
>
> I'll do this, for completeness, but I predict it's not going to make
> any measurable difference.  The indications so far are that neither of
> the means of time delivery I have available to check are compute-bound
> or disk-I/O bound at any point in their delivery chains.
>
> So I think they're just going to shrug off any load short of
> machine-thrashing-its-guts-out.  But part of the point of what I'm
> doing is that soon we'll have the test tools to know for *sure* that's
> true.

One thing that surprised me of late is http://www.bufferbloat.net/issues/271

while not related, surprises are the last thing we need as regards to time.

-- 
Dave Täht
SKYPE: davetaht
US Tel: 1-239-829-5608
http://the-edge.blogspot.com

Re: Preliminary results of using GPS to look for clock skew

[Rick Jones]

>
> One thing that surprised me of late is http://www.bufferbloat.net/issues/271
>
> while not related, surprises are the last thing we need as regards to time.
>

The decision to stop letting networking contribute to entropy goes back 
a few years actually :)

In another context, also where running-out of entropy was a problem, 
someone mentioned there are RNGs on USB keys that can be used to provide 
randomness/entropy/whatnot.  The one mentioned in that discussion was 
the "Entropy Key" from these folks: http://www.entropykey.co.uk/

rick jones

Re: Preliminary results of using GPS to look for clock skew

[Dave Taht]

On Thu, Sep 22, 2011 at 10:15 AM, Rick Jones <rick.jones2@hp.com> wrote:
>
>>
>> One thing that surprised me of late is
>> http://www.bufferbloat.net/issues/271
>>
>> while not related, surprises are the last thing we need as regards to
>> time.
>>
>
> The decision to stop letting networking contribute to entropy goes back a
> few years actually :)

I wasn't paying attention then.

> In another context, also where running-out of entropy was a problem, someone
> mentioned there are RNGs on USB keys that can be used to provide
> randomness/entropy/whatnot.  The one mentioned in that discussion was the
> "Entropy Key" from these folks: http://www.entropykey.co.uk/

While I would like RNGs to be on-chip, the lack of randomness in a system
that supposedly does a lot of WPA encryption does concern me.

https://dev.openwrt.org/ticket/9631

Secondly, routers at least have multiple interfaces to get randomness from
which would be hard to spoof all at the same time.

and wireless routers have more noise sources and interfaces...

so while I find the decision to eliminate networking as a source of randomness
makes some sense in a device with only one interface, I find it indefensible to
have nearly no entropy pool at all as a result for devices with
multiple interfaces.


> rick jones
>



-- 
Dave Täht
SKYPE: davetaht
US Tel: 1-239-829-5608
http://the-edge.blogspot.com

Re: Preliminary results of using GPS to look for clock skew

[Rick Jones]

On 09/22/2011 10:34 AM, Dave Taht wrote:
> On Thu, Sep 22, 2011 at 10:15 AM, Rick Jones<rick.jones2@hp.com>  wrote:
>>
>>>
>>> One thing that surprised me of late is
>>> http://www.bufferbloat.net/issues/271
>>>
>>> while not related, surprises are the last thing we need as regards to
>>> time.
>>>
>>
>> The decision to stop letting networking contribute to entropy goes back a
>> few years actually :)
>
> I wasn't paying attention then.
>
>> In another context, also where running-out of entropy was a problem, someone
>> mentioned there are RNGs on USB keys that can be used to provide
>> randomness/entropy/whatnot.  The one mentioned in that discussion was the
>> "Entropy Key" from these folks: http://www.entropykey.co.uk/
>
> While I would like RNGs to be on-chip, the lack of randomness in a system
> that supposedly does a lot of WPA encryption does concern me.
>
> https://dev.openwrt.org/ticket/9631
>
> Secondly, routers at least have multiple interfaces to get randomness from
> which would be hard to spoof all at the same time.
>
> and wireless routers have more noise sources and interfaces...
>
> so while I find the decision to eliminate networking as a source of randomness
> makes some sense in a device with only one interface, I find it indefensible to
> have nearly no entropy pool at all as a result for devices with
> multiple interfaces.

I don't necessarily disagree, but there were a number of reasons given, 
many of which I believe are/were independent of the number of interfaces 
in the host.  I believe at least some of it can be found at 
http://lkml.indiana.edu/hypermail/linux/kernel/0805.3/0370.html  though 
I don't think it has the thread all the way back to its beginning.

rick

Re: Preliminary results of using GPS to look for clock skew

[Dave Taht]

On Thu, Sep 22, 2011 at 10:43 AM, Rick Jones <rick.jones2@hp.com> wrote:
> On 09/22/2011 10:34 AM, Dave Taht wrote:
>>
>> On Thu, Sep 22, 2011 at 10:15 AM, Rick Jones<rick.jones2@hp.com>  wrote:
>>>
>>>>
>>>> One thing that surprised me of late is
>>>> http://www.bufferbloat.net/issues/271
>>>>
>>>> while not related, surprises are the last thing we need as regards to
>>>> time.
>>>>
>>>
>>> The decision to stop letting networking contribute to entropy goes back a
>>> few years actually :)
>>
>> I wasn't paying attention then.
>>
>>> In another context, also where running-out of entropy was a problem,
>>> someone
>>> mentioned there are RNGs on USB keys that can be used to provide
>>> randomness/entropy/whatnot.  The one mentioned in that discussion was the
>>> "Entropy Key" from these folks: http://www.entropykey.co.uk/
>>
>> While I would like RNGs to be on-chip, the lack of randomness in a system
>> that supposedly does a lot of WPA encryption does concern me.
>>
>> https://dev.openwrt.org/ticket/9631
>>
>> Secondly, routers at least have multiple interfaces to get randomness from
>> which would be hard to spoof all at the same time.
>>
>> and wireless routers have more noise sources and interfaces...
>>
>> so while I find the decision to eliminate networking as a source of
>> randomness
>> makes some sense in a device with only one interface, I find it
>> indefensible to
>> have nearly no entropy pool at all as a result for devices with
>> multiple interfaces.
>
> I don't necessarily disagree, but there were a number of reasons given, many
> of which I believe are/were independent of the number of interfaces in the
> host.  I believe at least some of it can be found at
> http://lkml.indiana.edu/hypermail/linux/kernel/0805.3/0370.html  though I
> don't think it has the thread all the way back to its beginning.

These guys are on drugs, and it doesn't look like my point about multiple
interfaces was raised...

http://lkml.indiana.edu/hypermail/linux/kernel/0805.3/0383.html

"Nearby microwave ovens will add periodicy to the arrival of WLAN data."

Yep, that's your typical attacker, hauling a microwave oven around to
help me crack WPA...

What I want to know is how bad the decline in quality of urandom is
without random sources....


> rick
>



-- 
Dave Täht
SKYPE: davetaht
US Tel: 1-239-829-5608
http://the-edge.blogspot.com

Re: Preliminary results of using GPS to look for clock skew

[Aidan Williams]

On 23/09/2011 3:34 AM, Dave Taht wrote:
> Secondly, routers at least have multiple interfaces to get randomness from
> which would be hard to spoof all at the same time.
>
> and wireless routers have more noise sources and interfaces...

Wireless devices also have access to random processes unique to the 
wireless medium.  Things like or RSSI, or perhaps some other low level 
radio related parameters related to fading probably generate a fair 
amount of entropy.  Would that be usable?

Use of WPA would go hand in hand with using the wireless interface.. 
thus generating randomness.  ;-)

- aidan

Re: Preliminary results of using GPS to look for clock skew

[Dave Taht]

On Wed, Sep 21, 2011 at 7:11 PM, Eric Raymond <esr@thyrsus.com> wrote:

> If we need rawstats in a form for real-time monitoring, why not modify
> NTP to optionally multicast them and avoid all this going to disk?

I have been collecting rawstats statistics for some time now on ntp
server currently dedicated to prototyping this stuff. 5 ntp servers comes
to about 45K/day - and /tmp is a ramdisk on the router, which has about
32MB to spare most of the time. So a plan - not the best one - was
to upload the latest rawstats file every day and delete 2 day old entries
in cron.

> I
> have good relations with the NTP guys, and they wouldn't be likely to
> resist a feature request with a network-health-monitoring use case
> even if we didn't. Let's *use* that zorch for something, rather than
> fielding a fragile pile of hacks.

I would like very much like to not field a fragile pile of hacks but
the ntp people  I've talked to reflexively (and rightly) seem focused
on means to get good time, come hell or high water, rather than
collecting and analyzing the outlier data as to why bad data is
arriving.

That said, adding a data message of some sort to propagate
rawstats-like data to a given server configured to receive it would be
nice.

2) Also on my list is to get ntp doing the right thing in the case of
dnssec enabled startup without valid time. There is a

Multiple means to do this have been described here:

http://www.bufferbloat.net/issues/113
http://www.bufferbloat.net/issues/205

I guess this somewhat separate convo should move to the ntp list.

I'd taken a look at the ntp codebase and it was convoluted enough to
make me wish someone familiar with the ntp codebase would tackle the
dnssec problem - when ntp is started with -g, to get the initial time
with dnssec validation disabled, then revalidate the dns entries after
the clock is slewed.

Regrettably I think the best long term solution to the dnssec problem
that there should be a flag to getaddrinfo in the libc as described
here:

http://www.bufferbloat.net/issues/224

in use to tell it not to validate dns, as it's only a single bit, darn
it!!, but that implies a whole standardization process, and hacking
the libcs etc, etc....

It just seems too heavyweight to add a dependency on libval for ntp
for a single bit...

to bring this back to getting time via gps somewhat, it takes a long
time to get a lock from a gps signal to set the clock, too...

I've had chicago's "does anybody really know what time it is" stuck in
my head for weeks now.

>
>
> --
>                <a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
>



-- 
Dave Täht
SKYPE: davetaht
US Tel: 1-239-829-5608
http://the-edge.blogspot.com

Re: Preliminary results of using GPS to look for clock skew

[Jan Ceuleers]

On 09/22/2011 02:18 AM, Dave Taht wrote:
> Two ideas here:
>
> 1) Run the router WITHOUT ntp enabled at all
>     (and/or testing against CLOCK_REALTIME)
>     It would be good to know how much the base clock drift is, without
> correction.

Note that ntpd has infrastructure for measuring the drift: use the 
driftfile setting in the config file and ntpd will periodically write 
the drift in ms to it.

Jan

Re: Preliminary results of using GPS to look for clock skew

[Jan Ceuleers]

Eric,

Can I suggest another method for your comparisons of GPS time to ntp (or 
rather network) time?

The whole purpose of ntpd is to compare multiple sources of time, 
whether local refclocks such as a GPS receiver or remote-ones. In fact, 
when acquiring a new refclock and before pressing it into service it is 
necessary to calibrate the offset between its PPS signal (as seen by the 
ntpd process, and therefore incorporating the propagation delay in the 
cable, in the receiver circuit and the processing delay in the OS) and 
the true UTC second.

This is done by adding the new refclock to the ntpd config file, but by 
also telling ntpd to distrust it (using the noselect keyword). You can 
then leverage all of ntpd's stats for comparing the refclock to all 
other available time sources.

More info at www.ntp.org.

HTH, Jan