Skip to main content

System Time retrieval and settings

10 replies [Last post]
amirn
Offline
Joined: 2009-05-06

I have a question regarding MPEOS System Time API (mpeos_getTime).

The current implementation uses system call to retrieve the system time.
This works well on the PC emulator, because the system clock is correctly initialized.
However this may not work on an embedded device, because system time needs to be initialized first.

So MPEOS needs to acquire the system time from the CableCard by looking at the System Time Table (STT)

The OpenCable Host seems to indicate that local time shall be provided by host as defined in SCTE65.

The question is what should be the time base and format returned by mpeos_getTime()? The STT time is based on Jan, 6th 1980. And it looks like mpeos_getTime() is expected to be based on Jan. 1th 1970.

Is MPEOS required to convert from one base to another?

Thanks,
Amir.

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
greg80303
Offline
Joined: 2008-07-03

The priority of task has been bumped up. It will be included in the 1.1.4 release. We have also revised the design slightly. Please see below for the updated design and stack changes

[b]===================================================
New MPE Configuration Variables (in mpeenv.ini)[/b]

[i]# Set to TRUE to enable parsing of the System Time Table. When STT
# parsing is enabled, the stack will handle the update of UTC time
# based on the STT.
# Set to FALSE to disable STT parsing. In this case the stack will
# completely rely on the implementation of mpeos_timeGetMillis()
# to return accurate network time. The native OS should not launch
# the stack until it has received its first network time update to
# prevent "jumps" in UTC time.[/i]
SITP.SI.STT.ENABLED=TRUE

[b]===================================================
MPEOS Porting API Modifications and Clarifications:[/b]

1) Modify the existing mpeos_timeGetMillis() API documentation to read:

/**
* The mpeos_timeGetMillis() function will get a representation of time
* in milliseconds with no worse than 10ms precision. The value returned by this
* function is guaranteed to increase monotonically over the duration of time the
* system is up. If SITP.SI.STT.ENABLED is set to TRUE in the mpeenv.ini, the
* implementation of this API need not return any real representation of UTC
* time. If SITP.SI.STT.ENABLED is set to FALSE, this API MUST always return
* an accurate representation of cable-network UTC time and MUST NOT be subject
* to large time corrections.
*
* @param time is a pointer for returning the current time value.
* @return The MPE error code if the create fails, otherwise MPE_SUCCESS
* is returned.
*/
mpe_Error mpeos_timeGetMillis(mpe_TimeMillis *time);

This modification (and its pass-thru MPE equivalent - mpe_timeGetMillis()) ensures that any JNI, MPE, and MPEOS code has access to a consistent time source that will not be subject to periodic adjustments from the System Time Table.

2) Clarify remainder of MPEOS time APIs

All of the remaining MPEOS porting APIs and types are not used by the upper levels of the RI stack. They are only used by the 'profmgr' profiling library ($OCAPROOT/mpe/mgr/profmgr) and, in some cases, could be used to port JVM profiling tools.

[b]================================
MPE Module and API Modifications[/b]

[i]1) System Time Table (STT) Parsing[/i]

Add new functionality to the SITP (SI Table Parser) module to parse the STT and make a MPE API call (mpe_timeSetMillis()) to update the current system time basis

[i]2) New Internal API -- ??timeSetMillis()??[/i]

This internal API is called by SITP as each STT is parsed to set the current time basis as dictated by the network. Only called when SITP.SI.STT.ENABLED is set to TRUE

[i]3) mpe_timeGetUTCTimeMillis()[/i]

When [b]SITP.SI.STT.ENABLED[/b] is set to FALSE, the API implementation will be a passthru directly to mpeos_timeGetMillis().
When [b]SITP.SI.STT.ENABLED[/b] is set to TRUE, the API implementation will return consistent UTC time as updated by the network operator via the System Time Table. The implementation of this API will use the most recent time basis and the system clock (mpeos_timeGetMillis()) to compute an accurate network-based time. The implementation will provide a "smoothing" algorithm to prevent "time jumps" due to network time corrections.

[i]3a) Poor System Clock[/i]

We must provide some protection against a very poor system clock at boot time. If the receipt of the first STT causes a massive jump in UTC, this can cause major problems for timers set at the Java layer (both in the stack and in the VM itself).

When [b]SITP.SI.STT.ENABLED[/b] is set to TRUE, calls to mpe_timeGetUTCTimeMillis() will block until the first STT has been parsed. Additionally, the JVM will not be started by the stack until the first STT has been parsed.
When [b]SITP.SI.STT.ENABLED[/b] is set to FALSE, calls to mpe_timeGetUTCTimeMillis() will NOT block. However, in this case, ports must ensure that the MPE main function is not launched by their platforms until the first STT has been parsed and proper network time will be returned by mpeos_timeGetMillis().

