CPU-GPU Performance Evaluation of Lightweight Tree-Based Machine Learning for IoT Anomaly Detection

Abstract

The increasing complexity of Internet of Things (IoT) environments necessitates efficient and reliable anomaly detection. This study experimentally evaluates established tree-based machine-learning models instead of proposing a new detection algorithm. Decision Tree (DT), Random Forest (RF), and XGBoost are compared using CPU- and GPU-based implementations on the highly imbalanced DS2OS dataset by considering training time, overall classification performance, and minority-class detection. GPU experiments were conducted using an NVIDIA T4 in a cloud-based environment; the results do not establish performance on physical IoT or edge devices. The recorded training times yielded CPU-to-GPU time ratios ranging from 2.12 to 2.94 across the evaluated implementations. However, the original CPU hardware configuration could not be verified, preventing these differences from being attributed exclusively to GPU acceleration and limiting their reproducibility under equivalent conditions. In the initial evaluation, Random Forest configurations failed to detect minority attack classes despite high overall accuracy, whereas supplementary evaluations demonstrated substantially improved performance with alternative feature encoding. XGBoost achieved near-perfect classification in the initial test partition and reduced-training configurations. Although supplementary evaluations initially showed lower and more variable performance with the complete-training partition under automatic initialisation, a controlled ten-fold evaluation demonstrated that fixing the initial prediction score eliminated this deterioration on both the CPU and GPU within the evaluated DS2OS configurations. Supplementary experiments further demonstrated that the GPU-based Decision Tree proxy achieved classification performance comparable to the CPU Decision Tree following adjustments to its model configuration, indicating that the original performance difference was primarily configuration-dependent rather than an inherent limitation of GPU hardware. Energy efficiency and embedded-device performances were not experimentally established.

1. Introduction

The rapid proliferation of Internet of Things devices has transformed modern digital infrastructure while simultaneously introducing significant security challenges [1]. IoT systems are characterised by device heterogeneity, constrained computational resources, and minimal built-in security, creating conditions under which conventional intrusion-detection systems struggle to operate effectively [2,3]. As cyberattacks targeting IoT environments continue to rise, anomaly detection has emerged as a critical component of early-warning defence systems due to its ability to identify deviations from normal behaviour, including previously unseen or zero-day attacks [4]. However, machine-learning-based anomaly detection in IoT contexts remains challenging because these systems must balance detection accuracy with limitations in processing power, memory, latency, and energy availability. These challenges are further compounded when models are deployed on heterogeneous computing platforms. CPU-based deployments must operate under tight energy and memory constraints typical of embedded or edge devices, while GPU-accelerated implementations introduce additional challenges related to power consumption, data-transfer overheads, memory management, and algorithmic compatibility between CPU and GPU libraries. As a result, achieving reliable, efficient, and scalable anomaly detection across CPU and GPU platforms requires careful consideration of both algorithmic behaviour and hardware-specific constraints rather than straightforward model portability [5].

Current research has increasingly focused on lightweight machine-learning algorithms, such as Decision Trees, Random Forests, and gradient-boosted models, as scalable and interpretable alternatives to deep-learning approaches [6,7]. While many studies agree that gradient-boosting methods (e.g., XGBoost) provide state-of-the-art accuracy on structured security datasets, others argue that simpler models offer favourable trade-offs for resource-constrained environments [8]. A central consideration concerns the role of hardware acceleration: although GPUs provide substantial performance gains in deep-learning tasks, their benefits for lightweight, non-neural machine-learning models are workload-dependent, with factors such as model complexity, dataset size, and data-transfer overheads influencing whether GPU acceleration is computationally advantageous [9,10]. Additionally, despite widespread recognition of severe class imbalances in IoT datasets, the research community remains divided on the best strategies to ensure robust minority attack detection without excessive computational overheads [11,12].

Motivated by these limitations, this study investigates the effect of CPU- and GPU-based executions on the classification and computational performance of lightweight tree-based machine-learning models for IoT anomaly detection. Decision Tree, Random Forest, and XGBoost models are evaluated using the highly imbalanced DS2OS dataset, enabling analysis of both overall classification performance and detection behaviour across individual attack categories. Instead of proposing a new anomaly-detection algorithm, this study contributes a systematic, hardware-aware experimental evaluation of established tree-based machine-learning models across CPU- and GPU-based implementations. Unlike studies primarily focused on classification accuracy or GPU acceleration independently, this work examines both computational performance and multi-class detection effectiveness across CPU- and GPU-based implementations of Decision Tree, Random Forest, and XGBoost using the highly imbalanced DS2OS dataset. Specifically, the study (1) quantifies implementation-specific training-time differences, with observed CPU-to-GPU training-time ratios ranging from 2.12× to 2.94×; (2) evaluates class-specific and macro-averaged performance to identify limitations concealed by aggregate accuracy, particularly the failure of Random Forest to detect minority attack classes; and (3) examines differences in classification behaviours between CPU and GPU implementations, including the reduced minority-class detection performance of the GPU-based Decision Tree. These findings provide an implementation-specific experimental perspective on the relationship between computational performance and anomaly-detection effectiveness while acknowledging the limitations of the evaluated dataset and computing environment.

The rest of the paper is structured as follows. Section 2 reviews related work on IoT anomaly detection, lightweight machine-learning approaches, and hardware-aware optimisation strategies. Section 3 presents the system and threat models considered in this study. Section 4 describes the dataset, preprocessing pipeline, model implementations, experimental environment, and evaluation methodology. Section 5 presents and discusses experimental results, including classification performance, CPU-GPU training-time comparisons, class-level detection behaviour, system-level memory observations, and assumption-based energy estimates. Finally, Section 6 concludes the paper, summarises the main findings and limitations, and outlines directions for future research.

2. Related Work

Research on IoT anomaly detection has expanded rapidly in response to the increasing frequency of cyberattacks against resource-constrained smart environments. Early approaches relied on signature-based intrusion-detection systems, which struggle to detect previously unseen or evolving threats [1,2]. As a result, anomaly detection has become a central paradigm in IoT security, enabling the identification of deviations from normal system behaviour that may indicate security breaches or operational faults [13,14,15]. This capability is especially important in IoT environments characterised by heterogeneous devices, large-scale deployments, and limited built-in security mechanisms [11,16,17].

The field of IoT anomaly and intrusion detection has shifted from rule-based and statistical techniques toward machine-learning-driven approaches that can model complex, non-linear traffic patterns and adapt to evolving threats [3,4,18]. These methods are typically categorised as supervised, unsupervised, or semi-supervised, each offering trade-offs between detection accuracy and data availability [19,20,21]. In realistic IoT deployments where benign data dominates and labelled attacks are scarce, semi-supervised and lightweight supervised models are particularly attractive.

2.1. Machine Learning for IoT Anomaly Detection

2.1.1. Evolution from Traditional to ML-Based Detection

Traditional intrusion-detection systems depend on static rules and curated signature databases, making them ineffective against the diversity and rapid evolution of IoT threats [18]. Machine-learning methods can address some of these limitations by identifying patterns in observed data that may not be captured by predefined signatures [4,17]. In IoT environments, normal behaviour refers to legitimate device interactions, service requests, and operational activities consistent with the expected functionality of the system. Anomalies represent deviations from these patterns that may indicate malicious activities. In the DS2OS dataset considered in this study, seven attack categories are represented: Denial of Service, Data Type Probing, Malicious Control, Malicious Operation, Scanning, Spying, and Wrong Setup. These attacks may involve abnormal service requests, unauthorised control commands, unusual reconnaissance activities, or manipulation of device operations. In contrast, benign observations represent normal interactions between IoT devices and services. The present study distinguishes these behaviours through supervised multi-class classification using labelled telemetry and contextual features rather than predefined anomaly thresholds.

2.1.2. Taxonomy of ML Approaches in IoT Security

Supervised learning methods rely on labelled datasets of normal and malicious behaviours, but such datasets are difficult to construct in IoT contexts where attacks are rare and diverse [21]. Unsupervised methods model normal behaviour and flag deviations, making them useful when labels are unavailable 20]. Semi-supervised approaches can be attractive in IoT environments because they reduce dependence on extensively labelled attack data when benign observations are abundant and labelled attacks are scarce [19]. Lightweight supervised models, particularly tree-based classifiers, can provide computationally efficient anomaly detection because their predictions rely on relatively simple feature comparisons and decision rules, reducing computational and memory requirements compared to more complex models. However, their effectiveness in detecting rare malicious activities depends on the availability of representative labelled attack samples. Under severe class imbalance, these models may favour the majority benign class and fail to recognise minority attacks [22]. Therefore, their suitability for IoT anomaly detection must be assessed by using class-specific and macro-averaged performance metrics rather than overall accuracy alone [23,24].

2.1.3. Lightweight ML Algorithms for IoT

Lightweight tree-based machine-learning models have attracted considerable attention in IoT security because of their interpretability, computational efficiency, and predictive performance [25,26]. However, strong results on benchmark datasets do not necessarily translate to operational networks, highlighting the importance of evaluating models under realistic deployment conditions [27].

Decision Trees (DTs) recursively partition the feature space into hierarchical decision rules, providing interpretable classification outcomes and feature-importance measures [28,29,30]. Their relatively simple operations make them attractive for resource-aware applications. However, DTs are susceptible to overfitting, instability, and majority-class bias under imbalanced data [31]. Previous studies have demonstrated high detection performance using tree-based machine-learning algorithms for IoT botnet traffic [32].

Random Forests (RF) is an ensemble learning algorithm that combines multiple decision trees trained on bootstrap samples of the dataset, incorporating random feature selection at each split. By aggregating predictions across these trees, RF reduces prediction variance, mitigates overfitting, and generally improves robustness to noise [32,33]. Although RF models have demonstrated strong intrusion-detection performance, aggregate accuracy can conceal poor recognition of individual attack categories [25]. Under severe class imbalance, standard configurations may favour benign observations unless appropriate imbalance-handling strategies are applied.

XGBoost (Extreme Gradient Boosting) constructs trees sequentially to correct errors made by preceding models, combining gradient boosting with regularisation and flexible objective functions [34,35]. These characteristics support strong classification performance on structured security datasets. Previous industrial IoT research has reported accuracy reaching 99.9%, with false-positive rates of 0.01% [36]. However, high accuracy and low false-positive rates alone do not establish reliable minority attack detection; class-specific recall and macro-averaged metrics must also be considered. Collectively, these algorithms offer different trade-offs between computational requirements, interpretability, and detection effectiveness [17,25,37].

2.1.4. Performance Considerations in IoT Contexts

Deploying machine-learning models in IoT environments requires balancing classification performance against processing capacity, memory availability, energy consumption, and latency constraints [38,39]. Computational requirements influence training and inference feasibility [10], while model footprints and intermediate memory allocation affect deployment on devices with limited resources [39]. Energy consumption is particularly important in battery-powered systems [40], and time-sensitive security applications require sufficiently low inference latency for effective threat detection [41,42].

Although deep-learning approaches can achieve strong detection performance, their computational and memory demands may limit deployment on resource-constrained devices. Lightweight tree-based models offer potentially more practical alternatives, depending on their complexity and the target hardware [23,39,40]. However, computational efficiency observed in cloud-based experiments does not establish energy efficiency or deployment suitability on physical IoT devices. These properties require direct evaluation on representative edge hardware, including measurements of inference latency, model footprints, and power consumption.

2.2. Hardware Acceleration: CPU vs. GPU in Machine Learning

2.2.1. Architectural Differences and Performance Implications

CPUs and GPUs differ in their processing architectures, memory organisation, and approaches to parallel computation. CPUs typically contain a smaller number of powerful cores, supported by multi-level cache hierarchies (L1, L2, and L3), designed to minimise memory-access latency and efficiently execute sequential operations and complex branching instructions [43]. GPUs employ a larger number of simpler processing units organised for massively parallel execution, supported by high-bandwidth device memory and smaller on-chip memory structures, including registers, shared memory, and caches. These characteristics enable GPUs to process large volumes of data concurrently, although data transfers between host RAM and GPU memory may introduce additional overhead [43,44].

