date:20120404

> I stand firm that the only proper way to do this is with a 100%
> deterministic architecture.


> ..only proper way to do what?  The goal is to discipline the internal
> software clock to GPS.  A typical application is a database server
> that is running a web e-comerse site so that transactions get time
> tagged.  So you would run a web, file or database server on a
> deterministic, no cache micro controller?
>

In the original message, Mike is trying to get the jitter better than 20e-6
on a pc. I don't believe this falls in the typical use of NTP category.
What i assume here is that the jitter is local to the machine sampling the
1pps signal. Otherwise this is moot.

 Numerically... 1/(20e-6) = 50e3,  likewise with nyquist variance (50e3 x2)
= 10e3, or time domain that is 100khz wide. This tells us that the input of
the pc must be rate monotonic to 100khz. The only thing that i can think of
that comes close to this monotic bw is a 192khz sound card, i have to
assume these cards are rated in raw sampling rate and not nyquist, so
correcting we see (192khz /2) = 96khz bw. Pretty close to 100khz. Maybe
close enough when considering both sides of figure contain the correction
for twice the highest bw.  Assuming i did not fat finger a calculation, a
192khz sound card is another possible solution to the problem.

The sound card approach would permit conversion to the frequency domain and
i think it would be fun to apply fourier analysis to something like a 1pps
signal. Does anyone have any thoughts as to how stable an approach like
this would be?

Steve
___
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] NTP jitter with Linux

2012-04-04 Thread Gmail

Indeed, I'm looking forward to getting a few raspberry pis to play with. NTP is 
but one of the interesting time related projects possible with a $35(us) Linux 
platform. The system has a number of i/o pins directly exposed that will make 
interfacing interesting. 

On a side note, speaking of deterministic systems, why has no one built a GPSDO 
with an FPGA yet? Or an NTP server? :)

Bob



On Apr 5, 2012, at 1:15, MailLists  wrote:

> As a rule of thumb, any general purpose architecture will be less effective 
> at a specific task than a specially designed one. That applies more and more 
> to the "modern" way of solving tasks: software.
> The PC is one of the classical examples of GPA, and as such it is best to 
> know its limitations, so as to not have exaggerated expectations.
> The first limitation, in that specific case, is the way the PPS source is 
> connected to the system. LinuxPPS tries to optimize it.
> The serial port is far from being a precision path, the "newer" 
> implementations being optimized for throughput (FIFOs) are even worse. Any 
> additional layer (USB especially) makes things just more and more worse.
> As for linux itself, to increase predictability, any disturbing factor should 
> be minimized, if not eliminated. That would mean especially laptop power 
> consumption optimization gimmicks, which are useless in a high performance 
> server/workstation environment (eco, green, and the other trendy 
> marketingdroid buzzwords are lately more, and more abused for a few percent 
> power consumption reduction).
> The suggested RTOS approach is workable, but it represents just another 
> example of tweaking a GPA to a specific task, which for a server is usually 
> not desired. The low latency patches are another example, used usually for 
> DAWs, but with the reverse side of increased processor loading.
> First you must define what your goals, and necessities are, and then optimize 
> your system for the desired task - here linux is your friend, with its almost 
> unlimited tweaking options (no comparison to windumb.) Also, don't use a 
> dumbed down distro, and (learn to) patch/compile your own special kernels 
> (best stripped down of all useless ballast of a "generic" one).
> 
> 
> On 4/5/2012 1:22 AM, Mike S wrote:
>> I asked this on an NTP list, got some guesses, but no knowledgeable
>> responses.
>> 
>> I've got a Trimble Thunderbolt PPS source for NTP, Linux 2.6.35, on a
>> quad core CPU. PPS source is coming into a multiport serial card, which
>> /proc/interrupts shows is sharing IRQ with some inactive USB ports (IRQ
>> 17). It's a PCI-E card, so it would be using MSI interrupts. My
>> understanding is that those aren't really "shared," in the traditional
>> sense, but IDK. The kernel clocksource is TSC, which is claimed to be
>> core invariant on my processor (AMD Athlon II 610e). Changing to HPET
>> doesn't help.
>> 
>> Running normally, I'll get about +- 20 us ptp of jitter (as reported by
>> ntpq -p, and in loopstats). If I load up the CPU (load average >4 is
>> swell), jitter will shrink to +- 1-2 us. I've played around with
>> different cpufreq setting, thinking it might be related to the processor
>> speed during an IRQ varying, but that seems to have minimal impact
>> (performance vs. conservative vs. ondemand).
>> 
>> I've also tried irqbalance, with no change in performance.
>> 
>> So, running a process(es) which keep the CPU completely busy reduces the
>> jitter. The busier, the better. Why? I'm guessing it has something to do
>> with interrupt latency, but why does a busy CPU make it more consistent
>> - I'd expect the opposite? The difference is very obvious.
>> 
>> Is there something else I can do to keep the jitter low?
>> 
>> Aside: Something which I believe was discussed here a few weeks ago -
>> clocksource speeds changing between reboots. I patched the kernel to
>> allow statically setting the TSC frequency (
>> http://old.nabble.com/-PATCH--tsc_khz%3D-boot-option-to-avoid-TSC-calibration-variance-td23494975.html
>> ). This eliminates the semi-random, often 30-40 ppm change in frequency
>> reported by NTP between reboots. After tweaking, it's now consistently <
>> 1 us, reboots be damned. This should be in the mainline kernel! This
>> made no difference to the jitter mentioned above, although non was
>> expected.
>> 
>> ___
>> 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] NTP jitter with Linux

