Installing ClockworkDB

For linux, you can install ClockworkDB using the provided RPM or DEB packages. These packages will install the necessary binaries, libraries, and configuration files to get you up and running with ClockworkDB quickly.

On Redhat based distributions:

  1. ctt-clockworkdb-support-<version>.rpm for RPM-based distributions (e.g., CentOS, RHEL, Fedora)

  2. ctt-clockworkdb-<version>.rpm for RPM-based distributions (e.g., CentOS, RHEL, Fedora)

  3. ctt-clockworkdb-utilities-<version>.rpm for RPM-based distributions (e.g., CentOS, RHEL, Fedora)

On Debian based distributions:

  1. ctt-clockworkdb-support-<version>.deb for DEB-based distributions (e.g., Ubuntu, Debian)

  2. ctt-clockworkdb-<version>.deb for DEB-based distributions (e.g., Ubuntu, Debian)

  3. ctt-clockworkdb-utilities-<version>.deb for DEB-based distributions (e.g., Ubuntu, Debian)

Configuring ClockworkDB

On linux, when using RPM or DEB packages, the configuration files are installed in the /opt/ctt/etc/clockworkdb/ directory. They are configured with basic settings for a WarpDrive+ repository named “warp1” that should work for most users. Follow the simple steps below to configure your environment, and run a quick test to list the repositories available.

Quick Start

  1. Source the cdb-env.sh file to set up environment variables for ClockworkDB configuration. You should add this to your shell profile or rc file (.zshrc, .bashrc, .bash_profile, etc.):

    source /opt/ctt/etc/clockworkdb/cdb-env.sh

  2. Test that the configuration is set up correctly by running a ClockworkDB tool, such as the command line interface (CLI) tool cdb-repositories which lists the repositories defined in the configuration files.

    Output:

    #> cdb-repositories

 /\_/\
( o.o )
 > ^ <
  ____ _            _                        _    ____  ____
 / ___| | ___   ___| | ____      _____  _ __| | _|  _ \| __ )
| |   | |/ _ \ / __| |/ /\ \ /\ / / _ \| '__| |/ / | | |  _ \
| |___| | (_) | (__|   <  \ V  V / (_) | |  |   <| |_| | |_) |
 \____|_|\___/ \___|_|\_\  \_/\_/ \___/|_|  |_|\_\____/|____/
                                                        v1.0.48

    [11:32:52] [cdb-repositories] cdb-repositories Version: 0.3.3
    [11:32:52] [cdb-repositories] Repository           Description                                        Module Provider
    [11:32:52] [cdb-repositories] -------------------- -------------------------------------------------- ---------------
    [11:32:52] [cdb-repositories] warp1                WarpDrive+ Repository(2k/16k)                      mod_warpdrive
    [11:32:52] [cdb-repositories] -------------------- -------------------------------------------------- ---------------

Creating and Managing Configuration Files

You can manage the configuration files for ClockworkDB using any text editor. The configuration files are XML files that define various settings and options for the ClockworkDB environment, repositories, and module providers that provide presistence logic for various backends.

To generate a new backend module provider configuration file, you can use the cdb-provider-config command line tool, which will create a new configuration file:

Usage: cdb-provider-config <module_provider_name>

#> cdb-provider-config mod_warpdrive

There are a number of configuration files which are used by the various tools, utilities, and programs which interact with ClockworkDB. These configuration files are XML files and one DTD file that defines ENTITYs, essentially variables used in the XML configuration files.

  1. cdb-env.sh file.

    This is a shell script that sets environment variables to point to the ClockworkDB configuration directory, TOM_HOME, and adjusts the PATH and LD_LIBRARY_PATH environment variables to include the directories for tools and libraries. You should source this file before running any of the tools, utilities, or programs which interact with ClockworkDB.

  2. tom-environment.dtd file.

    This file defines ENTITYs, which are essentially variables that can be used in the XML configuration files. This allows for easier management of configuration values and reduces redundancy across the XML files. Entities defined in this file can be referenced in the XML configuration files using the syntax &entity_name;.

    A sample tom-environment.dtd file:

    <!ENTITY support_email "support@curatedtimetech.com">