These architectural differences influence tree-based machine-learning workloads. Decision Trees involve conditional branching and irregular memory access, which can limit GPU utilisation. Random Forest provides opportunities for parallel execution across multiple trees, while XGBoost can exploit GPU parallelism during histogram construction and split evaluation. Consequently, the computational benefits of GPU acceleration depend on the algorithm, workload size, memory-access patterns, and implementation [45,46]. Table 1 presents a comparison of the architectural and memory characteristics of CPUs and GPUs, highlighting their differences in processing capabilities, parallelism, memory organisation, and data-access patterns.

Table 1. Architectural and memory characteristics of CPUs and GPUs.

Characteristic	CPU	GPU
Processing architecture	Fewer, complex cores 43]	Many parallel processing units [43,45]
Primary optimisation	Low-latency execution [43]	High-throughput execution [43,45]
Parallelism	Limited to moderate [43]	Massively parallel [45]
Memory architecture	System RAM, with multi-level caches [43]	Device VRAM, with registers, shared memory, and caches [43,45]
Memory bandwidth	Generally lower [43,45]	Generally higher [43,45]
Memory access	Efficient for irregular access [43]	Favours regular, parallel access [45]
Data-transfer overhead	Direct access to system RAM [43]	Host–device transfers may introduce overhead [45]
Tree-based ML suitability	Branching and sequential operations [23]	Parallel forest construction and histogram-based split evaluation [44,45]

2.2.2. GPU Acceleration Libraries and Implementations

Recent advances in software frameworks have significantly lowered the barrier to GPU-accelerated ML, including for classical algorithms beyond deep learning [47,48]. RAPIDS cuML provides a suite of GPU-accelerated ML algorithms that closely mirror the scikit-learn API, enabling relatively seamless migration of CPU-based workflows to GPU platforms [47]. The library includes GPU-optimised implementations of algorithms such as Random Forest and exploits CUDA-based parallelism to accelerate their computational operations.

GPU-accelerated Random Forest implementations using RAPIDS cuML have demonstrated substantial training-time improvements, with reported speedups of up to 45× compared with CPU-based scikit-learn implementations [49]. Similarly, XGBoost supports GPU acceleration through histogram-based methods that parallelise computationally intensive operations in gradient boosting [44]. Reported GPU training speedups for XGBoost depend on dataset characteristics, workload size, and hardware configuration. Mitchell and Frank [44] reported speedups of 3×–6× compared to a four-core CPU under their evaluated experimental conditions.

The suitability of these libraries for IoT applications depends on the computational capabilities and software compatibility of the target platform. Scikit-learn and CPU-based XGBoost can operate on general-purpose processors, including sufficiently capable edge gateways and servers. In contrast, RAPIDS cuML requires compatible NVIDIA GPUs, CUDA support, and associated software dependencies, whereas GPU-enabled XGBoost similarly requires supported CUDA-capable hardware. Consequently, these GPU-accelerated libraries are more appropriate for GPU-equipped gateways, edge servers, and cloud infrastructure than resource-constrained IoT sensors or microcontrollers. In this study, the libraries were evaluated using an NVIDIA T4 GPU within Google Colab Pro; their compatibility with and performances on physical IoT hardware were not experimentally assessed.

2.2.3. Performance Trade-Offs in IoT Environments

The computational benefits of GPU acceleration depend on the algorithm, workload, and underlying hardware, with CPU-GPU performance differences varying across machine-learning and deep-learning models [50]. In resource-constrained IoT environments, hardware selection must also account for deployment cost, platform compatibility, and available computing resources [37]. Some edge platforms lack general-purpose GPU support and instead employ specialised accelerators [12].

Alternative hardware accelerators, including field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), and neural processing units (NPUs), offer specialised computational capabilities for ML workloads. FPGAs provide reconfigurable hardware that can implement parallel processing pipelines and customised inference operations, potentially improving latency and energy efficiency [38]. ASICs implement dedicated hardware circuits optimised for specific computational tasks, offering high efficiency at the expense of flexibility. NPUs are designed primarily to accelerate neural-network operations, particularly matrix multiplication and tensor processing. Although these accelerators can support ML and DL workloads, their suitability depends on algorithmic requirements, hardware compatibility, and deployment constraints [12,28]. Unlike CPUs and GPUs, these alternative accelerators were not experimentally evaluated in the present study.

GPU deployment in IoT security therefore requires consideration of the target architecture, available power budget, latency requirements, and detection performance. The present study evaluates CPU-GPU implementations in a cloud-based computing environment; its findings do not establish performance or energy efficiency on physical edge or embedded devices.

2.2.4. Computational Requirements and Hardware Suitability for Machine Learning and Deep Learning

The suitability of CPUs and GPUs for machine-learning workloads depends on algorithmic characteristics, available parallelism, memory-access patterns, and dataset size [43]. Although GPUs are commonly associated with deep learning, conventional machine-learning algorithms can also benefit from GPU acceleration when their operations can be efficiently parallelised. However, the extent of acceleration varies across algorithms and implementations [44,50].

DL architectures typically involve matrix multiplications, tensor operations and gradient-based updates that provide substantial data-level parallelism [45]. GPUs are particularly effective for these workloads because of their parallel processing capabilities and high memory bandwidth [43]. In contrast, CPUs are better suited to sequential operations, irregular control flow, and latency-sensitive tasks. Tree-based ML algorithms exhibit different computational characteristics. Decision Trees rely on recursive feature partitioning and conditional branching, which can limit GPU efficiency because of irregular memory access and sequential dependencies [45,46]. Random Forest enables parallel construction of multiple trees [49], while XGBoost can exploit GPU acceleration during histogram construction and split evaluation. Consequently, GPU benefits depend on the available parallelism within each algorithm rather than whether the model is classified as ML or DL [44].

GPU acceleration also introduces overheads associated with host–device data transfers, memory allocation, and parallel execution coordination [45]. These overheads may offset acceleration benefits for smaller workloads, whereas larger datasets can provide greater opportunities for GPU parallelism [44]. Therefore, computational performance depends on workload characteristics and implementation rather than hardware selection alone [50]. Alternative accelerator architectures, including FPGAs, ASICs, and NPUs, and their suitability for ML workloads are discussed in Section 2.2.3.

In IoT environments, hardware selection must distinguish between model training and operational inference. Resource-constrained sensors and microcontrollers prioritise low power consumption, limited memory requirements, and predictable inference latency [39], whereas gateways, edge servers, and cloud platforms can support more computationally intensive training [10]. Faster GPU training does not necessarily establish lower inference latency, reduced energy consumption, or improved suitability for embedded deployment.

These considerations motivate the present evaluation of CPU- and GPU-based implementations of Decision Tree, Random Forest, and XGBoost. The observed CPU-to-GPU training-time ratios of 2.91×, 2.12× and 2.94× for Decision Tree, Random Forest, and XGBoost, respectively, reflect implementation-specific performance differences under the evaluated experimental configurations. However, these findings are specific to the selected implementations, DS2OS dataset and cloud-based experimental environment. They do not establish general GPU superiority or provide experimental comparisons with DL architectures or specialised accelerators.

2.3. Comparison to Literature

Previous research has examined lightweight machine-learning algorithms, class-imbalance handling, and hardware acceleration for IoT anomaly detection [6,8,25,51]. Other studies have investigated GPU acceleration and heterogeneous edge-computing environments [10,44]. However, these studies differ in their datasets, computational settings, and evaluation metrics, with comparatively limited emphasis on jointly assessing CPU-GPU training performance and minority-class detection. Table 2 summarises representative studies and highlights the research gaps addressed in this work.

Table 2. Comparison of related studies.

Ref.	Year	Dataset/Context	Method/Focus	Limitation/Gap
[6]	2024	Resource-constrained IoT	Lightweight ML anomaly detection and prevention	Does not systematically compare corresponding CPU and GPU implementations
[7]	2025	Intrusion detection	Boosting with minority-class recognition	Focuses on classification improvement rather than CPU-GPU computational comparison
[8]	2024	BoT-IoT	Imbalanced-class handling	Does not evaluate lightweight classifiers across CPU and GPU platforms
[10]	2024	Cloud–Edge–IoT continuum	Flexible ML inference deployment	Focuses on deployment architecture rather than controlled anomaly-detection model comparison
[25]	2023	IoT intrusion detection	Tree-based ML algorithms	Hardware acceleration and CPU-GPU behaviours are not the principal focus
[44]	2017	Large-scale ML	GPU-accelerated XGBoost	Not IoT-specific and does not compare multiple anomaly-detection models
[51]	2024	IoT anomaly detection	ML and DL techniques	Broad ML/DL focus rather than controlled CPU-GPU evaluation
This study	2026	DT, RF, and XGBoost on DS2OS	CPU-GPU comparison, class-specific/macro analysis	Single dataset and virtualised experimental environment

Instead of proposing a new anomaly-detection algorithm, this study provides a comparative experimental evaluation of Decision Tree, Random Forest, and XGBoost across CPU- and GPU-based implementations using the highly imbalanced DS2OS dataset. By combining measured training-time performance with overall, macro-averaged, weighted-average, and class-specific classification metrics, the analysis reveals limitations concealed by aggregate accuracy, particularly Random Forest’s failure to detect minority attack classes and implementation-dependent differences in Decision Tree performance. The evaluation also includes supplementary system-level memory observations and assumption-based energy estimates, which do not establish model-specific memory or energy efficiency. Although XGBoost demonstrated strong classification performance consistent with previous research [36], its robustness beyond the evaluated DS2OS configuration remains unverified. Although the original experiments did not include a full-training-partition baseline, the supplementary cross-validation analysis examined both 30% and 100% training configurations, providing additional evidence of model sensitivity to training-data proportions. Consequently, the contribution lies in a configuration-specific assessment of classification effectiveness and computational performance rather than generalisable claims about deployment on physical IoT or edge hardware.

3. System and Threat Model

3.1. System Model

The system model represents an IoT environment comprising heterogeneous sensors, actuators and service nodes that generate operational telemetry, including device-state updates, service requests, and contextual information [52,53]. The DS2OS dataset provides a simulated representation of smart-home and smart-building interactions, capturing the behaviours of devices and services with differing operational characteristics.

The conceptual architecture assumes that collected telemetry is forwarded to an analysis component for machine-learning-based anomaly detection. Depending on deployment requirements, this component could operate in the cloud, at a gateway, or on an edge node. Decision Tree, Random Forest, and XGBoost are considered as classifiers within this architecture. However, the present experiments evaluate their CPU- and GPU-based implementations in a cloud computing environment rather than on physical IoT or edge hardware. Real-time inference latency and deployment performance are not experimentally assessed.

Following data cleaning and categorical encoding, each DS2OS observation is represented by a feature vector and classified into one of eight predefined categories: benign behaviour or one of seven attack types. The task is therefore formulated as supervised multi-class classification. Although the predicted labels could support subsequent security monitoring and incident response, automated mitigation mechanisms remain outside the scope of this study.

3.2. Threat Model

The threat model considers adversarial activities relevant to IoT environments and their conceptual relationships to the seven attack categories represented in DS2OS. The potential adversarial capabilities are outlined below:

• Remote exploitation: The adversary may compromise IoT devices or services remotely by exploiting firmware vulnerabilities, weak authentication, or insecure communication channels. In the DS2OS dataset, this behaviour is reflected in Malicious Control, Malicious Operation, and Denial of Service attacks.
• Traffic manipulation: The adversary may inject, spoof, or modify network messages to disrupt normal device operation or conceal malicious activity. These behaviours correspond to Data Type Probing, Scanning, and Denial of Service attack categories.
• Service misuse: The adversary may issue unauthorised control commands, misconfigure devices, or induce malicious operational states, which are captured through Malicious Control, Malicious Operation, and Wrong Setup attacks.
• Stealth and evasion: The adversary attempts to mimic benign traffic in order to evade detection. This behaviour is represented by low-intensity attacks, such as Spying and certain Scanning activities, which closely resemble normal operational traffic.
• Resource-targeted attacks: The adversary may launch low-rate or low-power attacks designed to exhaust devices, gateways, or network resources, which are reflected in Denial of Service and probing-based attack categories within the dataset.

This formulation maps the considered adversarial behaviours to the seven attack categories represented in the DS2OS dataset, providing a consistent threat-model basis for the subsequent classification evaluation.

Other security threats relevant to IoT environments include attacks targeting stored cryptographic secrets, such as the extraction or theft of encryption keys, authentication credentials, or other sensitive keying material from compromised devices. Such attacks may result from physical access, software exploitation, insecure key storage, or side-channel techniques and can subsequently enable device impersonation, unauthorised access, or decryption of protected communications [11]. However, direct secret-key extraction is not represented as a distinct attack category in the DS2OS dataset and is therefore outside the empirical detection scope of the present study.

Man-in-the-middle (MITM) and replay attacks also represent relevant threats to IoT communications [53]. In a MITM attack, an adversary may intercept communications between IoT devices and services and potentially observe, modify, or inject messages without the communicating parties being aware of the intervention. In a replay attack, previously captured legitimate messages may be retransmitted to reproduce authorised actions or disrupt normal system behaviour [11]. Although these attacks are relevant to IoT security, MITM and replay attacks are not represented as distinct labelled attack classes in the DS2OS dataset. Consequently, their direct detection is not experimentally evaluated in this study, and the empirical analysis remains restricted to the seven attack categories available in DS2OS.

3.3. Attack Types Considered

The threat landscape includes the following seven attack categories, aligning with the DS2OS taxonomy:

• Denial of Service (DoS): Traffic flooding or resource exhaustion intended to degrade device responsiveness.
• Data Type Probing: Attempts to infer service functionality or device capabilities through abnormal queries.
• Malicious Control: Injection of unauthorised or dangerous control commands.
• Malicious Operation: Manipulation of device behaviours that cause operational anomalies or safety risks.
• Scanning: Reconnaissance activities aimed at mapping device endpoints or network topology.
• Spying: Covert monitoring or extraction of sensitive device information.
• Wrong Setup: Misconfiguration attacks altering operational parameters or device state.

All seven attack categories defined in this threat model are explicitly represented in the DS2OS dataset and are treated as distinct target classes in the experimental evaluation. The anomaly-detection task is therefore formulated as an eight-class classification problem (seven attack types plus benign traffic), allowing each attack category to be evaluated individually rather than being aggregated into a single ‘attack’ label. To ensure full traceability between the threat model and the empirical evaluation, per-attack detection performance is reported in Section 5. Experimental Results.

3.4. Security Goal

The primary security goal is accurate anomaly detection, with particular emphasis on the reliable identification of minority attack classes in the highly imbalanced DS2OS dataset. The experimental evaluation focuses on classification effectiveness and recorded CPU-GPU training-time differences under the available computing configurations. Although these findings may inform future investigations of IoT gateway and edge-server deployments, the present study does not experimentally assess performance, energy consumption, or deployment suitability on physical edge or embedded devices. Secondary goals include:

• Robust minority-class detection, ensuring that rare attack types are not overshadowed by dominant benign traffic patterns.
• Hardware-aware performance optimisation, assessing differences in classification performance and training time between CPU- and GPU-based implementations.
• Efficient model training, supporting faster model development and periodic retraining when updated IoT data become available.

3.5. Assumptions and Limitations

This work is conducted under reasonable assumptions that shape the interpretation of the system and threat model. In particular, it is assumed that the telemetry used for training and evaluation is accurate, complete, and not subject to adversarial manipulation. The anomaly-detection engine, including its preprocessing steps, model parameters, and execution environment, is presumed to operate in a trusted state. The training dataset is assumed to be representative of the simulated device behaviours and attack categories captured within DS2OS, without assuming that these observations necessarily reflect real-world IoT environments. Furthermore, the adversary is not assumed to possess detailed knowledge of the underlying models or their internal decision boundaries.

4. Methodology

4.1. Project Design

The experimental methodology was designed to provide a consistent comparison of CPU- and GPU-based implementations of the selected tree-based machine-learning models. As illustrated in Figure 1, the workflow consists of data preprocessing, train–test partitioning, training-data reduction, CPU- and GPU-based model training, and evaluation using a common held-out test partition.

Figure 1. Experimental workflow for CPUGPU evaluation.

4.2. Dataset Description

This study utilises the Distributed Smart Space Orchestration System (DS2OS) dataset, developed by Pahl and Aubet [54], to support the evaluation of anomaly-detection approaches in distributed IoT environments. The dataset contains network traces collected from multiple simulated IoT environments representing diverse service interactions. The underlying architecture consists of a collection of microservices that communicate using the Message Queuing Telemetry Transport (MQTT) protocol. These services emulate typical smart-environment components, including light controllers, thermometers, motion sensors, washing machines, and battery- and temperature-monitoring systems, as well as smart-door controls and smartphone-based interactions [37].

Key characteristics of the DS2OS dataset include:

• Total records: A total of 357,952 observations before cleaning, with 355,902 after removing records containing missing values.
• Class distribution: Approximately 97.76% normal traffic and 2.24% anomalous traffic across seven attack categories in the cleaned dataset.
• Attack categories: Denial of Service, Data Type Probing, Malicious Control, Malicious Operation, Scan, Spying, and Wrong Setup.
• Features: Thirteen attributes, including categorical descriptors (device ID, location and operation type), service information, and timestamps.

All seven attack categories listed in Table 3 are included in the training and test sets and are evaluated as distinct target classes in the experimental analysis, ensuring that each threat defined in the system model is empirically assessed.

Table 3. DS2OS dataset attack categories and distribution.

Attack Class	Attack Type	Count	Percentage	Training Subset	Test Set
0	Denial of Service (DoS)	4000	1.124%	907	808
1	Data Type Probing	242	0.068%	62	41
2	Malicious Control	889	0.250%	229	206
3	Malicious Operation	657	0.185%	177	116
4	Scan	1531	0.430%	367	331
5	Spying	532	0.149%	126	113
6	Wrong Setup	122	0.034%	32	18
7	Normal (benign) Traffic	347,929	97.760%	83,516	69,548
Total	All Classes	355,902	100.000%	85,416	71,181

Following the removal of 2050 records containing missing values from the original 357,952 observations, 355,902 complete records remained for evaluation. Table 3 presents the corrected class distribution of the cleaned dataset, the reduced training subset (85,416 observations), and the held-out test set (71,181 observations) that was generated using the experimental partitioning procedure described in Section 4.3. Normal traffic constitutes approximately 97.76% of the cleaned dataset. The encoded class identifiers 0–7 correspond to Denial of Service, Data Type Probing, Malicious Control, Malicious Operation, Scan, Spying, Wrong Setup, and normal traffic.

The DS2OS dataset was selected because it provides labelled, multi-class IoT telemetry representing heterogeneous smart-home and smart-building interactions, with seven distinct attack categories alongside benign behaviours. These characteristics align with the objectives of the present study in two important respects. First, its structured feature representation is suitable for evaluating the selected tree-based classifiers, namely DT, RF, and XGBoost. Second, its highly imbalanced multi-class distribution enables investigation into whether strong aggregate classification performance masks poor recognition of rare but security-relevant attack categories. This is particularly important in the present study, where overall accuracy is considered alongside macro-averaged, weighted-average, and class-specific performance metrics.

Other established IoT security benchmark datasets, such as BoT-IoT, TON_IoT, and CICIoT2023, could also support anomaly-detection evaluation; however, these datasets differ from DS2OS in their traffic characteristics, attack taxonomies, feature representations, class distributions, and experimental environments. The objective of this study is not to establish DS2OS as superior to these benchmarks but to use a consistent labelled multi-class IoT dataset that supports both class-specific anomaly-detection analysis and controlled CPU-GPU evaluation across the selected models. Consequently, the findings should be interpreted within the characteristics of DS2OS. Cross-dataset validation using additional contemporary IoT security benchmarks is therefore identified as an important direction for future work.

4.3. Data Preprocessing and CPU/GPU Implementations

The experimental workflow comprised data cleaning, categorical encoding, train–test partitioning, model training, and computational performance evaluation using the DS2OS dataset.

Data preprocessing: Records containing missing values were removed, and categorical predictors were transformed using one-hot encoding. The target variable was separated from the predictor variables, and the dataset was randomly divided into training and testing partitions using an 80:20 split (random_state = 42), without stratification by class label. To reduce computational demand, 30% of the resulting training partition was retained for model development, while the complete test partition was preserved for evaluation.

CPU-based implementation: Decision Tree and Random Forest were implemented using scikit-learn, while XGBoost used its CPU backend. These implementations provided the computational baseline for comparison with GPU-based execution. However, the precise CPU hardware configuration and execution environment could not be independently verified from the available experimental records, limiting the attribution of observed performance differences exclusively to hardware acceleration.

GPU-accelerated implementation: The GPU experiments were conducted in Google Colab Pro using an NVIDIA T4 GPU. RAPIDS cuML supported the tree-based GPU implementations while XGBoost employed GPU acceleration. The GPU-based Decision Tree was implemented using cuML’s RandomForestClassifier with a single estimator (n_estimators = 1) rather than a direct GPU equivalent of scikit-learn’s DecisionTreeClassifier. This distinction is relevant when interpreting the differences in classification and training-time performance.

Table 4 summrises the model configurations used in the original CPU-GPU experiments. All three algorithms were evaluated with a maximum tree depth of five and a fixed random state of 42. The CPU implementations used scikit-learn for Decision Tree and Random Forest, while XGBoost was implemented using its dedicated library. The GPU-based Decision Tree was approximated using RAPIDS cuML’s RandomForestClassifier with a single estimator (n_estimators = 1), rather than an equivalent DecisionTreeClassifier. This implementation distinction is important when interpreting the observed classification performance, particularly the differences in minority-class detection between the CPU and GPU configurations.

Table 4. Hyperparameter configurations of the CPU- and GPU-based Decision Tree, Random Forest, and XGBoost implementations used in the original experiments.

Model	Platform/Library	N_estimators	Max_depth	Random_state	Additional Model Settings
Decision Tree	CPU/scikit-learn	N/A (single tree)	5	42	criterion = gini; max_features = None; class_weight = None; splitter = best.
Decision Tree Proxy	GPU/cuML RF	1	5	42	n_streams = 1; bootstrap = True; max_features = auto; n_bins = 128; split_criterion = gini.
Random Forest	CPU/scikit-learn	50	5	42	criterion = gini; bootstrap = True; max_features = auto (equivalent to square-root feature selection in scikit-learn 0.24.2); class_weight = None.
Random Forest	GPU/cuML RF	50	5	42	n_streams = 1; bootstrap = True; max_features = auto; n_bins = 128; split_criterion = gini.
XGBoost	CPU/XGBoost	50	5	42	eval_metric = logloss; subsample = default; colsample_bytree = default; tree_method = auto (not explicitly configured); objective = default.
XGBoost	GPU/XGBoost	50	5	42	tree_method = hist; device = cuda; eval_metric = logloss; subsample = default; colsample_bytree = default; objective = default.

For the GPU-based Decision Tree proxy and Random Forest implementations, the number of estimators, maximum tree depth, random state, and CUDA streams were explicitly configured, while the remaining parameters followed the cuML library defaults. The CPU-based XGBoost implementation did not specify a tree-construction method, whereas the GPU implementation used histogram-based training with CUDA acceleration. These differences are considered when interpreting the training-time results in Section 5.3.

