DEV Community: dima853

I made a sign with brief explanations of the terms from LLDP

dima853 — Fri, 17 Oct 2025 12:22:55 +0000

This document (8021AB-2016) is the official standard for the LLDP protocol, which allows network devices to automatically find each other and exchange service information. All these acronyms are integral parts of this standard, which describe exactly how devices "get to know" each other on the network.

In Russian - https://gist.github.com/dima853/54ae0137ef51220c0ab9c7db40a12dbb
In English - https://github.com/dima853/self_university/blob/main/network/osi/L2/8021AB-2016/acronyms.md

More- https://t.me/dima853_code

INLINE vs. NORMAL FUNCTIONS: What's Really Happening in Assembly?

dima853 — Fri, 10 Oct 2025 15:22:50 +0000

🔥 INLINE vs. NORMAL FUNCTIONS: What's Really Happening in Assembly?

All sources (code, etc.) - https://github.com/dima853/self_university/tree/main/network/c/fucntions/inline

Everyone talks about 'inline', but few have seen the difference in real assembly. See:

🎯 With INLINE — code is INSERTED directly:

test_with_inline:
movl (%rdi), %r8d # Byte comparison
cmpl (%rsi), %r8d # ← code INSERTED!
je .L18

movl (%rsi), %ecx
cmpl (%rdx), %ecx # ← INSERTED again!
je .L19

The gist: The compiler COPYS the function code to each call site.

🐌 WITHOUT INLINE — CALLS to the function:

test_without_inline:
call mac_equals_normal # ← JUMP into the function!
movzbl %al, %ecx

call mac_equals_normal # ← JUMP AGAIN!
movl %eax, %esi

The gist: Each call is a jump to a different memory location

🍔 SIMPLE ANALOGY:

Without inline = "Courier: you → courier → restaurant → courier → you"
With inline = "Microwave: you → microwave → done!"

⚡ RESULT:

With inline: ~4 instructions per comparison
Without inline: ~20+ instructions (call + return)

🎯 CONCLUSION:

inline is when the compiler stops "sending the courier" and starts "microwave" right there!

Command for testing:

gcc -S -O2 test.c -o test.s

programming #C #assembler #optimization #inline #compiler

🛡️ OCTAL ACCESS RIGHTS IN LINUX: A COMPLETE GUIDE

dima853 — Fri, 10 Oct 2025 13:16:04 +0000

Everything you need to know about permissions: from basic RWX to advanced scenarios with setuid, setgid and sticky bit
• 100+ practical examples
• Ready-to-use solutions
• From basics to production security

in Russian/English - https://t.me/dima853_code/111

Linux #DevOps #SysAdmin #Permissions #Security #Guide

I'm creating a social network that is not hacable, trackable, or censored - by design.

dima853 — Fri, 10 Oct 2025 13:13:15 +0000

Hello everyone, I recently created a tg channel, where I will do the following

Subscribe - https://t.me/dima853_code

A DETAILED article about NullPointerException in java will be released soon.

I also made a detailed guide about octal access rights in Linux.

Here -> https://t.me/dima853_code/111

I'm creating a social network with full control over the stack. From the transcendental bridge at the L2 level to the UI components. No ready-made solutions in critical places.

I'm studying security, cryptography, low-level, network programming, and backend. I'm documenting the path to zero-to-one engineering. Posts about science, code, and hardware.

What I'm doing:
• Writing a social network on my own engines
• Digging into Linux, hardware, networks, and cryptography
• Solving LeetCode (373+ problems, 2 problems every day)
• Studying math and CS theory for practical application

What I will share:
• Architectural solutions for social networks
• Scientific notes (crypt, theorver, algorithms)
• Low-level optimization (C, assembler)
• Analysis of complex system problems
• Detailed analysis of hardware

Links:
GitHub: https://github.com/dima853
LeetCode: https://leetcode.com/u/dima853
Telegram - https://t.me/dima853_code
LinkedIn: https://linkedin.com/in/dima853

Goal: Disassemble the internet into atoms and put it back together.

2.3.2 - 2.3.5 Concepts (System Performance Brendan Gregg 2nd)

dima853 — Fri, 11 Jul 2025 11:45:13 +0000

2.3.3 Trade-Offs

Trade-offs in IT: "Pick two" and performance optimization

The image illustrates the classic principle "Good, Fast, Cheap — choose two", adapted for IT projects:

High performance (High-Performance)
Deadlines (On-Time)
Budget (Inexpensive)

They usually choose "On-Time+ Inexpensive", sacrificing performance, which leads to problems:

Suboptimal storage architecture.
Inefficient programming languages.
Lack of tools for performance analysis.

1. Key trade-offs in IT

(1) CPU vs Memory

In-memory caching → reduces CPU load, but requires more RAM.
Data compression → saves memory, but increases CPU load.

Example:

Redis (in-memory cache) vs PostgreSQL (page compression).

(2) File System block Size

Small block (4 KB)	Large block(64 KB)
Better for random I/O operations	Better for streaming reads/writes
Uses cache more efficiently	Speeds up backups

(3) Network Buffer size

Small buffer	Large buffer
Less memory load	Higher bandwidth

2. Where is it more efficient to adjust performance?

The closer the setting is to the application level, the greater the effect.:

Level	Examples of optimizations	Potential gain
Application	Optimization of SQL queries and logic	Up to 20x
Database	Indexes, partitioning	Up to 5x
File system	Configuring the cache, block size	Up to 2x
Storage	RAID, SSD vs HDD	Up to 1.5x

** Why?**

An application-level fix eliminates work at all lower levels of the stack.

3. Problems of modern approaches

The race for functionality:
- Developers focus on correctness, not performance.
- Performance problems are detected already in production.
Cloud environments:
Frequent updates (weekly/daily) complicate long-term monitoring.
- It is important to monitor the OS, even if the problem is in the application.

4. Practical advice

(1) For developers

Profile the code before release (for example, perf for Linux, VTune for Intel).
Avoid N+1 queries in databases.
Cache hot data (Redis, Memcached).

(2) For admins

Set up OS monitoring (Prometheus + Grafana for CPU/RAM/I/O metrics).
Optimize block sizes for load (for example, ext4 with bs=64k for DBMS).
Use modern storage (NVMe for high-load systems).

Conclusion

Sacrifice one of the three: speed, quality, or cost.
Optimize at the application level — this gives maximum effect.
Monitor the OS, even if the problem seems to be "applied".

"Late optimization is the root of all evil. But even worse is blind optimization without measurements."

— Adaptation of a quote by Donald Knuth

Optimizing block size for PostgreSQL: how to choose and why?

The size of a block (page) in PostgreSQL critically affects performance. Let's figure out how to choose it correctly for your workload.

1. What is a "block" in PostgreSQL?

Standard size: 8 KB (can be changed from 1 to 32 KB during compilation).
One page = 1 block = minimum unit of I/O operations.
Stores: table rows, indexes, metadata.

2. How does block size affect performance?

Small block (4 KB)	Large block (16-32 KB)
✅ Better for OLTP (lots of random reads/writes of short strings)	✅ Better for analytical queries (scanning large ranges)
❌ Accesses disk more often (less data per 1 I/O)	❌ Spends memory on empty areas if the rows are small

Example:

If you have a chat app (lots of inserts/updates of short messages) — 8 KB optimal.

For Data Warehouse (large table analytics) — 16-32 KB will speed up `SELECT * FROM large_table'.

3. How can I check my current performance?

Diagnostic requests:
`sql
-- Average row size in the table
SELECT avg(pg_column_size(t.*)) FROM my_table t;

-- How many blocks are "empty" (low occupancy)
SELECT relname, 100 - (pg_relation_size(oid) / (8192 * relpages) * 100) AS "empty_space_%"
FROM pg_class WHERE relkind = 'r';
`
If `empty_space_%' is > 30%, it may be worth reducing the block size.

4. How can I change the block size?

Only when compiling PostgreSQL (setting --with-blocksize=16 in ./configure).
Cannot be changed for an existing database — only create a new cluster with a different size:

   initdb -D /path/to/new/data --block-size=16384

Data transfer: Use pg_dump/`pg_restore'.

5. Optimal values for different scenarios

Load type	Recommended unit	Arguments
OLTP (short transactions)	8 KB	Minimizing overhead
Analytics (large scans)	16-32 KB	Reducing the number of I/O operations
Mixed load	8 KB	Read/Write balance

6. What else affects I/O efficiency?

TOAST: PostgreSQL automatically compresses/separates large fields (> 2 KB).
Fillfactor: Setting the page occupancy (for example, 90 for frequently updated tables).
File system: 'XFS or ZFS with the setting bs=16k` to match PostgreSQL.

