Keeping a VERY accurate time (within a millisecond)
Ignoramus10032
to have a clock accurate to less than a millisecond.
There is a business reason for it.
NTP, when it works, lets me keep a time accurate to a few
milliseconds, which is great, but I would like to do better than that.
If this is a question of money, a few hundred dollars can be spend on
buyin some Meinberg card or whatever. I would prefer something with
open source drivers already available in kernel, and not some closed
source junk.
--
Due to extreme spam originating from Google Groups, and their inattention
to spammers, I and many others block all articles originating
from Google Groups. If you want your postings to be seen by
more readers you will need to find a different means of
posting on Usenet.
http://improve-usenet.org/
Unruh
>I want my ubuntu servers to keep a VERY accurate time. That is, I want
>to have a clock accurate to less than a millisecond.
Buy a Gamin 18LVC gps receiver (about $70). Wire it up to your system and use one of
the refclocks for that. (eg refclock_nmea)
(Although I wrote my own interrupt routine to grab the pps) It can keep
your clock accurate to about 3usec (that is usec not msec)
You do need to mount the gps where it can see the sky.
Ignoramus10032
> Ignoramus10032 <ignoram...@NOSPAM.10032.invalid> writes:
>
>>I want my ubuntu servers to keep a VERY accurate time. That is, I want
>>to have a clock accurate to less than a millisecond.
>
> Buy a Gamin 18LVC gps receiver (about $70). Wire it up to your system and use one of
> the refclocks for that. (eg refclock_nmea)
> (Although I wrote my own interrupt routine to grab the pps) It can keep
> your clock accurate to about 3usec (that is usec not msec)
> You do need to mount the gps where it can see the sky.
After I made my post, I realized that I have a DeLuo USB based GPS. I
am running it right now, and I was actually very impressed. At this
moment I am a passenger in a moving car, running gpsdrive, looking at
the map, etc. It's all very cool.
Man pages of gpsd suggest that I can synchronize NTP to gpsd. There
are some warnings that it may not be very accurate, however, but I
will see.
Chris Davies
> I want my ubuntu servers to keep a VERY accurate time [...]
> If this is a question of money, a few hundred dollars can be spend on
> buyin some Meinberg card or whatever [...]
You mean something like this, http://www.timetools.co.uk/ ?
Chris
The Natural Philosopher
> I want my ubuntu servers to keep a VERY accurate time. That is, I want
> to have a clock accurate to less than a millisecond.
>
> There is a business reason for it.
>
> NTP, when it works, lets me keep a time accurate to a few
> milliseconds, which is great, but I would like to do better than that.
>
> If this is a question of money, a few hundred dollars can be spend on
> buyin some Meinberg card or whatever. I would prefer something with
> open source drivers already available in kernel, and not some closed
> source junk.
>
how long, I wonder, does a system call to read the time from a super
accurate clock take, and how long to do anything useful with it..and how
VARIABLE are these quantities..
I have to say, sub millisecond, I would be thinking in terms of a real
time operating system and dedicated to the task..Not a Ubuntu server..
Ignoramus10032
Well, hopefully something cheaper, like an add-on card.
www.GymRatZ.co.uk
Ignoramus10032 wrote:
> Well, hopefully something cheaper, like an add-on card.
When I were a lad... before the dizy days of interwebconnetlandshire...
We used to fit a product called a C.A.T. (rugby receiver) into the
serial port of the PC.
I've checked the company and they still make the stuff though it's all
windows specific drivers.
Might be something of use though..
http://www.galsys.co.uk/
HTH
Pete
--
http://www.GymRatZ.co.uk - Fitness+Gym Equipment.
http://www.bodysolid-gym-equipment.co.uk
http://www.trade-price-supplements.co.uk
http://www.water-rower.co.uk
Robert Heller
>
>
>
> Ignoramus10032 wrote:
>
> > Well, hopefully something cheaper, like an add-on card.
>
> When I were a lad... before the dizy days of interwebconnetlandshire...
> We used to fit a product called a C.A.T. (rugby receiver) into the
> serial port of the PC.
>
> I've checked the company and they still make the stuff though it's all
> windows specific drivers.
> Might be something of use though..
> http://www.galsys.co.uk/
> HTH
> Pete
If it *still* uses a serial port (RS232) interface, you don't need a
kernel-level driver, no matter what they tell you about 'windows
drivers'. You just need a *user mode* program that opens
/dev/ttyS<mumble>, and uses termios to condition the port (eg BAUD
rate, stop bits, parity, raw mode, handshaking protocols, etc.) and
then you need to just read the data bytes. A simple program can be
written to dump the bytes to stdout to determine what they might mean.
>
--
Robert Heller -- Get the Deepwoods Software FireFox Toolbar!
Deepwoods Software -- Linux Installation and Administration
http://www.deepsoft.com/ -- Web Hosting, with CGI and Database
hel...@deepsoft.com -- Contract Programming: C/C++, Tcl/Tk
dennis@home
"Ignoramus10032" <ignoram...@NOSPAM.10032.invalid> wrote in message
news:OY-dnVhm9J9UKl_V...@giganews.com...
> I want my ubuntu servers to keep a VERY accurate time. That is, I want
> to have a clock accurate to less than a millisecond.
>
> There is a business reason for it.
>
> NTP, when it works, lets me keep a time accurate to a few
> milliseconds, which is great, but I would like to do better than that.
>
> If this is a question of money, a few hundred dollars can be spend on
> buyin some Meinberg card or whatever. I would prefer something with
> open source drivers already available in kernel, and not some closed
> source junk.
GPS on a serial port.
Unruh
>On 2008-09-06, Unruh <unruh...@physics.ubc.ca> wrote:
>> Ignoramus10032 <ignoram...@NOSPAM.10032.invalid> writes:
>>
>>>I want my ubuntu servers to keep a VERY accurate time. That is, I want
>>>to have a clock accurate to less than a millisecond.
>>
>> Buy a Gamin 18LVC gps receiver (about $70). Wire it up to your system and use one of
>> the refclocks for that. (eg refclock_nmea)
>> (Although I wrote my own interrupt routine to grab the pps) It can keep
>> your clock accurate to about 3usec (that is usec not msec)
>> You do need to mount the gps where it can see the sky.
>After I made my post, I realized that I have a DeLuo USB based GPS. I
>am running it right now, and I was actually very impressed. At this
>moment I am a passenger in a moving car, running gpsdrive, looking at
>the map, etc. It's all very cool.
Ssure, but probably useless for timing. To be useful for timing th gps MUST
have a PPS output. AFAIK no usb one does. And almost no consumer one does.
>Man pages of gpsd suggest that I can synchronize NTP to gpsd. There
>are some warnings that it may not be very accurate, however, but I
>will see.
Sure. It will be accurate to about 10ms after a lot of fiddling to figure
out exactly how late the time delivered actually is. (if you use it raw it
will be out by about 500ms too slow)
Unruh
>Ignoramus10032 wrote:
>> I want my ubuntu servers to keep a VERY accurate time. That is, I want
>> to have a clock accurate to less than a millisecond.
>>
>> There is a business reason for it.
>>
>> NTP, when it works, lets me keep a time accurate to a few
>> milliseconds, which is great, but I would like to do better than that.
>>
>> If this is a question of money, a few hundred dollars can be spend on
>> buyin some Meinberg card or whatever. I would prefer something with
>> open source drivers already available in kernel, and not some closed
>> source junk.
>>
>how long, I wonder, does a system call to read the time from a super
>accurate clock take, and how long to do anything useful with it..and how
>VARIABLE are these quantities..
Typically around a microsecond less to read it. It depends on what you
mean by "useful" It could take centuries, if by "useful" you mean "stop global
warming"
.
>I have to say, sub millisecond, I would be thinking in terms of a real
>time operating system and dedicated to the task..Not a Ubuntu server..
What is the task?
Unruh
>Ignoramus10032 wrote:
>> Well, hopefully something cheaper, like an add-on card.
>When I were a lad... before the dizy days of interwebconnetlandshire...
>We used to fit a product called a C.A.T. (rugby receiver) into the
>serial port of the PC.
When you were a lad, gps receivers did not exist. They do now. They are
accurate to submicroseconds. rugby receiver is accurate to many
milliseconds, depending on how far away you are, what the ionisphere is
like, etc.
Ignoramus10032
A millisecond is a very long time for any computer.
Our network has sub-millisecond ping times.
I do realize that this is a challenge.
i
Ignoramus10032
Yes, it does not seem satisfactory...
Ignoramus10032
>
>>I want my ubuntu servers to keep a VERY accurate time. That is, I want
>>to have a clock accurate to less than a millisecond.
>
> Buy a Gamin 18LVC gps receiver (about $70). Wire it up to your
> system and use one of the refclocks for that. (eg refclock_nmea)
> (Although I wrote my own interrupt routine to grab the pps) It can
> keep your clock accurate to about 3usec (that is usec not msec) You
> do need to mount the gps where it can see the sky.
Unruh, now that I have some understanding of the complexity of this
issue, and have read a lot of stuff, I can understand your reference
to that product.
can you comment on Garmin GPS 18 LVC vs. Garmin GPS 18 PC?
How did you wire those bare wires to your PC?
Do I lose much by using a serial port and Garmin GPS 18 PC?
i
Joe User
> I want my ubuntu servers to keep a VERY accurate time. That is, I want to
> have a clock accurate to less than a millisecond.
>
> There is a business reason for it.
>
> NTP, when it works, lets me keep a time accurate to a few milliseconds,
> which is great, but I would like to do better than that.
Are you sure you want timebase ACCURACY? That is, a very close
correlation to a standard time?
Maybe you really want to measure DURATION? That is much easier and
cheaper to do. A cheap timer/counter can give really astounding precision
and accuracy of duration measurements. And that accuracy can be
maintained over surprisingly long time periods.
Keeping an accurate timebase, and still communicating over the internet is
kind of contradictory.
--
One of the most serious problems in planning
against American doctrine is that the Americans
do not read their manuals nor do they feel
any obligations to follow their doctrine.
Unruh
>On 2008-09-06, Unruh <unruh...@physics.ubc.ca> wrote:
>> Ignoramus10032 <ignoram...@NOSPAM.10032.invalid> writes:
>>
>>>I want my ubuntu servers to keep a VERY accurate time. That is, I want
>>>to have a clock accurate to less than a millisecond.
>>
>> Buy a Gamin 18LVC gps receiver (about $70). Wire it up to your
>> system and use one of the refclocks for that. (eg refclock_nmea)
>> (Although I wrote my own interrupt routine to grab the pps) It can
>> keep your clock accurate to about 3usec (that is usec not msec) You
>> do need to mount the gps where it can see the sky.
>Unruh, now that I have some understanding of the complexity of this
>issue, and have read a lot of stuff, I can understand your reference
>to that product.
>can you comment on Garmin GPS 18 LVC vs. Garmin GPS 18 PC?
ONLY the lvc has a PPS output. The PC only has a the nmea output to the
serial port, from which you can get at best about 10ms accuracy. The LVC
outputs a pulse on the second with an accuracy of 1usec. You can get GPS
receivers which will output a pulse with 100ns accuracy but they tend to be
much more expensive.
There are a number of places on the we which will guide you to setting up
the 18lvc to deliver usec accurate time to your computer.
>How did you wire those bare wires to your PC?
Well, I did it is a ratehr non-sandard way. I used a usb port to get the 5V
to run the device, fed the nmea to the serial port and ran the PPS line to
the parallel port. I then adapted a parallel port interrupt service routine
to timestamp the parallel port interrupts, and put them out onto
/dev/gpsint. I then adapted the refclock-shm driver from ntp to read
/dev/gpsint and report the timestamps to ntp. Yes, that is a rather
roundabout way of doing it. I had more faith in the parallel port interrupt
serviceing than the serial. Anyway, the refclock nmea driver will read the
nmea from teh serial port AND use the PPS on the serial port if you have
it, so that is probably the better way to go.
See for example
http://time.qnan.org/
http://www.linuxquestions.org/linux/answers/Hardware/Microsecond_Precision_From_Garmin_18_LVC_GPS_unit_with_PPS_Signal_And_NTP
However the main problem seems to be that you have to modify the kernel to
give the pps. That was another reason I went with the shm driver and the
parallel port interrupt driver.
>Do I lose much by using a serial port and Garmin GPS 18 PC?
About a factor of 5000 in accuracy.
Now that may not be important for you. 10ms may be pleanty good enough.
If not, the lvc is the only way to go.
Ignoramus10032
> On Sat, 06 Sep 2008 12:03:05 -0500, Ignoramus10032 wrote:
>
>> I want my ubuntu servers to keep a VERY accurate time. That is, I want to
>> have a clock accurate to less than a millisecond.
>>
>> There is a business reason for it.
>>
>> NTP, when it works, lets me keep a time accurate to a few milliseconds,
>> which is great, but I would like to do better than that.
>
> Are you sure you want timebase ACCURACY? That is, a very close
> correlation to a standard time?
Yes. To absolute time.
> Maybe you really want to measure DURATION? That is much easier and
> cheaper to do. A cheap timer/counter can give really astounding
> precision and accuracy of duration measurements. And that accuracy
> can be maintained over surprisingly long time periods.
>
> Keeping an accurate timebase, and still communicating over the internet is
> kind of contradictory.
Yes, I believe that it is difficult, but there is a good reason for
it. I just do not want to go into details.
Ignoramus10032
Unruh, thanks, I bought a Garmin 18 LVC an hour ago. Hopefully I will
get it in a few days. I will experiment then. I wil first try at home
and then will discuss it at work.
i
>
> See for example
> http://time.qnan.org/
> http://www.linuxquestions.org/linux/answers/Hardware/Microsecond_Precision_From_Garmin_18_LVC_GPS_unit_with_PPS_Signal_And_NTP
>
> However the main problem seems to be that you have to modify the kernel to
> give the pps. That was another reason I went with the shm driver and the
> parallel port interrupt driver.
>
>
>
>>Do I lose much by using a serial port and Garmin GPS 18 PC?
>
> About a factor of 5000 in accuracy.
>
> Now that may not be important for you. 10ms may be pleanty good enough.
> If not, the lvc is the only way to go.
>
--
Grant Edwards
> At Sat, 06 Sep 2008 19:32:49 +0100 "www.GymRatZ.co.uk" <0845.86...@GymRatZ.Gym.Equipment> wrote:
>
>>
>>
>>
>> Ignoramus10032 wrote:
>>
>> > Well, hopefully something cheaper, like an add-on card.
>>
>> When I were a lad... before the dizy days of interwebconnetlandshire...
>> We used to fit a product called a C.A.T. (rugby receiver) into the
>> serial port of the PC.
>>
>> I've checked the company and they still make the stuff though it's all
>> windows specific drivers.
>> Might be something of use though..
>> http://www.galsys.co.uk/
>> HTH
>> Pete
>
> If it *still* uses a serial port (RS232) interface, you don't
> need a kernel-level driver, no matter what they tell you about
> 'windows drivers'. You just need a *user mode* program that
> opens /dev/ttyS<mumble>, and uses termios to condition the
> port (eg BAUD rate, stop bits, parity, raw mode, handshaking
> protocols, etc.) and then you need to just read the data
> bytes.
That's only going to be accurate to a few tens of milliseconds.
You're not going to get sub-millisecond timings by reading a
serial port from a user-space application.
> A simple program can be written to dump the bytes to stdout to
> determine what they might mean.
Determining what they mean isn't an issue. The issue is
getting sub-millisecond accuracy with a user-space program.
--
Grant
Ignoramus10032
Why would it be so, if everything is in RAM and no swapping is going
on?
For simplicity reasons, I can easily dedicate a computer to this
application, so that it would run no seriously big loads.
Joe Pfeiffer
> On 2008-09-07, Grant Edwards <gra...@visi.com> wrote:
>>
>> Determining what they mean isn't an issue. The issue is
>> getting sub-millisecond accuracy with a user-space program.
>>
>
> Why would it be so, if everything is in RAM and no swapping is going
> on?
>
> For simplicity reasons, I can easily dedicate a computer to this
> application, so that it would run no seriously big loads.
Unless you go to a real real-time OS, this just isn't going to
happen. You can get sub-millisecond a lot of the time,
several-millisecond most of the time, but if you really seriously
want a guaranteed response time -- especially on short time scales
like milliseconds -- general-purpose OSes just don't offer them. When
the machine decides to do something that takes time... your response
suffers.
Ignoramus10032
Does that include responding to an interrupt from a serial port?
The Natural Philosopher
> The Natural Philosopher <a@b.c> writes:
>
>> Ignoramus10032 wrote:
>>> I want my ubuntu servers to keep a VERY accurate time. That is, I want
>>> to have a clock accurate to less than a millisecond.
>>>
>>> There is a business reason for it.
>>>
>>> NTP, when it works, lets me keep a time accurate to a few
>>> milliseconds, which is great, but I would like to do better than that.
>>>
>>> If this is a question of money, a few hundred dollars can be spend on
>>> buyin some Meinberg card or whatever. I would prefer something with
>>> open source drivers already available in kernel, and not some closed
>>> source junk.
>>>
>
>> how long, I wonder, does a system call to read the time from a super
>> accurate clock take, and how long to do anything useful with it..and how
>> VARIABLE are these quantities..
>
> Typically around a microsecond less to read it. It depends on what you
> mean by "useful" It could take centuries, if by "useful" you mean "stop global
> warming"
> .
you wont read much out of a serial port in a microsecond. If that's how
its connected. Or even a USB port.
>
>
>> I have to say, sub millisecond, I would be thinking in terms of a real
>> time operating system and dedicated to the task..Not a Ubuntu server..
>
> What is the task?
exactly.
The Natural Philosopher
> On 2008-09-06, The Natural Philosopher <a@b.c> wrote:
>> Ignoramus10032 wrote:
>>> I want my ubuntu servers to keep a VERY accurate time. That is, I want
>>> to have a clock accurate to less than a millisecond.
>>>
>>> There is a business reason for it.
>>>
>>> NTP, when it works, lets me keep a time accurate to a few
>>> milliseconds, which is great, but I would like to do better than that.
>>>
>>> If this is a question of money, a few hundred dollars can be spend on
>>> buyin some Meinberg card or whatever. I would prefer something with
>>> open source drivers already available in kernel, and not some closed
>>> source junk.
>>>
>> how long, I wonder, does a system call to read the time from a super
>> accurate clock take, and how long to do anything useful with it..and how
>> VARIABLE are these quantities..
>>
>> I have to say, sub millisecond, I would be thinking in terms of a real
>> time operating system and dedicated to the task..Not a Ubuntu server..
>>
>
> A millisecond is a very long time for any computer.
>
It certinly wasn't when I used yo do real time programming: Granted the
clock speeds are way higher these days, but its been accompanied by
bloatware operating systems, and Linux has suffered this as well.
> Our network has sub-millisecond ping times.
One of the few areas that have been optimised..
The Natural Philosopher
I believe Unruh has the best approach to t least putting a dead accurate
NTP server on the network..that is take some daemon like the NTP server,
and drive it from a fast interrupt service routine..from, as he suggests
the parallel port.
That will give you a pretty uptodate time stamp somewhere.. then the
issue is how fast the NTP server will respond..If it doesn't matter that
the call to NTP takes time as lon as a dead accurate response is
delivered, by the time the daemon has gotten into active state, as long
as what it then reads and sends back is good, things shoud be OK at the
server level.
The client is a bit of a different matter though..as some process will
presumably call into the network and suspend, waiting on a return packet
with the time: if it doesn't get resumed fast enough when the packet
comes back, the time it reads will be a little bit old.
Then there are various other unpredictable scheduling delays..depending
on the process lists etc.
On my linux serer, when freshly booted, an attempt to telnet into it
after a fresh reboot is instantaneous. After its been up a while though,
it can take several seconds. I guess something important gets paged out
eventually. Hardly 'sub millisecond'.
Its this whole variability in scheduling that is the raison d'etre of
real time OS'es, and why Linux doesn't normally get used in its shipped
state in any time critical application. Linux, like Unix, starts to slow
down under load. Real time stuff is designed to keep up, until it fails
utterly.
Without knowing the application, which appears to be sufficiently
sensitive not to be disclosed, its hard to say what would work better
though, or whether Linux would be 'good enough'
The Natural Philosopher
> On 2008-09-07, Joe Pfeiffer <pfei...@cs.nmsu.edu> wrote:
>> Ignoramus10032 <ignoram...@NOSPAM.10032.invalid> writes:
>>
>>> On 2008-09-07, Grant Edwards <gra...@visi.com> wrote:
>>>> Determining what they mean isn't an issue. The issue is
>>>> getting sub-millisecond accuracy with a user-space program.
>>>>
>>> Why would it be so, if everything is in RAM and no swapping is going
>>> on?
>>>
>>> For simplicity reasons, I can easily dedicate a computer to this
>>> application, so that it would run no seriously big loads.
>> Unless you go to a real real-time OS, this just isn't going to
>> happen. You can get sub-millisecond a lot of the time,
>> several-millisecond most of the time, but if you really seriously
>> want a guaranteed response time -- especially on short time scales
>> like milliseconds -- general-purpose OSes just don't offer them. When
>> the machine decides to do something that takes time... your response
>> suffers.
>
> Does that include responding to an interrupt from a serial port?
>
Which is why serial ports have FIFO buffers on em these days. If you
dint make your ISR read ALL the buffer, even though it was set to
interrupt on any input character, you occasionally lost data..
Even hardware interrupts have some sort of prioritization.
Its been a long time..but AFAICR the timer interrupt on the original PC
had top priority, but when doing something time critical like pulling
data via DMA off a disk, you might disable that..or postpone its effect
anyway.
And remember, even at 115k baud or whatever RS232 stops at, max data
rate is only about 10K bytes/second..if your time string is 10 bytes
long thats a millisecond to read it in..
Jean-David Beyer
http://www.cis.udel.edu/%7Emills/database/papers/fine.pdf
--
.~. Jean-David Beyer Registered Linux User 85642.
/V\ PGP-Key: 9A2FC99A Registered Machine 241939.
/( )\ Shrewsbury, New Jersey http://counter.li.org
^^-^^ 06:40:01 up 31 days, 12:46, 4 users, load average: 4.25, 4.21, 4.13
Jean-David Beyer
>
> Which is why serial ports have FIFO buffers on em these days. If you
> dint make your ISR read ALL the buffer, even though it was set to
> interrupt on any input character, you occasionally lost data..
>
> Even hardware interrupts have some sort of prioritization.
>
> Its been a long time..but AFAICR the timer interrupt on the original PC
> had top priority, but when doing something time critical like pulling
> data via DMA off a disk, you might disable that..or postpone its effect
> anyway.
>
> And remember, even at 115k baud or whatever RS232 stops at, max data
> rate is only about 10K bytes/second..if your time string is 10 bytes
> long thats a millisecond to read it in..
If you use NTP, especially if you have an accurate local time source to
drive it, you can do better than you would think from the hardware.
NTP does not merely get the time from its reference source(s). It runs a
phase lock loop that improves matters because it greatly reduces jitter
(which practically speaking includes real jitter in the time source(s) and
also the variable time it takes for the computer to respond to the time
reference signals).
So if the jitter is about 6 milliseconds, the phase lock loop can reduce the
jitter to a very low value. NTP polls the time sources every 64 seconds
until the phase lock loops (one per source) stabilize and gradually decrease
the polling interval to 1024 seconds once things are working smoothly. For
example, here is what my machine is doing (delay, offset, and jitter are in
milliseconds). remote is the source of the time information. st = 1 means
the time source is directly connected to an accurate time source. st = 2
means the time source is one hop away from an st = 1 source, etc.
remote refid st t when poll reach delay offset jitter
============================================================================
*clock1.redhat.c .CDMA. 1 u 963 1024 377 31.640 -4.328 1.634
+time.nist.gov .ACTS. 1 u 446 1024 377 56.778 -7.453 2.347
+lashiir.sapros. 128.194.254.9 3 u 878 1024 377 54.947 -8.416 0.259
Now if one of your sources is GPS or CDMA located right next to your
computer, the delay could be only a few nanoseconds (really, since the speed
of light is about one nanosecond per foot) plus the minimum delay to get an
interrupt through the system (perhaps a millisecond). The raw jitter is then
the variable delay to get the interrupt acknowledged, that might be from 1
to 10 milliseconds depending on the speed of the port used (I use a 100 MHz
NIC connected to a 20 megabit/sec Verizon FiOS link, but the jitter to those
clock sources may be considerable). So the jitter will not be much of an
issue with NTP after it has been running a few hours.
dennis@home
"Ignoramus10032" <ignoram...@NOSPAM.10032.invalid> wrote in message
news:-9idnc4pMdv6_17V...@giganews.com...
> On 2008-09-07, Joe Pfeiffer <pfei...@cs.nmsu.edu> wrote:
>> Ignoramus10032 <ignoram...@NOSPAM.10032.invalid> writes:
>>
>>> On 2008-09-07, Grant Edwards <gra...@visi.com> wrote:
>>>>
>>>> Determining what they mean isn't an issue. The issue is
>>>> getting sub-millisecond accuracy with a user-space program.
>>>>
>>>
>>> Why would it be so, if everything is in RAM and no swapping is going
>>> on?
>>>
>>> For simplicity reasons, I can easily dedicate a computer to this
>>> application, so that it would run no seriously big loads.
>>
>> Unless you go to a real real-time OS, this just isn't going to
>> happen. You can get sub-millisecond a lot of the time,
>> several-millisecond most of the time, but if you really seriously
>> want a guaranteed response time -- especially on short time scales
>> like milliseconds -- general-purpose OSes just don't offer them. When
>> the machine decides to do something that takes time... your response
>> suffers.
>
> Does that include responding to an interrupt from a serial port?
Linux, like all popular os, turns off interrupts when it is doing some
stuff.
Unless you know how long it does this for you cannot say it can respond to
an interrupt within a certain time.
The off time depends on the version of the kernel, the cpu type, the number
of cpus, the clock speed, the etc.
This is before you get into the priority, etc.
Its why generic linux and windows don't make good real time systems.
However you should be able to write some code to average the reported time
from a serial port GPS and get pretty close to the correct time.
Serial ports are somewhat easier to use than USB ones and they frequently
just emulate a serial port anyway.
Chris Davies
> I want my ubuntu servers to keep a VERY accurate time [...]
On 2008-09-06, Chris Davies <chris-...@roaima.co.uk> wrote:
> You mean something like this, http://www.timetools.co.uk/ ?
In comp.os.linux.misc Ignoramus10032 wrote:
> Well, hopefully something cheaper, like an add-on card.
OK. Assuming that MSF is sufficient (I can't remember offhand
what its resolution is, but it's sufficient that you need to
allow for the radio transmission delay across the UK), what about
http://www.buzzard.me.uk/jonathan/radioclock.html? I got the bits a
couple of years ago, and one day (ha!) I hope to complete it.
Chris
Chris Davies
> And remember, even at 115k baud or whatever RS232 stops at, max data
> rate is only about 10K bytes/second..if your time string is 10 bytes
> long thats a millisecond to read it in..
That's exactly why NTP has fudge factors in the configuration file to
adjust the data values read.
Chris
Unruh
>On Sat, 06 Sep 2008 12:03:05 -0500, Ignoramus10032 wrote:
>> I want my ubuntu servers to keep a VERY accurate time. That is, I want to
>> have a clock accurate to less than a millisecond.
>>
>> There is a business reason for it.
>>
>> NTP, when it works, lets me keep a time accurate to a few milliseconds,
>> which is great, but I would like to do better than that.
>Are you sure you want timebase ACCURACY? That is, a very close
>correlation to a standard time?
>Maybe you really want to measure DURATION? That is much easier and
>cheaper to do. A cheap timer/counter can give really astounding precision
>and accuracy of duration measurements. And that accuracy can be
>maintained over surprisingly long time periods.
Well, no. One of the key problems with the cheap crystals in a PC is that
they have typical drifts of 10s of PPM. Even 10PPM is 1 second per day.
I do not know if you call that "astounding accuracy" or whether a day is a
"surpisingly long time period".
>Keeping an accurate timebase, and still communicating over the internet is
>kind of contradictory.
Not sure what you mean by this.
Unruh
>On 2008-09-07, Joe Pfeiffer <pfei...@cs.nmsu.edu> wrote:
>> Ignoramus10032 <ignoram...@NOSPAM.10032.invalid> writes:
>>
>>> On 2008-09-07, Grant Edwards <gra...@visi.com> wrote:
>>>>
>>>> Determining what they mean isn't an issue. The issue is
>>>> getting sub-millisecond accuracy with a user-space program.
>>>>
>>>
>>> Why would it be so, if everything is in RAM and no swapping is going
>>> on?
>>>
>>> For simplicity reasons, I can easily dedicate a computer to this
>>> application, so that it would run no seriously big loads.
>>
>> Unless you go to a real real-time OS, this just isn't going to
>> happen. You can get sub-millisecond a lot of the time,
>> several-millisecond most of the time, but if you really seriously
>> want a guaranteed response time -- especially on short time scales
>> like milliseconds -- general-purpose OSes just don't offer them. When
>> the machine decides to do something that takes time... your response
>> suffers.
>Does that include responding to an interrupt from a serial port?
Interrupts have top priority. And some interrupt drivers are badly written
so they hog the interrupts and do not allow servicing of others.
But if you want to look at a real world example--
www.theory.physics.ubc.ca/chrony/chrony.html -- look at string-- will show
you an ntp clock running off a GArmin 18LVC-- those times are the offsets in
the GPS time readings over time.
The others are other computers that take their time from string but they
run chrony instead of ntp. chrony is about a factor of 2-3 better in
disciplining clocks but it has no ability to use hardware refclocks.
Unruh
>Ignoramus10032 wrote:
>> On 2008-09-06, The Natural Philosopher <a@b.c> wrote:
>>> Ignoramus10032 wrote:
>>>> I want my ubuntu servers to keep a VERY accurate time. That is, I want
>>>> to have a clock accurate to less than a millisecond.
>>>>
>>>> There is a business reason for it.
>>>>
>>>> NTP, when it works, lets me keep a time accurate to a few
>>>> milliseconds, which is great, but I would like to do better than that.
>>>>
>>>> If this is a question of money, a few hundred dollars can be spend on
>>>> buyin some Meinberg card or whatever. I would prefer something with
>>>> open source drivers already available in kernel, and not some closed
>>>> source junk.
>>>>
>>> how long, I wonder, does a system call to read the time from a super
>>> accurate clock take, and how long to do anything useful with it..and how
>>> VARIABLE are these quantities..
>>>
>>> I have to say, sub millisecond, I would be thinking in terms of a real
>>> time operating system and dedicated to the task..Not a Ubuntu server..
>>>
>>
>> A millisecond is a very long time for any computer.
>>
>It certinly wasn't when I used yo do real time programming: Granted the
>clock speeds are way higher these days, but its been accompanied by
>bloatware operating systems, and Linux has suffered this as well.
Interrupts even on bloated systems are "Real time" and work well in
general.
Unruh
Experiments are always a good idea. And I have been running one for about a
year now. See www.theory.physics.ubc.ca/chrony/chrony.html.
From a local network tens of microseconds is a reasonable expectation. from
the ntp server connected to the gps clock a few microseconds is reasonable.
From a computer connected over an adsl link 100s of microseconds are a
reasonable expectation, Even for a connection by internet to a server 1000
miles away, 100s of microseconds is reasonable, even though thought the
round trip time is 10s of milliseconds.
>Then there are various other unpredictable scheduling delays..depending
>on the process lists etc.
>On my linux serer, when freshly booted, an attempt to telnet into it
>after a fresh reboot is instantaneous. After its been up a while though,
>it can take several seconds. I guess something important gets paged out
>eventually. Hardly 'sub millisecond'.
Telnet? I do nope ssh. But anyway, that requires waking up many processes
and reading many files. Also ntp can be told to run at heightened priority,
so it is much less likely to get swapped out.
>Its this whole variability in scheduling that is the raison d'etre of
>real time OS'es, and why Linux doesn't normally get used in its shipped
>state in any time critical application. Linux, like Unix, starts to slow
>down under load. Real time stuff is designed to keep up, until it fails
>utterly.
Those are real time user space programs.
>Without knowing the application, which appears to be sufficiently
>sensitive not to be disclosed, its hard to say what would work better
>though, or whether Linux would be 'good enough'
All I know is that the linux clock can be conditioned to give microsecond
accuracy when called. I have no idea if this is useful to him.
Ie, calling gettimeofday will give microsecond type accuracy at the time it
is called. What happens before of after that call is another issue.
It may be that he does require a reeal-time-OS.
Unruh
No, it is not. The delay comes about because of the traversal of the
operating system and the network card to finally getting the stuff out onto
the internet. Even the packet length on the network is greater than a usec.
You cannot get nanosecond precision, even with a GPS attached directly to
your system. And ntp does not do the best possible job of getting rid of
the jitter. It is a rather simply second order feedback network, which
throws away past data.
>of light is about one nanosecond per foot) plus the minimum delay to get an
>interrupt through the system (perhaps a millisecond). The raw jitter is then
Interrupt times are microsecond range. I tested this by having a program
sendout data out the parallel port, with a gettimeofday just before it was
sent out. That was connected to the interrupt line on the parallel portand
the interrupt routine did a gettimeofday when it received that interrupt.
The difference was about 4-5usec
>the variable delay to get the interrupt acknowledged, that might be from 1
>to 10 milliseconds depending on the speed of the port used (I use a 100 MHz
>NIC connected to a 20 megabit/sec Verizon FiOS link, but the jitter to those
>clock sources may be considerable). So the jitter will not be much of an
>issue with NTP after it has been running a few hours.
There are two sources of jitter-- the clock reading jitter you have
discussed, and the drift rate of the clocks varying due to temp changes (
eg using or not using the computer which causes its temp to fluctuate). NTP
by design is rather slow in responding to the latter (hours) And a change
of 1PPM meas a clock error of 1usec per second.
Now, one can try to compensate by reading the temp of the system ( eg via
one of the on board thermometers) and compensating for the clock drift
rates using that temperature, and get about a factor of 5 improvement in
ntp. One can use chrony and get a factor of 2-3 improvement over ntp (It
respondes faster to termal fluctuations, and averages out over jitter
better if jitter dominates.)
Jim Moe
> I want my ubuntu servers to keep a VERY accurate time. That is, I want
> to have a clock accurate to less than a millisecond.
>
> There is a business reason for it.
>
> NTP, when it works, lets me keep a time accurate to a few
> milliseconds, which is great, but I would like to do better than that.
>
accurate time reference, or do you need the system to respond to
sub-millisecond events in sub-millisecond timeliness?
Linux is not a realtime system. Thread priorities can keep one thread
from responding to an event for 100s of milliseconds. Even acquiring a
timestamp would be fairly meaningless given the time variance in how the
timestamp is returned.
--
jmm (hyphen) list (at) sohnen-moe (dot) com
(Remove .AXSPAMGN for email)
Ignoramus19762
> On 09/06/08 10:03 am, Ignoramus10032 wrote:
>> I want my ubuntu servers to keep a VERY accurate time. That is, I want
>> to have a clock accurate to less than a millisecond.
>>
>> There is a business reason for it.
>>
>> NTP, when it works, lets me keep a time accurate to a few
>> milliseconds, which is great, but I would like to do better than that.
>>
> What are your application requirements? Do you just need a highly
> accurate time reference, or do you need the system to respond to
> sub-millisecond events in sub-millisecond timeliness?
Just to have accurate timestamps.
> Linux is not a realtime system. Thread priorities can keep one thread
> from responding to an event for 100s of milliseconds. Even acquiring a
> timestamp would be fairly meaningless given the time variance in how the
> timestamp is returned.
This is a big topic. I do not feel up to starting it. But suffice it
to say that response times improve greatly when nothing is swapped out
and there are more CPUs than the amount of stuff to compute.
Jean-David Beyer
> On 2008-09-07, Jim Moe <jmm-list...@sohnen-moe.com> wrote:
>> What are your application requirements? Do you just need a highly
>> accurate time reference, or do you need the system to respond to
>> sub-millisecond events in sub-millisecond timeliness?
>
> Just to have accurate timestamps.
>
I thought about this back when I was running sendmail open to the Internet
so people could send to me directly. I did get a lot of spam and I thought
it would help when getting in touch with other users of sendmail to have
accurate time so they could find things in their logs by knowing when they
sent stuff to me (if they did at all).
In the maillog, the timestamps are only to the nearest second, so it seemed
to me that if my clock were accurate to 1/2 second or so, that would be
enough. That is when I stopped running rdate once a day and started using
ntp. But I have made no effort to be more exact than that.
Similarly, my iptables firewall logs only to the nearest second.
You have not said just why you would need more accurate timestamps.
--
.~. Jean-David Beyer Registered Linux User 85642.
/V\ PGP-Key: 9A2FC99A Registered Machine 241939.
/( )\ Shrewsbury, New Jersey http://counter.li.org
^^-^^ 07:35:01 up 32 days, 13:41, 4 users, load average: 4.26, 4.15, 4.08
Ignoramus15569
> Ignoramus19762 wrote:
>> On 2008-09-07, Jim Moe <jmm-list...@sohnen-moe.com> wrote:
>
>>> What are your application requirements? Do you just need a highly
>>> accurate time reference, or do you need the system to respond to
>>> sub-millisecond events in sub-millisecond timeliness?
>>
>> Just to have accurate timestamps.
>>
> I thought about this back when I was running sendmail open to the Internet
> so people could send to me directly. I did get a lot of spam and I thought
> it would help when getting in touch with other users of sendmail to have
> accurate time so they could find things in their logs by knowing when they
> sent stuff to me (if they did at all).
>
> In the maillog, the timestamps are only to the nearest second, so it seemed
> to me that if my clock were accurate to 1/2 second or so, that would be
> enough. That is when I stopped running rdate once a day and started using
> ntp. But I have made no effort to be more exact than that.
>
> Similarly, my iptables firewall logs only to the nearest second.
>
> You have not said just why you would need more accurate timestamps.
>
I can only say "business reason".
Jean-David Beyer
> On 2008-09-08, Jean-David Beyer <jeand...@verizon.net> wrote:
>> Ignoramus19762 wrote:
>>> On 2008-09-07, Jim Moe <jmm-list...@sohnen-moe.com> wrote:
>>>> What are your application requirements? Do you just need a highly
>>>> accurate time reference, or do you need the system to respond to
>>>> sub-millisecond events in sub-millisecond timeliness?
>>> Just to have accurate timestamps.
>>>
>> I thought about this back when I was running sendmail open to the Internet
>> so people could send to me directly. I did get a lot of spam and I thought
>> it would help when getting in touch with other users of sendmail to have
>> accurate time so they could find things in their logs by knowing when they
>> sent stuff to me (if they did at all).
>>
>> In the maillog, the timestamps are only to the nearest second, so it seemed
>> to me that if my clock were accurate to 1/2 second or so, that would be
>> enough. That is when I stopped running rdate once a day and started using
>> ntp. But I have made no effort to be more exact than that.
>>
>> Similarly, my iptables firewall logs only to the nearest second.
>>
>> You have not said just why you would need more accurate timestamps.
>>
>
> I can only say "business reason".
I am not asking you to divulge the business reason.
It just seems to me to be an unusual need.
--
.~. Jean-David Beyer Registered Linux User 85642.
/V\ PGP-Key: 9A2FC99A Registered Machine 241939.
/( )\ Shrewsbury, New Jersey http://counter.li.org
^^-^^ 09:35:01 up 32 days, 15:41, 4 users, load average: 4.72, 4.48, 4.38
Ignoramus15569
> Ignoramus15569 wrote:
>> On 2008-09-08, Jean-David Beyer <jeand...@verizon.net> wrote:
>>> Ignoramus19762 wrote:
>>>> On 2008-09-07, Jim Moe <jmm-list...@sohnen-moe.com> wrote:
>>>>> What are your application requirements? Do you just need a highly
>>>>> accurate time reference, or do you need the system to respond to
>>>>> sub-millisecond events in sub-millisecond timeliness?
>>>> Just to have accurate timestamps.
>>>>
>>> I thought about this back when I was running sendmail open to the Internet
>>> so people could send to me directly. I did get a lot of spam and I thought
>>> it would help when getting in touch with other users of sendmail to have
>>> accurate time so they could find things in their logs by knowing when they
>>> sent stuff to me (if they did at all).
>>>
>>> In the maillog, the timestamps are only to the nearest second, so it seemed
>>> to me that if my clock were accurate to 1/2 second or so, that would be
>>> enough. That is when I stopped running rdate once a day and started using
>>> ntp. But I have made no effort to be more exact than that.
>>>
>>> Similarly, my iptables firewall logs only to the nearest second.
>>>
>>> You have not said just why you would need more accurate timestamps.
>>>
>>
>> I can only say "business reason".
>
> I am not asking you to divulge the business reason.
> It just seems to me to be an unusual need.
>
I agree that it is unusual. I can only say that it is related to finance
Unruh
>Ignoramus19762 wrote:
>> On 2008-09-07, Jim Moe <jmm-list...@sohnen-moe.com> wrote:
>>> What are your application requirements? Do you just need a highly
>>> accurate time reference, or do you need the system to respond to
>>> sub-millisecond events in sub-millisecond timeliness?
>>
>> Just to have accurate timestamps.
>>
>I thought about this back when I was running sendmail open to the Internet
>so people could send to me directly. I did get a lot of spam and I thought
>it would help when getting in touch with other users of sendmail to have
>accurate time so they could find things in their logs by knowing when they
>sent stuff to me (if they did at all).
>In the maillog, the timestamps are only to the nearest second, so it seemed
>to me that if my clock were accurate to 1/2 second or so, that would be
>enough. That is when I stopped running rdate once a day and started using
>ntp. But I have made no effort to be more exact than that.
>Similarly, my iptables firewall logs only to the nearest second.
>You have not said just why you would need more accurate timestamps.
Why not, when it is so easy.
The Natural Philosopher
dennis@home
"Jean-David Beyer" <jeand...@verizon.net> wrote in message
news:oV9xk.708$Dj1.148@trnddc02...
> Ignoramus15569 wrote:
>> I can only say "business reason".
>
> I am not asking you to divulge the business reason.
> It just seems to me to be an unusual need.
I had to design a clock system for the billing records for telephone
exchanges once, they have to be kept very accurate. I expect its something
similar.
Jim Moe
>
>> Linux is not a realtime system. Thread priorities can keep one thread
>> from responding to an event for 100s of milliseconds. Even acquiring a
>> timestamp would be fairly meaningless given the time variance in how the
>> timestamp is returned.
>
> This is a big topic. I do not feel up to starting it. But suffice it
> to say that response times improve greatly when nothing is swapped out
> and there are more CPUs than the amount of stuff to compute.
How likely is that condition going to exist as the application ramps up?
Regardless of how accurate the clock is, acquiring a timely timestamp is
your real need. Linux cannot do that for you.
Are there other servers that host the application? Do they require
sub-millisecond synchronization with each other?
It would seem you need a subsystem that handles whatever those events
are that require such precise timing, that will respond quickly enough,
and buffer one or more events and timestamps together for later collection.
Rick Jones
> > it to say that response times improve greatly when nothing is
> > swapped out and there are more CPUs than the amount of stuff to
> > compute.
> How likely is that condition going to exist as the application
> ramps up?
That probably depends on the conditions at Layer 8 oif the 9 layer model:
https://secure.isc.org/index.pl?/store/t-shirt/
WRT timestapms and linux and such. keep in mind that most (all?) NICs
these days (gig and above) have _some_ sort of interrupt coalescing
mechanism in place that unless you disable will result in traffic
getting "batched" and quite possibly delayed for a non-trivial length
of time (at least on the order of milliseconds) Whether or not that
matters for this particular application I have no idea and may depend
on condtions at Layer 9 of the aforementioned 9 Layer model. Still, I
thought I would mention it despite the potential for drift.
--
denial, anger, bargaining, depression, acceptance, rebirth...
where do you want to be today?
these opinions are mine, all mine; HP might not want them anyway... :)
feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...