2012-04-04 Thread MailLists

As a rule of thumb, any general purpose architecture will be less
effective at a specific task than a specially designed one. That applies
more and more to the "modern" way of solving tasks: software.
The PC is one of the classical examples of GPA, and as such it is best
to know its limitations, so as to not have exaggerated expectations.
The first limitation, in that specific case, is the way the PPS source
is connected to the system. LinuxPPS tries to optimize it.
The serial port is far from being a precision path, the "newer"
implementations being optimized for throughput (FIFOs) are even worse.
Any additional layer (USB especially) makes things just more and more worse.
As for linux itself, to increase predictability, any disturbing factor
should be minimized, if not eliminated. That would mean especially
laptop power consumption optimization gimmicks, which are useless in a
high performance server/workstation environment (eco, green, and the
other trendy marketingdroid buzzwords are lately more, and more abused
for a few percent power consumption reduction).
The suggested RTOS approach is workable, but it represents just another
example of tweaking a GPA to a specific task, which for a server is
usually not desired. The low latency patches are another example, used
usually for DAWs, but with the reverse side of increased processor loading.
First you must define what your goals, and necessities are, and then
optimize your system for the desired task - here linux is your friend,
with its almost unlimited tweaking options (no comparison to windumb.)
Also, don't use a dumbed down distro, and (learn to) patch/compile your
own special kernels (best stripped down of all useless ballast of a
"generic" one).

On 4/5/2012 1:22 AM, Mike S wrote:

I asked this on an NTP list, got some guesses, but no knowledgeable
responses.

I've got a Trimble Thunderbolt PPS source for NTP, Linux 2.6.35, on a
quad core CPU. PPS source is coming into a multiport serial card, which
/proc/interrupts shows is sharing IRQ with some inactive USB ports (IRQ
17). It's a PCI-E card, so it would be using MSI interrupts. My
understanding is that those aren't really "shared," in the traditional
sense, but IDK. The kernel clocksource is TSC, which is claimed to be
core invariant on my processor (AMD Athlon II 610e). Changing to HPET
doesn't help.

Running normally, I'll get about +- 20 us ptp of jitter (as reported by
ntpq -p, and in loopstats). If I load up the CPU (load average >4 is
swell), jitter will shrink to +- 1-2 us. I've played around with
different cpufreq setting, thinking it might be related to the processor
speed during an IRQ varying, but that seems to have minimal impact
(performance vs. conservative vs. ondemand).

I've also tried irqbalance, with no change in performance.

So, running a process(es) which keep the CPU completely busy reduces the
jitter. The busier, the better. Why? I'm guessing it has something to do
with interrupt latency, but why does a busy CPU make it more consistent
- I'd expect the opposite? The difference is very obvious.

Is there something else I can do to keep the jitter low?

Aside: Something which I believe was discussed here a few weeks ago -
clocksource speeds changing between reboots. I patched the kernel to
allow statically setting the TSC frequency (
http://old.nabble.com/-PATCH--tsc_khz%3D-boot-option-to-avoid-TSC-calibration-variance-td23494975.html
). This eliminates the semi-random, often 30-40 ppm change in frequency
reported by NTP between reboots. After tweaking, it's now consistently <
1 us, reboots be damned. This should be in the mainline kernel! This
made no difference to the jitter mentioned above, although non was
expected.

___
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] NTP jitter with Linux

On Wed, Apr 4, 2012 at 9:22 PM, Steve .  wrote:

> If the architecture has cache or wait states, it is still subject to be a
> moving target. I'm naturally skeptical on all architectures that have
> multiple channels, show me an architecture with cache or waits states and
> i'll show you a problem ( in regards to real time, that is)
>
> I stand firm that the only proper way to do this is with a 100%
> deterministic architecture.

..only proper way to do what?  The goal is to discipline the internal
software clock to GPS.  A typical application is a database server
that is running a web e-comerse site so that transactions get time
tagged.  So you would run a web, file or database server on a
deterministic, no cache micro controller?

Of course it would be easier to discipline a clock inside a purpose
built computer but that does not server the gol of time tagging
transactions in the server room

Or to say in another way.  If the goal is to deep a small micro
processor's clock in sync with GPS you don't need anything as complex
as NTP.   What NTP does well is that it can use reference loves that
are connected by slow and un-reliable data connections ilk the
Internet.  It works well over less than perfect links

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] NTP jitter with Linux

2012-04-04 Thread gary


http://www.newegg.com/Product/Product.aspx?Item=N82E16813131663


Yep. This is what I run 24 and 7 for a number of monitoring tasks. It 
has an Intel SSD. Mobo was $140 at Fry's. SSD was a Fry's special too. 
It has a Nvidia ion2 (it does home theater PC streaming at times.] USB 
3. Gigabit ethernet. Ignore the comment about it not playing 720P. It 
does 1080 no problem IF you are using hardware acceleration.