<!ENTITY install_dir "/opt/ctt/usr/">
<!ENTITY config_dir "/opt/ctt/etc/clockworkdb/">
<!ENTITY default_repo "warp1">
  3. tom-environment.xml file.

    This file defines elements for logging, license, and clockworkdb environment configuration. When creating a new configuration file for a new repository, you can include this file via the <xi:include> directive. See the <xi:include href=”&config_dir;/cdb1.xml”> in the tom-environment.xml file for an example.

    A sample tom-environment.xml file:

     <!--
 /\_/\
( o.o )
 > ^ <
  ____ _            _                        _    ____  ____
 / ___| | ___   ___| | ____      _____  _ __| | _|  _ \| __ )
| |   | |/ _ \ / __| |/ /\ \ /\ / / _ \| '__| |/ / | | |  _ \
| |___| | (_) | (__|   <  \ V  V / (_) | |  |   <| |_| | |_) |
 \____|_|\___/ \___|_|\_\  \_/\_/ \___/|_|  |_|\_\____/|____/
                                                     v1.0.48
 ClockworkDB is a high performance agnostic API for time series and vector data.
 Copyright (C) 2024 Curated Time Tech, Inc.
 -->

 <?xml version="1.0"?>
 <!DOCTYPE tom:environment SYSTEM "tom-environment.dtd">
 <tom:environment xmlns:tom="http://www.tomsolutions.com/tom/environment/1.0"
     xmlns:xi="http://www.w3.org/2001/XInclude">
     <!--
         level="trace|info|warn|error"
         type="daily|rolling"
         file="</path/to/log>" or <filename> created in the current working directory
         format=[see fmt c++ library documentation]
     -->
     <logger level="info"
         format="[%Y-%m-%d %H:%M:%S.%F%z] [%E] [%n] [Pid: %P] [Tid: %t] [%l] [%v]"
         file="/tmp/clockworkdb.log" logtype="daily"/>

     <!-- license file checked by ClockworkDB tools, utilities, and programs -->
     <license file="clockworkdb.lic" path="&config_dir;/" />

     <tsdb default-repository="&default_repo;" module-directory="&install_dir;/lib/tom-tsdb">
         <!-- Include the back end modules we are using -->
         <xi:include href="&config_dir;/cdb1.xml"/>
     </tsdb>
 </tom:environment>
  4. cdb1.xml file.

    This file is included in the tom-environment.xml file and defines the configuration for a specific repository, in this case, a WarpDrive+ powered repository named “warp1”. This file includes options for cache size, partitioning, transactions, environment settings, locking, datastore configuration, database home directory, directories for data and logs, and replication settings.

    You can find more information about the various configuration options in the Module Provider Options section of the documentation.

    A sample cdb1.xml file:

    <!--
    Template generated from mod_warpdrive [version: 1.0.10]
    Generated on: Tue Feb 17 12:43:10 2026
    Module Path: /opt/ctt/usr/lib/tom-tsdb
-->

