Re: [time-nuts] TICC resolution...

[Wojciech Owczarek]

Tom,

Thanks for your comments - the plot was really a quick example only. Yes, I
am aware of the TDC7200 method of operation, all I meant to say was that
the 55 ps clusters can be clearly seen, and I was expecting the jitter to
blur the lines somewhat more.

It was a combination of a histogram with a low number of bins, few samples,
and judging by the phase plot I am also suspecting quantisation of the 1PPS
output.

The source is quite stable, although it is being actively GPS+GLN
disciplined. While the 10 MHz and the 1PPS come from the same unit, they do
not come directly from the PRS10, they hit some
CMOS->LVDS->distribution->CMOS and some 74xxx, across different paths, so
all that takes a toll. I have some less complex systems available where
this should be cleaner.

Anyhow, the TICC is proving an invaluable tool for field testing,
calibration, and even cable delay measurement..

...One reaches a whole new level of anal retentiveness once in the sub-100
ps range.

Thanks,
Wojciech



On 4 April 2017 at 23:03, Tom Van Baak <t...@leapsecond.com> wrote:

> Hi Wojciech,
>
> Thanks for sharing your TICC plot. Yes, the periodic peaks show the ~55 ps
> quantization, which is the limiting factor of the TICC's single-shot
> resolution. The TICC is based on the TDC7200 Time-to-Digital Converter
> (TDC) chip, which uses a digital ring oscillator, which a mobius strip-like
> closed loop of an odd number of gates. So this quantization is expected and
> readily measurable with any pair of stable sources.
>
> But I'm not sure why your plot is so ragged. Either you have too few
> samples, or one of your sources is unstable, or maybe the 1PPS is itself
> quantized, or perhaps some low order digits from the TICC are truncated
> before you made your plot.
>
> If you use cleaner sources and longer runs you can get textbook-pretty
> results.
>
> The attached plot is the result of a 30 hour run on a TICC (beta, Nov
> 2016):
> http://leapsecond.com/pages/ticc/ticc-log5342-hist-1.gif
>
> Also attached is what happens if you zoom in a bit:
> http://leapsecond.com/pages/ticc/ticc-log5342-hist-3.gif
>
> In that second plot both the 1 ps granularity of the TICC ascii output and
> the ~55 ps quantization of the TDC7200 chip are visible.
>
> A TICC tends to have slightly better resolution than a hp 53132A but the
> "character" of their resolution is quite different: the TICC has strong
> quantization peaks and the 53132 is more Gaussian; the TICC outputs with 1
> ps resolution (overly optimistic) and the hp rounds to 0.1 ns (probably
> conservative). If you try to push the envelope with better-than-spec
> performance out of a TICC or try to automate channel-channel-reference
> calibration, these details start to matter.
>
> /tvb
>
>
> - Original Message -
> From: "Wojciech Owczarek" <wojci...@owczarek.co.uk>
> To: "Discussion of precise time and frequency measurement" <
> time-nuts@febo.com>
> Sent: Tuesday, April 04, 2017 9:20 AM
> Subject: [time-nuts] TICC resolution...
>
>
> > ___
> > time-nuts mailing list -- time-nuts@febo.com
> > To unsubscribe, go to https://www.febo.com/cgi-bin/m
> ailman/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/m
> ailman/listinfo/time-nuts
> and follow the instructions there.
>



-- 
-

Wojciech Owczarek
___
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] TICC resolution...

[Wojciech Owczarek]

___
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] Optical Cesium or maybe Cesium "light"!

[Wojciech Owczarek]

I tried lifting it but it wouldn't fit in my bag :(


___
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] A (slightly) different apu2 question

[Wojciech Owczarek]

On 18 November 2016 at 09:21, Martin Burnicki <martin.burni...@burnicki.net>
wrote:
>
> Just a few thoughts regarding NTP vs. PTP:
>


Oh dear... OK, before this snowballs into a bigger discussion this was not
meant to be:

My original post was _not_ about PTP vs. NTP, it was about the APU2 boards
and hardware timestamping.

My only point was to highlight the following:

1 This board has got exposed test pads for lots of 1PPS / frequency in /
out pins tied to timestamping hardware making it very easy to tap into
them. This is a great opportunity which begs to be exploited.

2. With a stable 1PPS from GPS or another source, this board can serve
nanosecond time, and that includes NTP in hardware, because the Intel NICs
can timestamp every packet, not just PTP. And yes, this mostly matters for
LAN.

I am fully aware of what you listed. NTP is just a different beast and
silicon vendors jumped onto PTP, and PTP inherently lacks the sophisticated
quorum and trust mechanisms NTP has, and yes, those are key items on the
P1588 WG agenda.

Thanks,
Wojciech

-- 
-

Wojciech Owczarek
___
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] A (slightly) different apu2 question

[Wojciech Owczarek]

>
>
> NTP does not require softstamps.  NTP can be (and I believe it has been in
> a product) modified to use "PTP" hardware (hardstamps) and  reasonably
> current releases can run with "drivestamps" (sampled in the NIC driver)
> between cooperating endpoints.


Of course it does not *require* software timestamps, I never said that, it
is just the fact that most people use it with software timestamps, even if
the NIC permits hardware timestamps. You need a secondary servo to sync the
NIC to O/S clock if you want to serve that (or consume that) - or sync the
NIC to external 1PPS. What you call a "drivestamp", I call a software
timestamp. If it's not a function of the silicon, it's software. All I
meant was that there is some unexploited potential.

-- 
-

Wojciech Owczarek
___
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] A (slightly) different apu2 question

[Wojciech Owczarek]

...do excuse the slightly off-topic 5(insert your preferred sub-currency
here).

I think many people put a significant effort into getting a precise pulse
into a board like the APU2, losing a lot of precision and accuracy by
getting it into the O/S software clock, and then perfectly waste what's
left by then retransmitting it via NTP with software timestamping. I am not
saying that there is anything wrong with NTP, just that software packet
transmission and receipt timestamps ruin both precision and accuracy.

