Brian Utterback wrote:
> On 12/20/2012 6:25 AM, Ulf Samuelsson wrote:
>>
>>> Yes there is. The ntpd program has to set a timestamp in the outgoing
>>> packet and then specify the launchtime when it writes the packet. The
>>> goal here is to have the timestamp written in the packet exactly match
>
On 12/20/2012 6:25 AM, Ulf Samuelsson wrote:
Yes there is. The ntpd program has to set a timestamp in the outgoing
packet and then specify the launchtime when it writes the packet. The
goal here is to have the timestamp written in the packet exactly match
the time the packet actually hits the w
Ulf Samuelsson wrote:
> Rick Jones skrev 2012-12-13 02:57:
> > 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 time support." Someone in Linux-land has started
> > asking about the prosp
On 19 Dec, 2012, at 13:49 , Brian Utterback wrote:
> On 12/19/12 14:05, unruh wrote:
>> On 2012-12-19, Hal Murray wrote:
>>>
>>> Doesn't the PPS signal to the kernel have to go over the same PCI bus?
...
> Generally, the PPS signal does not go over the PCI bus. The kernel gets its
> PPS signal
On 19 Dec, 2012, at 11:05 , unruh wrote:
> On 2012-12-19, Hal Murray wrote:
>>
>> Doesn't the PPS signal to the kernel have to go over the same PCI bus?
>>
>> I'd guess that you would get better results from a network card.
>> That's assuming it has a good clock. All you have to do is read
>>
On 2012-12-20 09:08, Jonatan Walck wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 12/19/2012 11:52 PM, Brian Utterback wrote:
On 12/19/12 16:49, Brian Utterback wrote:
Generally, the PPS signal does not go over the PCI bus. The
kernel gets its PPS signal via the serial port. You woul
On 2012-12-19 22:49, Brian Utterback wrote:
On 12/19/12 14:05, unruh wrote:
On 2012-12-19, Hal Murray
wrote:
In article<50d1c5b9.8020...@oracle.com>,
Brian Utterback writes:
No, you are missing the point. You have two clocks in this scenario,
the
kernel clock and the network controller clo
On 2012-12-19 17:05, Brian Utterback wrote:
On 12/19/12 10:12, Ulf Samuelsson wrote:
Now, if you have a PPS signal available and can provide it to both the
network controller and the kernel, then you don't have this problem
since the PPS signal will sync the time to an accuracy better than the
On 2012-12-20 10:32, Hal Murray wrote:
In article ,
unruh writes:
Pick the best one? How would you know what the best one was?
Read TSC, read clock, read TSC. Subtract the TSC values to
get an upper limit on how long it took to read the clock.
Best is fastest.
Not sure what you mean by
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 12/19/2012 11:52 PM, Brian Utterback wrote:
> On 12/19/12 16:49, Brian Utterback wrote:
>>
>> Generally, the PPS signal does not go over the PCI bus. The
>> kernel gets its PPS signal via the serial port. You would
>> therefore like the controller
On 12/19/12 16:49, Brian Utterback wrote:
Generally, the PPS signal does not go over the PCI bus. The kernel
gets its PPS signal via the serial port. You would therefore like the
controller to have its own PPS signal input, but I don't see one in
the datasheet.
So you are back to worrying a
On 12/19/12 14:05, unruh wrote:
On 2012-12-19, Hal Murray wrote:
In article<50d1c5b9.8020...@oracle.com>,
Brian Utterback writes:
No, you are missing the point. You have two clocks in this scenario, the
kernel clock and the network controller clock. If one gets a good time
then you have to
On 2012-12-19, Hal Murray wrote:
> In article <50d1c5b9.8020...@oracle.com>,
> Brian Utterback writes:
>
>>No, you are missing the point. You have two clocks in this scenario, the
>>kernel clock and the network controller clock. If one gets a good time
>>then you have to set the other from it.
On Wed, Dec 19, 2012 at 11:05:57AM -0500, Brian Utterback wrote:
> On 12/19/12 10:12, Ulf Samuelsson wrote:
> >The desired launchtime is compared to the network controller
> >timestamp counter in H/W, so again there is no need to synchronize
> >with the system time.
>
> Yes there is. The ntpd prog
On 12/19/12 10:12, Ulf Samuelsson wrote:
Now, if you have a PPS signal available and can provide it to both the
network controller and the kernel, then you don't have this problem
since the PPS signal will sync the time to an accuracy better than the
jitter that was introduced.
Even without th
On 2012-12-19 14:48, Brian Utterback wrote:
On 12/18/2012 7:05 PM, Ulf Samuelsson wrote:
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 t
On 12/18/2012 7:05 PM, Ulf Samuelsson wrote:
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 is internal to the controller, and is onl
On 2012-12-19 04:07, E-Mail Sent to this address will be added to the
BlackLists wrote:
Ulf Samuelsson wrote:> BlackLists wrote:
Ulf Samuelsson wrote:
In my proposal, I add a new flag to "socket.c:sendto".
While the launchtime is proposed to configurable using
Kconfig, this adds a small perfo
Ulf Samuelsson wrote:> BlackLists wrote:
>> Ulf Samuelsson wrote:
>>> In my proposal, I add a new flag to "socket.c:sendto".
>>> While the launchtime is proposed to configurable using
>>> Kconfig, this adds a small performance penalty to every
>>> other packet sent over Ethernet.
>>>
>>> An alter
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 is internal to the controller, and is only accurate to
the nearest sec
E-Mail Sent to this address will be added to the BlackLists
wrote:
> Ulf Samuelsson wrote:
>> In my proposal, I add a new flag to "socket.c:sendto".
>> While the launchtime is proposed to configurable using
>> Kconfig, this adds a small performance penalty to every
>> other packet sent over Ethe
Ulf Samuelsson wrote:
> In my proposal, I add a new flag to "socket.c:sendto".
> While the launchtime is proposed to configurable using
> Kconfig, this adds a small performance penalty to every
> other packet sent over Ethernet.
>
> An alternative would be to extend the kernel with a new
> sysca
Rick Jones skrev 2012-12-13 02:57:
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 time support." Someone in Linux-land has started
asking about the prospect of enabling support of that in the
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
-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
-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.
>
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 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
-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/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 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/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 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
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 time support." Someone in Linux-land has started
asking about the prospect of enabling support of that i
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 time support." Someone in Linux-land has started
asking about the prospect of enabling support of that in the stack,
with his stated use case being
35 matches
Mail list logo
