Abstract: Described are examples for synchronizing multiple timing sources in a computing device. At least a first clock associated with a first timing source and a second clock associated with a second timing source can be maintained at the computing device. A request for an indication of a difference in values between the first clock and the second clock can be received from the application. A first elapsed time of the first clock and a second elapsed time of the second clock from a previous instance of an event can be determined by the computing device at an instance of a reoccurring event in a domain of one of the first timing source or the second timing source. An indication related to the first elapsed time and the second elapsed time can be provided to the application.

Abstract: Described are examples for synchronizing multiple timing sources in a computing device. At least a first clock associated with a first timing source and a second clock associated with a second timing source can be maintained at the computing device. A request for an indication of a difference in values between the first clock and the second clock can be received from the application. A first elapsed time of the first clock and a second elapsed time of the second clock from a previous instance of an event can be determined by the computing device at an instance of a reoccurring event in a domain of one of the first timing source or the second timing source. An indication related to the first elapsed time and the second elapsed time can be provided to the application.

Abstract: A “Compatibility Tester” extracts observable behaviors from different system implementations (e.g., software, operating systems, device drivers, hardware interfaces, etc.), then performs compatibility testing via comparisons of the extracted behaviors. Traces (e.g., bus level signals between controllers and hardware devices or commands between software components) representing observable behaviors of different implementations of a system are captured. Temporal and structural rules are then mined from these traces. The mined rules (or a model constructed from those rules) are used by a “Rule Checking” process that determines whether reference rules (mined from a known compatible system) are compatible with rules mined from test traces of a second system. Invalid rules are flagged as behavioral compatibility bugs.

Abstract: A “Compatibility Tester” extracts observable behaviors from different system implementations (e.g., software, operating systems, device drivers, hardware interfaces, etc.), then performs compatibility testing via comparisons of the extracted behaviors. Traces (e.g., bus level signals between controllers and hardware devices or commands between software components) representing observable behaviors of different implementations of a system are captured. Temporal and structural rules are then mined from these traces. The mined rules (or a model constructed from those rules) are used by a “Rule Checking” process that determines whether reference rules (mined from a known compatible system) are compatible with rules mined from test traces of a second system. Invalid rules are flagged as behavioral compatibility bugs.