The APU2 is a real gem for many reasons, but one is of significance for
time sync. The board uses discrete i210 PHY/MAC chips which support
hardware timestamping (of all packets, not just PTP) - rather than using an
in-SOC Intel MAC paired with a different PHY like Marvell or, diety forbid,
Realtek. When designing the board, Pascal did the time nuts a huge favour
by presenting pins 60-63 of each i210 as test pads on the board, four per
chip. These pins are software-defined I/O pins which can be used for 1PPS
output, arbitrary square wave output, and input event timestamping - all
tied to the i210 hardware clocks.

I have exchanged a few e-mails with Pascal and he hinted that he will
consider breaking those i210 pads either as a pin header or possibly as
u.FL connectors - maybe not all, but say two per NIC. The only thing that
could make this board better (but then it would be a different board) is if
it used the latest generation of Intel Atom, where they implemented counter
correlation between the CPU and NICs, allowing for very tight O/S clock to
NIC clock sync. But that Atom was only recently announced (Skylake CPUs do
this already), and an AMD CPU was selected for the APU2 for specific
reasons.

Another small board with similar potential is the upcoming Minnowboard
Turbot Dual-E (
http://www.adiengineering.com/products/minnowboard-turbot-duale/):
Atom-based, small, with two i211 right on the board.

Cheers,
Wojciech


On 17 November 2016 at 13:04, Attila Kinali <att...@kinali.ch> wrote:

> On Wed, 16 Nov 2016 15:24:06 -0800
> Jay Grizzard <elfchief-timen...@lupine.org> wrote:
>
> > On the apu2, this crystal is easily accessible (at least as easy as
> > anything SMD is). Can anyone think of a reason that it wouldn't be
> > feasible to replace this crystal with an external reference, à la the
> > widely known clockblock + Soekris net4501 hack (but with 64x the RAM)? I
> > figure the higher frequency might make it a bit trickier to get the
> > signal to the board intact, but is there any other good reason this
> > wouldn't work?
>
> You should check with Pascal Dornier (the guy behind pc-engines).
> He can exactly tell you what would work and what wouldn't.
> And he is generally very very helpful.
>
> Attila Kinali
> --
> It is upon moral qualities that a society is ultimately founded. All
> the prosperity and technological sophistication in the world is of no
> use without that foundation.
>  -- Miss Matheson, The Diamond Age, Neil Stephenson
> ___
> 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.
>



-- 
-

Wojciech Owczarek
___
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] Leap second to be introduced at midnight UTC December 31 this year

[Wojciech Owczarek]

Every year... always makes me wonder, do these vendors even test this 
themselves? I know at least one vendor who disn't have GPS simulators and 
relied on Trimble's built-in test mode - which gives you 13-bit week counters, 
whereas the satellites give you 10-bit counters. So the vendor assumed 13-bit 
and was comparing the current wc to 13-bit that never came. Luckily I found the 
issue months before the event, and only because we purchased GPS simulators - 
which I recommend to anyone running timing services in production.

Oh well, at least this keeps us busy.


  Original Message  
From:noah.ro...@gmail.com
Sent:21 July 2016 5:11 p.m.
To:time-nuts@febo.com
Reply to:time-nuts@febo.com
Cc:hmur...@megapathdsl.net
Subject:Re: [time-nuts] Leap second to be introduced at midnight UTC December 
31 this year



> On Jul 21, 2016, at 5:23 AM, Hal Murray  wrote:
> 
> 
> noah.ro...@gmail.com said:
>> Discovered that my commercial GPS appliances opted to *apply* yesterday's
>> pending leap second, which has made for an interesting day.
> 
> Could you please say more?
> 
> How are you working around it?
> 
> Vendor?  Model?  Can you take the cover off (or peer in through the vents) 
> and see what type of GPS receiver they are using?

In earlier email. 

> 
> I assume the gear is recent or the problem would have been discovered the 
> last time we had a leap second.  Have you contacted the vendor?  Have they 
> confirmed the problem?  Any estimate on when they will ship new firmware?

We just finished replacing our previous gear with this a week ago; timing is 
everything. :)  Vendor was contacted yesterday and have supplied a patch this 
morning to reduce the GPS->UTC offset back to 17 until they get a more 
permanent fix from Trimble. I've not installed it yet, but the vendor states 
the patch won't persist across reboots. 

--n
___
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] 1 PPS 50-ohm driver

[Wojciech Owczarek]

Florian, Gerhard, All,

Thank you for the extensive answers. Just to think that at some point I
passed exams where I had to implement truth tables in "raw" NMOS/PMOS -
things evaporate quickly enough if you don't refresh, and then years go by
and you wish you had been paying more attention. The moment you mentioned
that a CMOS NOT gate only requires two transistors, it all came back.

As to Beaglebone Black and "use use whatever you have", fine for 1PPS
input, I'm using an SN74AHCT125 for the moment, I may revisit that. But for
the output, I do want the slope to look decent and the signal to be able to
travel over some length of coax, even if not so precise. I am developing a
PTP slave timing probe based on the BBB - you sync it to PTP and take a
reference 1PPS input to compare the phase. Or alternatively, sync time to
GPS + 1PPS, or just phase to 1PPS, and run PTP read-only and report the
observed offset.

The hardware right now is the bare minimum required to get the signals in.
On the software side, for 1PPS input, I am able to stay within the
resolution of the counter used for event capture, which runs at ~24 MHz, so
about +/-40 ns, I'm getting a pretty clean sawtooth. For the 1PPS output,
I'm using a PWM pulse, which is aligned to top of PTP second using a PI
servo (counter overflow generates a PWM pulse and a timestamp at the same
time). PI servo because it's a standalone device and the real frequency can
be unknown. Well, I can experiment with pure correct-and-rearm next, PI was
a quick and lazy solution. Also the PTP clock resolution is 4 ns, so
quantisation error is a problem, more for the output than for the input. I
can't test the quality of the output until this is hooked up to a proper
counter. Well, in fact I can't compensate for the h/w interface delays
either until I run this against a decent scope.

