H100 Tensor Core GPU

1. Executive Summary

This document provides a comprehensive technical analysis of NVIDIA's H100 Hopper architecture GPU, representing a landmark achievement in AI acceleration hardware. The H100 introduces three transformative innovations: (1) Transformer Engine with hardware-accelerated FP8 mixed precision for large language models, (2) DPX instructions enabling up to 40× acceleration for dynamic programming algorithms in genomics and graph optimization, and (3) 4th generation Tensor Cores delivering 4 PetaFLOPS of AI compute. These advances position H100 as the industry standard for training trillion-parameter models and serving inference at unprecedented scale.

2. 1. Architecture Overview and Core Innovations

2.1 1.1 Hopper SM (Streaming Multiprocessor) Architecture

The H100 implements 132 Streaming Multiprocessors (full die), each containing:

Computational Resources per SM:

• CUDA Cores: 128 FP32 cores + 64 FP64 cores
• 4th Gen Tensor Cores: 4 units per SM
• Special Function Units (SFU): 32 units
• Load/Store Units: 32 units
• Register File: 256 KB per SM
• L1/Shared Memory: 228 KB configurable partition

Aggregate Die Compute:

Peak Performance Calculation:

where $OP{S}_{cycle}=3,840$ operations per cycle for FP8 matrix multiply-accumulate in the 4th gen Tensor Core.

2.2 1.2 Memory Hierarchy and Bandwidth Analysis

Memory Subsystem:

• HBM3 Capacity: 80 GB (SXM5), 96 GB (variant)
• HBM3 Bandwidth: 3.0 TB/s (5 stacks × 600 GB/s)
• L2 Cache: 60 MB (unified)
• L1/Shared Memory: 228 KB per SM × 132 SMs = 30 MB total

Bandwidth Hierarchy:

Arithmetic Intensity for FP8 Tensor Operations:

This high arithmetic intensity necessitates data reuse strategies like tiling, which the Transformer Engine explicitly optimizes for attention mechanisms.

3. 2. Transformer Engine: Hardware-Accelerated LLM Training

3.1 2.1 Motivation and Problem Statement

Transformer Model Computational Challenge:

For a self-attention layer with sequence length $S$ and hidden dimension $D$:

Compute Complexity:

For GPT-3 scale models ($S=2048,D=12288$):

• $Q{K}^T$ multiplication: $2048^2\times 12288\approx 51$ GFLOPS per token
• Softmax: $2048^2$ elements requiring exp/div operations
• Output projection: $2048\times 12288\times 12288\approx 627$ GFLOPS

Memory Bandwidth Bottleneck:

Traditional FP16 attention stores intermediate $Q{K}^T$ matrix:

For a 96-layer model: $8.4\text{ MB}\times 96=806\text{ MB}$ of attention matrices alone.

3.2 2.2 Transformer Engine Architecture

Hardware Components:

Transformer Engine Architecture:
┌─────────────────────────────────────────────────────────────┐
│                   Transformer Engine                        │
├─────────────────────────────────────────────────────────────┤
│  ┌──────────────────────┐  ┌──────────────────────────┐    │
│  │  FP8 Tensor Cores    │  │  FP16 Accumulator Path   │    │
│  │  • E4M3 (Forward)    │  │  • 32-bit accumulation   │    │
│  │  • E5M2 (Gradients)  │  │  • Dynamic range check   │    │
│  └──────────────────────┘  └──────────────────────────┘    │
│                                                              │
│  ┌──────────────────────────────────────────────────────┐  │
│  │         Automatic Mixed Precision Controller         │  │
│  │  • Per-tensor scaling factors (FP32 stored)          │  │
│  │  • Dynamic loss scaling                               │  │
│  │  • Delayed scaling with exponential moving average   │  │
│  │  • Format conversion hardware (FP8 ↔ FP16 ↔ FP32)   │  │
│  └──────────────────────────────────────────────────────┘  │
│                                                              │
│  ┌──────────────────────────────────────────────────────┐  │
│  │         Attention Mechanism Accelerators             │  │
│  │  • Fused QKV projection (single kernel)              │  │
│  │  • Online softmax with max-subtraction stability     │  │
│  │  • Causal masking hardware support                   │  │
│  │  • Flash Attention integration                        │  │
│  └──────────────────────────────────────────────────────┘  │
└─────────────────────────────────────────────────────────────┘

