Re: [time-nuts] wifi with time sync

[Chuck Harris]

If there is a modern microwave oven with a switching power supply,
or a cordless telephone around, you might want to look there.

The old linear supply ovens were easy to deal with because they
presented a strong CW signal that drifted around as voltage, load,
and temperature changed.  The switcher ovens simply splatter the
whole ISM band with strong microwave noise.

-Chuck Harris

Bob Camp wrote:
> Hi
> 
> It just so happens that I’m trying to track down an issue with my WiFi as
> I type this. My *guess* is that there is a dropout going on. The only easy
> way I can see to get a round trip time with a high data rate is to run ping. 
> It’s the only tool that gives me something that is fast enough to spot issues.
> Is it perfect? certainly not. Is it an upper bound that is also likely the 
> limit
> for things like NTP - in my experience it sure is. That of course assumes 
> the gizmo that sends the pings back does so quickly and consistently. I’ve
> spent enough time testing that side of it that I’m quite sure it’s true in 
> this case.
> 
> Bob
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] wifi with time sync

[Chris Albertson]

On Fri, Jan 13, 2017 at 1:11 PM, Bob Camp  wrote:

> Hi
>
> Ok. so I bring up NTP on the laptop against a server on the other side of
> the country and install
> NTP on the laptop. I get all of the jitter and offset of my cable modem
> plus the network
> issues between here and who know where. If I want to know the specific
> delay issues just
> on the WiFi connection (like when it rotates keys), how do I separate that
> out?
>

Run an NTP server on your local network with a wired connection to the
router.Also in many cases the router itself can run NTP.

If you are looking for smaller delays than NTP's level of uncertainty which
is going to be some tens of milliseconds then you need a hardware back
channel.  What I would do in that case is get s GPS with one pulse per
second output and feed that to BOTH the laptop and the wired NTP server.
Both servers will eventually sync to the 1PPS and have clocks running at
some tens of microseconds from each other.   With clocks on both computers
sync's to that level you can trust time stamped log files.  But this
requires a source of the 1PPS and some custom cables.   If tens of
milliseconds is OK (that is 1,000 times worse) then software and one
Ethernet cable are enough

In short the best way is to have all the internal clocks of the computers
running UTC to some very close tolerance then when something happens you
log it and later process logs

Another idea;   Connect the laptop to an NTP server with 100BaseT cable and
set up NTP to look ONLY over that interface.  Then bring up wifi for all
other uses.   The time sync will be maintained at millisecond level over
Ethernet then do your WiFi experiments.   The 1PPS a couple orders of
magnitude better but more work too.

Actually your initial comment is right, you be measuring the uncertainty in
the WiFi delay added to the uncertainty in the Internet connection.  But he
local WiFi would be 10x worse (at least) and dominate.  If you used 5 or 7
NTP servers then NTP can figure out the uncertainty over the Internet by
comparing a large number of them and the effects of the local WiFi  account
for most of it.

All that said, you can buy a good enough GPS receiver on eBay for about $10
now.   One trouble is getting that 1PPS signal into a laptop that lacks a
serial port.  Using a USB dongle serieould degrades the timing accuracy.
But still the BEST way to distribute time sync is via a hardware 1PPS
network.  I use old RG58 coax salvaged from an old Ethernet to distribute
1PPS.The source of error is in the nanosecond range and mostly comes
from speed of light delays in the wire and not measuring the wire correctly
or not accounting for velocity factor correctly or noise.   But even so NTP
using a 1PPS  reference clock is going to keep the computer's system clock
accurate at close to the level off the system clock's resolution


>
> Bob
>
> > On Jan 13, 2017, at 3:45 PM, Chris Albertson 
> wrote:
> >
> > Short answer:  See man page for ntpq
> >
> > Longer...
> >
> > First run NTP then after some time (15 minute to an hour) at the command
> > line time type "ntpq -p"
> >
> > "ntpq" will query NTP for timing statistics.  It will report the average
> > delay between the local computer and the set of reference clocks (other
> > servers) that NTP is connected to.  Along with the average delay you get
> > variation in that delay (std dev?)Note the if NTP can calculate the
> > delay, it has already compensated for it.   It is only the uncertainty of
> > the compensation that matters, hence the need to report the variation.
> >
> > The data shows the total delay and variation over the network and the
> > reference clocks might be thousands of miles away.  So you might want to
> > run one on say your wifi router or a local computer with hardwire
> > connection to the router then you'd see the effect of only your wifi.
> >
> >
> >
> > On Fri, Jan 13, 2017 at 12:35 PM, Bob Camp  wrote:
> >
> >> Hi
> >>
> >> What standard protocol would you recommend I run from the command line
> on
> >> my computer
> >> to get a quick estimate of the timing lag and variablilty  on my
> >> particular WiFi connection?
> >>
> >> Bob
> >>
> >>> On Jan 13, 2017, at 3:25 PM, John Hawkinson  wrote:
> >>>
> >>> Can we please stop talking about pings?
> >>>
> >>> Bob Camp  wrote on Fri, 13 Jan 2017
> >>> at 15:12:38 -0500 in :
> >>>
>  I’m sure you are right about the response time. Right now the
>  variation is running almost 3 ms at one sigma on a ping so there is
>  a lot to do simply to get the accuracy anywhere near 1 us.
> >>>
> >>
> >> ___
> >> time-nuts mailing list -- time-nuts@febo.com
> >> To unsubscribe, go to https://www.febo.com/cgi-bin/
> >> mailman/listinfo/time-nuts
> >> and follow the instructions there.
> >>
> >
> >
> >
> > --
> >
> > 

Re: [time-nuts] wifi with time sync

[shouldbe q931]

On Fri, Jan 13, 2017 at 8:45 PM, Chris Albertson
 wrote:
> Short answer:  See man page for ntpq
>
> Longer...
>
> First run NTP then after some time (15 minute to an hour) at the command
> line time type "ntpq -p"
>
> "ntpq" will query NTP for timing statistics.  It will report the average
> delay between the local computer and the set of reference clocks (other
> servers) that NTP is connected to.  Along with the average delay you get
> variation in that delay (std dev?)Note the if NTP can calculate the
> delay, it has already compensated for it.   It is only the uncertainty of
> the compensation that matters, hence the need to report the variation.
>
> The data shows the total delay and variation over the network and the
> reference clocks might be thousands of miles away.  So you might want to
> run one on say your wifi router or a local computer with hardwire
> connection to the router then you'd see the effect of only your wifi.
>
>
>
> On Fri, Jan 13, 2017 at 12:35 PM, Bob Camp  wrote:
>
>> Hi
>>
>> What standard protocol would you recommend I run from the command line on
>> my computer
>> to get a quick estimate of the timing lag and variablilty  on my
>> particular WiFi connection?
>>
>> Bob
>>
>> > On Jan 13, 2017, at 3:25 PM, John Hawkinson  wrote:
>> >
>> > Can we please stop talking about pings?
>> >
>> > Bob Camp  wrote on Fri, 13 Jan 2017
>> > at 15:12:38 -0500 in :
>> >
>> >> I’m sure you are right about the response time. Right now the
>> >> variation is running almost 3 ms at one sigma on a ping so there is
>> >> a lot to do simply to get the accuracy anywhere near 1 us.
>> >

Presuming that the computer on the WiFi network is a supported Unix, I
might use PTP to measure one way delay, PTP needs "special" hardware
to do hardware timestamping, but _can_ be run on any network
interface.

I'd guess that the the WiFi for doing "sub microsecond" accuracy would
not be the current 2.4ghz and 5ghz, but 802.11ay

Cheers

Arne
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] wifi with time sync

[Paul]

On Fri, Jan 13, 2017 at 3:35 PM, Bob Camp  wrote:

> Hi
>
> What standard protocol would you recommend I run from the command line on
> my computer
> to get a quick estimate of the timing lag and variablilty  on my
> particular WiFi connection?


If I wanted to do this I would use MTR (it has been ported to Windows but I
don't use that version) with the jitter option and a sub-second period.
First characterize with a wired connection against a stable host and then
switch to WiFi.  Of course that assumes you don't want to do your own math.

--
Paul
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] wifi with time sync

[Hal Murray]

> What standard protocol would you recommend I run from the command line on my
> computer  to get a quick estimate of the timing lag and variablilty  on my
> particular WiFi connection? 

I'd use ping.  But you said "quick estimate".

My wifi is crappy enough that its noise swamps everything else.  Out of 
habbit, I never ping a switch so I don't have to worry about the extra delay 
from its CPU.