Yet another embedded project, but I will be happy to share the results when
ready. This is definitely not lab-grade stuff, but it is designed to be
used environments where you're aiming for sub-100 us accuracy, so 100 ns is
well enough, and for cheap. BBB is 100 megabit, but the upcoming BBB
Enhanced (third party fork) is gigabit.

Kind regards,
Wojciech
___
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] 1 PPS 50-ohm driver

[Wojciech Owczarek]

A slightly naive question(s) perhaps, so do excuse me, but I reckon this is
a good opportunity to ask since I am approaching the same design questions
(this is a 1PPS in + 1PPS out driver for the Beaglebone Black, to/from its
PTP clock). This involves 5v / 3.3v conversion but that's another topic.

IC spec sheets are one thing, but since the Time Nuts have seen and done it
all... Why an inverting buffer? Is there an advantage in using inverted
logic for 1PPS? I have come across other timing kit that internally uses
falling edge, which is eventually inverted when interfacing with the
outside world. Is this common, and why? If my output is rising edge right
from the PWM pin I'm using to generate my 1PPS (again, separate topic), do
I gain anything by inverting it and using an inverting buffer? Is this a
matter of different rise/fall propagation delays over the various ICs?

Thanks,
Wojciech

-- 
-

Wojciech Owczarek
___
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] GPS Outage

[Wojciech Owczarek]

Funny how apparently Trimble were involved in the wk860 problem, I thought they 
famously used their leap second based rollover protection: 
http://www.google.co.uk/patents/US5923618 :) Maybe that algorithm isn't that 
smart after all.

Thanks,
Wojciech 

  Original Message  
From:martin.burni...@burnicki.net
Sent:29 February 2016 11:02 am
To:time-nuts@febo.com
Reply to:time-nuts@febo.com
Cc:hmur...@megapathdsl.net
Subject:Re: [time-nuts] GPS Outage

Hal,

Hal Murray wrote:
> 
> martin.burni...@burnicki.net said:
>>> Strange that at least 3 independant firmware trees/development teams should
>>> chose the same magic wk860.
> 
>> I don't find it strange. If the next firmware version is based on the
>> previous version and none of the developers has stumbled across this
>> potential problem earlier ... 
> 
> That sounds like poor software engineering.  Or poor engineering management.
> 
> The wk860 is supposed to represent the build time of the software ...

Do you *know* this, or are you just *assuming* this? ;-)

> so it will 
> work for 20 years from when it was built rather than 20 years from when the 
> 10 bit week counter last rolled over or 20 years from when the constant was 
> last updated.

There are also approaches where the proper extension of a week number
doesn't just work within a single 1024 week cycle with some hardcoded
limit, like this simple example:

if ( wn < 860 )
  wn += 1024;

There may always be pieces of code which generate a faulty result under
certain conditions, and no stumbles across this even in reviews until it
really happens.

I'm not aware of *any* project where each single line of code is checked
once again whenever a new release is rolled out.

Martin

___
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] End of Loran-C in Europe confirmed.

[Wojciech Owczarek]

I have a memo / stakeholder briefing document from the General
Lighthouse Authorities UK/Ireland (can't see any confidentiality notes
on it), that states:

""
4. Effect if France Terminates eLoran
It is hoped that the RNTF [http://rntfnd.org] commercial initiative
can maintain the continuity of eLoran transmissions from France beyond
the end of 2015. However, in the event that the French and Norwegian
transmissions were to cease, all maritime eLoran Navigation capability
in UK waters would be lost immediately. In addition, the UTC basis of
precise Timing of the Anthorn eLoran transmissions would also be lost,
unless an alternative link to a source of UTC in the UK could be
provided. The Loran transmissions from Anthorn could be continued to
provide precise Timing (with intervention to synchronise transmissions
to UTC) for the benefit of UK and Irish CNI, but the maritime mandate
of the GLA does not cover this intervention. Without French
transmissions and hence with no maritime benefit, the GLA have no
mandate to maintain any eLoran capability in the UK and would plan to
close the service down.
""

Chronos in the UK have partnered with UrsaNAV to form this:
http://taviga.com . The various UK government bodies support eLORAN
and the people involved say they have the capacity to make Anthorn a
master station. They need a UTC reference, but given that the NPL are
transmitting MSF from Anthorn, I would assume that traceable UTC is
already there. All that's left to do is wait to see what actually
comes out of this, but things are looking bleak for now; for
positioning you can't do much with Anthorn alone.

Thanks,
Wojciech
___
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] trade timestamps

[Wojciech Owczarek]

Long time lurker here. Hefty read follows - apologies. Can't blame anyone
for TL;DR.

On 11 November 2015 at 02:07, Alexander List <a...@list.priv.at> wrote:
>
> On Wednesday, November 11, 2015 03:15 AM, Don Latham wrote:
> Indeed. HFT firms have been working on their own "advanced" timekeeping
> using PTP and GPS and what not, but it seems the MIFID-II directive and
> equivalents in other markets force the entire industry to up their
> systems from NTP to PTP...

It's all nice and simple when you have a GPSDO in your lab and nice, steady
10 MHz, and that's that.

So far MIFID-II sets a precedent. The tightest US requirement is currently
50 ms to UTC (time error, not timestamp granularity), but the US is bound
to follow EU at some point. PTP has been pretty much a standard for bigger
trading firms for 5+ years. I first saw it in 2007. Until now, it has only
been used by traders to gain advantage in establishing data arrival times,
and exchanges used it to maintain timestamp consistency between different
components of a trading system. Now it becomes a legal requirement
for both. They were all screaming and shouting, but the EU settled on
100 us from UTC (only for firms with low latency systems). Initially they
suggested 1 us! NTP is on the way out, but it's not the protocol's fault,
it's the implementations' fault. Long poll intervals, small amount of samples
and no hardware timestamping. PTP resolves all of those in its very
core definitions - and implementations follow. Your clock may be stable,
but if you're polling every 16 seconds and packet delay variation of the
network stack outweighs your path delays, and you have no accurate
transmission timestamp, no Allan Intercept will help. Suboptimal
measurement, and you have crap in, crap out.