[b]==================
Java Modifications[/b]

[i]1) TimeZone and Daylight Savings from CableCARD[/i]

Add some code to OcapMain that will monitor the CableCARD generic feature resource for TimeZone and Daylight Savings information. This code will create a custom java.util.SimpleTimeZone object based on the CableCARD data and call java.util.TimeZone.setDefault() to adjust the default system time zone.

[i]2) TimeZone.setDefault() security hole[/i]

The lack of security on java.util.TimeZone.setDefault() could pose a problems for guide applications if a rogue application is allowed to change the system time zone. MHP and subsequent errata have added language to attempt to deal with this problem, but we feel that the language is not strong enough to impose adequate protection. We have an internal project issue that is tracking an OCAP specification change that will solidify the behavior of this method.

Updated the design slightly -- we do not need a new mpeos_timeGetUTCMillis() API.

Message was edited by: greg80303

Updated the design to indicate that we do not need a new MPE API for "timeSetMillis()". Instead it can just be an internal API used by SITP to call into our MPE time-keeping code

Message was edited by: greg80303

scottkell
Offline
Joined: 2007-04-04

Thanks for the details Greg.

So in the case where SITP.SI.STT.ENABLED=FALSE,
[mpe/os/[Win_32,Linux_32]/mpeos_time.c]mpeos_timeGetMillis will provide the system time.
I think this is the same as the current behavior. There is currently a bug logged where the retrieved time is off by 5 hours. Will the off-by-5-hours problem be resolved in mpeos_time.c along with the other time related changes?

Scott

greg80303
Offline
Joined: 2008-07-03

The "off-by-5hours" problem will be resolved with the implementation of the "Java" section of the design. In the case you describe (SITP.SI.STT.ENABLED=FALSE), mpeos_timeGetMillis will provide UTC time (number of milliseconds since Jan 1, 1970 GMT) -- which is always the same regardless of what time zone you are in. The Java fixes will ensure that the correct Java TimeZone object is set based on the values retrieved from the POD. For the SDK, the values provided by the POD implementation should be configurable so that you can set the timezone that you expect.

Greg

amirn
Offline
Joined: 2009-05-06

It looks like mpeos_timeGetMillis() is NOT currently (in RI trunk) implemented as described above. I don't see it returning the time based on SITP.SI.STT.ENABLED.

It always returns the OS system time.

amirn
Offline
Joined: 2009-05-06

Okay. I miss-read the API change description.

Looks like this is the new API: mpe_timeGetUTCTimeMillis.

Does this require the VM to now call this API instead of mpeos_timeGetMillis() to support java Date class implementation?

Why not having changed mpeos_timeGetMillis() instead?

cpratt
Offline
Joined: 2008-12-18

On the second question (Why not having changed mpeos_timeGetMillis() instead?):

As mentioned above, it's important for the stack to have a continuous timebase (one that doesn't change drastically or move backward) for time-sensitve functionality within the stack - which is what mpe_timeGetMillis() has always served.

I believe the first question is also true - but I'll let Greg answer that authoritatively.

greg80303
Offline
Joined: 2008-07-03

If you port your VM to MPE, then yes, you must modify your port to use mpe_timeGetUTCTimeMillis(). You can see our phoneME example in $OCAPROOT/jvm/mpe_jvm/src/mpe/javavm/runtime/time_md.c

G

greg80303
Offline
Joined: 2008-07-03

We have been discussing this issue internally for several weeks and have put together the following plan as a proposed solution. We encourage all members of our community to comment on the proposed plan. We anticipate that the implementation of this plan will not make it into the RI until the 1.2 release.

[b]===================================================
MPEOS Porting API Modifications and Clarifications:[/b]

1) Remove the existing mpeos_timeGetMillis() API and replace it with the following:

/**
* The mpeos_timeGetSystemTimeMillis() function will get a representation of system time
* in milliseconds with no worse than 10ms precision. The value returned by this function is
* guaranteed to increase monotonically over the duration of time the system is up. However,
* the values returned are not guaranteed to correspond to any representation of local time
* (UTC or any other).
*
* @param time is a pointer for returning the current system time value.
* @return The MPE error code if the create fails, otherwise MPE_SUCCESS
* is returned.
*/
mpe_Error mpeos_timeGetSystemTimeMillis(mpe_TimeMillis *time);

