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

On Wed, Oct 19, 2011 at 10:04:33AM -0700, Jacob Keller wrote:

On Mon, Oct 17, 2011 at 9:44 AM, Richard Cochran [off-list ref] wrote:

quoted

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.

Oh, well. That stinks.

I think you do want to offer ppb adjustment.

quoted

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.

And these cards are highlighting timecompare weaknesses I had not even
thought of.

I expect that if you offer the RAW time stamps, then it should be
possible to have the time stamp values always correct (or nearly so)
even with a changing link speed. If the link speed change gives an
interrupt, then the ISR can reprogram the frequency compensation
registers and let the counter continue.

quoted

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.

For the audio/video profile, they have a max of 32 sync packets per
second. Not sure about delay request rate, maybe 16 per second.

Thanks,
Richard