[Linuxptp-devel] timecounter mask for non-bitwise overflowing?

[Keller, Jacob E]

Hey Richard, and others,

I am currently implementing a timecounter setup for a device which
(nominally) represents time as

Field1: 32bits, Seconds
Field2: 32bits, Nanoseconds (never > 999,999,999)

I do the math to convert this to u64 nanoseconds, and provide this to a
cycle counter.

The trouble is that the u64 field "overflows" at an arbitrary number,
not at a potential mask value.

Since seconds value will overflow at 0xFFFFFFFF, the nanoseconds u64
field overflows at

0xFFFFFFFF*(0d1000000000) + 0d999999999 or 3B9AC9FFFFFFFFFF which is not
a mask-able value.

It overflows somewhete between (2^61)-1 and (2^62)-1.. That is, 2^61-1
is a valid value, but (2^62)-1 is not.

I am trying to determine what mask I can use for this. If I use 64,
obviously I will get an incorrect value.

I believe that I have to use the mask as 41 bits, which is the maximum
value that it can actually hold that consistently overflows at the same
location.

I think the timecounter code is actually incorrect, because it doesn't
allow for arbitrary overflow points....

I tried it out at using 61, and it really didn't look right.. But I
don't really like the idea that I have to mask all the way down to 41
bits.

Any suggestions or thoughts on the timecounter stuff?

Regards,
Jake

[Richard Cochran]

Post by Keller, Jacob E
Hey Richard, and others,
I am currently implementing a timecounter setup for a device which
(nominally) represents time as
Field1: 32bits, Seconds
Field2: 32bits, Nanoseconds (never > 999,999,999)
I do the math to convert this to u64 nanoseconds, and provide this to a
cycle counter.

So, I guess you want to do this because your HW has this split
representation, but you cannot adjust the frequency?

Post by Keller, Jacob E
I think the timecounter code is actually incorrect, because it doesn't
allow for arbitrary overflow points....

I think the timecounter is okay. Your problem is that the timecounter
uses base-2 counting, but your clock counts 10^9 nanoseconds (base-10).

Post by Keller, Jacob E
Any suggestions or thoughts on the timecounter stuff?

32 bits of seconds gives you 136 years of uptime (assuming the counter
starts at zero). You can just use a 64 bit mask and forget about the
overflow, since it can never happen in practice.


HTH,
Richard

[Keller, Jacob E]

-----Original Message-----
Sent: Saturday, April 04, 2015 1:27 PM
To: Keller, Jacob E
Subject: Re: [Linuxptp-devel] timecounter mask for non-bitwise
overflowing?

Post by Keller, Jacob E
Hey Richard, and others,
I am currently implementing a timecounter setup for a device which
(nominally) represents time as
Field1: 32bits, Seconds
Field2: 32bits, Nanoseconds (never > 999,999,999)
I do the math to convert this to u64 nanoseconds, and provide this to a
cycle counter.

So, I guess you want to do this because your HW has this split
representation, but you cannot adjust the frequency?

Several reasons:

1) consistency with the rest of the hardware in the driver
2) atomic time increments (I have a patch I want to propose that will enable atomic time increment for timecounters by just adding or subtracting from the offset)
3) hardware may have to change the frequency of the clock driving the system timer, so even though it was supposed to represent nominal seconds and nanoseconds, it won't actually, since the underlying clock won't be running at the right frequency).
4) support the gettime64/settime64 routines via the timecounter.

Post by Keller, Jacob E
I think the timecounter code is actually incorrect, because it doesn't
allow for arbitrary overflow points....

I think the timecounter is okay. Your problem is that the timecounter
uses base-2 counting, but your clock counts 10^9 nanoseconds (base-10).

Post by Keller, Jacob E
Any suggestions or thoughts on the timecounter stuff?

32 bits of seconds gives you 136 years of uptime (assuming the counter
starts at zero). You can just use a 64 bit mask and forget about the
overflow, since it can never happen in practice.

Ok. That's what I was thinking. I would prefer that it not happen at all, but it really is a non-issue as you said.

HTH,
Richard

[Richard Cochran]

Post by Keller, Jacob E

Post by Richard Cochran
So, I guess you want to do this because your HW has this split
representation, but you cannot adjust the frequency?

1) consistency with the rest of the hardware in the driver
2) atomic time increments (I have a patch I want to propose that will enable atomic time increment for timecounters by just adding or subtracting from the offset)

We have this already. See 796c1ef in v4.0-rc1.

Post by Keller, Jacob E
3) hardware may have to change the frequency of the clock driving the system timer, so even though it was supposed to represent nominal seconds and nanoseconds, it won't actually, since the underlying clock won't be running at the right frequency).
4) support the gettime64/settime64 routines via the timecounter.

Of course, the big disadvantage of using timecounter is that it makes
it difficult or impossible to use hardware features like periodic
output signals or external time stamps.

Post by Keller, Jacob E

Post by Richard Cochran
32 bits of seconds gives you 136 years of uptime (assuming the counter
starts at zero). You can just use a 64 bit mask and forget about the
overflow, since it can never happen in practice.

Ok. That's what I was thinking. I would prefer that it not happen at all, but it really is a non-issue as you said.

IMHO an uptime range of 136 years is reasonable, but you should
document the actual range of possibilities according to the
frequencies you mentioned.

Thanks,
Richard

[Keller, Jacob E]

-----Original Message-----
Sent: Tuesday, April 07, 2015 10:33 PM
To: Keller, Jacob E
Subject: Re: [Linuxptp-devel] timecounter mask for non-bitwise
overflowing?

Post by Keller, Jacob E

Post by Richard Cochran
So, I guess you want to do this because your HW has this split
representation, but you cannot adjust the frequency?

1) consistency with the rest of the hardware in the driver
2) atomic time increments (I have a patch I want to propose that will

enable atomic time increment for timecounters by just adding or subtracting
from the offset)
We have this already. See 796c1ef in v4.0-rc1.

Yep I didn't notice this yet, but when I was looking at the code I thought of it. I'll get it implemented then :)

Post by Keller, Jacob E
3) hardware may have to change the frequency of the clock driving the

system timer, so even though it was supposed to represent nominal seconds
and nanoseconds, it won't actually, since the underlying clock won't be
running at the right frequency).

Post by Keller, Jacob E
4) support the gettime64/settime64 routines via the timecounter.

Of course, the big disadvantage of using timecounter is that it makes
it difficult or impossible to use hardware features like periodic
output signals or external time stamps.

Yea. The problem is that I pretty much can't use those anyways if the hardware frequency is incorrect, (which regrettably in this case it is).

Post by Keller, Jacob E

Post by Richard Cochran
32 bits of seconds gives you 136 years of uptime (assuming the counter
starts at zero). You can just use a 64 bit mask and forget about the
overflow, since it can never happen in practice.

Ok. That's what I was thinking. I would prefer that it not happen at all, but

it really is a non-issue as you said.
IMHO an uptime range of 136 years is reasonable, but you should
document the actual range of possibilities according to the
frequencies you mentioned.

Ofcourse. Thanks for the help.

Thanks,
Richard