Threads

Clocks Guide

Version
R2024.2.0
Threads

Threads control when the clock performs routine tasks such as submitting clock entries or checking for software updates. Each task (thread) can be run on an interval-basis or following a set schedule.

These values shouldn’t be modified without consultation.

Unless otherwise stated below, each thread has the following attributes:

  • name: The unique name that marks each thread. The available threads are described in the sections below. Don’t edit these values.
  • active: Set to yes to enable the thread or no to disable it.
  • interval: Specifies the number of seconds the clock waits until running the thread again.
  • retries: Specifies the number of times the clock will retry running the thread after it fails. For example, to specify that the clock should retry the thread twice, specify retries="2".
  • retry_interval: Specifies the amount of time the clock waits before it tries to run the thread again. For example, to specify that the clock should wait 60 seconds before retrying, specify retry_interval="60".

If necessary, you can schedule a thread to run at a specific time, rather than at an interval. To do so, delete the thread’s interval="#" attribute and type the following before the closing </thread> tag of the thread:

<schedules randomization="3600">
<schedule>3:00</schedule>
</schedules>

Replace the 3600 with the number of seconds the clock randomizes the scheduled start time by. This helps to ensure that multiple clocks in one location don’t perform a thread at the same time and burden the network.

Replace 3:00 with the time you want the thread to run every day, in the 24-hour format.

The available threads are as follows:

"CallHome"

Controls how often the clock communicates with the Admin Server.

"SubmitOfflinePunches"

Controls how often the clock submits any clock entries recorded when the clock was offline. This thread is used only in the online mode.

"SendHeartbeat"

Determines how often the clock sends its “heartbeat,” which tells the application that the clock is online.

"SynchronizeTime"

Determines how often the clock synchronizes its time with the application.

It has the following additional parameters:

  • timediff: Represents the difference in time under which no synchronization takes place.
  • timesynch: If set to no, the clocks synchronize their time using a NTP server.
  • Note: Synchronization by NTP must be selected during the deployment process.

"UpdateSoftware"

Determines when the clock automatically checks for software updates and installs the update when new software is found. This task is usually scheduled to take place at or near a specified time.

In this case there’s no interval attribute. Instead, this thread is scheduled to run daily using the method described above.

By default, this thread is configured to randomize the scheduled start time by 2 hours (or, 7,200 seconds).

"UpdateFirmware"

Determines how often the clock checks for firmware updates. When an update is found, the clock automatically installs it.

"SubmitLogFiles"

Determines when the clock’s log files are sent to the application. If interval is set to 0, the task runs only when it’s triggered for diagnostic or troubleshooting purposes.

Note: If the interval isn’t set to 0, clocks might overwhelm the servers.

"UpdateDatabase"

Determines how often the clock synchronizes its database with the application. Data synchronized includes the list of employees, schedules, job assignments, and dockets required for validation at the clock.

It has the following additional parameter:

  • <incremental_update>: Limits the amount of information the clock receives when it updates the database. By default, this parameter is enabled, and the clock receives only information that’s been updated since the last time it ran the thread. When disabled, the clock receives all of the information from the database, regardless of whether or not it’s been changed.

This thread isn’t required for clocks operating in online mode.

"SubmitPunches"

Determines how often clocks in standalone mode submit clock entries.

It has the following additional parameter:

  • <page_size>: Controls the number of clock entries submitted at the same time to prevent overloading the server. A value of 100 is recommended.

"ExchangeBioTemplates"

Determines how frequently clocks send recently enrolled or modified bio templates to the server and receive templates enrolled on other clocks.

It has the following additional parameter:

  • <page_size>: Controls the amount of data sent at the same time to prevent overloading the server.

"CleanupDatabase"

Determines when the clock can clean up its database. This task must be scheduled at a time of low activity and not while software is being updated.

It has the following additional parameters:

  • <punch_age>: The age (in days) before exported clock entries are purged from the clock’s database.
  • <checkpoint>: This parameter must not be modified.

"SubmitPictureTemplates"

Determines when the clock transmits the picture templates to the application. These picture templates are the pictures the clock captured during the photo enrollment process.

It has the following additional parameter:

  • <page_size>: Controls the number of templates submitted at the same time to prevent overloading the server.

"SubmitPunchPicture"

Determines when the clock transmits clock pictures to the application. These are the pictures that the clock captures when employees clock in and out, rather than the ones captured during photo enrollment.

Note: This thread doesn’t have an interval attribute and should be configured to run only at a scheduled time.

It has the following additional parameter:

  • <page_size>: Controls the number of clock pictures submitted at the same time to prevent overloading the server.

"SendMessages"

Determines when the clock sends information to its peers when clocks are configured for inter-clock communication. See Configure Inter-Clock Communication.

"SyncPeers"

Determines how often the clock receives updated IP addresses from clocks it is configured to communicate with. When the IP address is out of date, the clock stores any messages that failed and resends them once the address is updated.

"EssMessageSync"

Determines how many unread messages exist for active employees who perform clock entries on the clock, and sends the unread message count to the clock for display when the employee performs a clock entry.

"NetworkReboot"

Determines when the clock automatically reboots after losing network connectivity.