The D525 was the first 64 bit atom. It can use a full 4G of RAM. There 
may be better Atoms out there now since I've built this.


This particular mobo is very picky on RAM. It is best to read the 
feedback on Newegg, which was of more use than the Asus webpage. [I see 
someone claims 8Gbytes..eh, I think the chipset limit is 4.] Using 
SODIMMs is a drawback (more expensive than standard RAM).


---
"I did the same thing.  They work well and even if you have a "free"
quad core PC in a closet some place it is cost effective to toss the
thing in the trash and by a new computer with an Atom CPU."

___
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] NTP jitter with Linux

On Wed, Apr 4, 2012 at 9:17 PM, gary  wrote:
> I built a small form factor PC using the Intel D525.
>>
>>
>> http://ark.intel.com/products/49490/Intel-Atom-processor-D525-%281M-Cache-1_80-GHz%29

I did the same thing.  They work well and even if you have a "free"
quad core PC in a closet some place it is cost effective to toss the
thing in the trash and by a new computer with an Atom CPU.   The
reason is the price of electric power.  A large desktop PC, if you run
it 24x7 can add quite a bit to your utility bill.  After a year you
have paid for two Atoms  My Atom main board runs so cool there is no
cooling fan and it is still only just warm to the touch.   It is not
super fast but a 1.8GHz Atom is total overkill for running NTP

Get a flash drive, install the OS on that and run the little server
with no hard drive and no monitor, keyboard or mouse.
>
>
> If you look at the features (or lack thereof!), it lacks "turbo boost" and
> "enhanced Intel Speed Step technology". So you may not have to resort to
> using a uP if you don't want the PC clock to be a moving target. I was a bit
> surprised that the Atoms (at least to that generation) didn't play clock and
> core voltage games.
>
>
>
>
> ___
> 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] NTP jitter with Linux

On Thu, Apr 5, 2012 at 12:17 AM, gary  wrote:

> I built a small form factor PC using the Intel D525.
>
>>
>> http://ark.intel.com/products/49490/Intel-Atom-processor-D525-%281M-Cache-1_80-GHz%29
>>
>
> If you look at the features (or lack thereof!), it lacks "turbo boost" and
> "enhanced Intel Speed Step technology". So you may not have to resort to
> using a uP if you don't want the PC clock to be a moving target. I was a
> bit surprised that the Atoms (at least to that generation) didn't play
> clock and core voltage games.
>
>
>
> ___
> 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.
>

If the architecture has cache or wait states, it is still subject to be a
moving target. I'm naturally skeptical on all architectures that have
multiple channels, show me an architecture with cache or waits states and
i'll show you a problem ( in regards to real time, that is)

I stand firm that the only proper way to do this is with a 100%
deterministic architecture.

Steve
___
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] NTP jitter with Linux

2012-04-04 Thread gary


I built a small form factor PC using the Intel D525.

http://ark.intel.com/products/49490/Intel-Atom-processor-D525-%281M-Cache-1_80-GHz%29


If you look at the features (or lack thereof!), it lacks "turbo boost" 
and "enhanced Intel Speed Step technology". So you may not have to 
resort to using a uP if you don't want the PC clock to be a moving 
target. I was a bit surprised that the Atoms (at least to that 
generation) didn't play clock and core voltage games.




___
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] NTP jitter with Linux

It doesn't matter how fast the CPU clock rate is because you are not
dealing with a simple rate monotonicity. There are far too many
inconstancies in a PC to properly apply simple O(n) algorithms.

>Your reply ignores the simple fact that it _does_ track within a couple of
microseconds, as long as the processor is busy. The PC is _not_ the clock
source, a >PPS signal derived from GPS is. A PC is perfectly capable of 10
us accuracy. Even slower processors are capable of significantly better
accuracy

In this you are exposing a complex detail in the sampling conditions.
It is quite obvious that the experiment (The hardware,software, and
figures)
do not exhibit the precise control that you require. The more you focus,
the more problems you will find. Likewise, the mixed results you find
 from one experiment to another, strengthens the argument for
 lack of precision in the control. Whatever changes you make to increase
precision are not likely to apply to any one else.
  Those who do not see a problem are simply not objective in regards to the
scientific method. Just cargo cult science.

Steve

On Wed, Apr 4, 2012 at 11:42 PM, Mike S  wrote:

> On 4/4/2012 10:41 PM, Steve . wrote:
>
>> breaking the 1pps down as far as 10micro seconds,The
>> most obviously problem is that you are trying to use an inaccurate clock
>> source(the pc)
>>
>
> Your reply ignores the simple fact that it _does_ track within a couple of
> microseconds, as long as the processor is busy. The PC is _not_ the clock
> source, a PPS signal derived from GPS is. A PC is perfectly capable of 10
> us accuracy. Even slower processors are capable of significantly better
> accuracy - http://www.febo.com/pages/soekris/ .
>
>
>  Trying to tweak a PC to get 10microseconds (nyquist, 5microseconds max)
>>
>
> ???
>
> Maybe your PC runs in MHz, but mine runs in GHz. Are you confusing us with
> ns?
>
>
> ___
> 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] NTP jitter with Linux

2012-04-04 Thread Mike S