Conclusion

8 KB is a safe choice for most cases.
16+ KB — only for post-test analytics.
Before changing: Measure the current efficiency via 'pg_stat_io'.

Tip: For cloud databases (RDS, Cloud SQL), the block size is fixed — choose instances with preset values for your load.

The level of depth of performance analysis: when to stop?

Productivity is a balance between analysis costs and potential benefits. Let's look at how to determine the optimal level of effort for your project.

1. "Adequate level" of analysis: from startups to HFT

Organizations have different approaches to performance analysis depending on ROI (return on investment):

Company type	The level of analysis	Examples
Startups	Surface monitoring (CloudWatch, Sentry)	Checking API latency and alerts
Corporations	Deep analysis (perf, eBPF, CPU PMC)	Linux kernel optimization, simulation
HFT / Exchanges	Extreme optimization (nanoseconds)	Laying cables for $300 million to save 6 ms

Key principle: > "Adequate level" is when ** the cost of the analysis is less than the potential benefit**.

2. When should I stop the analysis?

Scenarios for stopping:

** The main reason is explained**
Example: A Java application eats CPU. We found exceptions that explain 12% of the load. But since slowdown 3x, we're looking further.
- Rule: We stop if we find >66% problems.
ROI is less than the cost of analysis
Optimization of a microservice that saves $100/year is not worth 10 hours of an engineer's work.
- Exception: If the problem is a "canary" for future disasters (for example, memory leak).
There are more important tasks
- Even if the problem is not completely clear, there are critical bugs elsewhere.

3. Recommendations "at a given time"

Performance settings ** become obsolete** after:

Hardware upgrades (for example, switching from 10 Gbit/s to 100 Gbit/s).
Software updates (the new version of PostgreSQL may change the optimal `shared_buffers').
Growth in the number of users.

How to avoid mistakes:

Do not copy tunings from the Internet blindly. Example: nginx # Old recommendation for Linux 2.6: net.ipv4.tcp_tw_reuse = 1 # May be harmful in modern kernels!
Version the settings (Git + annotations like: "Increased vm.swappiness=10 due to swap load in 2023-01").

4. Practical rules

For startups

Minimum: Latency/error monitoring (New Relic, Datadog).
Optimum: Once a quarter — deep check of slow queries and caching.

For corporations

Permanent team of performance engineers.
Tools:
perf/`eBPF' — for core analysis.
- Load forecasting (for example, via ML).

For HFT/Exchanges

Hard SLA: Every microsecond is money.
Investments: Custom network stacks, FPGA instead of CPU.

5. Checklist "Where to stay?"

Have you found the cause of >50% of the problem? → Stop, we're fixing.
Do the remaining hypotheses take a disproportionate amount of time? → Postpone.
Are there more important tasks with high ROI? → Switch to.

Metric: If the analysis takes longer than the potential savings, you have overdone it.

Conclusion

The depth of the analysis depends on budget and risks.
Tuning is outdated — document the changes.
80/20 rule: 20% of efforts give 80% of the result.

Case study:
After updating the AWS instance from m5.large to m6i.xlarge', the oldkernel.schedul_migration_cost_ns` settings began to slow down the application. Solution: reset the parameters to default + measurements under load.

2.2 - 2.3.2 Models/Concepts (System Performance Brendan Gregg 2nd)

dima853 — Fri, 11 Jul 2025 11:42:49 +0000

2.2 Models

2.2.1 System Under Test

It is important to consider the impact of perturbations (interventions) on test results! 🔍

Perturbations are unexpected or background interventions that can distort the results of system performance measurements. They may occur due to:

planned system activity (for example, automatic updates, backups),
actions of other users (if the system is multiuser),
competing workloads (other applications or virtual machines in the cloud).

🌩 Special difficulties in cloud environments

In cloud infrastructures (AWS, Azure, GCP, etc.), a physical host can serve multiple virtual machines (VMs). The activity of neighboring VMs ("noisy neighbors") can affect your system, but remain invisible from inside your test environment (SUT, System Under Test). This is called the "noisy neighbor problem" — and it can seriously distort benchmark results!

🧩 The complexity of modern distributed systems

Modern environments often consist of many components:

Load balancers (Nginx, HAProxy)
Proxies and caching servers (Varnish, Redis)
Web and app servers (Apache, Node.js)
Databases (PostgreSQL, MongoDB)
Network Storage (AWS S3, Ceph)

Each of these elements can make its own perturbations! For example, the cache can mask the real load on the database, and network delays can affect the response time.

🔎 How to minimize the impact of perturbations?

Careful mapping of the environment — draw up a diagram of all system components.
Isolation of the test environment — use dedicated resources whenever possible.
Monitoring of background processes (for example, via top, `htop', Prometheus).
Statistical analysis — multiple test runs and averaging of results.

🚀 Conclusion: Perturbations are the hidden enemy of accurate measurements. Always analyze the environment, isolate the interference and check the results several times!

2.2.2 Queueing System

Deep analysis: Modeling queues, Delays, and System Performance

📊 Modeling components as queue systems

Many elements of the IT infrastructure (disks, CPUs, network interfaces) can be represented as queuing systems (queuing systems). This allows you to predict their behavior under load!

🔹 Example with disks:

As the load increases, the disk response time increases non-linearly due to the queue of requests.
The M/M/1 model (exponential service time and one handler) is often used to predict delays.

Practical application: If your disk is serving 100 IOPS, but 150 requests per second are coming, the queue will grow, and latency will skyrocket! ☄️

What is M/M/1? (In simple words)

https://en.wikipedia.org/wiki/M/M/1_queue

Imagine that:

M: Customers arrive randomly. It's like people walk into a store and you can't predict in advance when the next customer will arrive. This is called a Poisson process, and it describes random events occurring in time.
/M/: Each customer's service takes a random amount of time. It is as if the cashier in the store serves each customer for a different amount of time (depends on the number of goods, etc.). The service time is also described by a Poisson process (exponential distribution).
/1 Questioner: we have one server (or cashier). Only one person can serve customers at a time.

As a result: M/M/1 is a simple queue model where customers arrive randomly, are serviced at random times, and there is only one service machine.

Real-life analogies

There is a queue in the store at one cashier: Customers come to the store at different times, everyone has their own basket of goods, and the cashier serves everyone at different speeds.
Calls to a call center with one operator: Calls arrive randomly, each call takes a different time (depending on the problem), and there is only one operator to take the call.
Request processing on a single-processor web server: Users send requests to the server randomly, each request takes different time to process, and the server has only one processor.

Key parameters of the M/M/1 model

To understand how the M/M/1 model works, we need the following parameters:

λ (lambda) is the intensity of the arrival flow: How many customers arrive on average per unit of time. For example, 10 clients per hour.
µ (mu) is the intensity of the service flow: How many clients the server can handle on average per unit of time. For example, 15 clients per hour.

Important: If λ > μ, the queue will grow indefinitely! The server will not be able to handle the flow of clients. In order for the queue to be stable, p = λ / μ (load factor) must be less than 1. p indicates how much of the time the server is busy servicing.

What does p = λ / μ < 1 (load factor) mean?

r (ro): This is the load factor. It shows how much of the time the server is busy working. It is calculated as λ / μ.

If p < 1, it means that the server is serving clients faster than they arrive. In our example:

λ = 10 clients per hour
μ = 15 clients per hour

- ρ = 10 / 15 = 0.67

Here p is less than 1 (0.67 < 1). This means that the cashier is busy only 67% of the time. He has time to relax between clients. The queue will be stable because the cashier manages to serve customers.

Key performance indicators

The M/M/1 model allows us to estimate the following indicators:

r (load factor): How much of the time is the server busy? ρ = λ / μ. If p = 0.8, the server is busy 80% of the time.
p₀ (probability of system downtime): What is the probability that there are no clients in the system? P₀ = 1 - ρ. If p = 0.8, then p₀ = 0.2, that is, the server is idle 20% of the time.
L (average number of clients in the system): How many customers are in the system on average (queued + serviced)? L = λ / (μ - λ).
Lq (average number of customers in the queue): How many customers are in the queue on average? Lq = ρ * L = (λ²)/(μ(μ - λ)).
W (average time spent by the client in the system): How much time does the client spend in the system (in the queue + on maintenance)? W = 1 / (μ - λ). (W = L/λ).
Wq (average waiting time for a customer in the queue): How much time does the customer spend in the queue? Wq = ρ / (μ - λ). (Wq = Lq/λ).

Formulas for calculation (if you are interested)

Here are some formulas for calculating these indicators. But don't be scared, the main thing is to understand the concept.

ρ = λ / μ
P₀ = 1 - ρ
L = λ / (μ - λ)
Lq = (λ²)/(μ(μ - λ))
W = 1 / (μ - λ)
Wq = λ / (μ(μ - λ))

Calculation example (simple)

Let's say 10 customers come to the store per hour (λ = 10) and the cashier serves 15 customers per hour (μ = 15).

ρ = 10 / 15 = 0.67. The server is loaded at 67%.
p₀ = 1 - 0.67 = 0.33. The probability that the cashier is free is 33%.
L = 10 / (15 - 10) = 2. On average, there are 2 customers in the store (in line or at the checkout).
Lq = (10 * 10) / (15 * (15 - 10)) = 1.33. On average, there are 1.33 customers in the queue.
W = 1 / (15 - 10) = 0.2 hours = 12 minutes. The average customer spends 12 minutes in the store.
Wq = 10 / (15 * (15 - 10)) = 0.133 hours = 8 minutes. On average, a customer waits in line for 8 minutes.

Advantages of the M/M/1 model

Simplicity: Easy to understand and use.
Applicability: Describes many real systems.
Usefulness: Helps to evaluate system performance, design new systems, and optimize existing ones.

Limitations of the M/M/1 model

Random nature: Assumes random customer arrivals and random service times. In reality, this is not always the case.
One server: Not suitable for systems with multiple servers.
Does not take into account priorities: Does not take into account the priorities of customers.

Conclusion

The M/M/1 model is a powerful tool for understanding and analyzing queues. Knowing its basics, you can evaluate how to improve customer service, reduce waiting times, and improve the efficiency of various systems. I hope it's clearer to you now! If you have any questions, don't hesitate to ask! ☕

⏱️ Latency is the Queen of Metrics

The delay is the waiting time before performing the operation. It looks different in different contexts.:

🌐 Network examples:

DNS Latency: Domain name resolution time (for example, google.com → IP address).
TCP Connection Latency: Connection setup delay (3-way handshake).
HTTP Request Latency: The time from sending the request to receiving the first byte of the response (TTFB).

🔢 Why is latency more important than IOPS?

IOPS (Input/Output Operations Per Second) shows only the number of operations, but not their execution speed.
Latency is measured in time units (ms, µs), which allows you to:
Compare heterogeneous systems (network vs. disk).
- Accurately assess the impact of optimizations.

Example*:

100 network I/O with a delay of 100 ms = 10,000 ms in total.
50 disk I/O with a delay of 50 ms = 2,500 ms. Conclusion: the disk is 4 times faster!

📏 Table of time units

It is important to use the correct units for accurate measurements.:

Unit	Reduction	Fraction of a second
Millisecond	ms	0.001 (10-3)
Microsecond	µs	0.000001 (10⁻⁶)
Nanosecond	ns	0.000000001 (10⁻)
Picosecond	ps	0.000000000001 (10-12)

🔬 Interesting fact: A delay of 1 ns is the time it takes for light to travel only ~30 cm!

🎯 Key findings

Queue models help predict performance degradation (for example, disks under load).
Latency is a universal metric for comparing systems. Always specify the context: "TCP latency", "disk seek latency", etc.
Convert metrics to time to make informed decisions (for example, choosing between network and disk I/O).

**Remember:* "Productivity is the art of measurement, not guesswork!"\

The shocking truth about delays: from nanoseconds to millennia!*

⚡ How to understand time scales in computers?

Imagine that 1 CPU cycle (0.3 ns) is 1 second in our "scaled" world. Then:

Event	Real delay	On the scale of "1 cycle = 1 sec"	💡 Real-life analogy
Access to the L1 cache	0.9 ns	3 sec	Blink an eye
Read from RAM	100 ns	6 minutes	Make coffee
SSD disk (read)	50 microseconds	45 hours	Two days of vacation
HDD (data search)	5 ms	6 months	Six months of pregnancy
Ping from SF to New York	40 ms	4 years	Full-time university studies
Physical server restart	5 minutes	32 000 years	The last Ice Age

, Shock content:

During the time until the light reaches the book from your eyes (** 1.7 ns*), the processor manages to execute **5+ instructions*!
Waiting for a response from the HDD (10 ms) on a CPU scale — how to wait for a package for 12 months →→.

🌍 Why is this important?

Code optimization: If your algorithm once again accesses RAM instead of cache, it's like waiting 6 minutes instead of 3 seconds!
Architecture choice:
SSD vs HDD: The difference between hours and years of waiting.
- Server location: The delay between the USA and Australia (183 ms) is comparable to 19 years in CPU time!

🔧 Practical advice

Cache aggressively: L1 cache is faster than RAM by 100+ times.
Avoid disk I/O in critical code: One request per HDD = months CPU downtime.
Consider geography: Place servers closer to users — the difference between SF and UK (81 ms) Like 8 years waiting!

📚 Source: Adapted from "Systems Performance: Enterprise and the Cloud" (Brendan Gregg), chapters 6 (CPU), 9 (Disks), 10 (Network).

🎯 Philosophical summary:

"Computers live in another time dimension. Your task is not to keep them waiting!" ⏳💻

MAMR vs HAMR: The Battle for the Future of hard Drives

dima853 — Thu, 19 Jun 2025 17:54:17 +0000

Taking apart MAMR: Why hasn't this technology taken over the HDD world yet?

1. What is MAMR?

MAMR (Microwave-Assisted Magnetic Recording) is a technology for recording data on hard drives (HDDs), where microwaves help to remagnetize tiny bits, allowing you to increase storage density without loss of reliability.

How does it work?

The Spin Torque Oscillator (STO) is integrated into the recording head — mini microwave generator.
Before recording, the STO emits a high-frequency field (~20-40 GHz), which "rocks" the magnetic moments of the bits, temporarily reducing their stability.
Now even the weak field of the head is enough for remagnetization.
After recording, the microwaves turn off — the bits become stable again.

Analog:

Imagine that a bat is a door with tight hinges. Without MAMR, it cannot be opened with a weak push. With MAMR, the door is first "rocked" (by microwaves), and then easily opened.

2. Why is MAMR a breakthrough?

Recording density ↑: You can reduce the bits without the risk that they will "demagnetize" from temperature.
Reliability: There is no extreme heat (as in HAMR), which means that the disc will last longer.
Energy efficiency: No need for a giant magnetic field.

3. Why isn't MAMR dominating yet?

🔹 Reason 1: HAMR turned out to be faster

The competing HAMR (Heat-Assisted Magnetic Recording) technology uses laser heating for recording.
Seagate released the most spacious hard drive in history - https://www.techradar.com/pro/seagate-confirms-40tb-hard-drives-have-already-been-shipped-but-dont-expect-them-to-go-on-sale-till-2026

🔹 Reason 2: The complexity of STO production

Spin Torque Oscillator (STO) is a nanodevice that must: — Generate an accurate frequency (otherwise the recording will not work).
- Be small enough (so as not to interfere with the operation of the head).
So far, Toshiba is the only company that has been able to establish mass production.

🔹 Reason 5: Industry conservatism

HDD manufacturers have been investing in PMR/CMR (traditional technologies) for decades.

The transition to MAMR requires the restructuring of production lines — it is expensive and risky.

It is quite possible that none of the technologies will be the clear winner. "I have not yet been able to talk to any specific customer who will exclusively use only HDD with one of the technologies," says Mark Ginen, founder of the consortium of Advanced storage Technologies. "I think there will be companies in the market that will buy both."

4. Does MAMR have a future?

Yes, but in niche scenarios:
Where reliability is important: Archives, medical data, backups.
- Where record volumes are not needed: Enterprise systems with a balance of price and capacity.
Toshiba plans to increase the MAMR density to 30+TB by 2026.

5. Comparison of MAMR and HAMR

Parameter	MAMR (Toshiba)	HAMR (Seagate/WD)
Technology	Microwaves (STO)	Laser + Magnetic field
Max. capacity	22TB (2024)	24+ TB (2024)
Risks	Complexity of STO	Overheating, disk degradation
Price	Cheaper than HAMR	More expensive because of lasers

6. Conclusion

MAMR is an elegant solution, but for now:

HAMR is inferior in the "terabyte race".
Depends on Toshiba's progress in miniaturization of STO.
Chance of Success: If HAMR runs into reliability issues, MAMR will be the HDD's savior.

How It Works? Let's dig a little deeper.

Simplified explanation of MAMR operation

Imagine that a hard disk is a notebook where data is written with tiny magnetic arrows (↑ and ↓). The smaller the arrows, the more information will fit, but there is a problem.:

Problem

If the arrows are made very small, it is difficult to turn them over. You need a strong magnet (like a powerful refrigerator magnet), but the HDD head is a weak button magnet.

Solution: MAMR (microwave "help")

A "microwave for atoms" — Spin Torque Oscillator (STO) has been added to the recording head. That's how it works.:

1. STO is a "sandwich" of two magnetic layers

The first layer: As a "teacher" who arranges the electrons (makes their spins the same).
The second layer: As a "rebellious student" — his electrons are set up in the opposite way.

When current is passed through them:

Electrons from the first layer collide with the second.
The "stubborn" electrons of the second layer ** begin to oscillate** (like a swing if they are slightly pushed to the beat).
These vibrations generate microwaves (like Wi-Fi, but very spot-on).

2. How do microwaves help record data?

The microwaves are tuned to the resonant frequency of the magnetic grains of the disk (like a tuning fork that makes only one glass vibrate).
They rock the magnetic arrows on the disk, making them "malleable".
Now even the weak field of the head is enough to flip the arrow (write 0 or 1).
After recording, the microwaves turn off — the arrows "freeze" again and store the data.

3. Why does it feel like "heating up", but without the temperature?

Ordinary heating (as in HAMR) is like setting fire to paper to write on it. It's dangerous!
MAMR is like shaking a piece of paper to make the ink fit more easily. Without fire!

And now — a super simple analogy

Imagine that:

Data is nails driven into a board.
The usual entry — you are trying to drive a nail into an oak plank ** with a small hammer**. It doesn't work!
MAMR — you first "vibrate" the board (with microwaves), and now even a weak hammer blow drives a nail.

Why is it brilliant?

No destruction: No overheating (as in HAMR), the disk lives longer.
Accuracy: Microwaves work only where needed, without touching neighboring data.
Energy Saving: No need for giant magnets or lasers.

Output:

MAMR is a ** "smart vibration"** that allows HDD to break records in terms of capacity without violating the laws of physics. The technology is not perfect yet, but it has every chance of changing the future of hard drives!

HDD recording head device with MAMR

The picture shows an enlarged section of the tip of the recording head of a hard disk (HDD) using Microwave-Assisted Magnetic Recording (MAMR) technology. Let's look at each element and its role in recording data.

1. The main components in the image are

A. Write Head

This is the part of the head that remagnetizes the bits on the disk, writing data (0 or 1).

B. The Reading Head

Responsible for reading data from the disk (determines the direction of the magnetization of the bits).

C. Microwaves

Indicated by arrows is the high frequency magnetic field generated by the Spin Torque Oscillator (STO).

2. Detailed structure of the recording head

① FGL (Field Generation Layer)

This is the part of the STO (Spin Torque Oscillator) that generates the microwave field.
Consists of magnetic material, the vibrations of which create a high-frequency (~20-40 GHz) field.

② SIL (Shielded Interaction Layer)

A layer that focuses microwave radiation into the desired recording area.
Prevents the field from scattering so as not to affect neighboring bits.

③ STO (Spin Torque Oscillator)

The "heart" of MAMR is a microscopic microwave generator.
Consists of:
FGL (generates a field),
Disconnected layers (enhance the effect).
Powered by spin-polarized current (electrons "spin up" magnetic moments, creating vibrations).

④ Multimagnetic Pole

The main part of the recording head, which creates a permanent magnetic field for remagnetization of bits.
In combination with microwaves from STO, it allows you to record data on ultra-small bits.

⑤ Non-magnetic layer

Separates magnetic components, preventing unwanted interactions.
Usually from ruthenium (Ru) or similar materials.

3. How does it work together?

Recording begins:
Current is applied through the STO → FGL generates microwaves.
Microwaves affect the bit:
- They ** sway the magnetic moments** in the bit, reducing their stability.
The head remagnetizes the bit:
The multi-magnetic pole creates a weak field, which is now sufficient to switch the bit (↑ or ↓).
Recording completed:
The microwaves turn off → the bit ** becomes stable again**.

4. Why is this a breakthrough?

Previously, ** a huge field was required to write to small bits (it cannot be created in a miniature head).
With MAMR microwaves temporarily reduce the resistance bits → recording is possible even with a weak field.

Analog:

Imagine that a bat is a door with tight hinges.

Without MAMR: You're trying to open it with your bare hands (not strong enough).
With MAMR: First the door is "rocked" (microwaves), then you open it easily.

5. Comparison with a regular head

Component	Regular Head	Head with MAMR
Recording	Magnetic field only	Magnetic field + microwaves
Density	Limited (~1 Tbit/in2)	Higher (~2+ Tbit/in2)
Reliability	Stable	Stable + protection against superparamagnetism

6. The future of technology

Toshiba already uses MAMR in disks MG09 (18 TB) and MG10 (22 TB).
Goal: to achieve 4 Tbit/in2 (disks on 30+ TB).

Problems:

Fine-tune the STO (so that the microwaves do not interfere with neighboring bits).
Competition with HAMR (where laser heating is used).

Relationship between STO resistance and applied magnetic field

1. The general structure of the STO

The STO consists of three key layers:

FGL (Free Gadget Layer)
A "free" magnetic layer that can change the magnetization.
- Analog: a piece of paper that can be turned over.
Non-magnetic layer
is a non-magnetic material (for example, copper).
- Analog: the air gap between two magnets.
SIL (Spin Injection Layer)
A fixed magnetic layer with constant magnetization.
- Analog: a magnet glued to a table.

2. How are microwaves generated?

Step 1: Apply current

High-density electric current is passed through the STO layers (see values in the diagram: from (8.7 \times 10^6) to (1.4 \times 10^8) A/cm2).
What happens:
The electrons in the current "twist" (polarize) when passing through the SIL.
- These polarized electrons are "injected" into FGL.

Step 2: Excitation of vibrations

In FGL, the electron spins begin to precess (like a spinning top about to fall).
This creates an alternating magnetic field (microwaves) at a frequency of ~15-20 GHz.

Step 3: Resonance with the disc

The microwaves synchronize with the magnetic grains on the disk, reducing their coercivity.

3. Key parameters from the scheme

Current density (A/cm2)

The higher the current density, the stronger the fluctuations: -(8.7 \times 10^6) — the threshold for the start of generation.
- (1.4\times 10^8) — maximum efficiency.

STO States

Oscillating state (Fluctuations):
FGL is actively oscillating → microwaves are generated.
- The arrow (direction of magnetization) rotates rapidly.
Non-oscillating state (Rest):
- FGL is static → there are no microwaves.
- The arrow is fixed.

Why do we need an intermediate (non-magnetic) layer in STO?

Intermediate layer in Spin Torque Oscillator (STO) — this is a critical element, without which the generation of microwaves would be impossible. That's why it's needed and how it works.:

1. The role of the intermediate layer

This layer (usually made of copper, aluminum, or magnesium oxide) performs two key functions:

🔹 (1) Separates two magnetic layers (FGL and SIL)

FGL (Free Gadget Layer) is a "free" layer that can fluctuate.
SIL (Spin Injection Layer) is a "fixed" layer with constant magnetization.

Without an intermediate layer:

The magnetic layers ** would stick together** (like two magnets), and FGL would not be able to oscillate.
There would be no spin-polarized current — basics of STO operation.

🔹 (2) Allows the current to "transfer" spin information

When electrons pass through SIL, their spins are polarized (aligned in the same direction).
Then they ** pass through a non-magnetic layer**, maintaining their polarization.
Reaching FGL, these electrons transfer their spin moment to it, causing it to oscillate.

2. Why is it a non-magnetic material?

The magnetic material would shield the spin current → the FGL oscillations would stop.
Dielectric (for example, MgO) It is sometimes used to enhance the spin transfer effect.

Optimal thickness: ~1-3 nm.

Too thin → the layers will "stick together".
Too thick → the electrons will lose their polarization.

3. What would happen without this layer?

It would be impossible to control FGL — it would just "stick" to SIL.
** There would be no microwaves** — there would be no fluctuations.
MAMR would not work — recording to high-density discs would remain impossible.

Graph analysis: Comparison of SNR of conventional and MAMR heads

This graph demonstrates the key advantage of MAMR (Microwave-Assisted Magnetic Recording) Before traditional magnetic recording: increased signal-to-noise ratio (SNR) by 7 dB. Let's take it apart piece by piece.

1. X-axis and Y-axis: what is depicted?

X-axis (Down-track / Cross-track direction, nm)
Shows the spatial position of the head relative to the track on the disc.
- Down-track — along the track (the direction of movement of the data).
- Cross-track — across the track (recording width).
Y-axis (SNR, dB / Magnetization, %)
SNR (Signal-to—Noise Ratio) is the ratio of the useful signal to noise (the higher the better).
- Magnetization saturation — the level of magnetization (↑ up / ↓ down).

2. Comparison of conventional and MAMR heads

(A) Conventional R/W Head

SNR: Low (conventionally ~0 dB on the graph).
Problem:
- At high recording density, the magnetic bits become too small → the signal weakens, the noise increases.
- The head cannot clearly remagnetize tiny areas → the data is distorted.

(B) MAMR head

SNR: Higher by 7 dB (significant improvement!).
Reason:
Microwaves from STO (Spin Torque Oscillator) helps ** to re-magnetize the bits more clearly**.
- This reduces the "smearing" of the signal and suppresses noise.

3. How do microwaves improve SNR?

Accurate recording
Microwaves ** locally reduce the coercivity** (Coercivity is the resistance of a ferromagnet to demagnetization) of the disc material.
- The head can record smaller and clearer bits without errors.
Improved reading
- Because the bits are recorded more clearly, it is easier for the head to recognize them - > less noise.
Stability
MAMR does not overheat the disc (unlike HAMR), so there is no additional thermal noise.

4. Why is +7 dB important?

Increase in SNR by 3 dB = doubling of information capacity.
+7 dB ≈ 5 times better signal-to-noise ratio → You can increase the recording density without data loss.

Example:

If a conventional head worked with a density of 1 Tbit/in2, then MAMR allows you to rise to 1.5–2 Tbit/in2 with the same reliability.

5. Conclusion

MAMR doesn't just "slightly improve" the recording — it makes it better.
+7 dB SNR means that HDDs with MAMR will be able to:
store more data,
read it faster,
- work longer without errors.

Results of evaluation of overwrite performance of MAMR read and write heads

This Fihure shows the changes in
overwrite performance over a range of write current (Iw). It
indicates that, when the STO is on, MAMR provides a roughly 10 dB
higher overwrite performance than a conventional magnetic
recording method without an STO. This
result indicates that the microwave field emitted by an STO helps
to achieve good write performance, demonstrating the feasibility
of MAMR. As a result of the foregoing, MAMR is considered to be
a promising next-generation high-density HDD recording
technology capable of overcoming the trilemma associated with
high-Ku recording media

Evaluation of a prototype HDD with MAMR read/write heads

and media

*Results of long-term reliability tests of prototype
MAMR HDDs

Figure 5 compares the changes in the bit error rate
(BER) of the MAMR and conventional HDDs over time. The MAMR media were made of materials similar to those used for conventional
recording media. Figure 5 presents the results obtained at a
recording density close to the maximum recording density of the
existing HDDs. It shows that MAMR with an STO provides a
significant reduction in the BER.
Generally, an STO with higher drive current generates a microwave
field with higher intensity and thus provides higher energy-assistfor MAMR, resulting in a greater reduction in the BER. However,
excessive current could degrade reliability because of Joule
heating and electromigration within the STO. In the example
shown in Figure 5, the BER of MAMR remains unchanged for up
to 1,000 hours of write operations without any STO degradation,
the possibility of which had been a concern. From this evaluation,
we have also obtained information about adequate STO drive
conditions. (from the article)

Bottom line: MAMR is a smart way to extend the life of an HDD, but the technology is still fighting for a place in the market, let's see what happens next.

An overview of the security of lower-level TCP/IP protocols

dima853 — Thu, 05 Jun 2025 12:43:36 +0000

Introduction

This section examines the protocols at the lower levels of the TCP/IP stack, focusing on their vulnerabilities and security issues. The focus is on IP, ARP and TCP.

2.1 Basic Protocols

2.1.1 IP Protocol (Internet Protocol)

Main function: A packet multiplexer that adds an IP header to messages of higher-level protocols
Features:
Unreliable datagram service (no guarantees of delivery, order, uniqueness)
Header checksum does not protect data
- Lack of authentication of the source address (IP spoofing is possible)

Example of IP spoofing in C:

// Example of creating a RAW socket with IP address substitution
int sock = socket(AF_INET, SOCK_RAW, IPPROTO_RAW);
char packet[4096];
// Filling in the IP header with a fake source IP
struct iphdr *ip = (struct iphdr *)packet;
ip->saddr = inet_addr("192.168.1.100"); // Spoofed
ip address->daddr = inet_addr("10.0.0.1");
// ... the remaining fields
of the sendto header(sock, packet, ip->tot_len, 0, (struct sockaddr *)&dest, sizeof(dest));

Fragmentation:
- Packets can fragment when the MTU is exceeded
Security issues: bypassing filters, overlapping fragments with different contents
IP addresses (IPv4):
32-bit, divided into network and host parts (CIDR)
Broadcast addresses (all 0 or 1 in the host part)
Directed broadcast traffic can be used for attacks

2.1.2 ARP (Address Resolution Protocol)

Purpose: Converting IP addresses to MAC addresses for Ethernet
Operating mechanism: Broadcast requests and responses with caching of results
Vulnerabilities:
- ARP spoofing: spoofing ARP responses to redirect traffic
- Lack of authentication in the protocol

Example of ARP spoofing:

// Example of sending a fake ARP response
struct arp_packet {
    uint16_t htype; // Hardware type
    uint16_t ptype; // Protocol type
// ... other fields of the ARP header
    u_char sha[6]; // Sender's MAC (forged)
u_char spa[4]; // Sender's IP (forged)
u_char tha[6]; // Target's MAC
    u_char tpa[4]; // IP of the target
};

struct arp_packet pkt;
// Filling with fake
memcpy data(pkt.sha, attacker_mac, 6);
memcpy(pkt.spa, victim_ip, 4);
// ...
send_packet(&pkt);

2.1.3 TCP (Transmission Control Protocol)

Main function: Providing a reliable duplex connection over an unreliable IP
Mechanisms:
Sequential numbers for ordering and confirmation
- Overload control and retransmission

Establishing a connection (Three-way handshake)

Client → Server: SYN (ISNc)
Server → Client: SYN-ACK (iSNS, ACK(ISNc+1))
Client → Server: ACK(iSNS+1)

Example in C:

// Simplified example of TCP handshake
int sock = socket(AF_INET, SOCK_STREAM, 0);
struct sockaddr_in serv_addr;
serv_addr.sin_family = AF_INET;
serv_addr.sin_port = htons(80);
inet_pton(AF_INET, "192.168.1.1", &serv_addr.sin_addr);

// SYN
connect(sock, (struct sockaddr *)&serv_addr, sizeof(serv_addr));
// The kernel completes the handshake automatically

TCP vulnerabilities:

SYN flood: Sending multiple SYNs without completing the handshake
- Filling the queue of half-open connections
- Solution: SYN cookies
The ISN predictability attack:
If the initial sequence number (ISN) is predictable, spoofing is possible
- Solution: Cryptographically strong ISN generation (RFC 1948)

Visualization of ISN:

Good implementation: diffuse point cloud (FreeBSD 4.6)
Poor implementations: clear patterns (Windows NT 4.0, IRIX 6.5)

Privileged ports (1-1024):
On UNIX, only root can open
Unreliable authentication scheme, as it is not universal

Closing the connection

An asymmetric process (each side closes independently)
FIN packages for initiating closure

Safety conclusions

IP layer:
- There is no source authentication
- Possible spoofing and fragmentation attacks
ARP:
Vulnerable to spoofing
- Solutions: Static ARP, ARP inspection
TCP:
Vulnerable to spoofing with predictable ISN
SYN-flooding can cause DoS
- Privileged ports are an unreliable authentication mechanism

Recommendations:

Use cryptographic authentication methods (do not rely on IP/TCP mechanisms)
Configure filtering of directed broadcast traffic
Implement protection against SYN flood
Ensure correct ISN generation (RFC 1948)

Introduction to DDD || Eric Evans

dima853 — Mon, 26 May 2025 10:30:08 +0000

Summary: Domain Models in software development

1. Models as a simplification of reality

An example of an 18th-century Chinese map: — China is depicted in the center, the rest of the countries are schematically shown.
- This reflected China's isolationist policy, but it did not help to interact with the outside world.
- Conclusion: A model is ** a simplified representation of reality** that focuses on important aspects and ignores unnecessary ones.

2. What is a Domain?

Domain is the user's area of activity that the program concerns.
- Examples:
Airline tickets: real people, planes, flights.
- Accounting: money, bills, taxes.
- Version control system: software development.
A domain is usually not directly connected to computers, but requires a deep understanding of the subject area.

3. Why do we need domain models?

Problem: The amount of domain knowledge is huge and complex.
Solution: Model is:
- Structured simplification of knowledge.
- Abstraction, which helps to focus on the task.
- A tool to combat information overload.

4. What is the Domain Model?

It's not just a diagram or a code, but the idea that they convey.
** Not "realism"**, but a useful abstraction (like cinema— not real life, but interpretation).
Example:
- The documentary film edits reality to convey meaning.
- Similarly, the domain model selects the important and discards the unimportant.

5. How is the Domain Model created?

Domain analysis (communication with experts).
Structuring knowledge (highlighting key entities and relationships).
Abstraction (ignoring unnecessary details).
Fixing the model (in the form of diagrams, code or descriptions).

6. Examples of models

Real world	Model in the program
Passenger, Plane, flight	`Class Passenger`, `Flight`
Money, accounts, transactions	`Account`, `Transaction`

7. Conclusion

Domain Model is a deliberately simplified representation of knowledge about a domain.
She helps:
- Understand complex processes.
- Communicate between developers and experts.
- Create software that solves users' real-world problems.

Key point: A good model is not one that is "realistic", but one that is useful for solving a specific problem.

Summary: The role of the model in Domain-Driven Design (DDD)

1. Three key model functions in DDD

The model forms the design of the system, and the design clarifies the model
The model is closely related to the implementation, which makes it relevant.
- The code can be interpreted through the lens of the model (convenient with support and development).
- Example: If the model includes the entity Order, then the code will have the class Order with the appropriate methods.
The model is the basis of a single team language (Ubiquitous Language)
Domain developers and experts speak the same language.
- There is no need to "translate" the requirements.
- The language helps to refine the model itself.
- Example: The term "order cancellation" in the speech of experts → the method Order.cancel()in the code.
A model is a condensed knowledge of a domain
- The team has agreed on how to structure knowledge about the subject area.
- The model captures important concepts and their interrelationships.
- Experience working with early versions of the software helps to improve the model.

2. Why is the model the "heart" of the software?

The main task of PO is ** to solve the problems of the subject area**.
Complex domains require deep understanding:
Developers must immerse themselves in business logic.
- Technical skills (frameworks, algorithms) are secondary without understanding the domain.
Risk: Developers often focus on technology, ignoring domain → create complex but useless systems.

3. Example: A story from Monty Python

On the set of Monty Python and the Holy Grail, one shot didn't turn out to be funny.
The actors changed the scene — it became funny, but the editor used the old version because the sleeve was visible in the new one.
Analogy in development:
- Editor = a developer who takes care of the technical details but loses the point.
- Director = team leader who returns the focus to the domain (as a funny scene).

4. Advantages of deep domain work

Complexity is interesting: — Creating a clear model in a chaotic domain is an intellectual challenge.
Modeling skills make a developer more valuable:
- The ability to identify entities, aggregates, and constraints is useful in any project.
System approaches:
Tactical DDD (Entity, Value Object, Aggregate).
- Strategic DDD (Bounded Context, Context Map).

5. Conclusion

A good model is not just documentation, but a decision—making tool.
DDD helps:
Connect code with business logic.
- Avoid "technical narcissism" (when technology is more important than the task).
- Create software that really solves user problems.

Key quote:
"The heart of software is its ability to solve problems in a subject area. Everything else is auxiliary."

Additional concepts to explore:

Tactical DDD: Entity vs Value Object, Aggregates, Repositories.
Strategic DDD: Bounded Context, Anti-Corruption Layer.
Practices: Event Storming, Domain Storytelling.

Knowledge Extraction in Domain-Driven Design || DDD Eric Evans

dima853 — Mon, 26 May 2025 10:27:28 +0000

Summary: Knowledge Extraction in Domain-Driven Design (Chapter 1)

1. Problem: Ignorance of the subject area

The author, a software developer, was faced with the task of creating a program for designing printed circuit boards (PCBs), having no knowledge of electronics.

Attempt 1: Get TK from experts → fail.
- Experts have proposed primitive solutions (for example, sorting ASCII files) that do not solve real problems.
Problem: The gap between technical and substantive knowledge.

2. The process of "Knowledge Crunching"

Method: Collaborative modeling through:

Dialogue with experts:
The author drew diagrams (informal UML), the experts corrected them.
- Example:
Expert: "These are not chips, but component instances."
- Developer: Clarified the terms (for example, "ref-des" = reference designator = component instance).
Focusing on a single function:
Disassembled "probe simulation" — analysis of signal delays in the circuit.
- Simplified the model: ignored the physics of the chips, focused on the topology of the connections.
Iterative refinement of the model:
- Developer's questions:
"How is the signal transmitted beyond the Pin?" → Found out: through * "pushes"* components.
- "What counts as a 'hop'?" → Network transition (Net) = 1 hop.
  - Result: A model of objects (Net, Pin, Component) with behavior.

3. Creating a prototype

Goal: To test the model in practice.
Prototype Features:
No UI, no persistence, just logic.
- Tests + output to the console.
Effect:
Experts saw the work of the model → the dialogue became more specific.
- The code and the model evolved together.

4. The final model

Key entities:
Net (connection).
- Pin (component contact).
- Component (the type of component that defines the "jolts" of the signal).
Excluded:
Physical parameters of the components (did not affect the task).
Advantages of the model:
Eliminated synonyms (for example, "ref-des" = "component instance").
- Gave a single language for the team.
- Allowed new developers to quickly understand the logic.

5. Lessons

A model is born in a dialogue — you can't just take TK from experts.
Focus on specific scenarios — for example, "probe simulation".
A prototype without "excess" helps to test ideas quickly.
The evolution of the model and the code — they must change together.

Quote:
"A model is a concise knowledge that excludes irrelevant details, but preserves the essence of the problem."

Additional concepts

Ubiquitous Language is a common language for developers and experts.
Tactical DDD — Entity (Component), Value Object (Pin), Aggregates.
Iteration — The model is religion, it can be changed as you learn.

Conclusion: The success of the project depends on ** deep immersion in the domain**, and not only on technology.

Ingredients of Effective Modeling

Certain things we did led to the success I just described.

Binding the model and the implementation
That crude prototype forged the essential link
early, and it was maintained through all subsequent iterations.
Cultivating a language based on the model
At first, the engineers had to explain
elementary PCB issues to me, and I had to explain what a class diagram meant. But as the
project proceeded, any of us could take terms straight out of the model, organize them into
sentences consistent with the structure of the model, and be un-ambiguously understood
without translation.
Developing a knowledge-rich model
The objects had behavior and enforced rules. The
model wasn't just a data schema; it was integral to solving a complex problem. It captured
knowledge of various kinds.
Distilling the model
Important concepts were added to the model as it became more
complete, but equally important, concepts were dropped when they didn't prove useful or
central. When an unneeded concept was tied to one that was needed, a new model was
found that distinguished the essential concept so that the other could be dropped.
Brainstorming and experimenting
The language, combined with sketches and a
brainstorming attitude, turned our discussions into laboratories of the model, in which
hundreds of experimental variations could be exercised, tried, and judged. As the team went
through scenarios, the spoken expressions themselves provided a quick viability test of a
proposed model, as the ear could quickly detect either the clarity and ease or the
awkwardness of expression.

It is the creativity of brainstorming and massive experimentation, leveraged through a model-based
language and disciplined by the feedback loop through implementation, that makes it possible to
find a knowledge-rich model and distill it. This kind of knowledge crunching turns the knowledge
of the team into valuable models.

2.3 ARCHITECTURES VERSUS MIDDLEWARE

dima853 — Sat, 17 May 2025 18:53:46 +0000

The role of Middleware in distributed systems

Architectural Styles and Middleware (Middleware)

Chapter 2.3 "Architectures vs Middleware"

The Middleware Role

Middleware is an intermediate layer between applications and distributed platforms. Its key task is to ensure transparency of distribution, hiding from applications the complexities associated with data distribution, processing and management.

The connection of Middleware with architectural styles

In practice, middleware often implements a specific architectural style:

Object-oriented style: for example, CORBA (Common Object Request Broker Architecture), where interaction is built through remote objects.
Event-oriented style: as in TIB/Rendezvous, where components exchange asynchronous event messages.

Advantages of this approach:

Simplify application design through standardized templates.

Disadvantages:

Limited flexibility. For example, CORBA initially supported only remote method calls (RPC), which later required the addition of other patterns (such as messaging), complicating the system.
The risk of "bloating" middleware due to the addition of new features.

Adapting Middleware to the needs of applications

To solve the problem of flexibility, two approaches are proposed.:

Specialized versions of middleware for different classes of applications.
Configurable systems, where mechanisms (basic functionality) and policies (configurable rules of behavior) are separated. This allows you to adapt middleware without rewriting the code.

Interceptors Technology

One of the ways to configure middleware is to use interceptors — software modules that "wedge" into the standard execution flow to add specific logic.

An example from object-oriented systems:

Object A calls the method B.do_something(value), where B is located on a remote machine.
The call is converted into a universal query invoke(B, &do_something, value).
The request is sent via the OS network interface.

How interceptors help:

At the query level: If object B is replicated, the interceptor can automatically forward the call to all replicas without requiring changes to either the A code or the underlying middleware.
At the message level: if the value parameter is a large amount of data, the interceptor can split it into parts to improve transmission reliability, unnoticed by the main system.

Advantages:

Transparency for the application.
Minimal changes to middleware.

Problems:

The complexity of implementing universal interceptors (as shown in Schmidt et al., 2000).
The balance between flexibility and ease of management.

Conclusion

Middleware, based on architectural styles, simplifies development, but requires adaptation mechanisms (for example, interceptors). Modern systems tend to separate policies and mechanisms in order to maintain flexibility without complicating the code.

Graphical representation

(You can add a scheme for interceptors in remote method invocation.)

Example of interceptor operation:

[Object A] → [Calling B.do_something()] → [Request Interceptor] →  
[Invoke for replicas B] → [Message Interceptor] → [Network]

Key terms:

Interceptor — interceptor.
Distribution Transparency — transparency of distribution.
Policy-Mechanism Separation — separation of policies and mechanisms.

2.3.2 General approaches to adaptive software

Adapting middleware through interceptors

Interceptors allow middleware to be adapted to the changing operating conditions of distributed systems, such as:

Mobility (changing the location of nodes).
Instability of QoS (network connection quality).
Equipment failures.
Low battery (in mobile devices).

Instead of making applications responsible for responding to changes, middleware takes over this task.

Three approaches to creating adaptive software

McKinley et al. (2004) identify three main methods:

Separation of concerns
The traditional approach: separating the main functionality from the "additional" aspects (security, reliability, performance).
- Problem: Many aspects (such as security) cannot be isolated into a separate module.
- Aspect-oriented programming (AOP) It is trying to solve this problem, but it is not yet scaling to large distributed systems (Filman et al., 2005).
Computational reflection
The ability of the program to analyze and change its behavior during execution (Kon et al., 2002).
- It is supported in languages (for example, Java) and some middleware systems.
- However, reflexive middleware has not yet proven effective in large distributed systems (Blair et al., 2004).
Component-based design
Adaptation through the composition of components (static or dynamic).
- Dynamic component replacement requires complex dependency management (Yellin, 2003).
- Problem: Components often turn out to be more connected than they seem.

2.3.3 Discussion

Middleware Issues

Complexity and cumbersomeness due to attempts to ensure transparency of distribution.
The conflict between universality (transparency) and specialization (for specific applications).
Example: the code size of some middleware solutions increases by 50% in 4 years, and the number of files increases by 3 times (Zhang & Jacobsen, 2004).

Do I need adaptability?

Arguments for:
Distributed systems cannot be stopped for updates.
- Dynamic replacement of components is required.
Arguments against:
Many changes (attacks, equipment failures) can be predicted in advance.
- The complexity of adaptive solutions may outweigh their advantages.

Alternative approach

Instead of rebuilding on the fly, you can:

Provide adaptation policies in advance (for example, reallocation of resources).
Automate the response to changes without human intervention.

Conclusion

Middleware adaptability is an important but challenging task. Modern approaches (AOP, reflection, components) are not perfect yet. Perhaps the best way is predictable adaptation policies instead of "realignment on the move."

3.1 Prediction methods for conditional jumps

dima853 — Thu, 08 May 2025 18:00:52 +0000

1. What is a saturating 2-bit counter?

This is a two-bit saturation counter, which is used in branch prediction algorithms. It helps the processor predict whether a conditional transition (for example, if-else, cycles) will be executed (taken) or not (not taken).

2. How does the saturating 2-bit counter work?

The counter can be in 4 states encoded with two bits:

Status	Value	Prediction
`00`	Strongly not taken	The transition will not be completed
`01`	Weakly not taken	Rather not executed, but may change
`10`	Weakly taken	Rather completed, but may change
`11`	Strongly taken	The transition will be completed

Tag update rules:

If the transition is completed (taken) → counter increases by 1 (but not higher than 11).
If the transition is not completed (not taken) → counter ** decreases by 1 (but not below 00)**.

Example:

The counter is in the 01 state (weakly not taken):
If a transition has occurred → goes to 10 (weakly taken).
- If the transition did not occur → goes to 00 (strongly not taken).

3. Why exactly 2 bits?

1- The bit counter (0 or 1) changes the prediction too abruptly and is subject to noise (frequent switching).
2- The bit counter adds "hysteresis": the transition between taken and not taken requires two erroneous predictions in a row, which makes the algorithm more resistant to random deviations.

4. Where is it used in processors?

Such counters are used in:

Transition History Tables (Branch History Table, BHT) – stores prediction states for different transition addresses.
Global and local prediction schemes (for example, in the Tournament Predictor algorithm for some processors).

5. Example of work

Let's say there is a loop that runs 9 times, and exits on the 10th time.:

The first iterations:
The counter starts at 00 (strongly not taken).
- The loop is running → the counter is gradually increased to 11 (strongly taken).
Last iteration (exit the loop):
The transition is not performed → the counter is reduced to 10 (weakly taken).
- If the cycle does not start anymore, the counter may drop to 00.

6. Optimizations related to saturating counters

Efficiency: Works well for stable branches (for example, loops with a large number of iterations).
Problems:
- Inefficient for random branches (if transitions are unpredictable, the counter will fluctuate frequently).
- Learning delay: It takes several runs for the counter to "learn" the correct prediction.

Conclusion

Saturating 2-bit counter is a simple but effective branch prediction mechanism used in many processors. It provides a balance between stability and adaptability, reducing the number of prediction errors (mispredictions).

Adaptive two-level predictor

1. What is Adaptive Two-Level Predictor?

This is an advanced branch prediction algorithm that uses two levels of information:

The first level is the history of previous transitions (branch history).
The second level is the state table (pattern history table), where each history template has its own saturating counter.

This approach allows to take into account correlations between successive transitions, which is especially useful for loops and complex conditional constructions.

2. How does Two-Level Predictor work?

2.1. Main components

Branch History Register (BHR)
is a register that stores the latest transition results (for example, taken = 1, not taken = 0).
- Example: BHR = 1011 means that the last 4 transitions were T, NT, T, T.
Pattern History Table (PHT)
A table of saturating counters (usually 2-bit), where each counter corresponds to a specific pattern from BHR.
- For example, if BHR = 1011, the processor looks at the PHT record for this template and uses it for prediction.
Global/Local History
- Global History (Global Two-Level) – One BHR for all transitions.
- Local History (Local Two-Level) – a separate BHR for each transfer address.

2.2. Work example

Let's say we have a loop that runs 3 times, and exits on the 4th time.:

Initialization:
- BHR = 0000 (if the history is 4-bit).
- In PHT, all counters are at 00 (strongly not taken).
First iterations (transition taken):
BHR shifts by adding 1: 0001 → 0011 → 0111 → 1111.
- For each template, the PHT is updated towards `taken'.
Last iteration (transition not taken):
BHR = 1111 → prediction taken (but actually not taken).
- The counter for 1111 is decreasing, and the prediction may change next time.

3. Why is Two-Level Predictor better than a simple saturating counter?

Takes into account the context of transitions:
A simple 2-bit counter "forgets" the previous states.
- Two-Level Predictor remembers transition sequences and predicts based on patterns.
Effective for cycles and periodic branching:
- For example, if the transition alternates T, NT, T, NT, BHR will help predict the next outcome.

4. Varieties of Two-Level Predictors

GAg (Global History, Global PHT)
One common BHR for all branches.
- Saves resources, but is less accurate for specific branches.
PAg (Per-Address History, Global PHT)
A separate BHR for each transfer address.
- More accurate, but requires more memory.
PAp (Per-Address History, Per-Address PHT)
Each branch has its own PHT.
- Maximum accuracy, but high difficulty.

5. Optimizations and challenges

5.1. Advantages

✅ Better accuracy than saturating counters.

✅ Effective for cycles and repetitive patterns.

5.2. Problems

❌ Requires more memory (BHR + PHT).

❌ Learning delay (it takes several iterations to set up).

❌ Conflicts in PHT (different branches may use the same counter).

6. Where is it used?

Intel Pentium Pro/II/III – two-level predictors were used.
Modern processors (AMD Zen, Intel Core) – combine two-level predictors with other methods (for example, TAGE predictor).

Conclusion

Adaptive Two-Level Predictor is a powerful branch prediction engine that takes into account the history of transitions to improve accuracy. It is especially useful in loops and complex conditional scenarios, but requires additional hardware resources.

1. The main idea of the Tournament Predictor

The processor uses two (or more) different predictors and dynamically selects which one is best suited for the current branch.

The main predictor (for example, gshare) works well for branches with global correlation.
An alternative predictor (for example, bimodal) is effective for simple branches.
Meta predictor (selector) – decides which of the two predictors to use.

2. How does the Tournament Predictor work?

2.1. Structure

Two predictors:
- P1 (for example, gshare) – takes into account the global history.
- P2 (for example, bimodal) is a simple 2-bit counter.
Meta-predictor table:
Stores 2-bit counters that decide which predictor (P1 or P2) to trust.

2.2. The algorithm of operation

When predicting branches:
P1 and P2 give their predictions.
- Meta-predictor chooses which one to use.
After completing the branch:
If the selected predictor was wrong and the alternative was right, the meta–counter is updated towards the alternative.
- If both were wrong or both were right, the meta counter does not change dramatically.

3. Why is Tournament Predictor effective?

Adaptability: If one predictor does not work well for a particular branch, the system automatically switches to another.
Versatility: Copes well with different types of branches (loops, random conditional jumps).
Reducing the number of mispredictions: The combination of methods gives a more stable result.

4. Example of work

Admit:

P1 (gshare) predicts taken.
P2 (bimodal) predicts not taken.
Meta-predictor tends towards P1 (for example, the counter 10 = weakly prefer P1).

Scenarios:

If the real transition is taken (P1 is right, P2 is wrong) → Meta-predictor enhances trust in P1 (10 → 11).
** If the real transition is not taken (P1 is wrong, P2 is right)** → Meta-predictor reduces confidence in P1 (10 → 01).

5. Where is it used?

Intel Pentium 4 (NetBurst) – used Tournament Predictor.
Modern processors (AMD Zen, Intel Core) – use sophisticated hybrid circuits (for example, TAGE + Loop Predictor).

6. Advantages and disadvantages

✅ High accuracy due to adaptive selection.

✅ Versatility – Suitable for different branching patterns.

❌ Complexity – requires additional tables and logic.

❌ Learning delay – The meta-predictor needs time to adjust.

Conclusion

Tournament Predictor (Agree Predictor) is a powerful hybrid algorithm that dynamically selects the best prediction method for each branch. It is especially useful in modern processors where it is important to minimize mispredictions.

Summary: Branch prediction mechanisms in processors

Method	Description	How does it work?	Positive	Minuses	Where is it used?
Saturating 2-bit Counter	The simplest predictor based on a 2-bit saturation counter.	- 4 states: `00` (strongly NT), `01` (weakly NT), `10` (weakly T), `11` (strongly T). - Increases with `taken`, decreases with `not taken`.	- Easy to implement. - Resistant to noise (hysteresis).	- Slowly adapts. - Predicts complex branches poorly.	A basic component of many predictors.
Two-Level Predictor	Uses the conversion history (BHR) and the template table (PHT).	- BHR stores the latest transition outcomes. - PHT contains 2-bit counters for each BHR template.	- Takes into account the context (better for loops). - More accurate than a 2-bit counter.	- Requires more memory. - Conflicts in PHT.	Intel P6 (Pentium Pro/II/III), AMD K8.
Tournament Predictor (Agree)	Hybrid predictor combining two methods (for example, gshare + bimodal).	- Meta-predictor selects which of the two predictors to use. - Updated based on errors.	- Adaptability. - High accuracy for different types of branches.	- Complex logic. - Additional hardware costs.	Intel Pentium 4, modern hybrid circuits.

Key terms

BHR (Branch History Register) is a register that stores the history of transitions.
PHT (Pattern History Table) is a table of counters corresponding to BHR patterns.
Meta-predictor is a mechanism for choosing between two predictors in Tournament Predictor.

The evolution of predictors

Saturating Counter → Two-Level → Tournament → TAGE (modern CPUs).
The more complex the algorithm, the higher the accuracy, but the higher the resource consumption.

DEV Community: dima853

I made a sign with brief explanations of the terms from LLDP

More- https://t.me/dima853_code

INLINE vs. NORMAL FUNCTIONS: What's Really Happening in Assembly?

🔥 INLINE vs. NORMAL FUNCTIONS: What's Really Happening in Assembly?

🎯 With INLINE — code is INSERTED directly:

🐌 WITHOUT INLINE — CALLS to the function:

🍔 SIMPLE ANALOGY:

⚡ RESULT:

🎯 CONCLUSION:

programming #C #assembler #optimization #inline #compiler

🛡️ OCTAL ACCESS RIGHTS IN LINUX: A COMPLETE GUIDE

Linux #DevOps #SysAdmin #Permissions #Security #Guide

I'm creating a social network that is not hacable, trackable, or censored - by design.

Subscribe - https://t.me/dima853_code

I also made a detailed guide about octal access rights in Linux.

2.3.2 - 2.3.5 Concepts (System Performance Brendan Gregg 2nd)

2.3.3 Trade-Offs

Trade-offs in IT: "Pick two" and performance optimization

1. Key trade-offs in IT

(1) CPU vs Memory

(2) File System block Size

(3) Network Buffer size

2. Where is it more efficient to adjust performance?

3. Problems of modern approaches

4. Practical advice

(1) For developers

(2) For admins

Conclusion

Optimizing block size for PostgreSQL: how to choose and why?

1. What is a "block" in PostgreSQL?

2. How does block size affect performance?

3. How can I check my current performance?

4. How can I change the block size?

5. Optimal values for different scenarios

6. What else affects I/O efficiency?

Conclusion

Tip: For cloud databases (RDS, Cloud SQL), the block size is fixed — choose instances with preset values for your load.

The level of depth of performance analysis: when to stop?

1. "Adequate level" of analysis: from startups to HFT

2. When should I stop the analysis?

Scenarios for stopping:

3. Recommendations "at a given time"

4. Practical rules

For startups

For corporations

For HFT/Exchanges

5. Checklist "Where to stay?"

Conclusion

2.2 - 2.3.2 Models/Concepts (System Performance Brendan Gregg 2nd)

2.2 Models

🌩 Special difficulties in cloud environments

🧩 The complexity of modern distributed systems

🔎 How to minimize the impact of perturbations?

2.2.2 Queueing System

📊 Modeling components as queue systems

What is M/M/1? (In simple words)

Real-life analogies

Key parameters of the M/M/1 model

- ρ = 10 / 15 = 0.67

Key performance indicators

Formulas for calculation (if you are interested)

Calculation example (simple)

Advantages of the M/M/1 model

Limitations of the M/M/1 model

Conclusion

⏱️ Latency is the Queen of Metrics

🌐 Network examples:

🔢 Why is latency more important than IOPS?

📏 Table of time units

🎯 Key findings

⚡ How to understand time scales in computers?

🌍 Why is this important?

🔧 Practical advice

MAMR vs HAMR: The Battle for the Future of hard Drives

Taking apart MAMR: Why hasn't this technology taken over the HDD world yet?

1. What is MAMR?

2. Why is MAMR a breakthrough?

3. Why isn't MAMR dominating yet?

🔹 Reason 1: HAMR turned out to be faster

1. The general structure of the STO