-

> To add to this I'd be curious in knowing about easy PC based ways to measure
> network latencies / delays with microsecond accuracy vs millisecond
> accuracy. 

I don't know of any "easy" way to do that.  If I wanted to work on that 
problem, I would investigate the PTP level time stamping that you can get 
from some Ethernet chips.

Most Unix like OSes now support getting a time stamp on received packets.  
That's interrupt level rather than hardware level.  I just poked around a 
bit.  I didn't find a simple way to get a transmit time stamp, but there was 
enough discussion that something might work.  Depends on your OS and hardware 
and ...

If the network is lightly loaded, you can probably assume that the packet has 
started when the call to send returns.

If you have a setup on a LAN with identical machines and can feed the same 
PPS pulse to both of them you can probably get the clocks in sync close to a 
microsecond.



-- 
These are my opinions.  I hate spam.



___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] wifi with time sync

[jimlux]

On 1/13/17 2:19 PM, Chris Caudle wrote:

On Fri, January 13, 2017 3:17 pm, Bob Camp wrote:

It just so happens that I'm trying to track down an issue with my WiFi
as I type this.


This is getting off topic for time-nuts very quickly,


well, wireless distribution of accurate time is, I think, on topic..

Wifi, in general, has really poor diagnostics - probably because while 
they had IP (in the TCP/UDP sense) when Unix was written, or shortly 
thereafter, so there are things like ping and traceroute..


WiFi has always had idiosyncracies with the Media Access and Link layer 
- all stuff that is "beneath" the sort of idealized network driver level.


It's like asking for generalized utilities to measure disk access time 
and error rates.. There aren't any, because every disk drive is 
different (originally.. now they tend to have the same interface, which 
hides most of the timing, but they also expose things like SMART)


802.11 performance is affected by oh-so-many things - your basic node is 
actually half duplex, so you have the whole access point/user timing 
cycle to deal with.  Then there's the whole infrastructure vs ad-hoc 
thing - the latter which is very poorly supported by a lot of drivers 
and OSes. Doesn't everyone just run their computer talking to an access 
point? That's what all the software focuses on.


802.11 changes the data rate on the fly according to conditions, which 
will change the time it takes to send the message over the air.


I'm sure there's probably some registers that count the number of bad 
packets and number of good packets, but knowing whether the packet was a 
2 Mbps or a 54 Mbps packet or something else is generally not available.


Most 802.11 devices have tons of configuration and status registers of 
one sort or another, but very sketchy documentation.


The fact that there are even tools like net stumbler is a credit to 
people who reverse engineered, or figured stuff out.




___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] hm H Maser

[Bruce Griffiths]

An entire room kept near to absolute zero with a simple door access???Unlikely, 
likely the writer is unfamiliar with science/engineering.
Bruce 

On Saturday, 14 January 2017 11:39 AM, Gary Woods 
 wrote:
 

 Hydrogen maser in radio astronomy to sync worldwide systems:

http://flip.it/rmbdRQ

(Lifted from the Albany, NY astronomy group).



-- 
Gary Woods O- K2AHC  Public keys at home.earthlink.net/~garygarlic, or get 
0x1D64A93D via keyserver
fingerprint =  E2 6F 50 93 7B C7 F3 CA  1F 8B 3C C0 B0 28 68 0B
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.


   
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] hm H Maser

[Gary Woods]

Hydrogen maser in radio astronomy to sync worldwide systems:

http://flip.it/rmbdRQ

(Lifted from the Albany, NY astronomy group).



-- 
Gary Woods O- K2AHC   Public keys at home.earthlink.net/~garygarlic, or get 
0x1D64A93D via keyserver
fingerprint =  E2 6F 50 93 7B C7 F3 CA  1F 8B 3C C0 B0 28 68 0B
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] wifi with time sync

[Chris Caudle]

On Fri, January 13, 2017 3:17 pm, Bob Camp wrote:
> It just so happens that I'm trying to track down an issue with my WiFi
> as I type this.

This is getting off topic for time-nuts very quickly, but use bufferbloat
and "make wifi fast" as search phrases.  The guy who did a lot of the work
on queue disciplines to solve bufferbloat (over sized buffers in network
devices and drivers adding unnecessary excess latency) turned his
attention to Wi-Fi and found that Wi-Fi devices and drivers were even
worse, and the devices often had firmware running on them that hid the
sources of latency.
Because you need to be able to measure latency and bandwidth concurrently
they put together some scripts using combinations of iperf, netperf, ping,
and other tools running concurrently to measure latency under conditions
of various levels of simultaneous bandwidth use.

You can start here:
https://www.bufferbloat.net/projects/
https://www.bufferbloat.net/projects/make-wifi-fast/wiki/

For the level of problem you are trying to diagnose ping is probably an
appropriate tool, although it doesn't give much diagnostic information
when the reply time increases, it is more of a "what" than a "why" tool.

-- 
Chris Caudle




___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Thermal effects on cables --> ADEV

[Scott Stobbe]

I think their advice was to limit the ADEV calculation for some tau to 300
bins. The standard error on estimating the standard deviation is ~ +- 5%
for 200 samples. So loosely speaking in the neighborhood of 100-300 bins
the resulting adev will have an rms uncertainty of roughly 5%. So limiting
the number of bins to 300 for any particular tau you wish to monitor, you
will see the ADEV wonder up and down over time, but if it exceeds say 5
sigma, 25% something is up.

On Fri, Jan 13, 2017 at 12:30 PM, Ole Petter Rønningen <
opronnin...@gmail.com> wrote:

> That IS interesting.. It reads to me that the advice is to keep a "moving
> 300 pt ADEV" when continously monitoring a (pair of) frequency source in
> e.g a VLBI site - the reason for limiting it to 300 pts being that much
> more than that is likely to average out potential issues..
>
> Does that make sense?
>
> > Den 13. jan. 2017 kl. 17.04 skrev Bob Camp :
> >
> > Hi
> >
> > There’s an interesting comment buried down in that paper about limiting
> ADEV to
> > < 300 samples per point. Their objective is apparently to better
> highlight “systematic
> > errors”. I certainly agree that big datasets will swamp this sort of
> thing. I’m not quite
> > sure that I’d recommend ADEV to find these things in the first place. My
> guess is that
> > it’s the only spec they have to call the device good or bad in this case
> …They don’t seem
> > to have Hadamard in their list of variances. If I was going after
> systematics with a deviation,
> > that’s the one I’d use. Of course I probably would not use a
> something-dev in the first place.
> >
> > Bob
> >
> >
> >> On Jan 13, 2017, at 1:52 AM, Ole Petter Ronningen <
> opronnin...@gmail.com> wrote:
> >>
> >> Hi, all
> >>
> >> The question of phase shifts in cables pops up every now and then on
> this
> >> list - I stumbled across a good table of measured phase shifts with
> >> temperature in different cable types in this paper:
> >> http://www.ira.inaf.it/eratec/gothenburg/presentations/ERATEC_2014_
> PresentationWSchaefer.pdf
> >> that I though would be of interest to others.
> >>
> >> A quick summary given below, see pdf for full details. Lots of other
> >> interesting stuff in there also.
> >>
> >> Values in ppm/K, for 10 Mhz except when otherwise stated. (The paper
> gives
> >> values for 5, 10 and 100Mhz)
> >>
> >> Huber-Suhner Multiflex 141: -6
> >> RG-223: -131.9
> >> Semiflex Cable: -11.5
> >> Huber-Suhner: -8.6
> >> Times Microwave LMR-240: -3.4
> >> Times Microwave SFT-205: 7.7
> >> Meggitt 2T693 SiO2: 30.6
> >> Andrew FSJ-1 (@5Mhz): 25
> >> Andrew FSJ-4 (@5Mhz): 10
> >> Andrew LDF-1P-50-42: 2.8
> >> Andrew LDF4-50A: 4.7
> >> Times Microwave TF4FLEX (@100Mhz):6.4
> >> Phasetrack PT210 (@100Mhz): 2
> >>
> >> Ole
> >> ___
> >> time-nuts mailing list -- time-nuts@febo.com
> >> To unsubscribe, go to https://www.febo.com/cgi-bin/
> mailman/listinfo/time-nuts
> >> and follow the instructions there.
> >
> > ___
> > time-nuts mailing list -- time-nuts@febo.com
> > To unsubscribe, go to https://www.febo.com/cgi-bin/
> mailman/listinfo/time-nuts
> > and follow the instructions there.
> ___
> time-nuts mailing list -- time-nuts@febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/
> mailman/listinfo/time-nuts
> and follow the instructions there.
>
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] wifi with time sync