Hardware can do small nanoseconds, the problem is getting the time
to the operating system where the application lives. People have to
realise that they are not driving actual crystals, just software models
describing OS clocks, that only use assumed known frequency
as a starting point. It is advanced timekeeping, considering scale,
network conditions, monitoring, holdover, mitigating GPS vulnerabilities,
complex GPS distribution into data centre bunkers, calibration, etc.
OK, it's not exactly China Mobile with 700,000 base stations
using PTP, but it's pretty advanced in my humble opinion.

With software-only PTP, with good filtering you get low microseconds,
albeit somewhat noisy. With a PTP timestamping NIC you can
get sub-150 ns between OS and NIC, and the NIC can definitely
get sub-500 ns to reference, assuming little or no delay asymmetries,
or use of PTP transparent clocks across the whole path. 100 us
is easy if you architect it right, the Finance community just has
a lot to learn. For many engineers from the "IP generation",
phase and frequency concepts are completely foreign, they mix
definitions and generally get confused. NTP you could just leave
running, syncing to something, and it gave you a number. With
PTP, suddenly every small detail affecting phase offset has to be
understood and accounted for, because your target is smaller.

It also works the other way round: explaining the problems of
time sync in enterprise networks to frequency / telecom people
(vendors) is a tough task. I have been doing this for a few years
now, and today they mostly get it. Now they have to explain "their"
stuff back to the users and everything will be fine (ha-ha).

Before the legal requirement is cut down to 10 us, hardware
timestamping will be available on every NIC (mostly is today
for new systems), and sync will be much less challenging.
Solving the "Last two inch problem" ( (c) John Eidson), that
is building computer systems that are time-aware and time-
correct by design, will be the last task on the road to ubiquitous
sync. Intel have already laid the foundations allowing to relate
the TSC counter to PTP time, and there is the PTM functionality
in PCI Express 3.x+ spec (basically PTP over PCIE). Finally,
there is Synchronous Ethernet, providing tight frequency lock
between network ports - add PTP for phase and time, and you've
got White Rabbit (picosecond accuracy).

The funniest thing about MIFID-II, or rather ESMA, the regulatory
body, is that they question the traceability of GPS time to UTC!
Perhaps because the EU has Galileo. Apparently.

[disclaimer: personal opinions only]

Thanks,
Wojciech

-- 
-

Wojciech Owczarek
___
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] When NTP goes wrong...

[Wojciech Owczarek]

I think this is a classic case of confusing application security with
network security. The whole idea relies on spoofing packets. A spoofing
scenario is only realistic in a lab setting. Or in case of a physical
takeover of a circuit, which - well, then you have more important things to
worry about, and please show me an actual existing case.

The series of off-path attacks described are off-path only because they
don't require intercepting previous communication, but they still require
spoofing. Theoretically any application using a connectionless protocol
like UDP suffers from this "vulnerability" to spoofing one way or another.
My personal favourite statement "on a properly designed network..." usually
negates most of those.

PHK - as you say, the only cure is to have your own NTP servers, and any
serious organisation out there does.

The paper definitely has some research value, but in my opinion the
negative publicity generated by this is overblown and undeserved. One thing
I will agree with, is that there are too many random NTP servers out there
which are dusty boxes sitting somewhere in the broom cupboard, running
ancient software. However, all those vulnerable public NTP servers are
vulnerable if you're sitting next to them.

Regards,
Wojciech
___
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] Symmetricom experts?

[Wojciech Owczarek]

Hi Chris,

This is a Linux box - an x86 box in fact. As far as I remember they even
have VGA pin headers on the board inside. Boot it up with the serial
console active and see if you get anything meaningful, but I doubt it. I
opened one up for the same purpose last year but I don't have it to hand
anymore and I don't remember what the exact platform was. Open it and you
may be able to connect to it by other means than the serial port - which I
found to be of little use for troubleshooting. It could be something as
trivial as the box stuck in fsck prompt because of a corrupted FS. They do
have dual partitions, but I'm not sure whether they can actually fail over,
or is the second partition used only during f/w upgrades.

Is the statement about copy protection actually confirmed? I would try
finding someone with another S200 and copying the CF card first. And yes,
they will want ,££s, and it got worse since the Microsemi acquisition.
I have witnessed multiple S2xx deaths. Usually PSU fail, but death on power
cycle is not uncommon either.

Thanks,
Wojciech


On 24 September 2015 at 09:46, Mike Cook <michael.c...@sfr.fr> wrote:

> Hi Chrs,
>   Not an expert… but usually computer systems give some indication of why
> a boot is failing on the systems console. The S200 is probably a unix based
> system as it has utilities such as SSH. TELNET. HTTP. So you could try
> connecting an RS232 terminal , or telnet’ing to its console server if it is
> managed by one. Then power it on again and see what the symptoms are. If
> there is no output, then it is a probably hardware problem and you will
> need to either have it serviced, or dig into it yourself . I doubt however
> that it is user serviceable.
> There are troubleshooting steps in the user manual, so I suggest you look
> at those. If you don’t have the manual handy, see
> <
> http://iecitel.com/resources/ntp%20network/S250/SyncServer%20S2xx%20User%20Guide.pdf
> >
>
> Have fun
> Mike
>
> > Le 24 sept. 2015 à 09:21, G1FEF <li...@g1fef.co.uk> a écrit :
> >
> > Do we have any Symmetricom experts on this list?
> >
> > I've had a Symmetricom Syncserver S200 GPS+PPS with rubidium clock
> running for several years until we had a power cut and the UPS battery
> failed, on powering back up it won't boot at all.
> >
> > I suspect the flash is corrupt but they protect it in some way, so one
> can't just copy the o/s onto a new card, and the company want 's to fix
> it for me!
> >
> > Thanks in advance,
> > Chris
> >
> >
> > ___
> > 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.
>
> "The main function of a modern police force is filling in forms."
> ___
> 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.
>