This new API (and its pass-thru MPE equivalent - mpe_timeGetSysteTimeMillis()) allows any JNI, MPE, and MPEOS code to have access to a consistent time source that will not be subject to periodic adjustments from the System Time Table. Native level timers in the RI that really only care about "time offsets" will use this API.

2) Clarify remainder of MPEOS time APIs

All of the remaining MPEOS porting APIs and types are not used by the upper levels of the RI stack. They are only used by the 'profmgr' profiling library ($OCAPROOT/mpe/mgr/profmgr) and, in some cases, could be used to port JVM profiling tools.

[b]================================
MPE Module and API Modifications[/b]

[i]1) System Time Table (STT) Parsing[/i]

Add new functionality to the SITP (SI Table Parser) module to parse the STT and make a MPE API call (mpe_timeSetMillis()) to update the current system time basis

[i]2) New API -- mpe_timeSetMillis()[/i]

This API is called by SITP as each STT is parsed to set the current time basis as dictated by the network.

[i]3) mpe_timeGetMillis()[/i]

This API, which was originally a passthru directly to mpeos_timeGetMillis(), will be re-worked to provide consistent UTC time as updated by the network operator via the System Time Table. The implementation of this API will use the most recent time basis and the system clock (mpeos_timeGetSystemTimeMillis()) to compute an accurate network-based time.

[i]3a) Preventing Backwards "Time Jumps"[/i]

mpe_timeGetMillis() will guarantee that the time value will NEVER decrease. The implementation will keep track of the last value returned by mpe_timeGetMillis(). If updates to the time basis (because of a new STT) would cause the computed UTC to be less than the last value returned, it will return the last value instead. In other words, "time can stand still, but it can never go back".

[i]3b) Configuring use of STT[/i]

It will be configurable (via mpeenv.ini) whether this STT time computation/adjustment actually takes place in mpe_timeGetMillis() or if the value of mpe_timeGetSystemTimeMillis() is used directly as UTC. This will allow our PC Platform and SDK to rely on the Window or Linux OS time and ignore our "invalid" STT sections.

[i]3c) Poor System Clock[/i]

We must provide some protection against a very poor system clock at boot time. If the receipt of the first STT causes a massive jump in UTC, this can cause problems for timers set at the Java layer (both in the stack and in the VM itself). We propose functionality that can be disable/enabled in the mpeenv.ini file that will cause all threads to block when calling mpe_timeGetMillis() until the first STT is received. This will increate boot times, but if a porting team feels that this is unecessary for their device, they can disable it.

[b]==================
Java Modifications[/b]

[i]1) TimeZone and Daylight Savings from CableCARD[/i]

Add some code to OcapMain that will monitor the CableCARD generic feature resource for TimeZone and Daylight Savings information. This code will create a custom java.util.SimpleTimeZone object based on the CableCARD data and call java.util.TimeZone.setDefault() to adjust the default system time zone.

[i]2) TimeZone.setDefault() security hole[/i]

The lack of security on java.util.TimeZone.setDefault() could pose a problems for guide applications if a rogue application is allowed to change the system time zone. MHP and subsequent errata have added language to attempt to deal with this problem, but we feel that the language is not strong enough to impose adequate protection. We have an internal project issue that is tracking an OCAP specification change that will solidify the behavior of this method.

Message was edited by: greg80303

Message was edited by: greg80303

amirn
Offline
Joined: 2009-05-06

Thanks,

I think this will resolve the system time issue in the stack. We currently have an implementation (in mpeos) based on STT that works. It is simpler than the solution proposed here and didn't require the addition of a new API. We also didn't have to worry about the RI Emulator backward compatibility.

greg80303
Offline
Joined: 2008-07-03

I would definitely verify that your OS clock doesn't skew too much with respect to the network time. Various timers in MPE and Java (especially Object Carousel) will not react too well to "jumps" in time (particularly backwards jumps) as reported by mpeos_timeGetMillis().

Also, don't forget about TimeZone and Daylight Savings settings from the CableCARD. If your applications use java.util.Date() to get localtime information, that value will be incorrect unless the timezone is set correctly.

G

swati_V
Offline
Joined: 2012-07-09

hi greg,
i am also facing some similar issue in ocap related t timezone setting.by default it gives off by 5 hours time. i want to to set it to take gmt +5:30.
i have made required changes in GfDatabseFile.xml file as follow:
timezone= "AUo="
daylight_saving= "AQAAAAAAAAAAAA=="

but still it is not giving me the correct system time.
any suggestion on this?
please reply.