[Denny Page]

It’s a little more complicated than that. A switch’s main cpu is like a host 
with rx coalesce set to 100. And there are a surprising number of things that 
trigger the main cpu beyond management functions. Multicast is a good example. 
The amount of load on the main cpu can be quite variable, and given ICMP’s low 
priority, it’s not unusual to see a switch that responds in 1ms suddenly jump 
to 25-100ms and then drop back.

Denny


> On Jan 13, 2017, at 12:25, John Hawkinson  wrote:
> 
> When you ping a switch, think of the switch as a network switch with a small 
> computer
> (host) attached that handles mangement functions, like responding to pings.

___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] wifi with time sync

[Bob Camp]

Hi

It just so happens that I’m trying to track down an issue with my WiFi as
I type this. My *guess* is that there is a dropout going on. The only easy
way I can see to get a round trip time with a high data rate is to run ping. 
It’s the only tool that gives me something that is fast enough to spot issues.
Is it perfect? certainly not. Is it an upper bound that is also likely the limit
for things like NTP - in my experience it sure is. That of course assumes 
the gizmo that sends the pings back does so quickly and consistently. I’ve
spent enough time testing that side of it that I’m quite sure it’s true in this 
case.

Bob

> On Jan 13, 2017, at 4:07 PM, John Hawkinson  wrote:
> 
> Bob Camp  wrote on Fri, 13 Jan 2017
> at 15:35:19 -0500 in :
> 
>> What standard protocol would you recommend I run from the command
>> line on my computer to get a quick estimate of the timing lag and
>> variablilty on my particular WiFi connection?
> 
> Bob: I hope you read the whole of my message, rather than just the
> short upper part you quoted. I said "I'm not aware of a tool that does
> this today" -- I don't think there is a good answer.
> 
> 
> ==> There isn't one. <==
> 
> 
> You can certainly use ping to get a gross upper bound. But rememnber
> it's a gross upper bound, and the underlying technology can do much
> better. As Chris said, ntp will do a good job telling you the delay
> between two hosts (that are running ntp and talking to each other)
> by sending a lot of samples and averaging over time.
> 
> But what is your application here? You haven't made it clear.  Ping is
> not representative of what you could get with a wifi using a new
> technology, which was what was how this thread started, and so the
> context some of the anwers (esp. mine) are in. Ping is representative
> of other things, though.
> 
> --jh...@mit.edu
>  John Hawkinson
> ___
> time-nuts mailing list -- time-nuts@febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.

___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] wifi with time sync

[Mark Spencer]

To add to this I'd be curious in knowing about easy PC based ways to measure 
network latencies / delays with microsecond accuracy vs millisecond accuracy.

The tools I used to use at work were generally designed for use on networks 
where millisecond resolution measurements made sense as a "figure of merit."

Best regards
Mark Spencer

Sent from my iPhone

> On Jan 13, 2017, at 12:35 PM, Bob Camp  wrote:
> 
> Hi
> 
> What standard protocol would you recommend I run from the command line on my 
> computer 
> to get a quick estimate of the timing lag and variablilty  on my particular 
> WiFi connection?
> 
> Bob
> 
>> On Jan 13, 2017, at 3:25 PM, John Hawkinson  wrote:
>> 
>> Can we please stop talking about pings?
>> 
>> Bob Camp  wrote on Fri, 13 Jan 2017
>> at 15:12:38 -0500 in :
>> 
>>> I’m sure you are right about the response time. Right now the
>>> variation is running almost 3 ms at one sigma on a ping so there is
>>> a lot to do simply to get the accuracy anywhere near 1 us.
> 
> ___
> time-nuts mailing list -- time-nuts@febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.
> 
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] wifi with time sync

[John Hawkinson]

Bob Camp  wrote on Fri, 13 Jan 2017
at 15:35:19 -0500 in :

> What standard protocol would you recommend I run from the command
> line on my computer to get a quick estimate of the timing lag and
> variablilty on my particular WiFi connection?

Bob: I hope you read the whole of my message, rather than just the
short upper part you quoted. I said "I'm not aware of a tool that does
this today" -- I don't think there is a good answer.


==> There isn't one. <==


You can certainly use ping to get a gross upper bound. But rememnber
it's a gross upper bound, and the underlying technology can do much
better. As Chris said, ntp will do a good job telling you the delay
between two hosts (that are running ntp and talking to each other)
by sending a lot of samples and averaging over time.

But what is your application here? You haven't made it clear.  Ping is
not representative of what you could get with a wifi using a new
technology, which was what was how this thread started, and so the
context some of the anwers (esp. mine) are in. Ping is representative
of other things, though.

--jh...@mit.edu
  John Hawkinson
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] wifi with time sync

[Bob Camp]

Hi

Ok. so I bring up NTP on the laptop against a server on the other side of the 
country and install
NTP on the laptop. I get all of the jitter and offset of my cable modem plus 
the network
issues between here and who know where. If I want to know the specific delay 
issues just 
on the WiFi connection (like when it rotates keys), how do I separate that out?

Bob

> On Jan 13, 2017, at 3:45 PM, Chris Albertson  
> wrote:
> 
> Short answer:  See man page for ntpq
> 
> Longer...
> 
> First run NTP then after some time (15 minute to an hour) at the command
> line time type "ntpq -p"
> 
> "ntpq" will query NTP for timing statistics.  It will report the average
> delay between the local computer and the set of reference clocks (other
> servers) that NTP is connected to.  Along with the average delay you get
> variation in that delay (std dev?)Note the if NTP can calculate the
> delay, it has already compensated for it.   It is only the uncertainty of
> the compensation that matters, hence the need to report the variation.
> 
> The data shows the total delay and variation over the network and the
> reference clocks might be thousands of miles away.  So you might want to
> run one on say your wifi router or a local computer with hardwire
> connection to the router then you'd see the effect of only your wifi.
> 
> 
> 
> On Fri, Jan 13, 2017 at 12:35 PM, Bob Camp  wrote:
> 
>> Hi
>> 
>> What standard protocol would you recommend I run from the command line on
>> my computer
>> to get a quick estimate of the timing lag and variablilty  on my
>> particular WiFi connection?
>> 
>> Bob
>> 
>>> On Jan 13, 2017, at 3:25 PM, John Hawkinson  wrote:
>>> 
>>> Can we please stop talking about pings?
>>> 
>>> Bob Camp  wrote on Fri, 13 Jan 2017
>>> at 15:12:38 -0500 in :
>>> 
 I’m sure you are right about the response time. Right now the
 variation is running almost 3 ms at one sigma on a ping so there is
 a lot to do simply to get the accuracy anywhere near 1 us.
>>> 
>> 
>> ___
>> time-nuts mailing list -- time-nuts@febo.com
>> To unsubscribe, go to https://www.febo.com/cgi-bin/
>> mailman/listinfo/time-nuts
>> and follow the instructions there.
>> 
> 
> 
> 
> -- 
> 
> Chris Albertson
> Redondo Beach, California
> ___
> time-nuts mailing list -- time-nuts@febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.

___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] wifi with time sync

[Bob Camp]

Hi

That *assumes* that NTP is installed on the laptop.

Bob

> On Jan 13, 2017, at 3:45 PM, Chris Albertson  
> wrote:
> 
> Short answer:  See man page for ntpq
> 
> Longer...
> 
> First run NTP then after some time (15 minute to an hour) at the command
> line time type "ntpq -p"
> 
> "ntpq" will query NTP for timing statistics.  It will report the average
> delay between the local computer and the set of reference clocks (other
> servers) that NTP is connected to.  Along with the average delay you get
> variation in that delay (std dev?)Note the if NTP can calculate the
> delay, it has already compensated for it.   It is only the uncertainty of
> the compensation that matters, hence the need to report the variation.
> 
> The data shows the total delay and variation over the network and the
> reference clocks might be thousands of miles away.  So you might want to
> run one on say your wifi router or a local computer with hardwire
> connection to the router then you'd see the effect of only your wifi.
> 
> 
> 
> On Fri, Jan 13, 2017 at 12:35 PM, Bob Camp  wrote:
> 
>> Hi
>> 
>> What standard protocol would you recommend I run from the command line on
>> my computer
>> to get a quick estimate of the timing lag and variablilty  on my
>> particular WiFi connection?
>> 
>> Bob
>> 
>>> On Jan 13, 2017, at 3:25 PM, John Hawkinson  wrote:
>>> 
>>> Can we please stop talking about pings?
>>> 
>>> Bob Camp  wrote on Fri, 13 Jan 2017
>>> at 15:12:38 -0500 in :
>>> 
 I’m sure you are right about the response time. Right now the
 variation is running almost 3 ms at one sigma on a ping so there is
 a lot to do simply to get the accuracy anywhere near 1 us.