-- 
-

Wojciech Owczarek
___
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] IEEE 1588v2 on CISCO IE 3010

[Wojciech Owczarek]

Hi,

Excuse the lengthy reply; I hope it helps however. Excuse if I'm stating
the obvious here and there.

I have not worked with the IE series, but other than physical build options
like DIN rail mount and IP67 (and protocol support), they are largely just
normal Cisco IOS Ethernet switches. IE3000 and IE2000 (newer) support PTPv2
in boundary and transparent clock modes, here's an example:

http://www.cisco.com/c/en/us/td/docs/switches/lan/cisco_ie3000/software/release/12-2_50_se/configuration/guide/ie3000scg/swptp.html

What your switch will support (and if it will), will depend on the software
image installed, not only the hardware. You may want to upgrade to the
latest IOS 15.x as well.

Not sure how familiar with Cisco IOS you are, but their CLI syntax for PTP
on this kit is common - material from the link above should work on your
platform. The easiest thing to do is just explore the CLI - see what
PTP-related commands you have available in config mode, and what
PTP-related commands you can see in exec mode ("show" commands). If you
can't find it, then you will likely need a different software image. Since
you're not under a support contract, you may need to search the Internet
for images and you might get lucky. If you have not worked with IOS, this
is a very popular platform and there is an abundance of beginners' guides
available.

If not Boundary Clock, the switch should at least support End-to-End
Transparent Clock operation. In fact, it should be enabled for E2E
Transparent by default (only the base ports; uplink modules don't support
PTP). It is not clear what PTP profile they support though, but this being
an Industrial Ethernet switch (and Layer 2), it may only run PTP over
Ethernet transport, and not IP/UDP multicast.

An easy test is to run a PTP conversation between a master and a slave
through the switch, do a packet capture and look for the presence of values
in the CorrectionField of Sync, (Follow Up in two-step mode), Delay Request
(in one-step it's on egress towards master) and Delay Response. If
CorrectionField is non-zero anywhere, you have a TC in the path.

Some vendors will not tell you this in the datasheets, but some Transparent
Clock implementations may only support PTP One-Step mode or Two-Step mode,
not both. For example, if you're running one-step and the switch is not
populating CorrectionField in Sync messages, it doesn't support one-step.
If you're running two-step and CorrectionField is still in Sync, not in
FollowUp, the switch only supports two-step; etc.

Regards,
Wojciech


On 15 September 2015 at 22:06, Andrew Symington <
andrew.c.syming...@gmail.com> wrote:

> Dear All
>
> I have managed to get hold of a 24-port rack mount Cisco switch
> (model: IE-3010-24TC) which, according to the datasheet, is "IEEE 1588v2
> hardware ready". I am developing a Quality of Time stack for Linux as part
> of a research project, and I would like to use this switch to synchronize a
> test bed comprising of 20 BeagleBone Black slave nodes.
>
> Despite the advertised IEEE 1588v2 support, none of the Cisco software
> documentation covers PTP configuration. Cisco support is not being very
> helpful to me, as the switch is not covered by a Smartnet contract.
>
> Does anybody have experience configuring PTP on this switch, which they are
> willing to share with me?
>
> Regards
> Andrew Symington
> ___
> 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.
>



-- 
-

Wojciech Owczarek
___
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] Trimble Resolution [T, SMT, SMT GG] - spontaneous GPS loss of signal events, multiple locations

[Wojciech Owczarek]

Hello Time Nuts,

I was wondering if other people have seen this. 20+ receivers and they all
use different variants of the Resolution boards - majority are the old
Resolution T.We have observed sudden GPS loss of signal occurring.
Seemingly nothing unusual, these things happen, that's what holdover is
for, etc... however:

- All devices are connected via decent distribution amps,
- All installations use roof-mounted antennas with unobstructed 180 degree
sky view
- All devices see about 11 birds most of the time
- None of these events coincided with known GPS SV outages

And here's the fun part:

- This is happening in multiple locations in the US, AND in the UK
- The log timestamps (UTC) for the alarms, are *exactly the same* across
all sites, down to the second. This happens twenty to ten seconds before
midnight, and usually recovers within two or three minutes.

The last event was on 5th September, at 23:59:37 UTC. We have seen this
happening anywhere between once every month to once every two months. Time
may differ by a few seconds, but it's the same across all devices.

I'm trying to establish whether the issue is with Trimble or with the
vendor who embedded Trimble. Because of what I refer to as "vendor
anal-digital decoupling delay", I have to investigate in parallel.

Has anyone seen this with Resolution? Unfortunately I have no visibility
into firmware versions in the Resolution boards.

Any pointers welcome.

Many thanks,
Wojciech
___
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] Trimble Resolution [T, SMT, SMT GG] - spontaneous GPS loss of signal events, multiple locations

[Wojciech Owczarek]

On 14 September 2015 at 15:37, Mike Cook  wrote:

>
> Hi,
>   I have both -T and SMT and have not seen this on the 5th or afik any
> other day. If you have other dates, I can check those in more detail.
>

OK - I think this itself excludes an issue with the boards. What firmware
are you running on the T's: 1.17, 1.14 or something else?


>  I would suggest that if you have spare capacity, that you remove one of
> the receivers from its platform and monitor with it hooked up
> independently. If it is shows no issue then you can go back to the vendor
> with the evidence.
>


Thanks Mike - I didn't mention in the original e-mail that I am not in a
position to remove the receivers as these are boxes under support /
warranty, even the lab ones I test with. I was trying to establish if this
is a Trimble issue, because the vendor tends to have little clue. Long
story. Also since I can't remove them, I can't check their firmware.