3.3 2.3 FP8 Precision Formats

E4M3 (Forward Pass):

• 1 sign bit, 4 exponent bits, 3 mantissa bits
• Range: $[-448,448]$
• Suitable for activations with moderate dynamic range
• Higher precision around zero

E5M2 (Backward Pass/Gradients):

• 1 sign bit, 5 exponent bits, 2 mantissa bits
• Range: $[-57,344,57,344]$
• Wider dynamic range for gradient explosions
• Coarser precision but handles outliers better

Per-Tensor Scaling:

For a tensor $\mathbf{X}\in {\mathbb{R}}^{m\times n}$:

During matrix multiplication $\mathbf{C}=\mathbf{AB}$:

3.4 2.4 Dynamic Loss Scaling with Delayed Updates

Gradient Scaling Strategy:

Traditional loss scaling multiplies loss by constant $s_{loss}$. Transformer Engine implements delayed scaling:

Delayed Update Mechanism:

• Scaling factors updated every $N$ steps (typically $N=1000$)
• Avoids overhead of per-iteration updates
• Exponential moving average ($\beta =0.99$) smooths gradient statistics

3.5 2.5 Fused Attention Kernels

Standard Attention Memory Traffic:

Without fusion:

Total: $\approx 6SD+4S^2$ bytes

Fused Kernel Traffic:

Transformer Engine fuses projection + attention:

Speedup for GPT-3 Layer:

3.6 2.6 Flash Attention Integration

Transformer Engine incorporates Flash Attention 2 optimizations:

Algorithm:

1. Partition $Q,K,V$ into blocks: $Q=[Q_1,\dots ,Q_n],K=[K_1,\dots ,K_m]$
2. For each $Q_i$ block, iteratively compute:

Hardware Optimizations:

• SM shared memory holds $Q_i,K_j,V_j$ blocks (no DRAM round-trip for $S_{ij}$)
• On-chip max/sum computation for numerical stability
• Asynchronous global memory loads while computing attention scores

Complexity Reduction:

• I/O Complexity: $\mathcal{O}(S^2)$ → $\mathcal{O}(S^2/B)$ where $B$ is block size
• For $B=256$: $256\times$ reduction in HBM traffic

4. 3. DPX Instructions: Dynamic Programming Acceleration

4.1 3.1 Motivation and Use Cases

Dynamic Programming Characteristics:

• Overlapping subproblems: Results reused multiple times
• Optimal substructure: Optimal solution contains optimal subsolutions
• Recurrence relations: $DP[i][j]=f(DP[i-1][j],DP[i][j-1],\dots )$

Common Patterns:

Target Applications:

1. Genomics: Sequence alignment (Smith-Waterman, Needleman-Wunsch)
2. Graph Algorithms: Shortest paths (Floyd-Warshall, Bellman-Ford)
3. Optimization: Knapsack, longest common subsequence
4. Robotics: Motion planning, path finding

4.2 3.2 DPX Instruction Set Architecture

New Instructions:

DPX Instruction Primitives:
┌────────────────────────────────────────────────────────────┐
│  MAX3(a, b, c) → max(a, max(b, c))                         │
│  Latency: 1 cycle  |  Throughput: 128 ops/cycle/SM        │
├────────────────────────────────────────────────────────────┤
│  MIN3(a, b, c) → min(a, min(b, c))                         │
│  Latency: 1 cycle  |  Throughput: 128 ops/cycle/SM        │
├────────────────────────────────────────────────────────────┤
│  ADD_MAX(a, b, c) → a + max(b, c)                          │
│  Latency: 1 cycle  |  Throughput: 128 ops/cycle/SM        │
├────────────────────────────────────────────────────────────┤
│  ADD_MIN(a, b, c) → a + min(b, c)                          │
│  Latency: 1 cycle  |  Throughput: 128 ops/cycle/SM        │
├────────────────────────────────────────────────────────────┤
│  Supported Types: INT32, UINT32, INT16×2 (SIMD)            │
│  128 operations/cycle/SM × 132 SMs = 16,896 ops/cycle      │
└────────────────────────────────────────────────────────────┘

Per-SM Throughput:

4.3 3.3 Smith-Waterman Algorithm Acceleration

Algorithm Overview:

Smith-Waterman finds optimal local alignment between two sequences using:

where:

• $s(a_i,b_j)$ is substitution score
• $W_k$ is gap penalty

Traditional GPU Implementation:

// 4 instructions per cell:
int match = H[i-1][j-1] + score;
int delete_gap = H[i-1][j] - gap_penalty;
int insert_gap = H[i][j-1] - gap_penalty;
H[i][j] = max(0, max(match, max(delete_gap, insert_gap)));

DPX-Optimized Implementation:

// 2 instructions per cell using DPX:
int temp = ADD_MAX(H[i-1][j-1], score, 0);  // match + max with 0
H[i][j] = MAX3(temp, H[i-1][j] - gap_penalty, H[i][j-1] - gap_penalty);

Computational Savings:

Measured Speedup:

• Single H100 vs A100: 7.8× for DNA sequences up to 10,000 base pairs
• 4× H100 vs 4× A100: 35× (includes NVLink scaling efficiency)

4.4 3.4 Floyd-Warshall Algorithm Acceleration

Algorithm:

All-pairs shortest paths in graph with $N$ vertices:

Complexity:

• Time: $\mathcal{O}(N^3)$
• $N^3$ min operations

Traditional Implementation:

for (int k = 0; k < N; k++)
  for (int i = 0; i < N; i++)
    for (int j = 0; j < N; j++)
      dist[i][j] = min(dist[i][j], dist[i][k] + dist[k][j]);
      // 2 instructions: add + min

DPX-Optimized:

dist[i][j] = ADD_MIN(dist[i][k], dist[k][j], dist[i][j]);
// 1 fused instruction

Performance:

• 4× H100 configuration: 40× speedup vs CPU (64-core AMD EPYC)
• Handles graphs with $N=8,192$ vertices in <1 second

4.5 3.5 Genomic Variant Calling Pipeline

Real-World Impact:

Genomic analysis pipeline for cancer diagnosis:

1. Sequence Alignment (Smith-Waterman): 30 million reads × 3 billion base pairs
2. Variant Calling: Identifying mutations from alignment
3. Annotation: Mapping mutations to known cancer markers

Traditional CPU Cluster:

• 64-core × 8-node cluster
• Time: ~4 hours per genome

H100 with DPX:

• 4× H100 GPUs
• Time: ~20 minutes per genome
• 12× cost reduction in cloud compute

5. 4. Thread Block Clusters and Distributed Shared Memory

5.1 4.1 Thread Block Cluster Architecture

Motivation:

Traditional CUDA model:

• Thread blocks execute independently
• No inter-block synchronization on-chip
• Limits cooperative algorithms (e.g., block-wide reductions)

Thread Block Cluster (TBC) Innovation:

Groups of thread blocks (typically 8-16) with:

• Shared scratchpad memory across blocks
• Cluster-wide synchronization primitives
• Enhanced SM-to-SM communication

Thread Block Cluster Organization:
┌───────────────────────────────────────────────────────┐
│                Thread Block Cluster                    │
│  (spans multiple SMs)                                  │
├───────────────────────────────────────────────────────┤
│  ┌──────────┐  ┌──────────┐  ┌──────────┐           │
│  │ SM 0     │  │ SM 1     │  │ SM 2     │           │
│  │ Block 0  │  │ Block 1  │  │ Block 2  │           │
│  │ SMEM 228K│  │ SMEM 228K│  │ SMEM 228K│           │
│  └──────────┘  └──────────┘  └──────────┘           │
│        │              │              │                │
│        └──────────────┼──────────────┘                │
│                       ▼                                │
│            Distributed Shared Memory                   │
│            (accessible across cluster)                 │
│            Total: 228K × cluster_size                  │
└───────────────────────────────────────────────────────┘

Programming Model:

__global__ void __cluster_dims__(8, 1, 1) kernel() {
    // Allocate distributed shared memory
    __shared__ int local_smem[1024];
    
    // Access another block's shared memory
    int* remote_smem = cluster::map_shared_rank(local_smem, target_block_id);
    
    // Cluster-wide synchronization
    cluster::sync();
}

5.2 4.2 Use Case: Multi-Block Reduction

Traditional Approach:

1. Each block reduces to shared memory
2. Write partial results to global memory
3. Launch second kernel to reduce partial results

Cluster Approach:

1. Each block reduces locally
2. Leader block reads all partial results from distributed shared memory
3. Final reduction in single kernel

Performance:

• Eliminates global memory round-trip
• 2-3× speedup for reductions in attention softmax

6. 5. Asynchronous Transaction Barrier and Memory Pipelining

6.1 5.1 Memory Copy-Compute Overlap

Problem:

Traditional CUDA: synchronous global memory loads block compute:

__shared__ float tile[TILE_SIZE][TILE_SIZE];
// GPU idles during this copy:
memcpy_async(tile, global_ptr, size);
__syncthreads();  // Wait for copy completion
compute(tile);    // Only now can we compute

Asynchronous Barrier Solution:

__shared__ float tile[2][TILE_SIZE][TILE_SIZE];
cuda::barrier barrier;
 
// Stage 0: Initiate first load
barrier.arrive();
memcpy_async(tile[0], global_ptr, size, barrier);
 
for (int stage = 1; stage < N; stage++) {
    // Prefetch next tile
    barrier.arrive();
    memcpy_async(tile[stage % 2], global_ptr + stage * size, size, barrier);
    
    // Compute on previous tile (overlapped with load)
    compute(tile[(stage - 1) % 2]);
    
    barrier.wait();  // Wait only when we need the data
}

Speedup for Transformer Layers:

• Memory-bound operations (layernorm, embedding): 1.8× speedup
• Hides $\approx 70\%$ of global memory latency

7. 6. Confidential Computing and Multi-Instance GPU (MIG)

7.1 6.1 Confidential Computing Architecture

Threat Model:

Cloud AI workloads require protection from:

• Malicious hypervisor/cloud provider
• Other tenants on same physical GPU
• Memory sniffing attacks on NVLink fabric

H100 Trusted Execution Environment (TEE):

Confidential Computing Stack:
┌──────────────────────────────────────────────────────┐
│          User Workload (Encrypted)                    │
├──────────────────────────────────────────────────────┤
│  Hardware Root of Trust                               │
│  • On-die AES-256-GCM encryption engine               │
│  • Per-tenant HBM memory encryption                   │
│  • Encrypted NVLink transfers                         │
│  • Attestation via SPDM protocol                      │
└──────────────────────────────────────────────────────┘
│
▼ (encrypted at rest and in-flight)
┌──────────────────────────────────────────────────────┐
│  HBM3 Memory (80 GB)                                  │
│  NVLink Fabric (900 GB/s)                             │
└──────────────────────────────────────────────────────┘

Performance Overhead:

• Encryption/decryption: <3% throughput impact
• Enables secure multi-tenant AI serving

7.2 6.2 Multi-Instance GPU (MIG)

Partitioning Scheme:

H100 can be divided into up to 7 independent instances:

Isolation Guarantees:

• Dedicated HBM memory partition (no shared allocation)
• Separate L2 cache slices
• QoS-enforced compute scheduling
• Independent fault domains

Multi-Tenant Serving:

• 7 concurrent users each get guaranteed resources
• No performance interference between tenants
• 7× better GPU utilization in inference workloads

8. 7. NVLink 4.0 and Scale-Out Performance

8.1 7.1 NVLink 4.0 Architecture

Per-GPU Bandwidth:

• 18 NVLink lanes × 50 GB/s per lane = 900 GB/s total
• Bidirectional: 450 GB/s each direction
• 3× faster than PCIe Gen5 (128 GB/s)

DGX H100 System:

• 8× H100 GPUs
• Full NVLink connectivity (all-to-all)
• Aggregate bisection bandwidth: 3.6 TB/s

NVLink Switch (NVSwitch 3.0):

• 64 ports × 50 GB/s = 3.2 TB/s per switch
• Enables non-blocking topology for 256 GPUs
• Pod-level scaling to 1,000+ GPUs

8.2 7.2 Multi-GPU Training Efficiency

Data Parallel Training:

For model with $P$ parameters, batch size $B$, and $N$ GPUs:

All-Reduce Gradient Communication:

For GPT-175B ($P=175\times 10^9$):

Overlap with Backward Pass:

• Backward pass: $\approx 5$ seconds
• Communication fully overlapped: 0% overhead

Scaling Efficiency:

• 8 GPUs: 95% scaling efficiency
• 64 GPUs (8× DGX): 92% scaling efficiency
• 256 GPUs (4× SuperPODs): 87% scaling efficiency