Google Colab Pro was selected to provide a CUDA-compatible environment for the GPU libraries used in this study. Unlike the selected NVIDIA GPU, integrated GPUs may differ in architecture and software compatibility and cannot be assumed to support these implementations without modification. Consequently, the findings are specific to the evaluated configurations rather than directly transferable to other GPU architectures.

The experimental evaluation assessed machine-learning implementations using IoT security data in a cloud-based computing environment, not on physical IoT or edge devices. Therefore, the measured training-time improvements do not establish inference latency, energy efficiency, memory suitability, or deployment feasibility on resource-constrained hardware. Such properties require direct evaluation on representative platforms, including Raspberry Pi and NVIDIA Jetson devices.

The NVIDIA T4 is a datacentre-class accelerator and is not representative of typical embedded IoT hardware. Furthermore, newer GPU architectures may exhibit different computational characteristics. Accordingly, the observed CPU-to-GPU training-time ratios of 2.12×–2.94× should be interpreted as implementation-specific differences rather than generalisable measures of GPU acceleration across hardware generations or edge platforms.

Performance and resource monitoring: Model training times were recorded for the CPU- and GPU-based implementations to compare their computational performance under the available experimental configurations. However, because the original CPU hardware specifications and execution conditions could not be independently verified, the observed timing differences cannot be attributed exclusively to hardware acceleration.

4.4. Machine-Learning Algorithms

Three established tree-based machine-learning algorithms were selected for evaluating CPU- and GPU-based anomaly detection using the DS2OS dataset: Decision Tree, Random Forest, and XGBoost. These models represent distinct learning strategies: DT provides a single-tree baseline, RF employs bootstrap aggregation across multiple trees, and XGBoost uses sequential gradient boosting. Their selection enables comparison of classification effectiveness and computational performance across different tree-based approaches.

The availability of CPU- and GPU-based implementations was another selection criterion. The models were evaluated using scikit-learn, RAPIDS cuML, and XGBoost, as described in Section 4.3. Other algorithms, including LightGBM, K-nearest neighbours, stochastic-gradient-based classifiers, and Isolation Forest, were excluded to maintain a focused comparison. Notably, Isolation Forest primarily addresses unsupervised anomaly detection, whereas this study investigates supervised multi-class classification.

The computational parallelism of tree-based ML algorithms differs from that of deep-learning architectures. DL models typically perform large-scale matrix multiplications and tensor operations during forward and backward propagation, allowing for numerous arithmetic operations to be executed concurrently on GPUs. In contrast, tree-based algorithms involve conditional branching, feature comparisons, and data-dependent operations that may restrict parallel executions [43,44]. However, the degree of parallelism varies across tree-based models. Decision Trees permit parallel evaluation of candidate splits, although subsequent tree construction depends on earlier splitting decisions. Random Forest supports additional parallelism through the independent construction of multiple trees, whereas XGBoost performs sequential boosting iterations but enables parallel computation within each iteration, particularly during histogram construction and split evaluation. Consequently, GPU acceleration may benefit conventional machine-learning algorithms despite their different computational structures, although the observed training-time differences depend on the evaluated implementations and computing environments [45,46].

A broader benchmark, incorporating additional machine-learning families and representative DNN architectures, is therefore identified as an important direction for future work.

4.5. Memory Profiling

Memory utilisation was monitored at the system level during the experiments to characterise the computational environment associated with CPU- and GPU-based executions. System RAM utilisation was observed using psutil while GPU VRAM utilisation was monitored using gpustat. The reported values therefore represent system-level memory utilisation during the experimental runs rather than memory attributable exclusively to an individual machine-learning model.

These measurements may include memory occupied by the operating environment, Python 3 runtime, loaded libraries, the DS2OS dataset, and other active processes in addition to the evaluated model. Furthermore, system RAM and GPU VRAM represent different memory spaces and should not be interpreted as directly equivalent measures of model-specific memory requirements. Consequently, the memory observations are reported descriptively to characterise the experimental environment and are not used to claim that one hardware implementation is inherently more memory efficient than another.

4.6. Energy Consumption Estimation

Direct hardware-level power measurements were not available during the experiments. The GPU experiments were conducted using an NVIDIA T4 GPU within Google Colab Pro, a virtualised cloud environment that does not provide direct access to physical power-monitoring instrumentation. Consequently, the instantaneous power consumption of the GPU during model execution could not be measured. Similarly, CPU power consumption was not directly recorded. Therefore, nominal power values of 45 W for CPU execution and 70 W for GPU execution were adopted solely to provide illustrative energy estimates based on measured training times. These assumptions do not capture workload-dependent power fluctuations, idle consumption, or other system-level overheads. Accordingly, the resulting estimates should not be interpreted as measured energy consumption or evidence of superior energy efficiency. A reliable comparison would require direct power monitoring throughout model execution, including baseline and workload-dependent power measurements.

Furthermore, the precise CPU hardware configuration and execution environment could not be independently verified from the available experimental records. Consequently, the assumed CPU power value cannot be associated with a confirmed processor configuration, further limiting the reliability of the estimated energy consumption. These estimates are therefore presented solely for illustrative purposes and should not be interpreted as experimentally validated energy measurements.

Although the shorter GPU training times produce lower calculated energy values under the assumed power levels, these estimates do not establish actual energy savings. Furthermore, the NVIDIA T4 and the general-purpose CPU computing environment are not representative of low-power embedded hardware. Accordingly, training time remains the primary computational performance indicator, while the estimated energy values are retained as supplementary information. Future investigations should incorporate direct power measurements on representative low-power platforms, such as Raspberry Pi or NVIDIA Jetson devices, to evaluate energy consumption under realistic deployment conditions.

4.7. Programming Environment and Libraries

Python was used to implement and evaluate the CPU- and GPU-based models. The GPU experiments were conducted in Google Colab Pro, while the accompanying notebook also includes the corresponding CPU implementations. However, the available records do not confirm whether the reported CPU training times were obtained in the same computing environment or establish the precise CPU hardware configuration. Table 5 summarises the software libraries and their applications in the experimental evaluation.

Table 5. Key libraries and their applications.

Category	Library	Version	Purpose
Core ML Libraries	scikit-learn	0.24.2	CPU-based implementations of DT and RF algorithms
	XGBoost	1.5.0	Implementation of gradient boosting with CPU/GPU support
	cuML	21.06	GPU-accelerated implementations of traditional ML algorithms
Data Processing	pandas	1.3.3	Data manipulation, cleaning, and preprocessing
	NumPy	1.21.2	Array operations and mathematical functions
	matplotlib	3.4.3	Statistical visualisation of results
	seaborn	0.11.2	Enhanced statistical visualisation
Performance Monitoring	psutil	5.8.0	System resource monitoring (CPU, memory)
	py-gpustat	0.6.0	GPU-specific metrics (memory allocation, utilisation)
	time/datetime	-	Precise measurement of execution durations

The experimental procedures for data preprocessing and CPU/GPU model implementation are described in Section 4.3. This section focuses only on the criteria used to evaluate the resulting models.

4.7.1. Performance Evaluation Metrics

Classification performance was evaluated using accuracy, precision, recall, and F1 scores. Given the severe class imbalance in the DS2OS dataset, both macro-averaged and weighted-average metrics were considered. Macro-averaged metrics were used to assess performances across classes without allowing the dominant benign class to disproportionately influence the result, whereas weighted-average metrics were retained to characterise overall performance according to the observed class distribution.

Confusion matrices and class-specific precision, recall, and F1 scores were additionally examined to evaluate detection performances for the seven attack categories and the benign class. This class-level analysis was particularly important for identifying cases in which high overall accuracy resulted primarily from successful classification of the dominant benign class while minority attack categories remained poorly detected.

4.7.2. Computational Performance

Computational performance was evaluated primarily using model training times. Training duration was recorded for the CPU- and GPU-based implementations of the evaluated models to compare their computational performance under the available experimental configurations. The corresponding CPU-to-GPU training-time ratios were calculated from the recorded training times to characterise implementation-specific performances differences across the models.

4.7.3. Resource Utilisation

System RAM and GPU VRAM utilisation were monitored during the experiments using system-level monitoring tools. These measurements characterise resource utilisation within the experimental environments and should not be interpreted as memory consumed exclusively by the individual machine-learning models. The recorded values may include memory associated with the operating environment, Python runtime, loaded libraries, dataset storage, and other active processes. Furthermore, system RAM and GPU VRAM represent different memory domains and therefore are not used to establish a direct model-specific memory-efficiency comparison.

Energy consumption was not directly measured. The original analysis estimated energy demand using the measured training times and fixed nominal power assumptions of 45 W for the CPU and 70 W for the GPU. These values are retained only as illustrative estimates under fixed power assumptions and are not interpreted as measured energy consumption or evidence of relative CPU-GPU energy efficiency. Direct hardware-level power monitoring would be required for a definitive energy comparison.

As direct power measurements were not collected, the estimated energy values are presented solely as illustrative calculations and cannot establish the actual energy consumption or energy efficiency of either computing platform. Consequently, the conclusions regarding computational efficiency are based primarily on the recorded training times, while empirical energy-efficiency comparisons remain outside the scope of this study.

4.7.4. Validation Strategy

The original experimental evaluation employed an 80:20 training–test split with a fixed random state of 42. To reduce computational requirements, 30% of the resulting training partition was retained for model development, while the complete test partition was preserved for evaluation. Consequently, the original CPU-GPU comparison was conducted using a restricted training subset without a corresponding full-training-partition baseline. This approach provided a consistent evaluation configuration across the selected implementations but did not establish whether the observed classification performance would remain stable with different training-data proportions.

To investigate this limitation, supplementary CPU-based XGBoost experiments were conducted using stratified 80:20 training–test partitions with random seeds of 42 and 43. Both 30% and 100% of the available training data were evaluated, together with duplicate-record analysis and a feature-disjoint partitioning procedure designed to prevent identical predictor records from appearing in both training and test partitions. These experiments provided additional evidence regarding training-data sensitivity and potential record overlap, while remaining separate from the original CPU-GPU benchmarks.

Further robustness evaluation was conducted using two repetitions of stratified five-fold cross-validation following the removal of missing values and exact duplicate observations. Both 30% and 100% training configurations were examined across the CPU- and GPU-based Decision Tree, Random Forest, and XGBoost implementations. Classification accuracy and macro-F1 were evaluated as mean ± standard deviation across ten folds. Additional tree-based evaluations employed ordinal encoding to accommodate GPU memory requirements, alongside corresponding CPU implementations. The GPU Decision Tree proxy was also evaluated with adjusted bootstrap sampling and feature-selection settings. To investigate the unexpected reduction in XGBoost performance observed with the complete-training partition, an additional controlled evaluation was conducted using XGBoost 3.4.1 with a fixed initial prediction score (base_score = 0.5). The same repeated stratified five-fold cross-validation procedure, training proportions, feature encoding and remaining model settings were retained. Both CPU- and GPU-based implementations were evaluated across ten folds, enabling a direct comparison with the results obtained using automatic initialisation. This additional experiment was designed to assess whether the initialisation procedure contributed to the observed differences in classification performance.

These supplementary evaluations are reported in Section 5.2.4 and Table 7, and they are distinguished from the original experimental results. Although they provide further evidence regarding classification stability, training-data sensitivity, and implementation-dependent behaviour, an independent dataset validation and more comprehensive feature-level leakage assessments remain necessary to establish broader generalisability.

Given the substantial class imbalance in DS2OS, reducing the training partition may further limit the representation of minority attack classes and influence classification performance. Although a fixed random state ensured reproducibility of the original data partition, it did not establish robustness across alternative training configurations. The supplementary experiments therefore examined training-data sensitivity through alternative stratified partitions, different training proportions and repeated cross-validation, while retaining the original CPU-GPU measurements as the primary experimental results.