I have some standalone Resolution T's at home, but I don't have them
operational 24/7. I should probably fire them up.

Best regards,
Wojciech
___
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] Trimble Resolution [T, SMT, SMT GG] - spontaneous GPS loss of signal events, multiple locations

[Wojciech Owczarek]

On 14 September 2015 at 17:06, Brian Inglis  wrote:

> Hi,
> Probably the vendor if no one else experiences or knows of Resolution
> issues.
> You can contact Trimble UK or Trimble Navigation Europe in Hampshire and
> they
> may know about any product or vendor OEM issues.
> If you can get the timing down to 30s GPS frame times or 750s/12.5m
> message times,
> it could possibly be a GPS system issue like updates, and you can report
> problems at:
> http://www.gps.gov/support/user/
> which links to the form at:
> http://www.navcen.uscg.gov/?pageName=gpsUserInput


Thanks - I have a case open and the vendor saw the same in their labs. I'm
aware of the 12.5m issue: the last Res T f/w (1.17) lists this in the
change log. I don't think this is what's affecting us, but this is one of
the things I'm trying to get the vendor to look into.

Actually looks like I forgot about the obvious. I have one of those
receivers at home and it's an old engineering sample (no warranty, no
worries) so I'll hook up the module to at least check the firmware.

Regards,
Wojciech
___
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] LORAN-C reception in the UK

[Wojciech Owczarek]

Dave,

I'm afraid I can't give you a quantitative answer about LORAN-C, but I can
say that eLORAN is your friend. It has recently been revived in the US and
it's doing all right in Europe, UK included. The promise in general is 50
ns to UTC. UrsaNav make some receivers and Chronos (who are a big eLoran
advocate) distribute them in the UK, along with their own product.

I take it you don't already have the FS700? In that case I think it's
definitely worth looking at eLORAN. Again, note that I'm also not using
eLORAN at the moment, but I'm looking at it very closely as a GNSS
alternative.

Cheers,
Wojciech


-- 
-

Wojciech Owczarek
___
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] Time in a cave

[Wojciech Owczarek]

 endgame worst case is to just do PPS from a stratum 2 NTP (or even a
 freerunning oscillator) and lie to my PTP server; hard sync to UTC is a
 secondary concern so long as the cluster agrees with itself.  Endrun is
 looking pretty good, but I'd really like to have a second option to compare
 against.

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




-- 
-

Wojciech Owczarek
___
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] June 30 2015 leap second

[Wojciech Owczarek]

On 7 Jan 2015 00:23, d0ct0r t...@patoka.org wrote:


 Hello,


 The same question is for UNIX epoch time. How computers knows if it is
necessary to add leap seconds ?

During the event, the kernel raw time (assuming UTC) will go from
23:59:58.9 straight to 00:00:00.0 when removing a leap
second, and when inserting one, Linux for example will go
23:59:59.9 to 23:59:59.0 again. The time formatting library
functions (aware of leap and time zones) will turn the latter into xx:59:60.

As to how the computer knows - some time sync software (NTPd, PTPd etc.),
which is made aware of the event from upstream, needs to tell the kernel
about this - on systems with the kernel NTP API like Linux, BSDs and
others, this is done by setting a respective STA_INS or STA_DEL status flag
with ntp_adjtime() or adjtimex(). This can be done in kernel up to 24 hours
in advance. When either of the two flags is set, the kernel will trigger
the leap event in the last seconds of the current day. GPS should announce
the pending leap second not long after the IERS announcement. I haven't
checked my clocks yet but it may already be out 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] rs-422 rs-232 to fast ethernet converter

[Wojciech Owczarek]

Ser2net is the way to go for me. 

A hardware solution I have been using for this purpose for quite a while are 
those tiny USB-powered SoC-based 3G / 4G portable routers from vendors like 
TP-Link (good little case designs - TL-MR3020 for instance which I currently 
use). The 3G models don't actually have cellular modems, they just have a 
single USB port - and a Fast Ethernet port, and 802.11. They (can) run Linux.

The newer ones have 4M onboard flash and you can flash them instantly with 
OpenWRT. You can drop the web UI to trim down flash usage if you want, but out 
of the box they will fit USB-serial drivers and ser2net. Just add a USB to 
serial cable (or even go wild and buy a quad one with an USB hub built in) and 
you are still below the price of a Raspberry Pi, nevermind a dedicated serial 
to Ethernet box. You can also add a mini USB hub, stick a mini USB key in and 
use it as storage overlay. OpenWRT has all the tools you need available in the 
package repositories.

