On Friday 02 March 2007 10:26, John wrote:
> Eric Dumazet wrote:
> > Anyway, if you want to play, you can apply this patch on top of
> > linux-2.6.21-rc2 (nanosecond resolution infrastructure needs 2.6.21)
> > I let you do the adjustments for rt kernel.
>
> Why does it require 2.6.21?
Well, this
Eric Dumazet wrote:
John wrote:
Consider an idle Linux 2.6.20-rt8 system, equipped with a single PCI-E
gigabit Ethernet NIC, running on a modern CPU (e.g. Core 2 Duo E6700).
All this system does is time stamp 1000 packets per second.
Are you claiming that this platform *cannot* handle most pa
On Fri, 02 Mar 2007 00:14:37 +0100
Eric Dumazet <[EMAIL PROTECTED]> wrote:
> Stephen Hemminger a écrit :
>
> >
> > You probably want to add a SO_TIMESTAMPNS setsockopt() value like existing
> > SO_TIMESTAMP
>
> You mean an alias like this ?
>
> #define SO_TIMESTAMPNS SO_TIMESTAMP
>
> Or shou
Stephen Hemminger a écrit :
You probably want to add a SO_TIMESTAMPNS setsockopt() value like existing
SO_TIMESTAMP
You mean an alias like this ?
#define SO_TIMESTAMPNS SO_TIMESTAMP
Or should we really use another value ?
Also use NSEC_PER_USEC rather than hardcoded 1000.
Yes I will
On Thu, 1 Mar 2007 12:30:50 +0100
Eric Dumazet <[EMAIL PROTECTED]> wrote:
> On Wednesday 28 February 2007 17:07, John wrote:
>
> >
> > Consider an idle Linux 2.6.20-rt8 system, equipped with a single PCI-E
> > gigabit Ethernet NIC, running on a modern CPU (e.g. Core 2 Duo E6700).
> > All this sys
On Thursday 01 March 2007 16:54, Stephen Hemminger wrote:
>
> I like it except changing stamp to stampns all over the place is
> unnecessary, just change the
> type.
Well... After seeing the compat code using casts, I felt some external users
could try to cast it as well and not detect the new ty
Eric Dumazet wrote:
On Wednesday 28 February 2007 17:07, John wrote:
Consider an idle Linux 2.6.20-rt8 system, equipped with a single PCI-E
gigabit Ethernet NIC, running on a modern CPU (e.g. Core 2 Duo E6700).
All this system does is time stamp 1000 packets per second.
Are you claiming tha
On Wednesday 28 February 2007 17:07, John wrote:
>
> Consider an idle Linux 2.6.20-rt8 system, equipped with a single PCI-E
> gigabit Ethernet NIC, running on a modern CPU (e.g. Core 2 Duo E6700).
> All this system does is time stamp 1000 packets per second.
>
> Are you claiming that this platform
On Wed, Feb 28, 2007 at 05:07:10PM +0100, John ([EMAIL PROTECTED]) wrote:
> Again, this is irrelevant. We are discussing whether it would make sense
> to support sub-microsecond resolution. If there is one platform that can
> achieve sub-microsecond precision, there is a need for sub-microsecond
On Wed, 28 Feb 2007 14:37:49 +0100
John <[EMAIL PROTECTED]> wrote:
> John wrote:
>
> > I know it's possible to have Linux timestamp incoming datagrams as soon
> > as they are received, then for one to retrieve this timestamp later with
> > an ioctl command or a recvmsg call.
>
> Has it ever been
Eric Dumazet wrote:
On Wednesday 28 February 2007 15:23, John wrote:
Eric Dumazet wrote:
John wrote:
I know it's possible to have Linux timestamp incoming datagrams as soon
as they are received, then for one to retrieve this timestamp later
with an ioctl command or a recvmsg call.
Has it ever
On Wednesday 28 February 2007 15:23, John wrote:
> Eric Dumazet wrote:
> >> John wrote:
> >>> I know it's possible to have Linux timestamp incoming datagrams as soon
> >>> as they are received, then for one to retrieve this timestamp later
> >>> with an ioctl command or a recvmsg call.
> >>
> >> Ha
Eric Dumazet wrote:
John wrote:
I know it's possible to have Linux timestamp incoming datagrams as soon
as they are received, then for one to retrieve this timestamp later with
an ioctl command or a recvmsg call.
Has it ever been proposed to modify struct skb_timeval to hold
nanosecond stamps
On Wednesday 28 February 2007 14:37, John wrote:
> John wrote:
> > I know it's possible to have Linux timestamp incoming datagrams as soon
> > as they are received, then for one to retrieve this timestamp later with
> > an ioctl command or a recvmsg call.
>
> Has it ever been proposed to modify str
John wrote:
I know it's possible to have Linux timestamp incoming datagrams as soon
as they are received, then for one to retrieve this timestamp later with
an ioctl command or a recvmsg call.
Has it ever been proposed to modify struct skb_timeval to hold
nanosecond stamps instead of just mic
Hello,
I know it's possible to have Linux timestamp incoming datagrams as soon
as they are received, then for one to retrieve this timestamp later with
an ioctl command or a recvmsg call.
As far as I understand, one can either do
const int on = 1;
setsockopt(sock, SOL_SOCKET, SO_TIMESTAM
16 matches
Mail list logo