The XGBoost models achieved near-perfect classification performance on the held-out test data under the evaluated experimental configuration. However, the original experimental evaluation relied on a single 80:20 train–test split with a fixed random state of 42, and repeated stratified evaluation or cross-validation was not performed as part of that initial investigation. Examination of the original implementation also indicates that categorical encoding was applied before dataset partitioning, while explicit checks for duplicate observations across training and test partitions were not incorporated into the documented workflow. Although one-hot encoding alone does not establish target leakage, potential overlap between observations and dataset-specific feature–label relationships cannot be conclusively excluded. Consequently, the reported XGBoost performance should be interpreted as specific to the evaluated test partition rather than evidence of consistently perfect detection. Although the supplementary experiments incorporated alternative stratified partitions, repeated cross-validation and duplicate-record analysis, further evaluation using independent datasets and comprehensive feature-level leakage assessments remains necessary to establish broader generalisability.

Future work could extend the evaluation through learning-curve analysis across progressively larger training subsets to further investigate the relationship between training-data availability and classification performance.

5. Experimental Results

5.1. Overview

This section evaluates the classification performance and measured training times of Decision Tree, Random Forest, and XGBoost across CPU- and GPU-based implementations using the DS2OS dataset. System-level memory observations and assumption-based energy estimates are presented as supplementary indicators, subject to their methodological limitations.

Given the severe class imbalance in DS2OS, overall accuracy and weighted metrics may conceal poor detection of minority attacks. Therefore, macro-averaged metrics and class-specific recall are used alongside aggregate measures to assess detection effectiveness across all seven attack categories.

5.2. Classification Performance

Table 6 summarises the classification performance of the evaluated models. XGBoost achieved 99.999% accuracy on the CPU and 100% on the GPU, with macro-F1 scores of 1.00 for both implementations. As shown in Figure 4e,f, both configurations demonstrated near-perfect detection across the seven attack categories. The CPU implementation produced a negligible misclassification in the benign class, whereas the GPU implementation correctly classified all observations in the evaluated test partition.

Table 6. Aggregate classification performance metrics for CPU and GPU implementations.

Model	Platform	Accuracy (%)	Weighted Precision	Weighted Recall	Weighted F1 Score
Decision Tree	CPU	99.42	0.993	0.994	0.993
Decision Tree	GPU	97.81	0.961	0.978	0.968
Random Forest	CPU	97.71	0.955	0.977	0.966
Random Forest	GPU	97.71	0.955	0.977	0.966
XGBoost	CPU	99.999	1.000	1.000	1.000
XGBoost	GPU	100.0	1.000	1.000	1.000

The CPU-based Decision Tree achieved 99.42% accuracy but a substantially lower macro-F1 score of 0.60, indicating uneven detection performance across the imbalanced classes. Although several attack categories were successfully identified, the confusion matrix revealed misclassification of some minority attacks.

In the original held-out evaluation, Random Forest achieved 97.71% accuracy on both CPU and GPU implementations, largely reflecting the dominance of benign observations. As illustrated in Figure 4c,d, both implementations predominantly classified observations as benign and failed to detect the minority attack classes. Consequently, high weighted-average metrics concealed poor class-specific performance, reflected in the substantially lower macro-averaged scores. These findings highlight the limitations of the evaluated RF configuration under a severe class imbalance and suggest that techniques, such as class weighting or resampling, warrant further investigation.

5.2.1. Per-Attack-Class Detection Performance

To ensure that the experimental evaluation reflects the full threat landscape defined in Section 3.3. Attack Types Considered, class-level recall is reported for each of the seven DS2OS attack categories. This analysis is necessary because the DS2OS dataset is highly imbalanced, with benign traffic accounting for more than 97% of all instances, which can cause aggregate accuracy and weighted F1 scores to mask failures in detecting rare but security-critical attacks. On the CPU platform, the Decision Tree classifier demonstrated strong detection capability for several attack types. Denial of Service was detected with 100% recall, while Malicious Control achieved 97.6% recall. For Malicious Operation, the model correctly identified 50 of the 116 instances, corresponding to a recall of 43.1%. Scanning attacks were detected with moderate effectiveness at 62.2% recall, and Spying attacks were detected at 35.4% recall. However, the Decision Tree failed to detect Data Type Probing and Wrong Setup attacks, for which recall was zero.

In contrast, the GPU-based Decision Tree showed substantially weaker performance on minority classes. All instances of Denial of Service, Data Type Probing, Malicious Control, Malicious Operation, and Wrong Setup were misclassified, resulting in zero recall for these attacks. Only Scanning and Spying were detected, with recall values of 10% and 43.4%, respectively. These results indicate a greater tendency towards majority-class predictions in the evaluated GPU-based Decision Tree proxy than in the CPU Decision Tree, although differences in the underlying model implementations and configurations may have contributed to this behaviour.

In the initial held-out evaluation, the CPU- and GPU-based Random Forest implementations failed to detect the seven attack categories, classifying the corresponding observations as benign traffic. However, the supplementary results in Table 7 show that Random Forest achieved substantially higher macro-F1 scores when ordinal encoding was used, reaching approximately 0.56 on both platforms. This indicates that the poor minority-class detection observed in the original experiments was specific to the evaluated feature representation and model configurations rather than an inherent limitation of the Random Forest algorithm.

In contrast, XGBoost achieved perfect recall across all seven attack categories on both CPU and GPU platforms, with every attack instance in the test partition correctly classified. This indicates that XGBoost achieved strong discrimination across both frequent and rare attack classes, including Spying and Wrong Setup. The CPU implementation produced a single misclassification within the benign class, while the GPU implementation correctly classified all evaluated test instances.

5.2.2. Platform Consistency Analysis

The original CPU-GPU evaluation revealed broadly comparable overall classification accuracy for Random Forest and XGBoost, whereas Decision Tree exhibited greater implementation-dependent variation. As shown in Table 6, the GPU-based Decision Tree proxy achieved an accuracy 1.61 percentage points lower than its CPU counterpart, while Random Forest maintained identical accuracy (97.71%) across both implementations. XGBoost demonstrated near-perfect accuracy on both platforms.

The supplementary evaluation provides further insight into the classification difference observed between the CPU Decision Tree and the GPU-based single-tree proxy. As reported in Table 7, adjusting the GPU proxy configuration (bootstrap = False, max_features = 1.0) increased mean macro-F1 from 0.4455 to 0.6086 under the 30% training configuration and from 0.5045 to 0.6118 under the complete-training configuration. The adjusted GPU proxy therefore achieved classification performance comparable to the CPU Decision Tree. These findings demonstrate that model configuration contributed substantially to the original performance difference, which should not be interpreted as an inherent classification disadvantage of GPU execution.

5.2.3. Impact of Class Imbalance on Performance Metrics

The severe class imbalance in the DS2OS dataset has an important influence on the interpretation of aggregate classification metrics. Weighted-average metrics assign greater weight to classes with larger numbers of observations and can therefore remain high when performance on the dominant benign class is strong, even if minority attack classes are detected poorly. Consequently, weighted-average performance should be interpreted alongside macro-averaged and class-specific metrics when evaluating anomaly-detection capability.

The macro-averaged F1 scores, calculated by assigning equal importance to each class regardless of its frequency, reveal substantial differences among the evaluated models:

• Decision Tree (CPU): Macro-F1 score of 0.60.
• Decision Tree (GPU): Macro-F1 score of 0.22.
• Random Forest (CPU and GPU): Macro-F1 score of 0.12.
• XGBoost (CPU and GPU): Macro-F1 score of 1.00.

As shown in Figure 2, these macro-averaged results indicate that XGBoost achieved a substantially stronger class-level performance than Decision Tree and Random Forest. Random Forest was particularly affected by the severe class imbalance, with its predictions predominantly concentrated in the benign class despite its relatively high overall accuracy. This discrepancy demonstrates why overall accuracy and weighted-average metrics alone can provide an incomplete assessment of anomaly-detection performance on highly imbalanced datasets.

Figure 2. Macro-averaged F1 scores comparison.

5.2.4. Supplementary XGBoost Validation and Feature-Sensitivity Analysis

Supplementary CPU-based XGBoost experiments were conducted using the DS2OS dataset that contained 357,952 observations, of which 355,902 remained after removing missing values. Unlike the original CPU-GPU experiments, the supplementary evaluation employed training-fitted one-hot encoding and stratified 80:20 partitions using random seeds 42 and 43. XGBoost was evaluated using 30% and 100% of the available training partition, with 50 estimators and a maximum tree depth of five.

For seed 42, the 30% training configuration achieved 99.9916% accuracy and a macro-F1 score of 0.9987 compared to 99.6923% and 0.8008 using the complete-training partition. For seed 43, the corresponding values were 99.9831% and 0.9963 with 30% training data, decreasing to 99.0096% and 0.6214 with the complete-training partition. These findings indicate that classification performance was sensitive to the evaluated training configuration, particularly for minority classes.

A data-integrity assessment identified 1326 duplicate complete observations. Feature-disjoint evaluation, which prevented identical predictor vectors from appearing in both training and test sets, achieved 99.9944% accuracy for both seeds under the 30% training configuration, with macro-F1 scores of 0.9983 and 0.9991, respectively. Under the full-training configurations, accuracies were 99.5829% and 99.7823%, with corresponding macro-F1 scores of 0.7994 and 0.8540.

Although feature-disjoint evaluation reduced identical-predictor overlap, the temporal dependencies, simulation-specific patterns, and other sources of information leakage cannot be excluded. The supplementary experiments also differed from the original CPU-GPU comparison in preprocessing and software environment. Therefore, these findings provide configuration-specific evidence of XGBoost robustness rather than an exact reproduction of the original experimental results or proof of generalisability to independent IoT datasets.

To further examine the robustness of the original findings, an additional evaluation was conducted using two repetitions of stratified five-fold cross-validation, following the removal of missing values and exact duplicate observations (354,576 remaining records). This supplementary assessment considered 30% and 100% of the available training partition, with accuracy and macro-F1 reported as mean ± standard deviation across ten folds. The original CPU-GPU experimental results were retained as the primary evaluation, while the cross-validation analysis provided additional evidence regarding classification stability.

The CPU Decision Tree achieved macro-F1 scores of 0.6001 ± 0.0117 and 0.6034 ± 0.0067 for the 30% and 100% training configurations, respectively. CPU Random Forest maintained a macro-F1 score of approximately 0.1238 under both configurations, reflecting its limited detection of minority classes. For XGBoost, the 30% training configuration achieved macro-F1 scores of 0.9987 ± 0.0010 on CPU and 0.9988 ± 0.0010 on GPU. However, the corresponding scores decreased to 0.5941 ± 0.1851 and 0.5393 ± 0.2191 when the complete-training partition was used. The substantial deterioration observed under the complete-training configuration prompted further investigation of the XGBoost initialisation procedure.

A further controlled evaluation was conducted using XGBoost 3.4.1 with a fixed initial prediction score (base_score = 0.5), while retaining the same cross-validation folds, training proportions, preprocessing procedures and remaining model settings. Under the complete-training configuration, mean macro-F1 increased from 0.5941 ± 0.1851 to 1.0000 ± 0.0000 on the CPU and from 0.5393 ± 0.2191 to 1.0000 ± 0.0000 on the GPU. The corresponding 30% training configurations also maintained near-perfect performance, achieving mean macro-F1 scores of 0.9994 ± 0.0004 on both platforms. These findings demonstrate that the deterioration observed with automatic initialisation was strongly dependent on the initial prediction-score setting instead of representing an unavoidable consequence of increasing the training-data proportion. Nevertheless, these results remain specific to the evaluated DS2OS dataset and do not establish generalisability to independent IoT environments.