I paired mine with a 12Ah portable USB power bank, clipped on using 3M 
Command(tm) hook-and-loop straps. It ran on it for 48 hours straight. This 
setup has proven an invaluable tool in data centre work for emergencies and 
upgrades. I can hang it in a rack or keep it in my pocket, connect to kit using 
serial or Ethernet, and work from my smartphone over wifi. File transfers, 
firmware upgrades, whatever you want. Not sure if ser2net supports X/Zmodem 
somehow (it's probably down to the telnet client here) but for the times you 
need it, there's minicom. Naturally, USB-RS converters are not always the 
way to go, but the RPi needs one as well, it can only do TTL natively.

With some DYI you can put the router board, USB hub and battery in a neat 
little box as well and add an antenna, for improved usability.

Regards
Wojciech


Wojciech Owczarek

-Original Message-
From: Paul Alfille paul.alfi...@gmail.com
Sender: time-nuts time-nuts-boun...@febo.comDate: Mon, 24 Nov 2014 22:38:04 
To: Discussion of precise time and frequency measurementtime-nuts@febo.com
Reply-To: Discussion of precise time and frequency measurement
 time-nuts@febo.com
Subject: Re: [time-nuts] rs-422 rs-232 to fast ethernet converter

There is a protocol for ending serial commands over telnet (tcp): RFC2217

See http://tools.ietf.org/html/rfc2217

A number of command line tools, like ser2net and netcat use the protocol.
Some of the small serial servers support it and it can make using serial
remotely tunneled over tcp seamless.

On Mon, Nov 24, 2014 at 6:23 PM, Graham planoph...@aei.ca wrote:


 I have done a bit of searching and found that what I want to do is nothing
 really new and their are several off the shelf applications which will work
 just fine - linux and Windows based hence the mention of the Raspberry PI
 and Beaglebone Black. Some of the higher end Arduinos (i.e. Yu) are capable
 of running linux and Windows as well but it would be entirely possible to
 roll you own using the lower end Arduinos as well.

 I found some answers rather quickly after I started searching for the
 right things, for example Serial to Network Proxy.

 On Windows you could use a virtual serial port to do the redirecting from
 com port to network and on linux there are several the one I found often
 mentioned is socat.

 The little serial to fast ethernet boxes which I was finding would work in
 the situations where you don't have a computer near the device you are
 trying to connect to, they act as the Serial to Network Proxy. In my case,
 I have a computer nearby which runs linux and is my GPS disciplined NTP
 server. I have purchased a RS422 to USB interface cable which will connect
 the KS-24631 to my linux box. Now I just have to sort through all of the
 information I have found and figure out just which app I need on the linux
 box (likely socat) and which one on any of the other computers on my
 network with which I may want to connect to the KS-24631. And of course,
 how to configure them.

 cheers, Graham ve3gtc




 On 2014-11-24 08:42, Jim Lux wrote:

 On 11/24/14, 2:20 AM, Graham wrote:

 Interesting.

 I have also been thinking that it might not be too difficult to
 implement using Beaglebone Black, Raspberry PI, or even one or another
 flavour of Arduino. Lots of possibilities from simple to not so simple.



 The challenge is always trying to figure out what sort of protocol to use
 for encapsulating serial data in the Ethernet Stream.  Do you send each
 character in its own UDP or TCP datagram? Do you batch them together and
 send a message every TBD milliseconds.

 Ideally, you'd like the protocol to match some commonly available client
 on the other end.  Sure, things like telnet exist, but does software that
 expects an actual serial port know how to use telnet instead?

 That said, there's plenty of example code out there for, example, the
 Arduino Ethernet.  There's a telnet server that could easily be modified

Re: [time-nuts] FYI: NPLTime(R) - a new service providing a precise time signal directly traceable to Coordinated Universal Time (UTC) and independent of GPS.

[Wojciech Owczarek]

NPL Time will be delivered to access centres where those finance people are
already present, from there it's only a matter of a crossconnect from their
kit to the client and other operators.

Regarding the three seconds - this is about to radically change with the
upcoming EU directives (MIFID II) and US ones (SEC regulations) are brought
out. We may see a 100 us target.

Obviously with timing distance is of less importance as long as links are
of symmetric latencies and low packet delay variation.
___
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] FASTRAX GPS

[Wojciech Owczarek]

My 2c - RS232 is extensively used in data centres over cat5 with network kit 
for out of band management via serial consoles, usually 9600 baud.

I've done this many times via (multiple) patching panels/frames easily over 
100ft, ribbon/rollover then cat6 but also cat5. This kit tends to be reliable 
and usually well grounded though. Well, and compliant.


Wojciech Owczarek
___
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] Linux TSC clocksource on multi-core systems

[Wojciech Owczarek]

Laszlo,

What sometimes helps is additional kernel command line parameters, namely
acpi=off (maybe you wouldn't have to disable the PM settings in the BIOS if
you had this) and noapic, also there is the clocksource=tsc parameter which
should make TSC the preferred clock source (that's if it's operational).
This all depends on your kernel version as well.

My experience is that the TSC sync issues were mostly an AMD thing and some
CPU / chipset generations ago, and anything modern should behave correctly
- but clearly the Atom doesn't. Perhaps some platforms are just not meant
for timing - some googling shows a lot of Atom D510 results showing TSC
clock source not starting.

The problem with writing the TSC is that it's a moving target that gets
incremented with every CPU tick. It is writable with the wrmsr (0x10)
instruction, and there's a write_tsc macro defined in asm/msr.h that does
exactly that, but you also need to send it to the right core.

One thing worth mentioning though is that issues like this can sometimes be
resolved with a BIOS upgrade - always worth a try.
___
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] Examples of leap-seconds in local timezones

[Wojciech Owczarek]

Magnus,

I have little experience with radio-based public time dissemination
services, but some with GPS/NTP/PTP, so here's some info - hope it's of
some value to you.

For US and European exchanges, the leap second time happens outside trading
hours, so maybe that's why we've heard little (horror) stories. This is
definitely not an easy thing to deal with during trading, unless your
messaging protocol actually has specific leap second extensions - which I'm
not aware of any of the ones I know having.

This is how the Linux kernel running UTC does it (assuming it's been told
by NTP/PTP/GPS/user and the respective leap second kernel flag was set -
and for example, a broken IRIG-B box somewhere hadn't forgotten to tell
some of your NTP servers about this and your quorum blocked it):

- If we're removing a second, Linux system clock will change from
23:59:58.9 straight to 00:00:00.0
- If we're inserting a second, Linux system clock will run the last second
second twice: 23:59:59.9 will change again to 23:59:59.0

(that's the kernel internal / UTC time, time formatting functions will
output the :60 value at insertion time).

This approach can potentially be problematic for some applications,
especially the insertion, which is essentially a step backwards, so some
institutions / vendors propose an alternative approach, which is the leap
second smear - I think Google was advocating that one: this is where you
gradually add/take the extra time throughout the whole leap second day
(which would be an approx. 11.6 ppm offset if you started from midnight -
so you'd have to model this carefully to bring it back to normal soon after
the leap second midnight).

Those alternative methods of time insertion may be fine if they're used
only internally within an organisation that doesn't provide timestamped
data to other organisations, without also providing time services to them -
or basically, all is well as long as interconnected parties use the same
method of dealing with this.