>>> 
>> 
>> ___
>> time-nuts mailing list -- time-nuts@febo.com
>> To unsubscribe, go to https://www.febo.com/cgi-bin/
>> mailman/listinfo/time-nuts
>> and follow the instructions there.
>> 
> 
> 
> 
> -- 
> 
> Chris Albertson
> Redondo Beach, California
> ___
> time-nuts mailing list -- time-nuts@febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.

___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] wifi with time sync

[Chris Albertson]

Short answer:  See man page for ntpq

Longer...

First run NTP then after some time (15 minute to an hour) at the command
line time type "ntpq -p"

"ntpq" will query NTP for timing statistics.  It will report the average
delay between the local computer and the set of reference clocks (other
servers) that NTP is connected to.  Along with the average delay you get
variation in that delay (std dev?)Note the if NTP can calculate the
delay, it has already compensated for it.   It is only the uncertainty of
the compensation that matters, hence the need to report the variation.

The data shows the total delay and variation over the network and the
reference clocks might be thousands of miles away.  So you might want to
run one on say your wifi router or a local computer with hardwire
connection to the router then you'd see the effect of only your wifi.



On Fri, Jan 13, 2017 at 12:35 PM, Bob Camp  wrote:

> Hi
>
> What standard protocol would you recommend I run from the command line on
> my computer
> to get a quick estimate of the timing lag and variablilty  on my
> particular WiFi connection?
>
> Bob
>
> > On Jan 13, 2017, at 3:25 PM, John Hawkinson  wrote:
> >
> > Can we please stop talking about pings?
> >
> > Bob Camp  wrote on Fri, 13 Jan 2017
> > at 15:12:38 -0500 in :
> >
> >> I’m sure you are right about the response time. Right now the
> >> variation is running almost 3 ms at one sigma on a ping so there is
> >> a lot to do simply to get the accuracy anywhere near 1 us.
> >
>
> ___
> time-nuts mailing list -- time-nuts@febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/
> mailman/listinfo/time-nuts
> and follow the instructions there.
>



-- 

Chris Albertson
Redondo Beach, California
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] wifi with time sync

[Bob Camp]

Hi

What standard protocol would you recommend I run from the command line on my 
computer 
to get a quick estimate of the timing lag and variablilty  on my particular 
WiFi connection?

Bob

> On Jan 13, 2017, at 3:25 PM, John Hawkinson  wrote:
> 
> Can we please stop talking about pings?
> 
> Bob Camp  wrote on Fri, 13 Jan 2017
> at 15:12:38 -0500 in :
> 
>> I’m sure you are right about the response time. Right now the
>> variation is running almost 3 ms at one sigma on a ping so there is
>> a lot to do simply to get the accuracy anywhere near 1 us.
> 

___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] wifi with time sync

[Chris Albertson]

Even with the long and variable ping time, time sync can work. The reason
it can work is that time is not re-sync'd in one "ping" but time sync is an
on-going process that occurs over a period as long as hours.

Think about adjusting the rate of a clock by hand.  The computer (NTP) can
(and does) use the same method.  You sync it up as best you can then come
back in 24 hours and see it your clock has gained or lost time then fix the
rate and continue this process forever, eventually some balance is reached
as you learn to make fine adjustments.

So having a few tens of milliseconds of error in the communications channel
is not so bad if we can let the clocks runs for a long time and also we can
average MANY measurements,  NTP uses quite a few tricks and works about as
well as it can given the nature of the communications channels it is given
work with.   PTP has one more trick it can use that really solves the
problem.,  PTP depends on special hardware that time stamps the messages so
it knows the ping-like delays you see.But  PTP's problem is that it
requires special PTP compatible hardware.

There are people in academia who have sync close to on order 100
nanoseconds over WiFi using PTP.  I think this is a do it your self thing
right now.   It would not be really hard to build a WiFi router form Linux
or BSD then add PTPd on each end.   There might be a commercial solution, I
don't know.

But in any case don't expect your system clock to bounce around like the
ping times do.  NTP is good enough that it does an average.

I run NTP in some WiFi connected autonomous robots and it works well enough
to keep internal log files sync'd between robots.  But I only need a few
tens of milliseconds for that.


On Fri, Jan 13, 2017 at 11:35 AM, Chris Caudle 
wrote:

> On Fri, January 13, 2017 11:40 am, Bob Camp wrote:
> > The ping response is anywhere from 2 ms out to 400 ms. Most of
> > the time it's in the 3 to 9 ms range. Simply taking that
> > down to < 1 us would be a really big deal.
>
> I doubt that the response time will get that low, rather the time sync
> will be moved lower in the hardware stack so that the variation stays
> below 1us so it can be compensated as a systematic offset.  Basically a
> Wi-Fi version of the hardware time stamping that a lot of NIC's do now for
> PTP support.  Just a guess at this point.
>
> --
> Chris Caudle
>
>
>
>
> ___
> time-nuts mailing list -- time-nuts@febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/
> mailman/listinfo/time-nuts
> and follow the instructions there.
>



-- 

Chris Albertson
Redondo Beach, California
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] wifi with time sync

[John Hawkinson]

Can we please stop talking about pings?

Bob Camp  wrote on Fri, 13 Jan 2017
at 15:12:38 -0500 in :

> I’m sure you are right about the response time. Right now the
> variation is running almost 3 ms at one sigma on a ping so there is
> a lot to do simply to get the accuracy anywhere near 1 us.

Using ping remains deeply problematic as a measure of what is possible.
The underlying layer does retransmissions and inserts delays. And ping
measures around those things, not within them. But any real tool
that was using the wireless frames for timing would be measuring
the raw layer 2 frame timing.

(It's not apparent that this would require hardware timestamping support,
although that can certainly help.)

This sort of thing is doable with today's hardware and software
technology.  Although I'm not aware of a tool that does this today
(but building one is not hard).

Denny Page's comment about hosts not prioritizing responding to ICMP
is...IMO misleading. That's not really what happens. When you ping a
switch, think of the switch as a network switch with a small computer
(host) attached that handles mangement functions, like responding to
pings. They are entirely decoupled, and the load on the management
computer is not related to the load on the network, and sometimes it's
really slow. That makes the claim about priority effectively true for
network equipment, but it's not generally true for *hosts*. Most hosts
will indeed respond to ICMP rapidly (in the kernel) without
prioritizing it any differently from other packets. Except the other
kinds of packets often require leaving kernel space (e.g. application
processes) which ncessarily induces more delay.

But anyhow, the upshot is correct: don't trust pings to switches, but
pings to idle hosts will be much more meaningful. But still not meaningful
on wireless networks.

So...can we please stop talking about pings? Thanks.

--jh...@mit.edu
  John Hawkinson
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] wifi with time sync

[Bob Camp]

Hi

I’m sure you are right about the response time. Right now the variation is 
running almost 3 ms
at one sigma on a ping so there is a lot to do simply to get the accuracy 
anywhere near 1 us.

Bob

> On Jan 13, 2017, at 2:35 PM, Chris Caudle  wrote:
> 
> On Fri, January 13, 2017 11:40 am, Bob Camp wrote:
>> The ping response is anywhere from 2 ms out to 400 ms. Most of
>> the time it's in the 3 to 9 ms range. Simply taking that
>> down to < 1 us would be a really big deal.
> 
> I doubt that the response time will get that low, rather the time sync
> will be moved lower in the hardware stack so that the variation stays
> below 1us so it can be compensated as a systematic offset.  Basically a
> Wi-Fi version of the hardware time stamping that a lot of NIC's do now for
> PTP support.  Just a guess at this point.
> 
> -- 
> Chris Caudle
> 
> 
> 
> 
> ___
> time-nuts mailing list -- time-nuts@febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.

___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] wifi with time sync

[Chris Caudle]

On Fri, January 13, 2017 11:40 am, Bob Camp wrote:
> The ping response is anywhere from 2 ms out to 400 ms. Most of
> the time it's in the 3 to 9 ms range. Simply taking that
> down to < 1 us would be a really big deal.

I doubt that the response time will get that low, rather the time sync
will be moved lower in the hardware stack so that the variation stays
below 1us so it can be compensated as a systematic offset.  Basically a
Wi-Fi version of the hardware time stamping that a lot of NIC's do now for
PTP support.  Just a guess at this point.