9. 8. Performance Analysis and Benchmarks

9.1 8.1 Large Language Model Training

GPT-3 175B Training (Mixed FP8/FP16):

Key Contributors to Speedup:

• FP8 Tensor Cores: 2.0×
• Transformer Engine (fused kernels): 2.2×
• HBM3 bandwidth: 1.5×
• Improved SM utilization: 1.3×

9.2 8.2 Inference Serving Throughput

BERT-Large Inference (Sequence Length 384):

FP8 Inference Advantages:

• 2× smaller model footprint (175B params: 350 GB → 175 GB)
• 2× higher batch throughput at same latency
• 30× better throughput/watt than CPU

9.3 8.3 Scientific Computing: Molecular Dynamics

GROMACS Benchmark (Protein Simulation):

Acceleration Sources:

• FP64 Tensor Cores: 34 TFLOPS (vs 19.5 TFLOPS A100)
• HBM3 bandwidth for particle neighbor lists
• Improved L2 cache for spatial locality

10. 9. Power Efficiency and TCO Analysis

10.1 9.1 Performance per Watt

Training Efficiency (GPT-3 Scale):

Inference Efficiency (BERT-Large):

10.2 9.2 Total Cost of Ownership (3-Year Cloud Deployment)

Assumptions:

• Cloud pricing: $2.50/GPU-hour (typical hyperscaler)
• Training: GPT-175B from scratch (300B tokens)
• Inference: 10M queries/day sustained

Training TCO:

Inference TCO (3 years):

11. 10. Competitive Positioning and Industry Impact

11.1 10.1 vs AMD MI250X

Market Reality: 95%+ of AI training runs on NVIDIA. H100 solidifies dominance.

11.2 10.1 vs Google TPU v4

Use Case Differentiation:

• TPU v4: Optimized for Google's internal models (BERT, PaLM)
• H100: Industry standard for custom models, research, multi-framework support

11.3 10.3 Industry Adoption

Deployed Infrastructure (as of 2024):

• Microsoft Azure: 100,000+ H100 GPUs for OpenAI GPT-4, Copilot
• AWS: H100 instances (p5.48xlarge) for enterprise AI
• Google Cloud: H100 VMs alongside TPU offerings
• Oracle Cloud: HPC clusters with H100 for genomics
• Meta: 16,000+ H100 GPUs for Llama training
• Startups: Anthropic (Claude), Cohere, Inflection AI

Market Impact:

• Enables GPT-4 class models (1T+ parameters)
• Democratizes LLM fine-tuning (LoRA on H100 vs full training on A100)
• Genomics revolution: Real-time variant calling in clinical settings

12. 11. Programming Model and Software Ecosystem

12.1 11.1 Transformer Engine API

PyTorch Integration:

import transformer_engine.pytorch as te
 
# Automatic mixed precision with FP8
with te.fp8_autocast(enabled=True):
    # Standard PyTorch operations automatically use FP8
    output = model(input_ids)
    loss = criterion(output, labels)
    loss.backward()
 
# Per-tensor scaling is handled automatically

TensorFlow Integration:

import transformer_engine.tensorflow as te
 
# Wrap model layers with TE equivalents
model = tf.keras.Sequential([
    te.LayerNormalization(),
    te.Linear(512, 2048),  # Automatically uses FP8 Tensor Cores
    te.GELU(),
])

12.2 11.2 DPX CUDA API

Smith-Waterman Example:

#include <cuda_dp.h>
 
__global__ void smith_waterman_dpx(
    const char* seq_a, const char* seq_b, 
    int* H, int N, int M
) {
    int i = blockIdx.x * blockDim.x + threadIdx.x;
    int j = blockIdx.y * blockDim.y + threadIdx.y;
    
    if (i < N && j < M) {
        int match_score = (seq_a[i] == seq_b[j]) ? 2 : -1;
        int match = H[(i-1)*M + (j-1)] + match_score;
        
        // Single DPX instruction replaces 3 operations:
        H[i*M + j] = __dpx_max3(
            0, 
            match, 
            __dpx_add_max(
                H[(i-1)*M + j], 
                H[i*M + (j-1)], 
                -1  // gap penalty
            )
        );
    }
}

12.3 11.3 Thread Block Cluster Example

Distributed Reduction:

