On Tuesday, February 26, 2013 10:57:22 AM UTC+10, unruh wrote:
> handling. And I only saw 1-2 us difference. Why are you getting 12us on
> the ldisc code?
The 11us in my case is how long it takes to get from early in the interrupt
code in arch/x86/kernel/irq_32.c to where the time stamp is normal
On 2013-02-26, Trevor Woerner wrote:
> Hi David,
>
> Thank you for your reply.
>
> On Tue, Feb 26, 2013 at 10:09 AM, David Taylor
> wrote:
>> The current NTP is 4.2.6, with 4.2.7 at an advanced development stage. My
>> first suggestion would be to update to at least the current NTP and see
>> wh
On Tue, Feb 26, 2013 at 12:46 PM, David Taylor
wrote:
> Bill's (unruh) point about the multiple time resets is pertinent - they
> simply shouldn't be happening. It suggests that something else might be
> trying to set the time (were you running Windows).
Thanks for your thoughts and suggestions.
Thanks for taking a look.
On Tue, Feb 26, 2013 at 12:25 PM, unruh wrote:
>> When NTPd is started up on the client, it will initially set its time with:
>>
>> # ntpd -n -q -g
>
> Why?
> ntpd will step the clock if it decides that the time is out by .128 sec.
> It will die if the time is out by
On 26/02/2013 17:01, Trevor Woerner wrote:
Hi David,
Thank you for your reply.
[]
I have replaced ntpd, ntpdate, ntpq, and tickadj on my client with a
build I just performed of ntp-dev-4.2.7p357. I configured this build
with the following options:
--enable-accurate-adjtime
--enable-s
On 2013-02-25, Trevor Woerner wrote:
> Hi everyone,
>
> I have been getting the following pattern show up in my log files and
> I'm hoping to better understand why and perhaps figure out how to
> improve the situation.
>
> I have two machines. One of which, the server, is syncing to an
> upstream
On 2013-02-26, Rob wrote:
> Richard B. Gilbert wrote:
>> I think that many hardware terminals e.g. VT100 or VT320 do not handle
>> long lines well.
>>
>> I can't see any reason why anyone would need to send more than 132
>> characters in one line of text!
>>
>> You may have noted that books, ma
On 2013-02-26, Charles Elliott wrote:
> I performed the same kind of test on a commercial real-time O/S at
> the time sold by Intel, but since divested. I put code in a program to
> output a digital pulse when the mock application program received
> notification of the parallel port interru
I'm starting to feel fairly inept.
I just moved an 18x to my office and attached it to a Dell running Ubuntu.
Very similar to the previous host which worked fine. I can't figure out why my
current status is 2001 instead of 2007.
remote refid st t when poll reach delay
Hi David,
Thank you for your reply.
On Tue, Feb 26, 2013 at 10:09 AM, David Taylor
wrote:
> The current NTP is 4.2.6, with 4.2.7 at an advanced development stage. My
> first suggestion would be to update to at least the current NTP and see
> whether the problem disappears.
>
> 4.2.0a may be so
Richard B. Gilbert wrote:
> I think that many hardware terminals e.g. VT100 or VT320 do not handle
> long lines well.
>
> I can't see any reason why anyone would need to send more than 132
> characters in one line of text!
>
> You may have noted that books, magazines and newspapers limit their l
On 2/21/2013 1:08 PM, Mike S wrote:
On 2/21/2013 8:52 AM, Brian Utterback wrote:
Having said that, I note that Ed Mischanko's mailer is not sending
text/plain flowed. So unruh has a point in that case.
On 2/21/2013 8:38 AM, Brian Utterback wrote:
Hate to get into a religious war here, but ther
On 2/21/2013 8:38 AM, Brian Utterback wrote:
Hate to get into a religious war here, but there is a hard, factual
standard here. RFC2646 which defines the MIME type text/plain format
parameter. If you are reading a message with content type text/plain and
format set to "flowed", and a non-quoted l
On 25/02/2013 20:31, Trevor Woerner wrote:
Hi everyone,
[]
The client:
- is running NTP version 4.2.4p4
[]
The server's IP address is 148.198.225.221 and is running ntpd 4.2.0a.
[]
Any suggestions? Can I provide any more information?
Best regards,
Trevor
The current NTP is 4.2.6, wi
Hi everyone,
I have been getting the following pattern show up in my log files and
I'm hoping to better understand why and perhaps figure out how to
improve the situation.
I have two machines. One of which, the server, is syncing to an
upstream NTP server over one ethernet interface and acts as t
The PPSAPI specification (RFC 2783) has an echo function where the PPS
driver must assert/clear an output pin after receiving the PPS event,
although the Linux PPS drivers doesn't seem to implement this.
I tried this method on a polling PPS driver but using the time mark
function of a LEA-6T GPS r
I performed the same kind of test on a commercial real-time O/S at
the time sold by Intel, but since divested. I put code in a program to
output a digital pulse when the mock application program received
notification of the parallel port interrupt and measured the interrupt
service delay b
17 matches
Mail list logo