-- 
Chris Caudle




___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Thermal effects on cables --> ADEV

[Tom Van Baak]

Mark, Ole,

Yes, averaging can both enhance precision but also destroy information. In many 
cases too much data is a bad thing. The solution is to add another dimension to 
the plot. Stable32 does this with DAVAR (dynamic Allan variance). TimeLab has a 
multi- "trace" feature. Both of these break large data sets into smaller ones 
and display each in succession. This way you get the best of both worlds; 
precision without long-term pollution and also a view of long-term trends. Yes, 
there's an art to picking the right parameters, but you get the idea. In some 
cases it is highly informative. The color 3D DAVAR plots in particular can be a 
thing of beauty.

So, in your case, save each of those 24 hour GIF's and then turn then into a 
single animated GIF. That way not only do you get a fresh view of current 
reception conditions, but also a time lapse view of changes over the long-term.

Another idea is to somehow 2D transform your polar plots into a horizontal 
rectangular strip and then use elapsed time in the vertical. This would allow a 
waterfall-style representation of GPS reception over time.

/tvb

- Original Message - 
From: "Mark Sims" 
To: 
Sent: Friday, January 13, 2017 11:03 AM
Subject: [time-nuts] Thermal effects on cables --> ADEV


>I recently made a change in Lady Heather's satellite signal maps to help with 
>a very similar issue.  Before, the maps were based upon the accumulated 
>average value of the sat signals at each point in the sky.  Now, every 24 
>hours, the signal level averages are reset to their current average and the 
>sample counts are reset to 1.  That way any change is your antenna performance 
>won't be masked by days/week/months of previous data.
> 
> 
> 
>> Don't use years worth of data.
> Otherwise it could be days before the xDEV visually changes

___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Thermal effects on cables --> ADEV

[Bob Camp]

Hi


That’s the way I read what they are saying. More or less: Keep the number of 
samples above
100, but below 300.

Bob

> On Jan 13, 2017, at 12:30 PM, Ole Petter Rønningen  
> wrote:
> 
> That IS interesting.. It reads to me that the advice is to keep a "moving 300 
> pt ADEV" when continously monitoring a (pair of) frequency source in e.g a 
> VLBI site - the reason for limiting it to 300 pts being that much more than 
> that is likely to average out potential issues.. 
> 
> Does that make sense?
> 
>> Den 13. jan. 2017 kl. 17.04 skrev Bob Camp :
>> 
>> Hi
>> 
>> There’s an interesting comment buried down in that paper about limiting ADEV 
>> to 
>> < 300 samples per point. Their objective is apparently to better highlight 
>> “systematic 
>> errors”. I certainly agree that big datasets will swamp this sort of thing. 
>> I’m not quite
>> sure that I’d recommend ADEV to find these things in the first place. My 
>> guess is that
>> it’s the only spec they have to call the device good or bad in this case 
>> …They don’t seem
>> to have Hadamard in their list of variances. If I was going after 
>> systematics with a deviation,
>> that’s the one I’d use. Of course I probably would not use a something-dev 
>> in the first place. 
>> 
>> Bob
>> 
>> 
>>> On Jan 13, 2017, at 1:52 AM, Ole Petter Ronningen  
>>> wrote:
>>> 
>>> Hi, all
>>> 
>>> The question of phase shifts in cables pops up every now and then on this
>>> list - I stumbled across a good table of measured phase shifts with
>>> temperature in different cable types in this paper:
>>> http://www.ira.inaf.it/eratec/gothenburg/presentations/ERATEC_2014_PresentationWSchaefer.pdf
>>> that I though would be of interest to others.
>>> 
>>> A quick summary given below, see pdf for full details. Lots of other
>>> interesting stuff in there also.
>>> 
>>> Values in ppm/K, for 10 Mhz except when otherwise stated. (The paper gives
>>> values for 5, 10 and 100Mhz)
>>> 
>>> Huber-Suhner Multiflex 141: -6
>>> RG-223: -131.9
>>> Semiflex Cable: -11.5
>>> Huber-Suhner: -8.6
>>> Times Microwave LMR-240: -3.4
>>> Times Microwave SFT-205: 7.7
>>> Meggitt 2T693 SiO2: 30.6
>>> Andrew FSJ-1 (@5Mhz): 25
>>> Andrew FSJ-4 (@5Mhz): 10
>>> Andrew LDF-1P-50-42: 2.8
>>> Andrew LDF4-50A: 4.7
>>> Times Microwave TF4FLEX (@100Mhz):6.4
>>> Phasetrack PT210 (@100Mhz): 2
>>> 
>>> Ole
>>> ___
>>> time-nuts mailing list -- time-nuts@febo.com
>>> To unsubscribe, go to 
>>> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
>>> and follow the instructions there.
>> 
>> ___
>> time-nuts mailing list -- time-nuts@febo.com
>> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
>> and follow the instructions there.
> ___
> time-nuts mailing list -- time-nuts@febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.

___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Thermal effects on cables --> ADEV

[Ole Petter Rønningen]

That IS interesting.. It reads to me that the advice is to keep a "moving 300 
pt ADEV" when continously monitoring a (pair of) frequency source in e.g a VLBI 
site - the reason for limiting it to 300 pts being that much more than that is 
likely to average out potential issues.. 

Does that make sense?

> Den 13. jan. 2017 kl. 17.04 skrev Bob Camp :
> 
> Hi
> 
> There’s an interesting comment buried down in that paper about limiting ADEV 
> to 
> < 300 samples per point. Their objective is apparently to better highlight 
> “systematic 
> errors”. I certainly agree that big datasets will swamp this sort of thing. 
> I’m not quite
> sure that I’d recommend ADEV to find these things in the first place. My 
> guess is that
> it’s the only spec they have to call the device good or bad in this case 
> …They don’t seem
> to have Hadamard in their list of variances. If I was going after systematics 
> with a deviation,
> that’s the one I’d use. Of course I probably would not use a something-dev in 
> the first place. 
> 
> Bob
> 
> 
>> On Jan 13, 2017, at 1:52 AM, Ole Petter Ronningen  
>> wrote:
>> 
>> Hi, all
>> 
>> The question of phase shifts in cables pops up every now and then on this
>> list - I stumbled across a good table of measured phase shifts with
>> temperature in different cable types in this paper:
>> http://www.ira.inaf.it/eratec/gothenburg/presentations/ERATEC_2014_PresentationWSchaefer.pdf
>> that I though would be of interest to others.
>> 
>> A quick summary given below, see pdf for full details. Lots of other
>> interesting stuff in there also.
>> 
>> Values in ppm/K, for 10 Mhz except when otherwise stated. (The paper gives
>> values for 5, 10 and 100Mhz)
>> 
>> Huber-Suhner Multiflex 141: -6
>> RG-223: -131.9
>> Semiflex Cable: -11.5
>> Huber-Suhner: -8.6
>> Times Microwave LMR-240: -3.4
>> Times Microwave SFT-205: 7.7
>> Meggitt 2T693 SiO2: 30.6
>> Andrew FSJ-1 (@5Mhz): 25
>> Andrew FSJ-4 (@5Mhz): 10
>> Andrew LDF-1P-50-42: 2.8
>> Andrew LDF4-50A: 4.7
>> Times Microwave TF4FLEX (@100Mhz):6.4
>> Phasetrack PT210 (@100Mhz): 2
>> 
>> Ole
>> ___
>> time-nuts mailing list -- time-nuts@febo.com
>> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
>> and follow the instructions there.
> 
> ___
> time-nuts mailing list -- time-nuts@febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

[time-nuts] Thermal effects on cables --> ADEV

[Mark Sims]

I recently made a change in Lady Heather's satellite signal maps to help with a 
very similar issue.  Before, the maps were based upon the accumulated average 
value of the sat signals at each point in the sky.  Now, every 24 hours, the 
signal level averages are reset to their current average and the sample counts 
are reset to 1.  That way any change is your antenna performance won't be 
masked by days/week/months of previous data.



> Don't use years worth of data.
Otherwise it could be days before the xDEV visually changes
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] wifi with time sync

[Bob Camp]

Hi

I probably should have added that I already know that the switch will do sub 1 
ms
LAN pings all day long with the near zero load that it’s running. Sorry about 
that.

Now, there certainly are OS level things on my laptop that will muck up pings. 
Unfortunately 
they also get into a number of timing things as well.

Bob