Additional XGBoost evaluations excluding the timestamp attribute produced macro-F1 scores of 0.8962 ± 0.1357 on CPU and 0.9275 ± 0.0505 on GPU under the 30% training configuration. This reduction suggests that temporal information contributed to classification performance, although its potential relationship with simulation-specific characteristics requires further investigation.

With ordinal encoding, Random Forest achieved mean macro-F1 scores of 0.5658 and 0.5649 on the CPU and GPU, respectively, under the 30% training configuration. These results contrast with the approximately 0.12 macro-F1 obtained using one-hot encoding and demonstrate the sensitivity of the evaluated Random Forest implementations to feature representation.

As shown in Table 7, a further controlled evaluation of the GPU Decision Tree proxy, with bootstrap = False and max_features = 1.0, improved mean macro-F1 from 0.4455 to 0.6086 for the 30% training configuration and from 0.5045 to 0.6118 for the complete-training configuration. These findings indicate that sampling and feature-selection settings substantially influence the performance of the single-estimator cuML Random Forest used as a Decision Tree proxy. As this supplementary assessment employed a different feature encoding from the original experiments, its results are interpreted separately and do not replace the original classification measurements.

Table 7. Supplementary repeated stratified five-fold cross-validation results.

Model	Platform	Training	Accuracy (%, Mean ± SD)	Macro-F1 (Mean ± SD)	Feature Encoding Used
Decision Tree	CPU	30%	99.398 ± 0.085	0.6001 ± 0.0117	One-hot encoding
Decision Tree	CPU	100%	99.426 ± 0.016	0.6034 ± 0.0067	One-hot encoding
Decision Tree	CPU	30%	99.053 ± 0.008	0.5628 ± 0.0049	Ordinal encoding
Decision Tree	CPU	100%	99.059 ± 0.007	0.5658 ± 0.0048	Ordinal encoding
Decision Tree proxy	GPU	30%	98.715 ± 0.168	0.4455 ± 0.0849	Ordinal encoding
Decision Tree proxy	GPU	100%	98.801 ± 0.183	0.5045 ± 0.0907	Ordinal encoding
Decision Tree proxy—adjusted	GPU	30%	99.200 ± 0.011	0.6086 ± 0.0068	Ordinal encoding
Decision Tree proxy—adjusted	GPU	100%	99.211 ± 0.009	0.6118 ± 0.0050	Ordinal encoding
Random Forest	CPU	30%	98.123 ± 0.000	0.1238 ± 0.0000	One-hot encoding
Random Forest	CPU	100%	98.123 ± 0.000	0.1238 ± 0.0000	One-hot encoding
Random Forest	CPU	30%	99.059 ± 0.008	0.5658 ± 0.0056	Ordinal encoding
Random Forest	CPU	100%	99.050 ± 0.019	0.5540 ± 0.0364	Ordinal encoding
Random Forest	GPU	30%	99.055 ± 0.015	0.5649 ± 0.0055	Ordinal encoding
Random Forest	GPU	100%	99.053 ± 0.013	0.5625 ± 0.0113	Ordinal encoding
XGBoost (automatic initialisation)	CPU	30%	99.993 ± 0.004	0.9987 ± 0.0010	One-hot encoding
XGBoost (automatic initialisation)	CPU	100%	98.831 ± 0.839	0.5941 ± 0.1851	One-hot encoding
XGBoost (automatic initialisation)	GPU	30%	99.993 ± 0.004	0.9988 ± 0.0010	One-hot encoding
XGBoost (automatic initialisation)	GPU	100%	98.087 ± 1.375	0.5393 ± 0.2191	One-hot encoding
XGBoost (fixed initialisation)	CPU	30%	99.996 ± 0.003	0.9994 ± 0.0004	One-hot encoding
XGBoost (fixed initialisation)	CPU	100%	100.000 ± 0.000	1.0000 ± 0.0000	One-hot encoding
XGBoost (fixed initialisation)	GPU	30%	99.997 ± 0.002	0.9994 ± 0.0004	One-hot encoding
XGBoost (fixed initialisation)	GPU	100%	100.000 ± 0.000	1.0000 ± 0.0000	One-hot encoding

Table 7. Supplementary repeated stratified five-fold cross-validation results.

Model	Platform	Training	Accuracy (%, Mean ± SD)	Macro-F1 (Mean ± SD)	Feature Encoding Used
Decision Tree	CPU	30%	99.398 ± 0.085	0.6001 ± 0.0117	One-hot encoding
Decision Tree	CPU	100%	99.426 ± 0.016	0.6034 ± 0.0067	One-hot encoding
Decision Tree	CPU	30%	99.053 ± 0.008	0.5628 ± 0.0049	Ordinal encoding
Decision Tree	CPU	100%	99.059 ± 0.007	0.5658 ± 0.0048	Ordinal encoding
Decision Tree proxy	GPU	30%	98.715 ± 0.168	0.4455 ± 0.0849	Ordinal encoding
Decision Tree proxy	GPU	100%	98.801 ± 0.183	0.5045 ± 0.0907	Ordinal encoding
Decision Tree proxy—adjusted	GPU	30%	99.200 ± 0.011	0.6086 ± 0.0068	Ordinal encoding
Decision Tree proxy—adjusted	GPU	100%	99.211 ± 0.009	0.6118 ± 0.0050	Ordinal encoding
Random Forest	CPU	30%	98.123 ± 0.000	0.1238 ± 0.0000	One-hot encoding
Random Forest	CPU	100%	98.123 ± 0.000	0.1238 ± 0.0000	One-hot encoding
Random Forest	CPU	30%	99.059 ± 0.008	0.5658 ± 0.0056	Ordinal encoding
Random Forest	CPU	100%	99.050 ± 0.019	0.5540 ± 0.0364	Ordinal encoding
Random Forest	GPU	30%	99.055 ± 0.015	0.5649 ± 0.0055	Ordinal encoding
Random Forest	GPU	100%	99.053 ± 0.013	0.5625 ± 0.0113	Ordinal encoding
XGBoost (automatic initialisation)	CPU	30%	99.993 ± 0.004	0.9987 ± 0.0010	One-hot encoding
XGBoost (automatic initialisation)	CPU	100%	98.831 ± 0.839	0.5941 ± 0.1851	One-hot encoding
XGBoost (automatic initialisation)	GPU	30%	99.993 ± 0.004	0.9988 ± 0.0010	One-hot encoding
XGBoost (automatic initialisation)	GPU	100%	98.087 ± 1.375	0.5393 ± 0.2191	One-hot encoding
XGBoost (fixed initialisation)	CPU	30%	99.996 ± 0.003	0.9994 ± 0.0004	One-hot encoding
XGBoost (fixed initialisation)	CPU	100%	100.000 ± 0.000	1.0000 ± 0.0000	One-hot encoding
XGBoost (fixed initialisation)	GPU	30%	99.997 ± 0.002	0.9994 ± 0.0004	One-hot encoding
XGBoost (fixed initialisation)	GPU	100%	100.000 ± 0.000	1.0000 ± 0.0000	One-hot encoding

5.3. Training Times and Speedup Analysis

Table 8 presents the recorded training times for the CPU- and GPU-based implementations of Decision Tree, Random Forest and XGBoost. Under the evaluated experimental configurations, the GPU-based implementations recorded shorter training durations than their CPU-based counterparts. The recorded CPU and GPU training times were 19.93 s and 6.86 s for Decision Tree, 8.26 s and 3.90 s for Random Forest, and 215.61 s and 73.38 s for XGBoost, respectively.

Table 8. Training-time comparison between CPU and GPU implementations.

Model	CPU Training Time (s)	GPU Training Time (s)	Observed CPU/GPU Time Ratio
Decision Tree	19.93	6.86	2.91×
Random Forest	8.26	3.90	2.12×
XGBoost	215.61	73.38	2.94×

The recorded training times indicate lower execution durations for the GPU-based implementations than for their CPU-based counterparts, with CPU-to-GPU time ratios of 2.91 for Decision Tree, 2.12 for Random Forest, and 2.94 for XGBoost. XGBoost showed the largest absolute difference among the recorded training times. However, because the original CPU hardware configuration, available computational resources, and execution environments could not be independently verified, these ratios represent differences between the recorded experimental configurations rather than reproducible measures of GPU acceleration. The observed differences may reflect variations in hardware resources, software implementations, and execution conditions.

As shown in Table 8, XGBoost exhibited the largest absolute difference in recorded training time, decreasing by 142.23 s between the CPU- and GPU-based implementations. However, this difference does not establish an equivalent improvement in operational anomaly-detection latency, which was not evaluated in this study.

The observed CPU-to-GPU training-time ratios ranged from 2.12 for Random Forest to 2.94 for XGBoost. These ratios are descriptive comparisons of the recorded execution times and cannot be attributed exclusively to GPU acceleration because the original CPU hardware configuration was not documented. The computational characteristics of the three algorithms may help explain the observed timing differences, although the contributions of hardware, software implementation, and execution environment cannot be isolated. These findings align with expectations based on the algorithmic characteristics of each model:

• XGBoost (observed CPU/GPU time ratio: 2.94): The GPU implementation explicitly employed histogram-based tree construction (tree_method = hist), whereas the CPU implementation did not explicitly specify tree_method, leaving its selection to the installed XGBoost version. From XGBoost 2.0 onwards, the default auto setting corresponds to histogram-based construction, while earlier versions selected between exact and approximate methods. Consequently, the tree-construction method used in the original CPU experiments cannot be confirmed from the available execution records. Together with the unverified CPU hardware configuration, this limits the interpretation of the reported 2.94× training-time ratio to a comparison of the original experimental configurations rather than a direct measure of GPU acceleration.
• Decision Tree (observed CPU/GPU time ratio: 2.91): The GPU-based single-tree implementation recorded a shorter training time than the CPU-based Decision Tree. However, the GPU implementation used a single-tree Random Forest configuration in RAPIDS cuML rather than an algorithmically identical Decision Tree implementation. Consequently, the observed timing difference may reflect both implementation differences and the underlying computational environments and cannot be attributed exclusively to GPU acceleration.
• Random Forest (observed CPU/GPU time ratio: 2.12): Random Forest supports parallel tree construction, although its training performance depends on the implementation, number of trees, available processing resources, and execution environment. The recorded GPU training time was shorter than the CPU training time. However, because the original CPU hardware configuration and effective core utilisation could not be verified, the observed 2.12 ratio represents a comparison between the recorded experimental setups rather than an independently reproducible measure of GPU acceleration.

The reported CPU-to-GPU training-time ratios were obtained from the original experimental configurations, which included an NVIDIA T4 GPU in Google Colab Pro. Performance may differ across hardware architectures, dataset sizes, and model configurations; therefore, these ratios should be interpreted as specific to the evaluated implementations and execution environments.

5.4. Memory and Energy Utilisation

5.4.1. Energy Consumption Analysis

Energy consumption was not directly measured during the experiments. Instead, illustrative estimates were calculated from the recorded training times using fixed nominal power assumptions of 45 W for CPU execution and 70 W for GPU execution:

$$E=P\times t$$

where E denotes estimated energy consumption in joules (J), P represents assumed power consumption in watts (W), and t is the recorded training time in seconds (s).

Table 9 presents the resulting estimates, which are lower for the GPU implementations across all three models under the selected power assumptions.

Table 9. Illustrative energy estimates under fixed power assumptions.

Model	CPU Energy (J)	GPU Energy (J)
Decision Tree	896.85	480.37
Random Forest	371.70	273.17
XGBoost	9702.45	5136.75

The estimated energy values depend on the assumed CPU and GPU power levels and do not account for workload-dependent power fluctuations, dynamic voltage and frequency scaling (DVFS), hardware power-management mechanisms, or virtualised resource allocation. Furthermore, the precise CPU hardware configuration could not be independently verified. Consequently, these calculations should be regarded as illustrative estimates rather than measurements of actual energy consumption or evidence of comparative CPU-GPU energy efficiency. Recorded training time therefore remains the primary computational performance indicator.

