timestamp

Syntax:

timestamp [[-f] path_file [-s] string_name]

Runs on:

QNX Neutrino

Options:

string_name: The string to identify the timestamp. The string you use is up to you. If the string includes spaces, you must surround it with double quotes("").
-f path_file: Write to the specified path and filename. For example, /dev/shmem/mytimestamp.log.
-s: Write the timestamps and strings to standard output.

Description:

This utility allows you to indicate the number of clock systems since the board was reset and associate a string with it. The string typically represents an event or action on the system, such as when a driver or program is started. Typically, you use this utility to perform measurements, which are useful to optimize boot times and to identify the time it takes for components to boot.

If no options are provided, the results are written to /dev/shmem/timestamp.log on the target.

Note: You can't simultaneously write to a file and to standard output when you use this utility.

Variation in timers

Timestamp values are provided using a call to the ClockCycles() kernel function. This function provides the timestamp utility with the number of clock cycles since the board was reset.

Note: These measurements aren't entirely accurate because they're taken close to—but not simultaneously with— with the string that you want logged. The timestamp utility is a process that's run in the background at a normal priority, as closely as possible to the event or action being measured.

On some boards, the time reported by the timestamp utility correlates very closely with the time elapsed since power was actually applied to the board (i.e., a board reset was done either in software or by pressing the reset button). This is the most desirable implementation. In some cases, however, the time reported by the timestamp utility could represent the time since the IPL started, or even the time since the startup driver started. This situation results in measurements that are much smaller than would be observed using a stopwatch from power on. These measurements are obviously less accurate, but can still be useful in comparing one software build to another.

The particular measurements you get depend on whether:

the board provides a counter in the hardware that starts as close as possible to power-on reset (PoR). If the board doesn't provide a hardware counter, you can use the counter provided in the kernel, but it won't start counting until the kernel takes control, which is well after PoR.
the IPL/startup driver can (or actually does) initialize this hardware counter to zero.
the startup driver performs a “cold” or “warm” reset on shutdown (software reset). A cold reset generally initializes the hardware more thoroughly than a warm reset, so a cold reset would be more likely to set the hardware counter to 0

Contents of the timestamp.log

The /dev/shmem/timestamp.log file looks like this—the strings you see are application specific, which means there may be system-defined ones:

TIMESTAMP: (IFS SCRIPT START) at 0.484901 seconds
TIMESTAMP: (LaunchingAPP) at 0.629556 seconds
TIMESTAMP: (DoneLoadingScreen) at 0.661630 seconds
TIMESTAMP: (DoneLoadingAPP) at 1.837985 seconds

Example:

To write the time to a custom file:

if /proc/boot/waitfor /dev/screen 10; then
    /proc/boot/timestamp -f /dev/shmem/mytimestamp.log "STARTING SCREEN" &

To write the time to standard output:

if /proc/boot/waitfor /dev/screen 10; then
    /proc/boot/timestamp -s "STARTING SCREEN" &