> On Jan 13, 2017, at 1:08 PM, Denny Page  wrote:
> 
>> On Jan 13, 2017, at 09:40, Bob Camp  wrote:
>> 
>> Just for reference, I happen to be running a ping over my local WiFi to one 
>> of the switches
>> on the LAN. The ping response is anywhere from 2 ms out to 400 ms. Most of 
>> the time it’s 
>> in the 3 to 9 ms range. Simply taking that down to < 1 us would be a really 
>> big deal. 
> 
> 
> Ping, particularly to a switch, is not a good indication of actual latency in 
> a local network. Hosts do not prioritize responding to icmp, and on a switch 
> to icmp is the lowest “I’ll get around to it” priority the switch has. 
> Pinging the switch that my host is directly attached to gives an average of 
> 1.22ms. Pinging another host attached to the same switch gives an average of 
> 100us. The actual port to port latency on the switch is 2.45us. Your mileage 
> may vary.
> 
> Denny
> 
> ___
> time-nuts mailing list -- time-nuts@febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.

___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Thermal effects on cables --> ADEV

[Scott Stobbe]

You are certainly justified to be cautious of only using an xDEV for state
of health. I don't know what GPS does for example to mark SV's as healthy
or not healthy.

On Fri, Jan 13, 2017 at 1:11 PM, Bob Camp  wrote:

> Hi
>
> I do agree with their point that systematics will get buried in giant data
> blocks.
> What I’m not quite as sure of is the utility of even 300 sample blocks to
> spot
> systematic issues.
>
> Bob
>
> > On Jan 13, 2017, at 1:08 PM, Scott Stobbe 
> wrote:
> >
> > I think you might be overthinking their point, that if you plan to use an
> > xDEV as a measure for state of health, don't use years worth of data.
> > Otherwise it could be days before the xDEV visually changes.
> >
> > On Fri, Jan 13, 2017 at 11:04 AM, Bob Camp  wrote:
> >
> >> Hi
> >>
> >> There’s an interesting comment buried down in that paper about limiting
> >> ADEV to
> >> < 300 samples per point. Their objective is apparently to better
> highlight
> >> “systematic
> >> errors”. I certainly agree that big datasets will swamp this sort of
> >> thing. I’m not quite
> >> sure that I’d recommend ADEV to find these things in the first place. My
> >> guess is that
> >> it’s the only spec they have to call the device good or bad in this case
> >> …They don’t seem
> >> to have Hadamard in their list of variances. If I was going after
> >> systematics with a deviation,
> >> that’s the one I’d use. Of course I probably would not use a
> something-dev
> >> in the first place.
> >>
> >> Bob
> >>
> >>
> >>> On Jan 13, 2017, at 1:52 AM, Ole Petter Ronningen <
> opronnin...@gmail.com>
> >> wrote:
> >>>
> >>> Hi, all
> >>>
> >>> The question of phase shifts in cables pops up every now and then on
> this
> >>> list - I stumbled across a good table of measured phase shifts with
> >>> temperature in different cable types in this paper:
> >>> http://www.ira.inaf.it/eratec/gothenburg/presentations/ERATEC_2014_
> >> PresentationWSchaefer.pdf
> >>> that I though would be of interest to others.
> >>>
> >>> A quick summary given below, see pdf for full details. Lots of other
> >>> interesting stuff in there also.
> >>>
> >>> Values in ppm/K, for 10 Mhz except when otherwise stated. (The paper
> >> gives
> >>> values for 5, 10 and 100Mhz)
> >>>
> >>> Huber-Suhner Multiflex 141: -6
> >>> RG-223: -131.9
> >>> Semiflex Cable: -11.5
> >>> Huber-Suhner: -8.6
> >>> Times Microwave LMR-240: -3.4
> >>> Times Microwave SFT-205: 7.7
> >>> Meggitt 2T693 SiO2: 30.6
> >>> Andrew FSJ-1 (@5Mhz): 25
> >>> Andrew FSJ-4 (@5Mhz): 10
> >>> Andrew LDF-1P-50-42: 2.8
> >>> Andrew LDF4-50A: 4.7
> >>> Times Microwave TF4FLEX (@100Mhz):6.4
> >>> Phasetrack PT210 (@100Mhz): 2
> >>>
> >>> Ole
> >>> ___
> >>> time-nuts mailing list -- time-nuts@febo.com
> >>> To unsubscribe, go to https://www.febo.com/cgi-bin/
> >> mailman/listinfo/time-nuts
> >>> and follow the instructions there.
> >>
> >> ___
> >> time-nuts mailing list -- time-nuts@febo.com
> >> To unsubscribe, go to https://www.febo.com/cgi-bin/
> >> mailman/listinfo/time-nuts
> >> and follow the instructions there.
> >>
> > ___
> > time-nuts mailing list -- time-nuts@febo.com
> > To unsubscribe, go to https://www.febo.com/cgi-bin/
> mailman/listinfo/time-nuts
> > and follow the instructions there.
>
> ___
> time-nuts mailing list -- time-nuts@febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/
> mailman/listinfo/time-nuts
> and follow the instructions there.
>
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] wifi with time sync

[Denny Page]

> On Jan 13, 2017, at 09:40, Bob Camp  wrote:
> 
> Just for reference, I happen to be running a ping over my local WiFi to one 
> of the switches
> on the LAN. The ping response is anywhere from 2 ms out to 400 ms. Most of 
> the time it’s 
> in the 3 to 9 ms range. Simply taking that down to < 1 us would be a really 
> big deal. 


Ping, particularly to a switch, is not a good indication of actual latency in a 
local network. Hosts do not prioritize responding to icmp, and on a switch to 
icmp is the lowest “I’ll get around to it” priority the switch has. Pinging the 
switch that my host is directly attached to gives an average of 1.22ms. Pinging 
another host attached to the same switch gives an average of 100us. The actual 
port to port latency on the switch is 2.45us. Your mileage may vary.

Denny

___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Thermal effects on cables --> ADEV

[Bob Camp]

Hi

I do agree with their point that systematics will get buried in giant data 
blocks. 
What I’m not quite as sure of is the utility of even 300 sample blocks to spot
systematic issues.

Bob

> On Jan 13, 2017, at 1:08 PM, Scott Stobbe  wrote:
> 
> I think you might be overthinking their point, that if you plan to use an
> xDEV as a measure for state of health, don't use years worth of data.
> Otherwise it could be days before the xDEV visually changes.
> 
> On Fri, Jan 13, 2017 at 11:04 AM, Bob Camp  wrote:
> 
>> Hi
>> 
>> There’s an interesting comment buried down in that paper about limiting
>> ADEV to
>> < 300 samples per point. Their objective is apparently to better highlight
>> “systematic
>> errors”. I certainly agree that big datasets will swamp this sort of
>> thing. I’m not quite
>> sure that I’d recommend ADEV to find these things in the first place. My
>> guess is that
>> it’s the only spec they have to call the device good or bad in this case
>> …They don’t seem
>> to have Hadamard in their list of variances. If I was going after
>> systematics with a deviation,
>> that’s the one I’d use. Of course I probably would not use a something-dev
>> in the first place.
>> 
>> Bob
>> 
>> 
>>> On Jan 13, 2017, at 1:52 AM, Ole Petter Ronningen 
>> wrote:
>>> 
>>> Hi, all
>>> 
>>> The question of phase shifts in cables pops up every now and then on this
>>> list - I stumbled across a good table of measured phase shifts with
>>> temperature in different cable types in this paper:
>>> http://www.ira.inaf.it/eratec/gothenburg/presentations/ERATEC_2014_
>> PresentationWSchaefer.pdf
>>> that I though would be of interest to others.
>>> 
>>> A quick summary given below, see pdf for full details. Lots of other
>>> interesting stuff in there also.
>>> 
>>> Values in ppm/K, for 10 Mhz except when otherwise stated. (The paper
>> gives
>>> values for 5, 10 and 100Mhz)
>>> 
>>> Huber-Suhner Multiflex 141: -6
>>> RG-223: -131.9
>>> Semiflex Cable: -11.5
>>> Huber-Suhner: -8.6
>>> Times Microwave LMR-240: -3.4
>>> Times Microwave SFT-205: 7.7
>>> Meggitt 2T693 SiO2: 30.6
>>> Andrew FSJ-1 (@5Mhz): 25
>>> Andrew FSJ-4 (@5Mhz): 10
>>> Andrew LDF-1P-50-42: 2.8
>>> Andrew LDF4-50A: 4.7
>>> Times Microwave TF4FLEX (@100Mhz):6.4
>>> Phasetrack PT210 (@100Mhz): 2
>>> 
>>> Ole
>>> ___
>>> time-nuts mailing list -- time-nuts@febo.com
>>> To unsubscribe, go to https://www.febo.com/cgi-bin/
>> mailman/listinfo/time-nuts
>>> and follow the instructions there.
>> 
>> ___
>> time-nuts mailing list -- time-nuts@febo.com
>> To unsubscribe, go to https://www.febo.com/cgi-bin/
>> mailman/listinfo/time-nuts
>> and follow the instructions there.
>> 
> ___
> time-nuts mailing list -- time-nuts@febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.

