netdev - Re: [net-next 5/6] ixgbe: add hardware timestamping support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 19 Oct 2011 10:04:33 -0700
From:	Jacob Keller <jacob.keller@...il.com>
To:	Richard Cochran <richardcochran@...il.com>
Cc:	Jeff Kirsher <jeffrey.t.kirsher@...el.com>, davem@...emloft.net,
	Jacob Keller <jacob.e.keller@...el.com>,
	netdev@...r.kernel.org, gospo@...hat.com, sassmann@...hat.com
Subject: Re: [net-next 5/6] ixgbe: add hardware timestamping support

On Mon, Oct 17, 2011 at 9:44 AM, Richard Cochran
<richardcochran@...il.com> wrote:
> On Mon, Oct 17, 2011 at 05:21:01AM -0700, Jeff Kirsher wrote:
>> The cyclecounter has the potential to miss a wrap-around of the
>> systim register (this should occur no more often than every 35
>> seconds) unless some activity regarding the cycle counter occurs at
>> least once within this time. This version adds a cycle counter read
>> every time the watchdog task is run, which should occur at least once
>> within this timeframe. Any packets being timestamped will also count
>> as a read due to the call to timecompare_update.
>
> So, is this wrap around due to the fact that you are tied to the
> system time via time_compare? Or, putting it another way, can't you
> program the hardware time stamping unit so that the registers have
> some reasonable resolution (like 64 bits worth of nanoseconds) and
> just offer RAW timestamps?

The wrap around is due to hardware limitations. The ixgbe devices
cannot support 64bits worth of nanoseconds and still have the ability
to adjust the frequency in parts per billion. A larger increment
increases the resolution available for frequency adjustments, but
decreases the time it takes for the cycle counter to wrap around.

>
> I would really like to move away from the timecompare hacks and
> towards a proper PHC->SYS PPS solution.
>

I agree that this is the correct approach. The timecompare
functionality does have issues.

>> This version fixes an issue regarding timecompare not updating
>> detected skew after the clock offset is changed due to ptpd or outside
>> influence from the OS. Now the skew detection is forced just before we
>> hand a timestamp up to the kernel stack
>
> Again, doing the update thing on every packet won't work for real
> world PTP scenarios.
>
Which is why the PHC solution is better. Work on implementing this
support is in progress. Out of curiosity, what is the sync rate for
the scenario that breaks this? I would like to try that rate out on my
setup.

> Thanks,
> Richard
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@...r.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html