On 4/4/2012 10:41 PM, Steve . wrote:

breaking the 1pps down as far as 10micro seconds,The
most obviously problem is that you are trying to use an inaccurate clock
source(the pc)


Your reply ignores the simple fact that it _does_ track within a couple 
of microseconds, as long as the processor is busy. The PC is _not_ the 
clock source, a PPS signal derived from GPS is. A PC is perfectly 
capable of 10 us accuracy. Even slower processors are capable of 
significantly better accuracy - http://www.febo.com/pages/soekris/ .



Trying to tweak a PC to get 10microseconds (nyquist, 5microseconds max)


???

Maybe your PC runs in MHz, but mine runs in GHz. Are you confusing us 
with ns?


___
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] Do you know the correct time?

2012-04-04 Thread jerryfi

I thought many of you would be interested in this article :


http://www.devmonkey.edn.com/blog/jon-titus-blog/how-do-you-know-correct-time?cid=Newsletter+-+EDN+on+Development+Tools
___
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] Improving performance of a GPS antenna...?

2012-04-04 Thread lists

"I mounted the antenna on a small Al plate about 10 X 20 cm attached
to a balcony rail 3 stories from the ground with a clear view of about 75%
of the sky.

I would have expected that the receiver would see quite a few satellites, a
similar arrangement with a magnetic puck antenna regularly sees up to 6
birds. The Lucent however regularly only sees one. Could this be due to the
way it's mounted?  Could the baseplate have something to do with it?"

If the GPS is known to be good, I would suspect the antenna is defective. I 
wouldn't blame the ground plane. 

That said, I just wonder if you should use a ground plane for an antenna not 
designed to be used over a ground plane? Is the ground plane itself a source of 
reflection?

Incidentally, the RF absorbing part of the thread was quite interesting. 

___
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] NTP jitter with Linux

There are a lot of problems here.  I'm not even sure where to start, but
here goes.  ;)

I suspect if you keep within the input period, ie, of 1pps you may not see
long term problems. All the pase shifting will average out to 1 in the long
run. 1 second is a lot of time for a PC to miss, but it could theoretically
happen. Consider a page out pr fault in combination with and idle cpu and
 idle disk, or worse powered down disk.--that would be very expensive and
you may see a second or more with no signal, then all the signals show up
in a very tight window.

Back to the problem, breaking the 1pps down as far as 10micro seconds,The
most obviously problem is that you are trying to use an inaccurate clock
source(the pc) to sample a precise and accurate source. --A PC is not a
frequency standard so it can't be used for (2/f) ..(3/f) ..(n/f)
measurements. After if it could do this, we would see PC based high
precision and accuracy frequency standards.

One way to achieve your goal is to use a higher source frequency standard
to drive a  cacheless microcontroller(most like a low end 8bit model),
derive a precision timer from the high frequency source, log the 1pps
signal and apply a time stamp to each sample.  Pull those samples via
USB/Serial, whatever...  Though this all defeats the purpose of NTP doesn't
it?

I think the simple answer here is that PC architecture is not intended for
such precise, accurate measurements.

Steve

Trying to tweak a PC to get 10microseconds (nyquist, 5microseconds max)...
I don't think you'll ever do it, or at least not in a way that can be peer
reviewed.

On Wed, Apr 4, 2012 at 6:22 PM, Mike S  wrote:

> I asked this on an NTP list, got some guesses, but no knowledgeable
> responses.
>
> I've got a Trimble Thunderbolt PPS source for NTP, Linux 2.6.35, on a quad
> core CPU. PPS source is coming into a multiport serial card, which
> /proc/interrupts shows is sharing IRQ with some inactive USB ports (IRQ
> 17). It's a PCI-E card, so it would be using MSI interrupts. My
> understanding is that those aren't really "shared," in the traditional
> sense, but IDK. The kernel clocksource is TSC, which is claimed to be core
> invariant on my processor (AMD Athlon II 610e). Changing to HPET doesn't
> help.
>
> Running normally, I'll get about +- 20 us ptp of jitter (as reported by
> ntpq -p, and in loopstats). If I load up the CPU (load average >4 is
> swell), jitter will shrink to +- 1-2 us. I've played around with different
> cpufreq setting, thinking it might be related to the processor speed during
> an IRQ varying, but that seems to have minimal impact (performance vs.
> conservative vs. ondemand).
>
> I've also tried irqbalance, with no change in performance.
>
> So, running a process(es) which keep the CPU completely busy reduces the
> jitter. The busier, the better. Why? I'm guessing it has something to do
> with interrupt latency, but why does a busy CPU make it more consistent -
> I'd expect the opposite? The difference is very obvious.
>
> Is there something else I can do to keep the jitter low?
>
> Aside: Something which I believe was discussed here a few weeks ago -
> clocksource speeds changing between reboots. I patched the kernel to allow
> statically setting the TSC frequency (
> http://old.nabble.com/-PATCH--tsc_khz%3D-boot-option-to-avoid-TSC-calibration-variance-td23494975.html).
>  This eliminates the semi-random, often 30-40 ppm change in frequency
> reported by NTP between reboots. After tweaking, it's now consistently < 1
> us, reboots be damned. This should be in the mainline kernel! This made no
> difference to the jitter mentioned above, although non was expected.
>
> ___
> 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] Improving performance of a GPS antenna...?