<?xml version="1.0"?>
<!--
__        __               ____       _
\ \      / /_ _ _ __ _ __ |  _ \ _ __(_)_   _____   _
 \ \ /\ / / _` | '__| '_ \| | | | '__| \ \ / / _ \_| |_
  \ V  V / (_| | |  | |_) | |_| | |  | |\ V /  __/_   _|
   \_/\_/ \__,_|_|  | .__/|____/|_|  |_| \_/ \___| |_|
                    |_|
WarpDrive+ is a high performance embedded database for time series and vector data.
Copyright (C) 2024 Curated Time Tech, Inc.
-->

<!-- Definition of an WarpDrive+ repository
name=[unique:string]        value used to identify discrete repo in engine.get_session('name')
module="mod_warpdrive"      The module(.so|.dll) that manages the WarpDrive+ environment.
description="<any>" Anything that describes this repository. Market data, Fed Data...
-->
<repository name="warp1" module="mod_warpdrive" description="WarpDrive+ Data (2k/16k)">
<options>

<!--
    This specifies the amount of memory for caching in the db environment.
    This is shared by all databases within the environment, but not across
    separate db environments.
    NOTE: This should be a power of 2!  Sizes < 500M are rounded up 25% for overhead.
    max-mmap-size: This is the maximum part of the cache to mem-map into the process space
    [CONTENT]: The total size of cache memory for the environment subsystems (lock/write-ahead-log/transactions)
-->
<cache-size max-mmap-size-gigs="1" cache-segments="1"
            max-cache-gigs="1" init-cache-gigs="1"/>

<!-- Use datastore partitioning
    use=[0|1] 1 turns on partitioning
    num-partitions=[1-64] Number of partitions to use
    hash-strategy=[substr,0,4] The hashing strategy to use. substr,0,4 means take the first 4 characters of the key
    partition-dirs=[dir1,dir2,dir3,...] The directories to use for the partitions
-->
<partitioning use="0" num-partitions="6" hash-strategy="substr,0,4" partition-dirs="data1,data2,data3,data4,data5,data6"/>

<!--
    For threaded performance, it is often beneficial to break environments into sub-enviornments
    so the locking subsystems have less contention
    enable="[0|1]": turn on(1) or off(0)
    slice-count="<N>": the number of cpu cores is a good choice
    slice-on-dimension=[0|1]: split data using the entire object name or the 1st dimension (part before the first '.')
    cache-size="<n>Gig.<bytes>": the size of the cache for each slice of environment
    cache-regions="<n>": break the cache into N contiguous regions

    -->
<slices enable="0" slice-count="10" slice-on-dimension="1" cache-size="0.536870912" cache-regions="1"/>

<!--
    Will the environment be transactionally protected
    use: Turn on transactions
    write-ahead-logging: Use write-ahead logging to guarantee durability w/in ACID semantics
    timeout: The amount of time to wait for a transaction to complete or fail, in microseconds
-->
<transactions use="1" write-ahead-logging="1" timeout="10000"/>

<!--
    Some options to control the workings of the environment and dbs
    direct-db: turn off double buffering in the file-system
    multiversion: enable multiversion support in db
    no-mmap: don't memory map db pages into user/process space w/ mmap
    db-region-init: initialize data structures, preloading into memory for env
    auto-commit: automatically wrap all db operations in a transaction
    txn-nosync: don't write or sync txn log entries on transaction commits
    txn-write-nosync: write, but don't sync log entries on transaction commits
    auto-recover=[0|1] Cleanup environment support files. This will be ignored
                        if replication is in use and this is not the master
    mlock-files: mlock mmap'd databases and environment files into memory
    use-sysv-ipc: instead of memory mapping files for cache, use System V Interprocess Comms
    sysv-ipc-key: unique id for System V IPC memory
-->
<environment direct-db="0" multiversion="0" no-mmap="0" db-region-init="1"
                auto-commit="0" txn-nosync="1" txn-write-nosync="1"
                auto-recover="0" mlock-files="1" use-sysv-ipc="0" sysv-ipc-key="55"/>

<!--
    Configure locking. This is important for both heavily threaded applications and
    many and/or massive multi-process shared environments.  If you find frequent lock
    failures, try increasing timeout(in microseconds) or increase the lock/lockers/objects
    accross the board.
-->
<locking max-lockers="1200" max-locks="1200" max-objects="1200" timeout="10000"/>

<!-- timeseries are stored in chunks on datastore pages
    chunk-size=[n] n should be a power of 2. a datastore, once created, cannot change
                        chunk-size.
    page-size=[n] n should be a power of 2. a datastore locks pages, so pages should
                    be large enough to hold several chunks, but not so big that lock
                    contention becomes an issue for multi-threaded programs.
    NOTE: On most modern day hardware the hardware page size most widely used is 4096(4K) bytes.
        It would be wise to pick chunk size and page size with that in mind.
        If this baffles you, go find someone who understands hardware ;)
-->
<datastore chunk-size="2048" page-size="16384" compress="0" compress-algo="lz4" compress-level="12"/>

<!--
    This specifies the root directory for database files.
    dbs should be openned relative to this path.
    mode: POSIX file permision flag when creating new databases
    paths-relative-to: any database created, deleted, or openned will live under the
                        specified directory in content
    [CONTENT]: The path where the database environment files live
    -->
<db-home mode="666" paths-relative-to="1">/opt/ctt/usr/data/warp1</db-home>

<!--
    Where will various environment files live
    data-dir: the sub-directory of the db-home where database files live
    shared-memory-region-dir: locking/transaction/cache files live here
    log-dir: write-ahead log files live here to support Durability
    NOTE: ACID semantics supported. This is a standard requirement of enterprise database systems
    ACID: Atomicity Concurrent Isolation Durability. Google it if you need.
    WarpDrive+ supports both ACI and full ACID semantics
    WarpDrive+ also supports multi-version databases that maintain multiple views of the same
        data depending on the isolation of the applicable given transaction unit
-->
<directories data-dir="data" shared-memory-region-dir="regions" log-dir="logs"/>

<!--
    Configure replication:
    use=[0|1]  1 turns on replication
    master=[0|1] Should almost always be 0. 1 is reserved for the master in the replication group
    priority=[<a number>] Higher number get priority to be master if the master falls over
    port=[0-64k] Port to listen on
    verbose=[0|1] Turns on replication debugging
    auto-init=[0|1] Whether or not to re-init out of data replicas
    bulk-transfers=[0|1] Accumulate changes in a buffer before doing network transfers
    ack-policy: Strategy for considering how many/type of ACKs come in for cloud update
-->
<replication use="0" master="1" priority="150" port="3500" verbose="1" auto-init="1"
    bulk-transfers="1" ack-policy="quorum">

    <master host="localhost" port="3500"/>

    <peers>
    <peer host="localhost" port="3501"/>
    <peer host="localhost" port="3502"/>
    <peer host="localhost" port="3503"/>
    </peers>
</replication>

</options>
</repository>

Sample Python Programs

The Python API for ClockworkDB allows you to interact with the engine, repositories, datastores, and data using Python code. Below are some sample Python programs that demonstrate how to use the API to interact with the configured repositories and datastores in your environment. These programs can all be found in the examples/ directory of the source code, and you can run them after installing the package and setting up your environment.

List configured Repositories

You can use the cdb-repositories command line tool to list the repositories available in your environment, and then use the repository names in your Python programs to create sessions and interact with the data. The code below mimics the behavior of the cdb-repositories tool, however, it uses the Python API to interact with the engine and print out the repository metadata.

Code:

#!/bin/env python3

# The core ClockworkDB API is in the clockworkdb.tsdb module
from clockworkdb.tsdb import *

if __name__ == "__main__":
    # The engine class is a singleton responsible for managing sessions and repositories.
    # You ALWAYS get an instance of the engine using Engine.Instance()
    e = Engine.Instance()

    # This asks the engine for metadata about the repositories configured in the environment,
    # and prints out the name, description, and module provider for each repository.
    repos = e.get_repositories_meta_data()
    rng = range(repos.size())
    for i in rng:
        repo = repos.get(i)
        print(f"Repository Name: {repo.name()}")
        print(f"  Description: {repo.description()}")
        print(f"  Module: {repo.module()}")
        print()

Output:

Repository Name: warp1
  Description: WarpDrive+ Data (2k/16k)
  Module: mod_warpdrive

List Repository Datastores

You can use the cdb-datastores command line tool to list the datastores available in a given repository, and then use the datastore names in your Python programs to interact with the data. The code below mimics the behavior of the cdb-datastores tool, however, it uses the Python API to interact with the engine and print out the datastore metadata for a given repository.

Code:

#!/bin/env python3

from clockworkdb.tsdb import *

if __name__ == "__main__":
    e = Engine.Instance()

    # get a session for the "warp1" repository, which is configured in the environment.
    # You can have multiple repositories configured, and you can get sessions for any of them by name.
    session = e.get_session("warp1")

    # If you pass nothing to get_session(), it will use the default repository configured in your
    # environment, which is often what you want.
    # session = e.get_session()

    # WarpDrive+ is embedded in the same process as your Python program, so you can get a direct
    # connection to the data store
    connection = session.get_connection()

    # This asks the connection for metadata about the datastores configured in the repository,
    # and prints out the name of each datastore.
    ds_names = connection.get_datastores_meta_data()
    rng = range(ds_names.size())
    for i in rng:
        ds = ds_names.get(i)
        print(f"Datastore Name: {ds.path()}")

Output:

Datastore Name: co-insider-transactions.bdb
Datastore Name: co-logo.bdb
Datastore Name: co-news.bdb
Datastore Name: co-peers.bdb
Datastore Name: co-profile.bdb
Datastore Name: fxdata.bdb
Datastore Name: market-news.bdb
Datastore Name: mktdata.bdb
Datastore Name: normal.ann.bdb
Datastore Name: normal.bdb
Datastore Name: sec-master.bdb
Datastore Name: stac-test.bdb

Catalog a Datastore

You can use the cdb-catalog command line tool to print out the catalog of a given datastore, which includes the timeseries and vectors stored in the datastore. The code below mimics the behavior of the cdb-catalog tool, however, it uses the Python API.

Code:

#!/bin/env python3

from clockworkdb.tsdb import *

if __name__ == "__main__":

    # should be looking normal. Get an engine instance, get a session for the "warp1" repository, and get a connection,
    # and then a datastore for the "mktdata" datastore in that repository. NOTE: we open the datastore in read-only mode,
    # which is all we need to do to list the objects in it.
    e = Engine.Instance()
    session = e.get_session("warp1")
    connection = session.get_connection()
    datastore = connection.get_datastore("mktdata", AccessMode.READ_ONLY())

    # Then we can do a regex search for all objects in that datastore and print their names.
    matches = datastore.regex_name_search(".*")

    while matches.next():
        match = matches.name()
        print(f"Object Name: {match}")

Output:

Object Name: A.ADJUSTED
Object Name: A.CLOSE
Object Name: A.HIGH
Object Name: A.LOW
Object Name: A.OPEN
Object Name: A.VOLUME
Object Name: AA.ADJUSTED
Object Name: AA.CLOSE
Object Name: AA.HIGH
Object Name: AA.LOW
Object Name: AA.OPEN
Object Name: AA.VOLUME
Object Name: AACG.ADJUSTED
Object Name: AACG.CLOSE
Object Name: AACG.HIGH
...
Object Name: ZWS.CLOSE
Object Name: ZWS.HIGH
Object Name: ZWS.LOW
Object Name: ZWS.OPEN
Object Name: ZWS.VOLUME
Object Name: ZYME.ADJUSTED
Object Name: ZYME.CLOSE
Object Name: ZYME.HIGH
Object Name: ZYME.LOW
Object Name: ZYME.OPEN
Object Name: ZYME.VOLUME
Object Name: ZYXI.ADJUSTED
Object Name: ZYXI.CLOSE
Object Name: ZYXI.HIGH
Object Name: ZYXI.LOW
Object Name: ZYXI.OPEN
Object Name: ZYXI.VOLUME

Display timeseries/vector metadata

You can use the cdb-ts-meta command line tool to print out the metadata of a given timeseries or vector, which includes information about the object such as its name, type, number of records, and other relevant metadata. The code below mimics the behavior of the cdb-ts-meta tool, however, it uses the Python API.

Code:

#!/bin/env python3

# used to get at argv for passing in the name of the timeseries to get metadata for.
# If no name is passed, it defaults to "nvda.close"
import sys

# The core ClockworkDB API is in the clockworkdb.tsdb module, and we also need to import
# the calendars and scalar modules to get at the relevant types for timeseries metadata.
from clockworkdb.tsdb import *
from clockworkdb.calendars import *
from clockworkdb.scalar import *

if __name__ == "__main__":

    # normal setup to get at the datastore. We get an engine instance, then a session for the "warp1" repository,
    # then a connection, and then a datastore for the "mktdata" datastore in that repository.
    # NOTE: we open the datastore in read-only mode, which is all we need to do to get metadata about the timeseries stored in it.
    e = Engine.Instance()
    session = e.get_session("warp1")
    connection = session.get_connection()
    datastore = connection.get_datastore("mktdata", AccessMode.READ_ONLY())
    ts_name = sys.argv[1] if len(sys.argv) > 1 else "nvda.close"

    # check to see that we have the timeseries/vector in the datastore, and if we do, get it and print out its metadata.
    # If not, print an error message and exit.
    if( not datastore.has_time_series(ts_name) ):
        print(f"Time series {ts_name} not found in datastore.")
        datastore.close()
        sys.exit(1)

    # If we have the timeseries/vector, we can get it from the datastore and print out its metadata, including its
    # name, type, calendar, creation and modification dates, first and last dates, and count of records.
    ts = datastore.get_time_series(ts_name)
    print(f"Time Series Name: {ts.name()}")
    print(f"  Type:        {ts.get_data_type().name()}")
    print(f"  Calendar:    {ts.get_calendar().name()}")
    print(f"  Created:     {ts.get_create_date()}")
    print(f"  Modified:    {ts.get_modify_date()}")
    print(f"  First Date:  {ts.get_first_date()}")
    print(f"  Last Date:   {ts.get_last_date()}")
    print(f"  Count:       {ts.get_last_date_int() - ts.get_first_date_int() + 1:,d}")

Output (passing xom.close as argv[1]):

Time Series Name: XOM.CLOSE
    Type:        Float
    Calendar:    Business
    Created:     2024-Mar-02 21:26:58
    Modified:    2026-Feb-15 13:37:18
    First Date:  1970-Jan-02
    Last Date:   2026-Feb-13
    Count:       14,641

Display timeseries/vector data

You can use the cdb-ts command line tool to print out the data of a given timeseries or vector, which includes the date and value of each record in the timeseries or vector. The code below mimics the behavior of the cdb-ts tool, however, it uses the Python API.

Code:

#!/bin/env python3

# used to get at argv for passing in the name of the timeseries to get metadata for.
# If no name is passed, it defaults to "nvda.close"
import sys

# The core ClockworkDB API is in the clockworkdb.tsdb module, and we also need to import
# the calendars and scalar modules to get at the relevant types for timeseries metadata.
from clockworkdb.tsdb import *
from clockworkdb.calendars import *
from clockworkdb.scalar import *

if __name__ == "__main__":

    # normal setup to get at the datastore. We get an engine instance, then a session for the "warp1" repository,
    # then a connection, and then a datastore for the "mktdata" datastore in that repository.
    # NOTE: we open the datastore in read-only mode, which is all we need to do to get metadata about the timeseries stored in it.
    e = Engine.Instance()
    session = e.get_session("warp1")
    connection = session.get_connection()
    datastore = connection.get_datastore("mktdata", AccessMode.READ_ONLY())
    ts_name = sys.argv[1] if len(sys.argv) > 1 else "nvda.close"

    # check to see that we have the timeseries/vector in the datastore, and if we do, get it and print out its metadata.
    # If not, print an error message and exit.
    if( not datastore.has_time_series(ts_name) ):
        print(f"Time series {ts_name} not found in datastore.")
        datastore.close()
        sys.exit(1)

    # If we have the timeseries/vector, we can get it from the datastore and print out its name and data.
    ts = datastore.get_time_series(ts_name)

    # internally, timeseries and vectors just store observations. There index in the vector identifies the date, time, or
    # ordinal location of the observation. To get the date for a given observation, you can use the calendar associated
    # with the timeseries/vector, and to get the value of the observation. you can use the appropriate scalar type, in this case, Float.
    # The code below iterates through all the observations in the timeseries/vector.
    rng = range( ts.get_first_date_int(), ts.get_last_date_int() + 1)
    calendar = ts.get_calendar()

    print(f"Time Series Name: {ts.name()}")
    for date_int in rng:
        # We check to see if the observation is normal, which means it has a valid value.
        # If it does, we get the value and print it out along with the date.
        if( ts.get_observation(date_int).is_normal() ):
            value = Float(ts.get_observation(date_int)).value()
            d = calendar.get_date(date_int)
            print(f"  {d}[{date_int}]: {value:.2f}")

Output (passing xom.close as argv[1]):

Time Series Name: XOM.CLOSE
1970-Jan-02[31309]: 1.94
1970-Jan-05[31310]: 1.97
1970-Jan-06[31311]: 1.96
1970-Jan-07[31312]: 1.95
1970-Jan-08[31313]: 1.96
1970-Jan-09[31314]: 1.96
1970-Jan-12[31315]: 1.95
1970-Jan-13[31316]: 1.94
1970-Jan-14[31317]: 1.95
1970-Jan-15[31318]: 1.93
1970-Jan-16[31319]: 1.93
1970-Jan-19[31320]: 1.93
1970-Jan-20[31321]: 1.93
...
2026-Jan-23[45934]: 134.97
2026-Jan-26[45935]: 134.84
2026-Jan-27[45936]: 136.83
2026-Jan-28[45937]: 137.58
2026-Jan-29[45938]: 140.51
2026-Jan-30[45939]: 141.40
2026-Feb-02[45940]: 138.40
2026-Feb-03[45941]: 143.73
2026-Feb-04[45942]: 147.59
2026-Feb-05[45943]: 146.08
2026-Feb-06[45944]: 149.05
2026-Feb-09[45945]: 151.21
2026-Feb-10[45946]: 151.59
2026-Feb-11[45947]: 155.56
2026-Feb-12[45948]: 149.93
2026-Feb-13[45949]: 148.45