___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Thermal effects on cables --> ADEV

[Scott Stobbe]

I think you might be overthinking their point, that if you plan to use an
xDEV as a measure for state of health, don't use years worth of data.
Otherwise it could be days before the xDEV visually changes.

On Fri, Jan 13, 2017 at 11:04 AM, Bob Camp  wrote:

> Hi
>
> There’s an interesting comment buried down in that paper about limiting
> ADEV to
> < 300 samples per point. Their objective is apparently to better highlight
> “systematic
> errors”. I certainly agree that big datasets will swamp this sort of
> thing. I’m not quite
> sure that I’d recommend ADEV to find these things in the first place. My
> guess is that
> it’s the only spec they have to call the device good or bad in this case
> …They don’t seem
> to have Hadamard in their list of variances. If I was going after
> systematics with a deviation,
> that’s the one I’d use. Of course I probably would not use a something-dev
> in the first place.
>
> Bob
>
>
> > On Jan 13, 2017, at 1:52 AM, Ole Petter Ronningen 
> wrote:
> >
> > Hi, all
> >
> > The question of phase shifts in cables pops up every now and then on this
> > list - I stumbled across a good table of measured phase shifts with
> > temperature in different cable types in this paper:
> > http://www.ira.inaf.it/eratec/gothenburg/presentations/ERATEC_2014_
> PresentationWSchaefer.pdf
> > that I though would be of interest to others.
> >
> > A quick summary given below, see pdf for full details. Lots of other
> > interesting stuff in there also.
> >
> > Values in ppm/K, for 10 Mhz except when otherwise stated. (The paper
> gives
> > values for 5, 10 and 100Mhz)
> >
> > Huber-Suhner Multiflex 141: -6
> > RG-223: -131.9
> > Semiflex Cable: -11.5
> > Huber-Suhner: -8.6
> > Times Microwave LMR-240: -3.4
> > Times Microwave SFT-205: 7.7
> > Meggitt 2T693 SiO2: 30.6
> > Andrew FSJ-1 (@5Mhz): 25
> > Andrew FSJ-4 (@5Mhz): 10
> > Andrew LDF-1P-50-42: 2.8
> > Andrew LDF4-50A: 4.7
> > Times Microwave TF4FLEX (@100Mhz):6.4
> > Phasetrack PT210 (@100Mhz): 2
> >
> > Ole
> > ___
> > time-nuts mailing list -- time-nuts@febo.com
> > To unsubscribe, go to https://www.febo.com/cgi-bin/
> mailman/listinfo/time-nuts
> > and follow the instructions there.
>
> ___
> time-nuts mailing list -- time-nuts@febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/
> mailman/listinfo/time-nuts
> and follow the instructions there.
>
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] wifi with time sync

[Joshua Pollack]

I saw this article too -- is anyone aware of something with more
technical details?  For example, where in the protocol stack does it
work?  Is it specific to 802.11 or general purpose ethernet?

Speaking as someone who has a primary hobby of the development of
super low cost time sync algorithms and software implementations with
the express application of audio over disparate clocks...  this
interests me.

Joshua

On Fri, Jan 13, 2017 at 08:30:44AM -0800, walter shawlee 2 wrote:
> While probably not tight enough for time nuts use, there is a new
> WiFi technology shown at CES that provides time sync between nodes
> to allow audio to be simulcast over many locations.  the info (in
> short form) is here for those interested:
> 
> http://electronicdesign.com/embedded/upgrade-wi-fi-provides-precise-time-sychronization?NL=ED-001=ED-001_20170113_ED-001_372=42=article_2_b_rid=CPG0502043119_campaign=9246_medium=email=a803bc263ff84affa98f3ddbd0650ec0
> 
> there might be some way it can be used for more precision purposes
> down the road. I just thought it might be of interest to the group.
> all the best,
> walter
> 
> -- 
> Walter Shawlee 2, President
> Sphere Research Corporation
> 3394 Sunnyside Rd.,  West Kelowna,  BC
> V1Z 2V4  CANADA  Phone: (250) 769-1834
> walt...@sphere.bc.ca
> WS2: We're all in one boat, no matter how it looks to you.
> Love is all you need. (John Lennon)
> But, that doesn't mean other things don't come in handy. (WS2)
> 
> ___
> time-nuts mailing list -- time-nuts@febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] wifi with time sync

[Chris Caudle]

On Fri, January 13, 2017 10:59 am, Bob Camp wrote:
> 1588 is a "less than a microsecond" sort
> of approach that does indeed get down to nanosecond
> sort of levels. This could be similar.

There was talk of adding a wireless profile into 1588 either as an
addendum or as part of PTPv3.  I suspect this is an early version of that
work, but hard to tell for sure since the phrase "1588" or "PTP" does not
appear in any of those press releases from the Wi-Fi Alliance.

-- 
Chris Caudle




___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] wifi with time sync

[Bob Camp]

Hi

Just for reference, I happen to be running a ping over my local WiFi to one of 
the switches
on the LAN. The ping response is anywhere from 2 ms out to 400 ms. Most of the 
time it’s 
in the 3 to 9 ms range. Simply taking that down to < 1 us would be a really big 
deal. 

Bob

> On Jan 13, 2017, at 12:06 PM, walter shawlee 2  wrote:
> 
> they were really short on hard details about this new technology.
> the *WiFi alliance* website only shows this off-site article link I found 
> under NEWS:
> 
> http://www.rcrwireless.com/20170104/test-and-measurement/20170104test-and-measurementwi-fi-alliance-to-certify-timesync-among-multiple-devices-tag6
> 
> the main alliance site is here:
> http://www.wi-fi.org/   but I don't see anything helpful other than this
> general explanation of TimeSync:
> http://www.wi-fi.org/discover-wi-fi/wi-fi-timesync
> 
> but meaty details that might help us are hard to find.
> 
> all the best,
> walter
> 
> 
> Walter Shawlee 2, President
> Sphere Research Corporation
> 3394 Sunnyside Rd.,  West Kelowna,  BC
> V1Z 2V4  CANADA  Phone: (250) 769-1834
> walt...@sphere.bc.ca
> WS2: We're all in one boat, no matter how it looks to you.
> Love is all you need. (John Lennon)
> But, that doesn't mean other things don't come in handy. (WS2)
> 
> On 2017-01-13 08:47 AM, Joshua Pollack wrote:
>> I saw this article too -- is anyone aware of something with more
>> technical details?  For example, where in the protocol stack does it
>> work?  Is it specific to 802.11 or general purpose ethernet?
>> 
>> Speaking as someone who has a primary hobby of the development of
>> super low cost time sync algorithms and software implementations with
>> the express application of audio over disparate clocks...  this
>> interests me.
>> 
>> Joshua
>> 
>> On Fri, Jan 13, 2017 at 08:30:44AM -0800, walter shawlee 2 wrote:
>>> While probably not tight enough for time nuts use, there is a new
>>> WiFi technology shown at CES that provides time sync between nodes
>>> to allow audio to be simulcast over many locations.  the info (in
>>> short form) is here for those interested:
>>> 
>>> http://electronicdesign.com/embedded/upgrade-wi-fi-provides-precise-time-sychronization?NL=ED-001=ED-001_20170113_ED-001_372=42=article_2_b_rid=CPG0502043119_campaign=9246_medium=email=a803bc263ff84affa98f3ddbd0650ec0
>>> 
>>> there might be some way it can be used for more precision purposes
>>> down the road. I just thought it might be of interest to the group.
>>> all the best,
>>> walter
>>> 
>>> -- 
>>> Walter Shawlee 2, President
>>> Sphere Research Corporation
>>> 3394 Sunnyside Rd.,  West Kelowna,  BC
>>> V1Z 2V4  CANADA  Phone: (250) 769-1834
>>> walt...@sphere.bc.ca
>>> WS2: We're all in one boat, no matter how it looks to you.
>>> Love is all you need. (John Lennon)
>>> But, that doesn't mean other things don't come in handy. (WS2)
>>> 
>>> ___
>>> time-nuts mailing list -- time-nuts@febo.com
>>> To unsubscribe, go to 
>>> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
>>> and follow the instructions there.
> 
> ___
> time-nuts mailing list -- time-nuts@febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.