2012-04-04 Thread Morris Odell

Hi all,

While we're on this subject, I have a related question. 

I recently bought one of those cone shaped Lucent GPS timing antennas from a
vendor in China. I'm using it for one of my GPS controlled clocks which
contains a 6 channel Oncore VP receiver and is on the end of about 15 feet
of RG58. I mounted the antenna on a small Al plate about 10 X 20 cm attached
to a balcony rail 3 stories from the ground with a clear view of about 75%
of the sky.

I would have expected that the receiver would see quite a few satellites, a
similar arrangement with a magnetic puck antenna regularly sees up to 6
birds. The Lucent however regularly only sees one. Could this be due to the
way it's mounted?  Could the baseplate have something to do with it?

Any advice would be welcome.

Morris 


___
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] NTP jitter with Linux

2012-04-04 Thread Dennis Ferguson

On 4 Apr, 2012, at 16:10 , Mike S wrote:

> On 4/4/2012 6:51 PM, Eric Williams wrote:
>> Could the CPU be reducing its clock rate when it's not being loaded?  Just
>> a guess, most multi-core processors these days have power saving features
>> like that.
>> 
>> On Wed, Apr 4, 2012 at 3:22 PM, Mike S  wrote:
>>> >  I've played around with different
>>> >  cpufreq setting, thinking it might be related to the processor speed 
>>> > during
>>> >  an IRQ varying, but that seems to have minimal impact (performance vs.
>>> >  conservative vs. ondemand).
> 
> Setting /sys/devices/system/cpu/cpuX/cpufreq/scaling_governor to 
> "performance" should lock that core to the max clock rate.
> 
> In looking that up, I found that the script I made to set this was just doing 
> cpu0 (i.e. one of four cores). Doh! I've changed it to do all 4 cores, and am 
> trying that again to see if that's it.

