Jeroen Mostert wrote:
negatively affect performance of the host (which makes sense, since
driving all virtuals with 1000 interrupts/sec can't be easy). Even so,
You wouldn't expect 1ms ticks. You might get 20 ticks back to back, and
then a gap of 20ms, or even larger numbers. VMs generally
> -Original Message-
> From: questions-
> bounces+edward.mischanko=arcelormittal@lists.ntp.org
> [mailto:questions-
> bounces+edward.mischanko=arcelormittal@lists.ntp.org] On
> Behalf Of Jeroen Mostert
> Sent: Wednesday, December 12, 2012 6:30 PM
> To: questions@lists.ntp.org
> Subj
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 12/13/2012 03:52 AM, Brian Utterback wrote:
> On 12/12/2012 8:57 PM, Rick Jones wrote:
>> It would seem that at least one NIC has the ability to allow one
>> to "schedule" the time at which a packet will be transmitted.
>> This is called "launch tim
andreas.a...@de.transport.bombardier.com wrote:
Dear all,
I'm rather new to NTP so please forgive me, if my question is trivial.
I'm maintaining a legacy system with its own proprietary time
synchronisation protocols. Now I want to add a new subsystem which
requires a NTP daemon to be availabl
On 12/13/2012 5:00 AM, Jonatan Walck wrote:
This is going to be very hard to get it to be useful. Looking at
>the specs for the card, the timestamp you give is relative to a
>clock that is internal to the controller, and is only accurate to
>the nearest second. That is, it is like the PPS in that
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 12/13/2012 02:23 PM, Brian Utterback wrote:
> On 12/13/2012 5:00 AM, Jonatan Walck wrote:
>>> This is going to be very hard to get it to be useful. Looking
>>> at
the specs for the card, the timestamp you give is relative to
a clock that i
On 12/13/12 09:14, Jonatan Walck wrote:
I'm pondering two different use cases and senarios to make this work,
and work well;
In a generic case: If a client or server (same principle) runs NTP and
lets propose run a PPL locking the PHC clock to the local/kernel clock
(I admit this creates new cha
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 12/13/2012 03:34 PM, Brian Utterback wrote:
> On 12/13/12 09:14, Jonatan Walck wrote:
>> I'm pondering two different use cases and senarios to make this
>> work, and work well;
>>
>> In a generic case: If a client or server (same principle) runs
>>
On 12/13/2012 9:45 AM, Jonatan Walck wrote:
The three packet limit is only for 82580 iirc, I350 and I210 widens
the whole rx queue and can save timestamps for each and every incoming
packet.
I might be wrong, but from the flowchart on the data sheet, it looks
like it only buffers three packet
On Thu, Dec 13, 2012 at 08:23:47AM -0500, Brian Utterback wrote:
> >The internal clock of the network controller is the PHC for IEEE1588,
> >it has a 1 ns resolution, and can be steered with a 32 bit fractional
> >of 1 ns. see SYSTIML and TIMINCA in the I210 datasheet.
> >
> >// jwalck
>
> I know
On 2012-12-13 09:08, David Woolley wrote:
Jeroen Mostert wrote:
negatively affect performance of the host (which makes sense, since driving
all virtuals with 1000 interrupts/sec can't be easy). Even so,
You wouldn't expect 1ms ticks. You might get 20 ticks back to back, and then a
gap of 20ms
On 2012-12-13 09:53, Mischanko, Edward T wrote:
I have always read that NTP should not be run Virtual Machines. NTP should
only be running on the "Real" machine with a hardware system clock. If the
hardware machine is in synch, then the VM on the hardware machine should also
be in synch.
That
Jeroen Mostert wrote:> BlackLists wrote:
>> ntpq -c "rv&0 precision"
>> should give a clue how close you can expect to get on
>>a given machine.
>>
> I assume you mean 'ntpq -c "rv 0 precision"'.
> Your command gives me an error.
Yes, however it should work with the '&' on newer 4.2.7 flavo
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 12/13/2012 03:55 PM, Brian Utterback wrote:
> On 12/13/2012 9:45 AM, Jonatan Walck wrote:
>> The three packet limit is only for 82580 iirc, I350 and I210
>> widens the whole rx queue and can save timestamps for each and
>> every incoming packet.
>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 12/13/2012 04:05 PM, Miroslav Lichvar wrote:
> The phc2sys program from the linuxptp project can be used to
> synchronize the system clock to the PHC or the PHC to the system
> clock. It can do that via PPS or filtered clock readings.
>
I've don
On 12/13/2012 6:14 AM, Jonatan Walck wrote:
...
> you wouldn't have to "move time" over the bus at every
> single query. One could fetch a receive timestamp from
> the network controller (actually it'll come along with
> the packet already, so you don't have to fetch anything)
> and use that as
On 2012-12-13, E-Mail Sent to this address will be added to the BlackLists
wrote:
> Jeroen Mostert wrote:> BlackLists wrote:
>>> ntpq -c "rv&0 precision"
>>> should give a clue how close you can expect to get on
>>>a given machine.
>>>
>> I assume you mean 'ntpq -c "rv 0 precision"'.
>> Yo
On 2012-12-13, Jeroen Mostert wrote:
> On 2012-12-13 09:08, David Woolley wrote:
>> Jeroen Mostert wrote:
>>
>>> negatively affect performance of the host (which makes sense, since driving
>>> all virtuals with 1000 interrupts/sec can't be easy). Even so,
>>
>> You wouldn't expect 1ms ticks. You m
On 2012-12-14 00:25, Jeroen Mostert wrote:
I'm an engineer. I don't pay bills, I just foot new ones
Ugh. Of course I'm not footing the new ones either. Current system uptime is
19.5 hours; wizard needs sleep, badly.
--
J.
___
questions mailing lis
On 2012-12-14 00:06, unruh wrote:
On 2012-12-13, Jeroen Mostert wrote:
On 2012-12-13 09:08, David Woolley wrote:
Jeroen Mostert wrote:
negatively affect performance of the host (which makes sense, since driving
all virtuals with 1000 interrupts/sec can't be easy). Even so,
You wouldn't exp
E-Mail Sent to this address will be added to the BlackLists wrote:
That Precision is supposed to represent the time it takes
to read the system clock.
It is the smallest non-zero difference between two readings of the
clock. If the clock is very high resolution, it may be close to the
ti
David Woolley wrote:> BlackLists wrote:
>> That Precision is supposed to represent the time it takes
>> to read the system clock.
>
> It is the smallest non-zero difference between two readings
> of the clock. If the clock is very high resolution,
> it may be close to the time to read the cl
22 matches
Mail list logo