*personal opinion*

While the leap second is a somewhat inconvenient phenomenon, while it's
still there, it's there and we have to deal with it. I think that most of
the problems around it that people talk about are a little bit of FUD
resulting purely from the lack of adequate testing. This is based on my
experience with computer/network kit - this wasn't meant to be an absolute
statement.

I'd say let the IERS keep computing it but let's drop it from UTC and let's
do a one-off leap hour in some 4,000 years :-)

Regards
Wojciech
___
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] Affordable (cheap) COTS / eBay kit for TIE / 1PPS phase comparison

[Wojciech Owczarek]

Thanks for your suggestions so far everyone,

The picPET would be a great solution if it could run at higher frequencies
- but now there's a separate thread about that :)

Magnus - my reference is a Brilliant Telecom (now Juniper Networks TCA
series) PTP grandmaster (TCA8000), which does PTP and has
E1/T1/BITS/frequency outputs. Internally it uses a Trimble Resolution T
board for GPS/PPS. I think it could run Rubidium if I replaced the OCXO
with a SpectraTime LPFRS.

I'm familiar with Stable32 and I have a basic understanding of frequency
stability / phase noise measurement concepts, but for the most part I will
be simply looking at realtime phase offset measurement to test filtering
and PI servo optimisations.

Regards
Wojciech
___
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] Affordable (cheap) COTS / eBay kit for TIE / 1PPS phase comparison

[Wojciech Owczarek]

Hi List,

I'm a software developer turned network test engineer slowly turning
timefrequency guy (not sure if this is upwards or downwards ;-) ) with
some distant background in electronic engineering.

For the last couple of years I have been increasingly involved in various
work involving IEEE 1588 and finally I started fitting out a small home lab
setup. I never really needed lab kit at home before and my work lab is
primary to do with Ethernet and IP (and timing, but outside my price
ranges), so I was wondering if you could point me in the right direction:

I'm looking for some reasonably inexpensive solution to allow me a) to do
TIE measurements of 1PPS signals against a reference and b) do phase
comparisons of different 1PPS signals - so something with REF and at least
two inputs.

I have an OCXO GPS reference (upgradable to Rb) with 1PPS, 5MHz and 10MHz
outputs which is stable enough for my needs so that part (perhaps most
important) is sorted. In terms of requirements, granularity wise, well, as
good as achievable - I'm used to 10 ns and 5 ns granularity with TIE that I
get from work kit. 50 ns or better would be perfect.

I must add that ideally I would like to avoid having to design or build the
kit myself - I would love a project, but I have time to spare to complete
one.

Any pointers much appreciated.

Best regards
Wojciech

-- 
-

Wojciech Owczarek
___
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] Affordable (cheap) COTS / eBay kit for TIE / 1PPS phase comparison

[Wojciech Owczarek]

I meant I have *no* time to spare to complete one.

Thanks
Wojciech
___
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] PTPv2 grandmaster with a Z3805A?

[Wojciech Owczarek]

On 20 August 2013 11:03, David Gravereaux davyg...@pobox.com wrote:

 Hi,

 I've been lurking a bit and absorbing.


So have I.


 Are the 3.58 MHz ACPI timers okay or should I use the 25MHz HPET ones
 for system clock?


I would recommend the TSC time source: lowest read overhead.

All three have different behaviours - different (cold start) frequency
offset and different drift rates once stabilised and then left drifting.
However reading time with TSC time source takes least amount of time and id
least prone to jitter , which helps with timestamp accuracy.

Regards
Wojciech

 --
-

Wojciech Owczarek
___
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] PTPv2 grandmaster with a Z3805A?

[Wojciech Owczarek]

On 20 August 2013 17:16, Mike S mi...@flatsurface.com wrote:


 By default, the tsc is calibrated at each boot, which means that timing
 will likely change (and ntp drift values will be off) each time you boot.

 There's a linux kernel command line option which will fix that and provide
 consistency between boots, something like  clocksource=tsc
 tsc_khz=2410988. The exact value depends on how fast the processor is
 clocked.


True, this will help, and needless to say, dynamic CPU frequency etc. is a
no-no, and it's best to bind the (ntp) process to a single CPU core.
However I find it that the drift differences will be sub-1ppm across
reboots. In my case (data center) they are in fact sub-500ppb - calculated
with ptpd.

You always need some stabilisation time after reboot, especially that your
wall clock will likely get re-initialised from RTC. I think overcoming that
may sometimes take longer than re-calculating drift.

I pointed to TSC mostly because of the PTP GM side of the original poster's
query.

Regards
Wojciech

-

Wojciech Owczarek
___
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] PTPv2 grandmaster with a Z3805A?

[Wojciech Owczarek]

On 20 August 2013 19:12, Mike S mi...@flatsurface.com wrote:

On modern x86 processors, both Intel and AMD, the tsc increments at a
 constant rate, independent of the CPU frequency.


I keep forgetting about constant_tsc.

-- 
-

Wojciech Owczarek
___
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] PTPv2 grandmaster with a Z3805A?

[Wojciech Owczarek]

On 20 August 2013 21:16, Poul-Henning Kamp p...@phk.freebsd.dk wrote:

 You never should, for precision timekeeping, for a host of technical
 hacks, all outside your control.


I brought up TSC only as a, to me, better alternative to HPET / ACPI.

Of course it's not good enough for serious timekeeping, no mostly
software clock is.


 support for timing electrical signals
 using the same free-running counter as used for the PTP packets.


Sounds interesting. Can you elaborate? Does the card then run its own clock?




but it's the best chip there is right now


OK, different price range, but do you think it trumps the likes of
SolarFlare's 10GE
adapters with dedicated OCXOs, or copper-only cards with OCXOs like
Oregano's,
or other dedicated timing NICs? What makes it stand out so much - is it
just that
it supports all that's needed without being marketed as a precision timing
NIC?

Best regards
Wojciech
-- 
-

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