I don't know much about Linux but if that doesn't help try to find out what
the operating system does in its idle loop.  If it is ending up in some
power-saving state when it is idle it may be volunteering to do this by
executing some magic `wait' instruction which does the power-saving thing as
a side effect, and if you can find where it does this you might be able to
work around it.

Dennis Ferguson

___
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] NTP jitter with Linux

2012-04-04 Thread Javier Herrero


El 05/04/2012 00:58, gary escribió:

That is the AMD speed step, but doesn't intel do the same thing?

I suppose so. In any case, under Linux you can force off the speed step 
(i.e. force the CPU to a fixed clock). I did that some time ago in a 
Dell server with a dual quad-core Opteron with Fedora Core 10... but 
don't remember the procedure


Regards,

Javier

___
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] NTP jitter with Linux

2012-04-04 Thread Mike S

On 4/4/2012 6:51 PM, Eric Williams wrote:

Could the CPU be reducing its clock rate when it's not being loaded?  Just
a guess, most multi-core processors these days have power saving features
like that.

On Wed, Apr 4, 2012 at 3:22 PM, Mike S  wrote:

>  I've played around with different
>  cpufreq setting, thinking it might be related to the processor speed during
>  an IRQ varying, but that seems to have minimal impact (performance vs.
>  conservative vs. ondemand).

Setting /sys/devices/system/cpu/cpuX/cpufreq/scaling_governor to 
"performance" should lock that core to the max clock rate.

In looking that up, I found that the script I made to set this was just 
doing cpu0 (i.e. one of four cores). Doh! I've changed it to do all 4 
cores, and am trying that again to see if that's it.

___
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] NTP jitter with Linux

2012-04-04 Thread Randall Prentice

The INTEL HRET (High Resolution blagh Timer) seemed to work whereas the AMD 
equivalent didn't seem to fix the problem.  
Note: this was older AMD ATHLON processors,  they may have fixed this by now.

Regards
Randall
-Original Message-
From: time-nuts-boun...@febo.com [mailto:time-nuts-boun...@febo.com] On Behalf 
Of gary
Sent: Thursday, 5 April 2012 10:58 a.m.
To: Discussion of precise time and frequency measurement
Subject: Re: [time-nuts] NTP jitter with Linux

That is the AMD speed step, but doesn't intel do the same thing?

Incidentally, there are hacks for linux to make it more real time, i.e. 
lower latency. I never messed with them, but you find this mentioned related to 
multimedia oriented distributions.

On 4/4/2012 3:53 PM, Randall Prentice wrote:
> I found that the AMD processors change CPU frequency with load and this 
> seemed to upset any NTP calculations.
>
> In the end I went to Intel CPU  (Mutter mutter).
>
> Regards
> Randall

___
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] Improving performance of a GPS antenna...?

2012-04-04 Thread Bill Hawkins

My first job was in a blasting cap plant in 1960. Raw materials and
finished product were kept in earthen bunkers separated by a distance
that would prevent an explosion in one from propagating (the distances
were found by experience).

Tall, grounded masts were spaced among the bunkers to prevent strikes
by lightning. There is a 45 degree cone of protection from the top of
the mast to the ground. This is based on British Navy experience with
sail masts of warships between 1793 and 1847. There were 220 strikes
reported in that time. 2/3 of them struck the top masts. Only 1 in 50
struck the hull below the masts. See the report at
http://www.lightningsafety.com/nlsi_lhm/conventionalLPT.pdf
and search the PDF for "cone of protection"

Then again, this outfit says the cone is a myth
http://www.lightningsafety.com/index.html

All I know is that we never lost a bunker in the 5 years I was there.
We did have thunderstorms near Kingston, NY, 90 miles above NYC. The
safety department tested the mast grounds with an instrument like a
megger that used two probes driven in the ground (IIRC) to measure
less than a tenth of an ohm resistance to ground.

Looking back on it, I don't think anything would survive a direct hit
on the mast. It was more a matter of the mast misdirecting the leader
of the strike to look elsewhere for ground. Or, given the small numbers,
maybe it was probability that saved us, like snapping your fingers to
keep the tigers away in North America.

Lightning arrestors for lead-ins are still a very good investment.

Bill Hawkins

PS- The worst explosion I remember there was the day a new technician
took a few pounds of scrap powder to the burning grounds. It was
supposed to be mixed with ten times as much sawdust to make it burn
instead of detonate. He got the proportions backwards. The explosion
got the attention of everybody in the plant.



-Original Message-
From: Chris Albertson
Sent: Wednesday, April 04, 2012 12:53 PM

People will argue that if you ground the pole it then will become a
"lightning magnet"   That thinking is 180 degrees backward.  A pole
becomes a lightning magnet if it is allowed to charge above ground
potential.  So for most of us who don't live in Florida a #10 wire
clamped to the mast and run off to a ground rod is good enough.


___
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] NTP jitter with Linux

2012-04-04 Thread gary


That is the AMD speed step, but doesn't intel do the same thing?

Incidentally, there are hacks for linux to make it more real time, i.e. 
lower latency. I never messed with them, but you find this mentioned 
related to multimedia oriented distributions.



On 4/4/2012 3:53 PM, Randall Prentice wrote:

I found that the AMD processors change CPU frequency with load and this seemed 
to upset any NTP calculations.

In the end I went to Intel CPU  (Mutter mutter).

Regards
Randall


___
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] NTP jitter with Linux

2012-04-04 Thread Randall Prentice

I found that the AMD processors change CPU frequency with load and this seemed 
to upset any NTP calculations.

In the end I went to Intel CPU  (Mutter mutter).

Regards
Randall
-Original Message-
From: time-nuts-boun...@febo.com [mailto:time-nuts-boun...@febo.com] On Behalf 
Of Mike S
Sent: Thursday, 5 April 2012 10:22 a.m.
To: Discussion of precise time and frequency measurement
Subject: [time-nuts] NTP jitter with Linux

I asked this on an NTP list, got some guesses, but no knowledgeable responses.

I've got a Trimble Thunderbolt PPS source for NTP, Linux 2.6.35, on a quad core 
CPU. PPS source is coming into a multiport serial card, which /proc/interrupts 
shows is sharing IRQ with some inactive USB ports (IRQ 17). It's a PCI-E card, 
so it would be using MSI interrupts. My understanding is that those aren't 
really "shared," in the traditional sense, but IDK. The kernel clocksource is 
TSC, which is claimed to be core invariant on my processor (AMD Athlon II 
610e). Changing to HPET doesn't help.

Running normally, I'll get about +- 20 us ptp of jitter (as reported by ntpq 
-p, and in loopstats). If I load up the CPU (load average >4 is swell), jitter 
will shrink to +- 1-2 us. I've played around with different cpufreq setting, 
thinking it might be related to the processor speed during an IRQ varying, but 
that seems to have minimal impact (performance vs. conservative vs. ondemand).

I've also tried irqbalance, with no change in performance.

So, running a process(es) which keep the CPU completely busy reduces the 
jitter. The busier, the better. Why? I'm guessing it has something to do with 
interrupt latency, but why does a busy CPU make it more consistent
- I'd expect the opposite? The difference is very obvious.

Is there something else I can do to keep the jitter low?

Aside: Something which I believe was discussed here a few weeks ago - 
clocksource speeds changing between reboots. I patched the kernel to allow 
statically setting the TSC frequency ( 
http://old.nabble.com/-PATCH--tsc_khz%3D-boot-option-to-avoid-TSC-calibration-variance-td23494975.html
). This eliminates the semi-random, often 30-40 ppm change in frequency 
reported by NTP between reboots. After tweaking, it's now consistently <
1 us, reboots be damned. This should be in the mainline kernel! This made no 
difference to the jitter mentioned above, although non was expected.

___
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] NTP jitter with Linux

2012-04-04 Thread Eric Williams

Could the CPU be reducing its clock rate when it's not being loaded?  Just
a guess, most multi-core processors these days have power saving features
like that.
--
eric

On Wed, Apr 4, 2012 at 3:22 PM, Mike S  wrote:

> I asked this on an NTP list, got some guesses, but no knowledgeable
> responses.
>
> I've got a Trimble Thunderbolt PPS source for NTP, Linux 2.6.35, on a quad
> core CPU. PPS source is coming into a multiport serial card, which
> /proc/interrupts shows is sharing IRQ with some inactive USB ports (IRQ
> 17). It's a PCI-E card, so it would be using MSI interrupts. My
> understanding is that those aren't really "shared," in the traditional
> sense, but IDK. The kernel clocksource is TSC, which is claimed to be core
> invariant on my processor (AMD Athlon II 610e). Changing to HPET doesn't
> help.
>
> Running normally, I'll get about +- 20 us ptp of jitter (as reported by
> ntpq -p, and in loopstats). If I load up the CPU (load average >4 is
> swell), jitter will shrink to +- 1-2 us. I've played around with different
> cpufreq setting, thinking it might be related to the processor speed during
> an IRQ varying, but that seems to have minimal impact (performance vs.
> conservative vs. ondemand).
>
> I've also tried irqbalance, with no change in performance.
>
> So, running a process(es) which keep the CPU completely busy reduces the
> jitter. The busier, the better. Why? I'm guessing it has something to do
> with interrupt latency, but why does a busy CPU make it more consistent -
> I'd expect the opposite? The difference is very obvious.
>
> Is there something else I can do to keep the jitter low?
>
> Aside: Something which I believe was discussed here a few weeks ago -
> clocksource speeds changing between reboots. I patched the kernel to allow
> statically setting the TSC frequency ( http://old.nabble.com/-PATCH--**
> tsc_khz%3D-boot-option-to-**avoid-TSC-calibration-**
> variance-td23494975.html).
>  This eliminates the semi-random, often 30-40 ppm change in frequency
> reported by NTP between reboots. After tweaking, it's now consistently < 1
> us, reboots be damned. This should be in the mainline kernel! This made no
> difference to the jitter mentioned above, although non was expected.
>
> __**_
> 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] NTP jitter with Linux

2012-04-04 Thread Mike S

I asked this on an NTP list, got some guesses, but no knowledgeable
responses.

I've also tried irqbalance, with no change in performance.

Is there something else I can do to keep the jitter low?

___
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] Improving performance of a GPS antenna...?

2012-04-04 Thread Brooke Clarke


Hi Mike:

I used military surplus radar absorbing material to stop reflections on a satellite antenna by applying it to the rain 
gutter, see:

http://www.prc68.com/I/Images/SB_angw.jpg

A sheet of this stuff about 4 x 6 feet weighed maybe 40 pounds.  An easy way to confirm it works is to use it to block a 
receiver antenna and see how far the signal goes down.


Have Fun,

Brooke Clarke
http://www.PRC68.com
http://www.end2partygovernment.com/Brooke4Congress.html


Michael Baker wrote:

Hello, Time-Nutters--

I saw a rather expensive GPS antenna made by one of the
big-name GPS survey equipment mfgrs that was mounted
on top of a 12 or 15 inch diameter disc about 3/4 inch thick.

Turns out that the disc is made of some sort of RF absorbent
foam covered by a weather-proofing coating of some sort.

If one were to try to home-brew something like this, where
would a small piece of the RF absorbent material be obtained
without having to spend too much $$ for this experiment?

Thanks for any feedback on this!!

Mike Baker
WA4HFR


___
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] Improving performance of a GPS antenna...?

On Wed, Apr 4, 2012 at 10:31 AM, beale  wrote:
>>  ---Original Message---
>>  From: Chris Albertson 
>>  Better and faster way to get good performance is to buy a 10 foot section 
>> of 3/4" pipe and a pipe flange.  Place your GPS antenna on the  flange and 
>> then attach the pipe to the tallest thing around.  Then  there will be no 
>> reflectors that are above the antenna's horizon and no multi path.
>
> That should work, but if you live in thunderstorm country, making your 
> antenna the tallest thing around can come back to bite you.

people say this all the time but many ham radio operators have antenna
masts that are very tall and actually survive storms.  All TV and
radio stations do too.And then I owned a sail boat for years along
with thousands of others.   and it does not take much of a mast for
you to be the tallest thing on the water. The trick to being safe
is to make sure the antenna has a VERY low impedance path to a good
ground.  On my boat I had a 60+ foot aluminum mast that was over a
6,000 pound cast lead keel and the two where electrically connected.
 So one end of the system had a good saltwater ground.   It is hard to
do that well at home but you can come close.

People will argue that if you ground the pole it then will become a
"lightening magnet"   That thinking is 180 degrees backward.  A pole
becomes a lightening magnet if it is allowed to charge above ground
potential.  So for most of us who don't live in Florida and #10 wire
clamped to the mast and run off to a ground rod is good enough.  It is
also required by most building codes.   Even outdoor TV antenna have
the same code requirement.

One more argument:  Let's agree the a tall grounded pole is a
lightening rod.  then if the house is going to be struck would you
prefer to have the rod or not?  Without it, the lighting will find
some other patch like a furnace exhaust vent or whatever

So I guess I'd say that a GPS on a mast is not worse than any other antenna.
>
> ___
> 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] Improving performance of a GPS antenna...?

2012-04-04 Thread beale

>  ---Original Message---
>  From: Chris Albertson 
>  Better and faster way to get good performance is to buy a 10 foot section of 
> 3/4" pipe and a pipe flange.  Place your GPS antenna on the  flange and then 
> attach the pipe to the tallest thing around.  Then  there will be no 
> reflectors that are above the antenna's horizon and no multi path.

That should work, but if you live in thunderstorm country, making your antenna 
the tallest thing around can come back to bite you.

___
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] Improving performance of a GPS antenna...?

Maybe get some a wide tupperware dish and fill it with water and just
a little salt.  It may not be as portable but it would turn RF into
heat well enough.   The trick is to add sale until the water will just
conduct RF so you need an RF signal generator and a pair of metal
probes and a way to measure RF current

In all cases if you build this using any material, water, foam,
conductive paint or whatever you will need to have some way to measure
its effectiveness.How to measure GPS multi path resistance?

Better and faster way to get good performance is to buy a 10 foot
section of 3/4" pipe and a pipe flange.  Place your GPS antenna on the
flange and then attach the pipe to the tallest thing around.  Then
there will be no reflectors that are above the antenna's horizon and
no multi path.

Surveyors need the special antenna because they work close to the
ground and can't choose a good antenna location.  You are not a
surveyor and can simply move the antenna.

On Wed, Apr 4, 2012 at 5:53 AM, Michael Baker  wrote:
> Hello, Time-Nutters--
>
> I saw a rather expensive GPS antenna made by one of the
> big-name GPS survey equipment mfgrs that was mounted
> on top of a 12 or 15 inch diameter disc about 3/4 inch thick.

___
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] GPS antennas


Oops hit send accidentally..

Charles Counselman, Multipath-Rejecting GPS antennas, IEEE Proceedings, 
V87, #1, Jan 1999, pp 86-91


The antenna in the paper is one approach, but of more interest are the 
references..


___
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] more GPS antenna stuff


A google of helibowl GPS turns up dozens..


But here's a reference that might be useful to the tinkerer:
M

___
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] Improving performance of a GPS antenna...?


On 4/4/12 7:35 AM, Chuck Forsberg WA7KGX N2469R wrote:

If foliage does such a number on GPS signals, just fill a big garbage bag
with yard debris and set the antenna in the middle of that.



*wet* yard debris..


___
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] Improving performance of a GPS antenna...?


On 4/4/12 5:53 AM, Michael Baker wrote:

Hello, Time-Nutters--

I saw a rather expensive GPS antenna made by one of the
big-name GPS survey equipment mfgrs that was mounted
on top of a 12 or 15 inch diameter disc about 3/4 inch thick.

Turns out that the disc is made of some sort of RF absorbent
foam covered by a weather-proofing coating of some sort.

If one were to try to home-brew something like this, where
would a small piece of the RF absorbent material be obtained
without having to spend too much $$ for this experiment?



This material may or may not be what you want
http://www.chomerics.com/products/CHO-MUTE.htm

Parker-Chomerics *does* do samples  (probably a 10-15cm square piece 
that is mailable)


http://www.lairdtech.com/ is another supplier

http://www.masttechnologies.com/magnetic-vs-dielectric-absorber-selection/

http://www.emc-products.dk/

http://www.arc-tech.com/

http://www.aemi-inc.com/  - pyramidal absorber
http://www.ets-lindgren.com/Absorbers

If you get the blue pyramidal absorber, get the kind that has the 
waterproof coating.. not only is it more rugged, it doesn't shed as much 
of that horrible blue/black conductive dust.  (we had a roof leak in one 
of our indoor ranges at JPL a few years ago, and wound up having to buy 
all new absorber.. turns out that the fire-proofing and conductive salts 
wash out..)



Even if you have to buy the stuff, it's not all that expensive, usually. 
 Last time (5 years ago) that I bought pyramidal absorber it was 
something like $20/2x2 foot panel.  The elastomer isn't a whole lot more 
expensive: it's made in huge quantities and the raw materials are cheap. 
 The dominant cost is the packaging/shipping & handling.


the ferrite loaded elastomer is quite dense.  It reminds me of the lead 
apron they put on you when you get dental x-rays.  It's thin and floppy, 
but surprisingly heavy.


Once you get a handle on the names and kinds of stuff you might want, 
you can probably find a way to get it.  You might find it at somewhere 
like Newark or Allied.



___
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] Improving performance of a GPS antenna...?

2012-04-04 Thread Chuck Forsberg WA7KGX N2469R


If foliage does such a number on GPS signals, just fill a big garbage bag
with yard debris and set the antenna in the middle of that.

On 04/04/2012 05:53 AM, Michael Baker wrote:

Hello, Time-Nutters--

I saw a rather expensive GPS antenna made by one of the
big-name GPS survey equipment mfgrs that was mounted
on top of a 12 or 15 inch diameter disc about 3/4 inch thick.

Turns out that the disc is made of some sort of RF absorbent
foam covered by a weather-proofing coating of some sort.

If one were to try to home-brew something like this, where
would a small piece of the RF absorbent material be obtained
without having to spend too much $$ for this experiment?

Thanks for any feedback on this!!

Mike Baker
WA4HFR


___
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.



--
Chuck Forsberg WA7KGX N2469R c...@omen.com   www.omen.com
Developer of Industrial ZMODEM(Tm) for Embedded Applications
  Omen Technology Inc  "The High Reliability Software"
10255 NW Old Cornelius Pass Portland OR 97231   503-614-0430


___
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] Improving performance of a GPS antenna...?