Re: Keeping a VERY accurate time (within a millisecond)

On 09/06/08 10:03 am, Ignoramus10032 wrote:[color=blue]
> 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.
>[/color]
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?
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)

On 2008-09-07, Jim Moe <jmm-list.AXSPAMGN@sohnen-moe.com> wrote:[color=blue]
> On 09/06/08 10:03 am, Ignoramus10032 wrote:[color=green]
>> 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.
>>[/color]
> 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?[/color]

Just to have accurate timestamps.
[color=blue]
> 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.[/color]

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.
--
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.
[url]http://improve-usenet.org/[/url]

Ignoramus19762 wrote:[color=blue]
> On 2008-09-07, Jim Moe <jmm-list.AXSPAMGN@sohnen-moe.com> wrote:[/color]
[color=blue][color=green]
>> 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?[/color]
>
> Just to have accurate timestamps.
>[/color]
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 [url]http://counter.li.org[/url]
^^-^^ 07:35:01 up 32 days, 13:41, 4 users, load average: 4.26, 4.15, 4.08

On 2008-09-08, Jean-David Beyer <jeandavid8@verizon.net> wrote:[color=blue]
> Ignoramus19762 wrote:[color=green]
>> On 2008-09-07, Jim Moe <jmm-list.AXSPAMGN@sohnen-moe.com> wrote:[/color]
>[color=green][color=darkred]
>>> 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?[/color]
>>
>> Just to have accurate timestamps.
>>[/color]
> 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.
>[/color]

I can only say "business reason".
--
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.
[url]http://improve-usenet.org/[/url]

Ignoramus15569 wrote:[color=blue]
> On 2008-09-08, Jean-David Beyer <jeandavid8@verizon.net> wrote:[color=green]
>> Ignoramus19762 wrote:[color=darkred]
>>> On 2008-09-07, Jim Moe <jmm-list.AXSPAMGN@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.
>>>[/color]
>> 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.
>>[/color]
>
> I can only say "business reason".[/color]

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 [url]http://counter.li.org[/url]
^^-^^ 09:35:01 up 32 days, 15:41, 4 users, load average: 4.72, 4.48, 4.38

On 2008-09-08, Jean-David Beyer <jeandavid8@verizon.net> wrote:[color=blue]
> Ignoramus15569 wrote:[color=green]
>> On 2008-09-08, Jean-David Beyer <jeandavid8@verizon.net> wrote:[color=darkred]
>>> Ignoramus19762 wrote:
>>>> On 2008-09-07, Jim Moe <jmm-list.AXSPAMGN@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.
>>>[/color]
>>
>> I can only say "business reason".[/color]
>
> I am not asking you to divulge the business reason.
> It just seems to me to be an unusual need.
>[/color]

I agree that it is unusual. I can only say that it is related to finance

--
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.
[url]http://improve-usenet.org/[/url]

Jean-David Beyer <jeandavid8@verizon.net> writes:
[color=blue]
>Ignoramus19762 wrote:[color=green]
>> On 2008-09-07, Jim Moe <jmm-list.AXSPAMGN@sohnen-moe.com> wrote:[/color][/color]
[color=blue][color=green][color=darkred]
>>> 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?[/color]
>>
>> Just to have accurate timestamps.
>>[/color]
>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).[/color]
[color=blue]
>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.[/color]
[color=blue]
>Similarly, my iptables firewall logs only to the nearest second.[/color]
[color=blue]
>You have not said just why you would need more accurate timestamps.[/color]

Why not, when it is so easy.

Ignoramus15569 wrote:[color=blue]
> On 2008-09-08, Jean-David Beyer <jeandavid8@verizon.net> wrote:[color=green]
>> Ignoramus15569 wrote:[color=darkred]
>>> On 2008-09-08, Jean-David Beyer <jeandavid8@verizon.net> wrote:
>>>> Ignoramus19762 wrote:
>>>>> On 2008-09-07, Jim Moe <jmm-list.AXSPAMGN@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".[/color]
>> I am not asking you to divulge the business reason.
>> It just seems to me to be an unusual need.
>>[/color]
>
> I agree that it is unusual. I can only say that it is related to finance
>[/color]
like who bids first or something on an auction..

"Jean-David Beyer" <jeandavid8@verizon.net> wrote in message
news:oV9xk.708$Dj1.148@trnddc02...[color=blue]
> Ignoramus15569 wrote:[/color]
[color=blue][color=green]
>> I can only say "business reason".[/color]
>
> I am not asking you to divulge the business reason.
> It just seems to me to be an unusual need.[/color]

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.

On 09/07/08 08:25 pm, Ignoramus19762 wrote:[color=blue]
>[color=green]
>> 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.[/color]
>
> 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.[/color]

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.

--
jmm (hyphen) list (at) sohnen-moe (dot) com
(Remove .AXSPAMGN for email)

> > This is a big topic. I do not feel up to starting it. But suffice[color=blue][color=green]
> > 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.[/color][/color]
[color=blue]
> How likely is that condition going to exist as the application
> ramps up?[/color]

That probably depends on the conditions at Layer 8 oif the 9 layer model:

[url]https://secure.isc.org/index.pl?/store/t-shirt/[/url]

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