A more comprehensive energy assessment could be conducted using monitoring frameworks, such as CodeCarbon, which utilise available hardware-monitoring interfaces and estimation methods to estimate energy consumption. However, their accuracy depends on hardware support and monitoring permissions, and such tools were not employed in the original experiments. Future work should therefore incorporate direct power measurements and hardware-aware energy profiling under controlled conditions using clearly specified computing platforms.

The lower estimated energy values associated with the GPU implementations can be explained mathematically by the fixed-power assumptions underlying the race-to-finish principle, whereby shorter execution times may offset higher power requirements. In the present study, energy consumption was estimated using (E = P × t), assuming a constant power of 45 W for the CPU and 70 W for the GPU. Under these assumptions, the GPU-based implementation yields a lower estimated energy value whenever the CPU-to-GPU training-time ratio exceeds (${\displaystyle \raisebox{1ex}{$70$}\!\left/ \!\raisebox{-1ex}{$45$}\right.}\approx 1.56$). Since the recorded ratios range from 2.12 to 2.94, the lower GPU energy estimates follow directly from this calculation rather than demonstrating an empirically established energy-efficiency advantage. Actual power consumption was not monitored, and the original CPU hardware configuration could not be independently verified. Therefore, direct power measurements under controlled hardware conditions are required to determine whether genuine energy savings can be achieved.

5.4.2. Memory Utilisation Patterns

Memory utilisation was monitored during the experiments to provide an indication of the overall resource usage within the experimental environment. Figure 3 presents the recorded system-level CPU RAM and GPU VRAM observations. However, the available experimental records do not provide sufficient information to independently verify the reported GPU memory capacity and utilisation values. Consequently, these observations are retained only as descriptive indicators and are not used to establish model-specific memory requirements or comparative memory efficiency.

Figure 3. Observed system RAM and GPU VRAM utilisation in the experimental environments.

These measurements should not be interpreted as the memory requirements of the individual Decision Tree, Random Forest, or XGBoost models. The CPU RAM measurement includes memory utilised by the operating environments, Python runtimes, loaded libraries, the DS2OS dataset, and other active processes. Similarly, the GPU VRAM measurement may include allocations associated with the GPU runtime, libraries, data structures, and other GPU-related processes.

Furthermore, system RAM and GPU VRAM represent different memory domains with different allocation and management mechanisms. Therefore, their absolute utilisation values cannot be directly compared to establish the relative memory efficiency of the CPU and GPU model implementations. The measurements in Figure 3 are retained only to characterise the observed resource utilisation of the experimental environments.

A rigorous comparison of model-specific memory requirements would require baseline measurements before model execution and process- or model-specific monitoring of peak incremental memory utilisation during training under controlled experimental conditions. Such profiling is identified as an area for future work.

5.5. Class-Level Analysis Using Confusion Matrices

The confusion matrices in Figure 4 provide deeper insight into the behaviour of each algorithm beyond the aggregate performance metrics. XGBoost demonstrated near-perfect class-level identification across both CPU and GPU implementations. In the initial evaluation, the CPU Decision Tree detected several attack classes, whereas the GPU-based single-tree proxy exhibited weaker minority-class discrimination. However, the supplementary evaluation in Table 7 demonstrated that adjusting the GPU proxy’s sampling and feature-selection settings increased its mean macro-F1 to approximately 0.61, comparable to the CPU Decision Tree. This provides evidence that the original classification difference was substantially influenced by model configuration rather than representing an inherent limitation of GPU hardware. Random Forest exhibited the most substantial limitation, with both CPU- and GPU-based implementations failing to identify any of the seven attack categories in the original test partition. This behaviour is consistent with strong majority-class bias under the severe class imbalance of the DS2OS dataset. These findings further demonstrate the importance of examining class-specific results rather than relying solely on overall accuracy when evaluating anomaly-detection models on imbalanced datasets.

5.6. Comparative Analysis and Interpretation

The comparative results in Table 10 summarise the classification effectiveness and computational performance of Decision Tree, Random Forest, and XGBoost across the evaluated CPU and GPU implementations. Measured training-time and classification metrics constitute the principal evaluation outcomes, whereas energy values are illustrative estimates based on fixed power assumptions.

Table 10. Comparative classification and training-time performance in the initial held-out evaluation.

Metric	Decision Tree (CPU)	Decision Tree (GPU)	Random Forest (CPU)	Random Forest (GPU)	XGBoost (CPU)	XGBoost (GPU)
Accuracy	99.42%	97.81%	97.71%	97.71%	99.999%	100%
Macro-F1 score	0.60	0.22	0.12	0.12	1.00	1.00
Training time (s)	19.93	6.86	8.26	3.90	215.61	73.38
Estimated energy, fixed power assumptions (J)	896.85	480.37	371.70	273.17	9702.45	5136.75
Attack-class detection	Partial	Very Limited	None	None	Complete	Complete

The confusion matrices demonstrate substantial differences in minority-class detection despite relatively high aggregate accuracy. Random Forest predominantly classified observations as benign, whereas Decision Tree exhibited implementation-dependent differences in attack-class recall. XGBoost achieved near-perfect classification within the initial test partition. Supplementary repeated stratified cross-validation confirmed consistently high classification performance across different data partitions when a fixed initial prediction score was used. Nevertheless, further evaluation using independent IoT datasets is necessary to establish the generalisability of these findings. Although supplementary repeated cross-validation was conducted, the available evidence does not establish whether the original models were affected by overfitting. Further investigation using learning curves and independent datasets would be necessary to assess generalisation performance more comprehensively.

Figure 4. Confusion matrices for (a) Decision Tree (CPU), (b) Decision Tree (GPU), (c) Random Forest (CPU), (d) Random Forest (GPU), (e) XGBoost (CPU), and (f) XGBoost (GPU).

Figure 4. Confusion matrices for (a) Decision Tree (CPU), (b) Decision Tree (GPU), (c) Random Forest (CPU), (d) Random Forest (GPU), (e) XGBoost (CPU), and (f) XGBoost (GPU).

The relevance of the present study to lightweight and low-power IoT systems should be interpreted in terms of the computational characteristics of the evaluated tree-based algorithms rather than demonstrated deployment efficiency on resource-constrained devices. The experiments were conducted using general-purpose CPU and GPU computing environments and did not involve direct implementation on single-board computers or microcontrollers. Consequently, the observed training-time improvements cannot be directly translated into conclusions regarding inference latency, memory requirements, or energy consumption on embedded platforms. Nevertheless, the evaluation provides preliminary evidence concerning the computational behaviour and classification effectiveness of established tree-based models, which may inform subsequent investigations of their suitability for edge-level anomaly detection. Platforms, such as Raspberry Pi and NVIDIA Jetson, offer potential environments for evaluating model inference and resource utilisation, while microcontrollers, such as the ESP32-S3, would require additional consideration of model representation, available memory, software compatibility, and computational constraints. Future work should therefore investigate deployment on representative edge and embedded devices, incorporating inference latency, model footprints, power consumption, and detection performance to determine whether the observed findings translate into practical low-power IoT applications.

5.6.1. Algorithm Effectiveness Comparison

In the initial held-out evaluation, XGBoost achieved the highest classification performance among the three evaluated algorithms. It achieved near-perfect accuracy on the CPU and perfect accuracy on the GPU, with a macro-F1 score of 1.00 for both implementations, indicating strong discrimination across all seven attack categories despite the severe class imbalance in the DS2OS dataset. The recorded XGBoost training times were 215.61 s for the CPU-based implementation and 73.38 s for the GPU-based implementation, corresponding to an observed CPU-to-GPU time ratio of 2.94. However, because the original CPU hardware configuration could not be verified, this ratio should be interpreted as a difference between the recorded experimental setups rather than a reproducible measure of GPU acceleration.

The supplementary validation experiments provided further insight into the sensitivity of XGBoost classification performance to model configuration. Although near-perfect macro-F1 scores were obtained using 30% of the training data, the complete-training configuration initially produced lower and more variable results under automatic initialisation. A subsequent controlled evaluation using a fixed initial prediction score (base_score = 0.5) eliminated this deterioration across the ten evaluated folds, achieving mean macro-F1 scores of 1.0000 on both the CPU and GPU with the complete-training partition. These findings demonstrate that the observed performance variation was strongly associated with model initialisation rather than training-data volume alone. Nevertheless, the consistently high results obtained under the adjusted configuration remain specific to DS2OS and require independent validation before broader conclusions can be drawn.

Nevertheless, XGBoost’s computational demands should not be overlooked. Its recorded CPU training time was approximately 26 times that of Random Forest under the initial experimental configuration. The GPU-based XGBoost implementation recorded a shorter training duration than its CPU-based counterpart. However, because the original CPU hardware configuration and execution conditions could not be independently verified, this difference cannot be attributed exclusively to GPU acceleration or generalised to other hardware environments.

Although XGBoost achieved 99.999% accuracy on the CPU and 100% accuracy on the GPU, with macro-F1 scores of 1.00 for both implementations, these results require careful interpretation. The strong classification performance indicates that XGBoost effectively distinguished the eight labelled classes within the evaluated DS2OS test partition. However, the near-perfect outcomes may also be influenced by dataset-specific characteristics, including the separability of the recorded attack patterns and relationships between the input features and class labels. The original CPU-GPU comparison relied on a single 80:20 held-out split. Subsequent supplementary evaluations incorporated alternative training proportions, stratified data partitions, duplicate-record analysis, feature-sensitivity assessment, and repeated cross-validation across the six CPU- and GPU-based implementations. The supplementary findings also demonstrated that Random Forest classification performance was strongly influenced by feature representation, with ordinal encoding substantially improving macro-F1 scores on both CPU and GPU compared with the initially evaluated configurations. However, these evaluations were restricted to the DS2OS dataset, and independent IoT datasets were not examined. Consequently, the generalisability of the findings beyond the evaluated DS2OS configurations remains unestablished.

In the initial experiments, Random Forest achieved 97.71% accuracy on both CPU and GPU but failed to identify minority attack classes. However, the supplementary evaluation demonstrated that this behaviour was strongly dependent on the feature representation and model configuration. With ordinal encoding, the CPU and GPU implementations achieved mean macro-F1 scores of approximately 0.56, indicating substantially improved minority-class detection compared with the original configurations. Random Forest also recorded the shortest training times in the original experiments, requiring 8.26 s on the CPU and 3.90 s on the GPU. These findings highlight the importance of considering preprocessing choices alongside classification performance and computational efficiency when evaluating Random Forest for IoT anomaly detection.

Decision Tree exhibited implementation-dependent classification performance in the original experiments. The CPU implementation detected several minority attack classes, whereas the GPU-based single-tree proxy achieved weaker class-level recall. However, the supplementary evaluation demonstrated that this difference was strongly influenced by model configuration. With bootstrap = False and max_features = 1.0, the GPU proxy achieved mean macro-F1 scores of 0.6086 and 0.6118 under the 30% and 100% training configurations, respectively, comparable to the CPU Decision Tree results. These findings indicate that the original classification gap should not be attributed to an inherent disadvantage of GPU hardware. The original training times were 19.93 s for the CPU Decision Tree and 6.86 s for the GPU proxy, corresponding to an observed CPU-to-GPU ratio of 2.91. As the two implementations were not algorithmically identical, this timing comparison remains specific to the evaluated configurations.

5.6.2. Implications of Minority-Class Detection Performance