___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

[time-nuts] HP5065A pressure compensation

[timeok]

   Hi Corby,
   I an looking your Pressure Compensation for the HP5065A ad I have a question 
about the preliminary adjustment of R3.
   Can you give me the alignment procedure you have used?. I suppose you have 
used the Pressure chamber looking at the frequency offset.
   thanks,
   Luciano
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] wifi with time sync

[Bob Camp]

Hi

A lot depends on how much “less than a microsecond” the chip sets really 
deliver in the real world. If they get down into
the sub 100 ns range (which they might), it’s a very useful thing for relaying 
GPS data from a roof antenna down to an 
NTP server in the basement. 1588 is a “less than a microsecond” sort of 
approach that does indeed get down to nanosecond
sort of levels. This could be similar. 

Bob

> On Jan 13, 2017, at 11:30 AM, walter shawlee 2  wrote:
> 
> While probably not tight enough for time nuts use, there is a new WiFi 
> technology shown at CES that provides time sync between nodes to allow audio 
> to be simulcast over many locations.  the info (in short form) is here for 
> those interested:
> 
> http://electronicdesign.com/embedded/upgrade-wi-fi-provides-precise-time-sychronization?NL=ED-001=ED-001_20170113_ED-001_372=42=article_2_b_rid=CPG0502043119_campaign=9246_medium=email=a803bc263ff84affa98f3ddbd0650ec0
> 
> there might be some way it can be used for more precision purposes down the 
> road. I just thought it might be of interest to the group.
> all the best,
> walter
> 
> -- 
> Walter Shawlee 2, President
> Sphere Research Corporation
> 3394 Sunnyside Rd.,  West Kelowna,  BC
> V1Z 2V4  CANADA  Phone: (250) 769-1834
> walt...@sphere.bc.ca
> WS2: We're all in one boat, no matter how it looks to you.
> Love is all you need. (John Lennon)
> But, that doesn't mean other things don't come in handy. (WS2)
> 
> ___
> time-nuts mailing list -- time-nuts@febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.

___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] wifi with time sync

[walter shawlee 2]

they were really short on hard details about this new technology.
the *WiFi alliance* website only shows this off-site article link I found under 
NEWS:


http://www.rcrwireless.com/20170104/test-and-measurement/20170104test-and-measurementwi-fi-alliance-to-certify-timesync-among-multiple-devices-tag6

the main alliance site is here:
http://www.wi-fi.org/   but I don't see anything helpful other than this
general explanation of TimeSync:
http://www.wi-fi.org/discover-wi-fi/wi-fi-timesync

but meaty details that might help us are hard to find.

all the best,
walter


Walter Shawlee 2, President
Sphere Research Corporation
3394 Sunnyside Rd.,  West Kelowna,  BC
V1Z 2V4  CANADA  Phone: (250) 769-1834
walt...@sphere.bc.ca
WS2: We're all in one boat, no matter how it looks to you.
Love is all you need. (John Lennon)
But, that doesn't mean other things don't come in handy. (WS2)

On 2017-01-13 08:47 AM, Joshua Pollack wrote:

I saw this article too -- is anyone aware of something with more
technical details?  For example, where in the protocol stack does it
work?  Is it specific to 802.11 or general purpose ethernet?

Speaking as someone who has a primary hobby of the development of
super low cost time sync algorithms and software implementations with
the express application of audio over disparate clocks...  this
interests me.

Joshua

On Fri, Jan 13, 2017 at 08:30:44AM -0800, walter shawlee 2 wrote:

While probably not tight enough for time nuts use, there is a new
WiFi technology shown at CES that provides time sync between nodes
to allow audio to be simulcast over many locations.  the info (in
short form) is here for those interested:

http://electronicdesign.com/embedded/upgrade-wi-fi-provides-precise-time-sychronization?NL=ED-001=ED-001_20170113_ED-001_372=42=article_2_b_rid=CPG0502043119_campaign=9246_medium=email=a803bc263ff84affa98f3ddbd0650ec0

there might be some way it can be used for more precision purposes
down the road. I just thought it might be of interest to the group.
all the best,
walter

--
Walter Shawlee 2, President
Sphere Research Corporation
3394 Sunnyside Rd.,  West Kelowna,  BC
V1Z 2V4  CANADA  Phone: (250) 769-1834
walt...@sphere.bc.ca
WS2: We're all in one boat, no matter how it looks to you.
Love is all you need. (John Lennon)
But, that doesn't mean other things don't come in handy. (WS2)

___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.


___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

[time-nuts] wifi with time sync

[walter shawlee 2]

While probably not tight enough for time nuts use, there is a new WiFi 
technology shown at CES that provides time sync between nodes to allow audio to 
be simulcast over many locations.  the info (in short form) is here for those 
interested:


http://electronicdesign.com/embedded/upgrade-wi-fi-provides-precise-time-sychronization?NL=ED-001=ED-001_20170113_ED-001_372=42=article_2_b_rid=CPG0502043119_campaign=9246_medium=email=a803bc263ff84affa98f3ddbd0650ec0

there might be some way it can be used for more precision purposes down the 
road. I just thought it might be of interest to the group.

all the best,
walter

--
Walter Shawlee 2, President
Sphere Research Corporation
3394 Sunnyside Rd.,  West Kelowna,  BC
V1Z 2V4  CANADA  Phone: (250) 769-1834
walt...@sphere.bc.ca
WS2: We're all in one boat, no matter how it looks to you.
Love is all you need. (John Lennon)
But, that doesn't mean other things don't come in handy. (WS2)

___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Thermal effects on cables --> ADEV

[Bob Camp]

Hi

There’s an interesting comment buried down in that paper about limiting ADEV to 
< 300 samples per point. Their objective is apparently to better highlight 
“systematic 
errors”. I certainly agree that big datasets will swamp this sort of thing. I’m 
not quite
sure that I’d recommend ADEV to find these things in the first place. My guess 
is that
it’s the only spec they have to call the device good or bad in this case …They 
don’t seem
to have Hadamard in their list of variances. If I was going after systematics 
with a deviation,
that’s the one I’d use. Of course I probably would not use a something-dev in 
the first place. 

Bob


> On Jan 13, 2017, at 1:52 AM, Ole Petter Ronningen  
> wrote:
> 
> Hi, all
> 
> The question of phase shifts in cables pops up every now and then on this
> list - I stumbled across a good table of measured phase shifts with
> temperature in different cable types in this paper:
> http://www.ira.inaf.it/eratec/gothenburg/presentations/ERATEC_2014_PresentationWSchaefer.pdf
> that I though would be of interest to others.
> 
> A quick summary given below, see pdf for full details. Lots of other
> interesting stuff in there also.
> 
> Values in ppm/K, for 10 Mhz except when otherwise stated. (The paper gives
> values for 5, 10 and 100Mhz)
> 
> Huber-Suhner Multiflex 141: -6
> RG-223: -131.9
> Semiflex Cable: -11.5
> Huber-Suhner: -8.6
> Times Microwave LMR-240: -3.4
> Times Microwave SFT-205: 7.7
> Meggitt 2T693 SiO2: 30.6
> Andrew FSJ-1 (@5Mhz): 25
> Andrew FSJ-4 (@5Mhz): 10
> Andrew LDF-1P-50-42: 2.8
> Andrew LDF4-50A: 4.7
> Times Microwave TF4FLEX (@100Mhz):6.4
> Phasetrack PT210 (@100Mhz): 2
> 
> Ole
> ___
> time-nuts mailing list -- time-nuts@febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.

___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Thermal effects on cables

[jimlux]

On 1/12/17 10:52 PM, Ole Petter Ronningen wrote:

Hi, all

The question of phase shifts in cables pops up every now and then on this
list - I stumbled across a good table of measured phase shifts with
temperature in different cable types in this paper:
http://www.ira.inaf.it/eratec/gothenburg/presentations/ERATEC_2014_PresentationWSchaefer.pdf
that I though would be of interest to others.



Handy...
and they mention the notorious problem with PTFE
"Beware of the nonlinear „PTFE“ effect around room temperature (mainly
solid PTFE), manufacturers „shift“ that temperature out of practical 
range, foam and composite dielectrics)



Lots of other useful system design info, too..


___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.