#include <cuda/barrier>
 
__global__ void __cluster_dims__(8, 1, 1) 
clustered_reduction(float* data, float* result) {
    __shared__ float partial_sum;
    
    // Local reduction
    float thread_sum = 0;
    for (int i = threadIdx.x; i < N; i += blockDim.x)
        thread_sum += data[i];
    atomicAdd(&partial_sum, thread_sum);
    
    __syncthreads();
    
    // Leader block collects from all blocks in cluster
    if (threadIdx.x == 0) {
        float cluster_sum = partial_sum;
        
        for (int rank = 1; rank < 8; rank++) {
            float* remote_sum = cluster::map_shared_rank(&partial_sum, rank);
            cluster_sum += *remote_sum;
        }
        
        if (cluster::this_block_rank() == 0)
            *result = cluster_sum;
    }
}

13. 12. Future Roadmap and Implications

13.1 12.1 Post-Hopper Architectures

Blackwell (H200, successor announced 2024):

• 20 PetaFLOPS FP4 (new precision)
• 192 GB HBM3e @ 4.8 TB/s
• 2nd generation Transformer Engine
• Enhanced MIG with finer partitioning

Rubin (Expected 2025-2026):

• Chiplet-based design for yield/cost
• Optical interconnects for rack-scale systems
• 10× AI performance per socket

13.2 12.2 Implications for AI Research

Enabled Research Directions:

1. Trillion-parameter models: H100 makes GPT-4 class models accessible to more orgs
2. Multimodal LLMs: Video-language models feasible with HBM3 capacity
3. Real-time genomics: DPX enables personalized medicine at scale
4. Federated learning: MIG allows multi-tenant secure training

Industry Shifts:

• Inference-first deployments: FP8 enables cost-effective LLM serving
• Open-source LLMs: Llama 2, Falcon trained on H100 clusters
• Scientific AI: Protein folding, drug discovery accelerated 10×

14. 13. Conclusion

The NVIDIA H100 Hopper architecture represents a watershed moment in AI hardware, introducing three transformative innovations that redefine performance boundaries:

1. Transformer Engine: Hardware-accelerated FP8 mixed precision delivers 9× faster training for large language models, enabling the current generation of GPT-4 class systems while reducing inference costs by 30×.

2. DPX Instructions: Purpose-built dynamic programming acceleration achieves 40× speedup for genomic algorithms, bringing real-time sequencing and personalized medicine from research labs to clinical practice.

3. 4th Generation Tensor Cores: 4 PetaFLOPS of AI compute combined with 3 TB/s HBM3 bandwidth establishes new standard for datacenter AI infrastructure, with 5× better performance-per-watt than previous generation.

Beyond raw performance, H100's confidential computing and Multi-Instance GPU capabilities address the operational realities of production AI deployments: multi-tenancy, security, and cost efficiency. The result is an architecture that not only trains state-of-the-art models faster but also serves them at unprecedented scale, cementing NVIDIA's position as the infrastructure foundation for the AI era.

As trillion-parameter models become standard and AI applications span from genomics to autonomous systems, H100's architectural innovations will be studied as the blueprint that made these advances economically viable and operationally practical.

15. References and Further Reading

1. NVIDIA H100 Tensor Core GPU Architecture Whitepaper, NVIDIA Corporation, 2022
2. DPX Instructions Programming Guide, NVIDIA CUDA Documentation, 2022
3. Transformer Engine: Hardware-Accelerated Training, NVIDIA Technical Blog, 2023
4. Flash Attention 2: Faster Attention with Better Parallelism, Dao et al., 2023
5. Smith-Waterman Algorithm Acceleration on GPUs, Hopper Tuning Guide, NVIDIA, 2022
6. MLPerf Training v3.0 Results, MLCommons, 2023 (H100 records)
7. Multi-Instance GPU User Guide, NVIDIA Data Center Documentation, 2023
8. NVLink and NVSwitch: High-Speed GPU Interconnect, NVIDIA Networking, 2022
9. Confidential Computing with NVIDIA Hopper, NVIDIA Security Documentation, 2023
10. GPT-3 Training at Scale, Brown et al., 2020 (baseline for H100 comparisons)

Document Version: 1.0
Last Updated: October 2, 2025
Status: Comprehensive Technical Analysis
Classification: Public / Educational Use