The class-level results confirm that overall accuracy alone is insufficient for evaluating anomaly-detection effectiveness on the highly imbalanced DS2OS dataset. As reported in Section 5.2.1, the initially evaluated Random Forest configurations failed to detect minority attacks despite high aggregate accuracy, whereas Decision Tree achieved partial detection and XGBoost identified all seven attack categories in the held-out test partition. However, the supplementary results in Table 7 demonstrated that Random Forest achieved substantially improved minority-class detection with ordinal encoding, reaching mean macro-F1 scores of approximately 0.56 on both CPU and GPU. These findings reinforce the importance of class-specific recall and macro-averaged metrics alongside aggregate measures when evaluating machine-learning models for imbalanced IoT anomaly detection.

5.6.3. Hardware Platform Comparison

The GPU-based implementations recorded shorter training times than their CPU-based counterparts under the original experimental conditions. The observed CPU-to-GPU training-time ratios ranged from 2.12× for Random Forest to 2.94× for XGBoost, indicating shorter recorded training durations for the evaluated GPU-based implementations under the original experimental configurations. In contrast, the reported energy values were calculated using fixed nominal power assumptions of 45 W for the CPU and 70 W for the GPU rather than obtained through direct power measurements. These estimates are therefore illustrative and cannot establish actual energy consumption or comparative energy efficiency. Similarly, the RAM and VRAM observations represent system-level utilisation within the respective experimental environments and do not quantify the memory requirements of individual models. Accordingly, the training time is treated as the principal quantitative measure of computational performance, whereas the estimated energy values and system-level memory observations are retained only as supplementary contextual indicators. No definitive claims regarding energy savings or model-specific memory efficiency are made on the basis of these estimates.

The original CPU-GPU evaluation revealed weaker minority-class detection by the GPU-based Decision Tree proxy than by the CPU Decision Tree. However, the supplementary controlled evaluation provides evidence that model configuration played a substantial role in this difference. Adjusting bootstrap = False and max_features = 1.0 improved the GPU proxy’s mean macro-F1 to 0.6086 and 0.6118 under the 30% and 100% training configurations, respectively, bringing its performance into a range comparable to that of the CPU Decision Tree. These results demonstrate that the original classification difference should not be interpreted as an inherent consequence of GPU execution. Because both parameters were adjusted simultaneously, their individual contributions were not separately established. The recorded CPU-GPU training-time ratios remain as comparisons between the specific software implementations and computing configurations evaluated in the original experiments rather than isolated measurements of hardware acceleration.

5.6.4. Practical Deployment Considerations

The potential application of these findings to IoT deployment environments requires further investigation, as the present study evaluated CPU- and GPU-based training performance using general-purpose computing configurations rather than physical edge or embedded hardware.

Embedded GPU platforms, such as NVIDIA Jetson devices, offer potential opportunities for deploying GPU-accelerated anomaly detection closer to IoT data sources. Unlike resource-constrained sensors and microcontrollers, GPU-equipped edge gateways can collect and preprocess telemetry from multiple IoT devices and execute compatible machine-learning models locally. However, these platforms were not experimentally evaluated in the present study. Their suitability for IoT anomaly detection therefore requires further investigation, including direct measurements of inference latency, memory utilisation, power consumption, and classification performance under representative workloads.

Within such architectures, model training may be performed on more powerful computing infrastructure, while the trained models are deployed on embedded GPUs for inference. Alternatively, periodic retraining could be performed at the edge where computational resources permit. However, practical deployment requires consideration of memory availability, power consumption, inference latency, and compatibility with GPU-accelerated libraries. Although shorter training times were recorded for the NVIDIA T4 GPU implementations, the original CPU hardware configuration could not be independently verified, preventing these differences from being attributed exclusively to GPU acceleration. Furthermore, these results cannot be directly generalised to embedded GPU platforms, which have different computational and memory characteristics. Evaluating inference performance, energy consumption, and detection effectiveness on representative embedded hardware therefore remains an important direction for future work.

In the initial held-out evaluation, GPU-based XGBoost achieved 100% accuracy and a macro-F1 score of 1.00. Supplementary repeated cross-validation initially revealed lower and more variable macro-F1 scores under the complete-training configuration with automatic initialisation. However, a subsequent controlled evaluation using XGBoost 3.4.1 with a fixed initial prediction score (base_score = 0.5) eliminated this deterioration across all ten folds, achieving a mean macro-F1 score of 1.0000 on both CPU and GPU with the complete-training partition. These findings demonstrate that the observed performance variation was strongly dependent on model initialisation rather than training-data volume alone. Nevertheless, the results remain specific to the evaluated DS2OS configurations and should not be interpreted as evidence of consistently high classification performance across independent IoT environments. XGBoost remains a promising candidate for further investigation, although its suitability for gateway- or edge-server-level anomaly detection requires additional evaluation of inference latency, hardware compatibility, and model-specific resource requirements.

The experiments were conducted using general-purpose computing platforms rather than physical IoT or edge hardware. GPU training was performed in Google Colab Pro, while the original CPU execution environment could not be independently confirmed. Further experiments on representative resource-constrained devices would therefore be required to assess on-device training feasibility in terms of execution time, memory requirements, and energy consumption. Algorithm-specific adjustments should also be investigated to improve deployment suitability. For Random Forest, class-rebalancing mechanisms should be evaluated to determine whether they can mitigate the majority-class bias observed in this study. Decision Tree deployment should account for the implementation-dependent performance differences observed between the evaluated CPU-based classifier and GPU-based single-tree proxy. XGBoost may be further optimised through hyperparameter tuning to reduce computational cost while preserving the strong detection performance observed under the evaluated configuration.

The use of a single benchmark dataset, DS2OS, limits the generalisability of the findings. Although DS2OS provides labelled multi-class IoT telemetry with significant class imbalance, it differs from other established IoT security datasets, such as BoT-IoT, TON_IoT, and CICIoT2023, in terms of traffic characteristics, feature representations, attack taxonomy, and class distribution. These differences may influence both model-training performance and classification effectiveness, particularly minority-class detection. Consequently, the strong classification results obtained for XGBoost, the majority-class bias observed in Random Forest and the recorded CPU-to-GPU training-time ratios should be interpreted within the evaluated DS2OS configurations rather than assumed to generalise across diverse IoT environments. Cross-dataset evaluation using additional established IoT security benchmarks, consistent preprocessing procedures and comparable model configurations is therefore necessary to assess the robustness and transferability of these findings.

5.7. Key Insights Gained

The findings contribute to understanding the computational, methodological, and practical characteristics of tree-based machine-learning approaches for IoT anomaly detection. From a computational perspective, the GPU-based implementations recorded shorter training times than their CPU counterparts under the evaluated experimental conditions. However, differences in hardware configurations, software implementations, and execution environments limit the extent to which these results can be attributed solely to GPU acceleration. System-level monitoring recorded approximately 21,448 MB of system RAM utilisation in the CPU environment and 7505 MB of GPU VRAM utilisation in the GPU environment. These measurements include potential contributions from the operating environment, Python runtime, loaded libraries, dataset storage, and other processes. They therefore do not represent model-specific memory consumption. Moreover, system RAM and GPU VRAM are distinct memory resources and cannot be directly compared to establish relative memory efficiency.

The energy analysis produced lower estimates for all three GPU implementations under fixed nominal power assumptions, reflecting their shorter training times. However, these estimates were not based on direct power measurements and remain sensitive to the assumed power values, workload-dependent consumption, virtualised resource allocation, and hardware power-management mechanisms. Consequently, no definitive conclusion regarding CPU-GPU energy efficiency can be drawn without direct power monitoring on controlled hardware.

From a classification perspective, the experiments revealed substantial differences in the algorithms’ responses to severe class imbalance. XGBoost achieved perfect recall across all seven minority attack categories in the evaluated test partition, whereas Random Forest predominantly predicted the benign class and failed to detect minority attacks. Decision Tree demonstrated intermediate performance, with significant differences between its CPU and GPU implementations. These findings emphasise the importance of algorithm selection and class-specific evaluation in IoT security applications, where detecting rare attacks is particularly important.

The initial experiments used 30% of the available training partition to reduce computational demand. Supplementary evaluations subsequently examined both 30% and 100% training configurations using repeated stratified cross-validation. Under automatic initialisation, XGBoost maintained near-perfect classification performance with 30% training data but exhibited lower and more variable macro-F1 scores when the complete-training partition was used. However, a subsequent controlled experiment using XGBoost 3.4.1 with a fixed initial prediction score (base_score = 0.5) eliminated this deterioration across all ten validation folds, achieving mean macro-F1 scores of 1.0000 on both the CPU and GPU under the complete-training configuration. These findings demonstrate the importance of model initialisation when interpreting classification performance and indicate that the initial deterioration should not be attributed to increasing training-data volume alone. Nevertheless, further validation using independent IoT datasets remains necessary to establish the robustness and generalisability of these findings.

Several limitations affect the interpretation and transferability of these findings. Although DS2OS provides a useful benchmark, it may not capture the behavioural diversity, evolving attack patterns or class distributions encountered in large-scale operational IoT networks. The virtualised experimental environment also limits hardware-level energy assessment. Furthermore, physical tampering, insider threats, and adversarial machine-learning attacks were outside the defined threat model. These constraints should be considered when assessing the applicability of the findings to real-world IoT deployments.

The experimental evaluation focused on model-training performance and classification effectiveness within the selected computational environments. Although the results provide insights into the computational behaviour of tree-based models across CPU and GPU implementations, inference latency and deployment performance were not experimentally evaluated on physical edge or IoT hardware. Consequently, the measured training-time improvements should not be interpreted as evidence of faster real-time inference or suitability for deployment on resource-constrained IoT devices. Such deployment scenarios involve additional considerations, including model size, available memory, processing capabilities, energy constraints, and communication overhead. Future work should evaluate inference latency, throughput, and resource utilisation on representative edge platforms, such as NVIDIA Jetson devices and CPU-based IoT gateways, to establish whether the observed computational advantages translate into practical deployment benefits.

6. Conclusions

This study compared CPU- and GPU-based implementations of lightweight tree-based machine-learning models for IoT anomaly detection, examining classification effectiveness and recorded training-time differences across the evaluated experimental configurations. The supplementary evaluation demonstrated that adjusting the GPU Decision Tree proxy’s sampling and feature-selection settings increased its mean macro-F1 to approximately 0.61, comparable to the CPU Decision Tree. This finding indicates that the original classification difference was substantially influenced by model configuration and should not be interpreted as an inherent disadvantage of GPU execution. While the virtualised experimental environment and assumption-based energy estimation introduce important limitations, the measured classification and training-time results remain informative within the evaluated DS2OS setting. However, the study does not establish energy-efficiency benefits or deployment suitability for physical low-power and edge devices, as direct power measurements and hardware-level deployment evaluations were not conducted.

Supplementary validation extended the original evaluation through alternative training proportions, stratified data partitions, duplicate-record analysis, feature-sensitivity assessment, and repeated cross-validation across the six CPU- and GPU-based implementations. The supplementary XGBoost evaluation initially revealed substantial performance deterioration with the complete-training partition under automatic initialisation. However, an additional controlled ten-fold experiment demonstrated that fixing the initial prediction score eliminated this deterioration within the evaluated configurations, producing mean macro-F1 scores of 1.0000 on both the CPU and GPU. These findings identify model initialisation as an important factor influencing the observed classification performance. Additional analyses indicated that timestamp information contributed substantially to classification performance, highlighting the potential influence of dataset-specific temporal patterns. These findings demonstrate the importance of evaluating model stability under different experimental configurations and investigating potential information leakage. Nevertheless, validation was restricted to DS2OS, and the generalisability of the results to independent IoT datasets and operational environments remains unestablished.

Future work will focus on improving the reliability and deployability of IoT intrusion detection by incorporating real-time energy measurement, evaluating model robustness under adversarial and concept-drift conditions, and developing imbalance-aware and resource-efficient learning techniques to support secure deployment on edge and GPU-enabled platforms.