In this article, we’ll look at RTT, jitter, and packet loss as parts of a single timing system rather than separate metrics. You’ll start by understanding RTT and why it changes over time. Then you’ll learn how jitter emerges as an extra delay relative to a baseline. Finally, you’ll see how TCP uses this timing information to decide when delay turns into packet loss, with a focus on real protocol behaviour such as TLS and post-quantum TLS handshakes.

The goal is simple: to understand how timing turns into decisions.

Table of Contents

1. RTT (Round Trip Time)

   • Baseline RTT

   • Why Baseline RTT Matters

2. What is Jitter?

   • What Jitter Actually Means

   • Where Jitter Comes From

   • What Jitter Tells Us

3. How TCP Learns RTT and Jitter

   • TCP Does Not Know RTT in Advance

   • SRTT (Smoothed RTT)

   • RTTVAR (RTT Variance)

   • Why TCP Needs Both

4. How TCP Decides Packet Loss

   • TCP Never Sees a Packet Being Dropped

   • Retransmission Timeout (RTO)

   • Delay vs Packet Loss

   • How Jitter Turns Into Packet Loss

5. Conclusion

RTT (Round Trip Time)

Before talking about delay, jitter, or packet loss, we need to clearly understand what RTT is. If RTT is not clear, everything that comes after it becomes confusing.

RTT stands for Round Trip Time. It is the total time taken for a packet to travel from a client to a server and for the response to return to the client.

Assuming you send a packet and receive the reply after 50 milliseconds, then the RTT is 50 ms. That is the basic definition.

But here is the important part: RTT is not a fixed number. It changes all the time. Even when you communicate with the same server, RTT can change from one packet to the next. This happens because the network is always changing, and this can be because of any of these reasons:

• Packets waiting in queues

• Temporary congestion

• Scheduling inside routers

• Background traffic on the same path

Let’s assume you connect to Google, and you send a packet now. In practice, RTT can be measured using simple tools. One common way is the ping command, which sends a packet and measures how long it takes for the reply to return.

ping -n 1 google.com

And here, you get the reply after 50 ms.

RTT = 50 ms

That value is real, but it is incomplete. A single RTT measurement does not tell us whether the network path itself takes 50 ms, or whether the path is faster and the packet experienced a small temporary delay along the way.

For example, the actual path delay might be 49 ms, with an additional 1 ms spent waiting in a queue. From a single RTT value, there is no way to separate these effects. RTT only makes sense after multiple measurements.

So, let’s measure multiple RTT values.

Now you can see a pattern. From the measurements:

min RTT ≈ 18 ms
max RTT ≈ 19 ms
average RTT ≈ 18 ms

That is why RTT is not something you magically know from one packet. It is something you observe over time.

But now, at this point, an important question comes up: Which of these RTT values represents the real network path?

When RTT is measured repeatedly, the values are not consistent. Some RTT measurements are small, some are larger, and some suddenly jump due to temporary network conditions.

You may see something like this: small, small, small, small, BIG. That is why we need a reference point, which we can call the stable point. Without it, every RTT value looks equally confusing, and we cannot tell whether a packet was slow because the path itself is slow or because something temporary happened.

Baseline RTT

That stable point is the baseline RTT. Baseline RTT means the minimum RTT observed over time. This represents the RTT without temporary effects.

For example, in the above example, our repeated measurements show minimum RTT ≈ 18 ms. 18 ms becomes our baseline RTT. You can think of baseline RTT as the fastest possible RTT for a given path, representing the calm state of the network where packets do not wait in queues, there is no congestion, and no retransmissions occur.

In other words, baseline RTT reflects what the network is capable of when nothing unusual is happening. The best happy case that usually excludes temporary effects.

Why Baseline RTT Matters

Once we have a baseline RTT, individual RTT measurements stop feeling random. We can see when an RTT is close to the baseline, when it is higher than expected, and when extra delay has been introduced by temporary network conditions.

Without a baseline RTT, each RTT value stands alone, and comparison becomes guesswork. With a baseline in place, RTT values gain meaning, variation becomes visible, and we are finally able to reason about what causes RTT to increase, which naturally leads to jitter.

This is the point where we are finally ready to talk about what causes RTT to increase, which leads naturally to jitter.

What is Jitter?

Now comes Jitter. Once we have a baseline RTT, something important becomes clear. Most RTT values are not equal to the baseline. They are usually higher.

So the next natural question is: If baseline RTT shows the calm network, what is causing the RTT to increase in the other measurements?

That extra part is what we call jitter.

What Jitter Actually Means

Jitter is the extra delay added on top of the baseline RTT. In simple words, baseline RTT shows what the network can do when nothing is wrong, while jitter describes what happens when the network becomes busy, and packets experience extra delay.

So every observed RTT can be thought of like this: Observed RTT = Baseline RTT + Extra Delay

Example

Baseline RTT = 18 ms. That extra delay is jitter.

There are two important points to remember. First, jitter is always positive because a packet can be delayed but can never arrive faster than the baseline RTT. Second, baseline RTT acts as the reference point, which means jitter only exists relative to that baseline. Without a baseline, jitter has no meaning.

Where Jitter Comes From

Jitter appears when packets do not move immediately through the network.

This usually happens because of:

• Packets waiting in queues

• Routers delaying packets before forwarding

• Temporary congestion on links

• Retransmissions after drops

These effects are not constant. They come and go. Because of that, jitter is irregular and bursty. Sometimes it is very small, and at other times it can suddenly become large.

What Jitter Tells Us

At this stage, jitter is still just an observation. It tells us how unstable the network timing is and how often packets experience extra delay. We are not making decisions yet. We are only describing what the network is doing.

How TCP Learns RTT and Jitter

We have seen that:

• RTT changes over time

• Baseline RTT gives us a reference

• Jitter explains extra delay

So, up to this point, we have only been observing the network. But now a new question appears: If RTT keeps changing, and if delay and jitter exist, who is actually watching all this? More importantly, who decides when waiting is normal and when waiting becomes a problem?

This is the point where TCP enters the picture. TCP is the component that observes these timing changes and uses them to decide what to do next.

TCP Does Not Know RTT in Advance

TCP does not start with any knowledge of how long the path is, how stable the network will be, or how much delay to expect. It learns all of this dynamically while the connection is running.

TCP learns everything while the connection is running, only by looking at time. Every time TCP sends data and receives an acknowledgement, it gets one RTT sample. Over time, these samples are used to build expectations.

To make sense of these timing samples, TCP maintains two internal values that summarize what it has learned so far.

SRTT (Smoothed RTT)

SRTT is the RTT that TCP expects most of the time. It is not the minimum RTT, and it is not a simple average. It is a smoothed value that represents the normal RTT that the TCP has learned from recent history. This means recent RTT measurements matter more, while older RTT measurements gradually matter less.

Because of this, SRTT does not jump because of a single delayed packet. Instead, it adapts gradually as network conditions change.

For example, suppose TCP observes these RTT samples (in ms): 48, 50, 49, 51, 50.

Then TCP smooths these values into a stable expectation, such as: SRTT ≈ 50 ms.

You can think of SRTT as: The RTT that TCP believes is reasonable for this connection, based mostly on recent history. It is a memory-weighted average, biased toward recent RTT values.

RTTVAR (RTT Variance)

RTTVAR tells TCP how much RTT is changing. Now compare two situations.

Stable RTT

RTT samples: 49, 50, 51, 50

Because these values are close to each other, the variation is small, RTTVAR remains low, and TCP feels confident about its timing estimates.

Unstable RTT

RTT samples: 50, 52, 90, 48

Here, the sudden jump increases variation, causes RTTVAR to rise, and makes TCP less confident about its timing.

Why TCP Needs Both

SRTT alone is not enough for TCP to make reliable timing decisions. If TCP only knew that the RTT is around 50 ms, it would still have no way to tell whether delays are stable or whether sudden spikes are common.

RTTVAR fills this gap by capturing how much RTT changes over time. While SRTT tells TCP what RTT to expect under normal conditions, RTTVAR tells TCP how confident it should be in that expectation.

At this stage, TCP is still learning, not judging. It is building a timing model of the network.

So far, the network produces RTT variation, baseline RTT provides a calm reference, jitter explains extra delay, and TCP observes all of this using SRTT and RTTVAR.

TCP now has expectations. Only after this point does TCP start making decisions. And one of those decisions is packet loss.

How TCP Decides Packet Loss

Now that TCP has learned what RTT usually looks like and how much it varies, it has to answer one important question: How long should I wait before assuming a packet is gone?

This is where packet loss comes in.

TCP Never Sees a Packet Being Dropped

TCP does not see routers, queues, or links, and it does not know where packets go. TCP only sees time. It sends data and then waits.

If the acknowledgment arrives in time, everything is fine. If it does not, TCP must decide what to do next.

Retransmission Timeout (RTO)

To make this decision, TCP uses the Retransmission Timeout, or RTO. RTO is not random. It is computed from what TCP has already learned about network timing.

Conceptually, RTO is calculated as:

RTO=SRTT+max(𝐺,4×RTTVAR)

Here, SRTT sets the expected delay, while RTTVAR adds extra margin to account for jitter. As a result, RTO represents how long TCP is willing to wait, based on how uncertain the network timing is.

Suppose TCP has learned that the SRTT is 50 ms and the RTTVAR is 5 ms. In that case, the RTO becomes 70 ms.

RTO = 50 + 4 × 5
RTO = 70 ms

Now TCP behavior is simple:

• ACK arrives at 60 ms → delay

• ACK arrives at 75 ms → packet loss

The network is the same, and the packet is the same. Only the arrival time changes, and that alone leads to a different decision.

Delay vs Packet Loss

TCP logic is simple. If a packet arrives before the RTO expires, it is treated as delay. If it does not arrive before the RTO, TCP declares it lost.

This leads to an important rule: packet loss is a timing decision, not a certainty. The packet may still arrive later, but once the RTO expires, TCP has already acted.

How Jitter Turns Into Packet Loss

This behaviour connects directly to jitter. As long as jitter stays within the RTO window, packets are delayed but not considered lost. When jitter becomes large enough that delays cross the RTO boundary, TCP interprets delay as packet loss.

So packet loss does not always mean a packet disappeared. Often, it means the network timing has become too unpredictable.

Conclusion

At this point, everything connects: RTT, jitter, and packet loss are not separate network metrics. They describe different parts of the same timing process.

• RTT shows how long communication usually takes.

• Baseline RTT gives a stable reference.

• Jitter explains why delays change.

• Packet loss appears when that variation exceeds what the protocol can tolerate.

Once this flow is clear, network behavior stops feeling random. It becomes a matter of timing, uncertainty, and decisions.

Logs keep track of what’s happening inside your code so that when things go wrong, you don’t have to guess. They’re similar to print or console.log, but more powerful.

In this tutorial, I will use Python to create and walk you through some logging code examples.

Before we talk about logs, let’s understand the different error types you might use or encounter.

Types of Errors

When you’re building a production-level application, you need to display errors based on their severity. There are several error types, and the most important ones are:

• DEBUG: Detailed information, typically useful for diagnosing problems.

• INFO: General information about the program’s progress.

• WARNING: Something unexpected happened, but it’s not critical.

• ERROR: An error occurred, but the program can still run.

• CRITICAL: A very serious error that may stop the program from running.

What is Logging?

Now, let’s get straight to the point and understand what logging is.

In simple terms, logs or logging is the act of recording information about everything your program does. The recorded information could be anything, from basic details like which functions were called to more detailed ones like tracking errors or performance issues.

Why Do We Need Logging?

You might be thinking, "If logs are printing errors, info, and so on, I can just use print statements. Why do I need logging?" Well, print works, but logging gives you more control:

↳ It can store messages in a file.
↳ It has different levels (info, warning, error, and so on).
↳ You can filter messages based on importance.
↳ It helps in debugging without cluttering your code.

These are things print statements can't do effectively.

How to Add Logs in Python

In Python, the logging module is built specifically for logging purposes.

Let’s set up some logs to see how they work.

Step 1: Import the Logging Module

To start using logging, we need to import the module:

import logging

Step 2: Log Messages

Now, you can start logging messages in your program. You can use different log levels based on the importance of the message. As a reminder, those levels are (from least to most urgent):

• DEBUG

• INFO

• WARNING

• ERROR

• CRITICAL

Let’s log a simple message at each level:

logging.debug("This is a debug message")
logging.info("This is an info message")
logging.warning("This is a warning message")
logging.error("This is an error message")
logging.critical("This is a critical message")

When you run this, you’ll see a message printed to the console, similar to this:

You might wonder why you don’t see the DEBUG and INFO messages. The default logging level prevents this.

By default, the logging level is set to WARNING. This means that only messages with a severity of WARNING or higher will be displayed (that is, WARNING, ERROR, and CRITICAL).

Step 3: Set Up the Basic Configuration

To see the debug and info messages, we need to set the logging level DEBUG before running the code.

This means we need to configure the logs. So to do this, use the method basicConfig below:

logging.basicConfig(level=logging.DEBUG)

This basic configuration allows you to log messages at the DEBUG level or higher. You can change the level depending on the type of logs you want.

Now, all logs are printing:

Step 4: Log to a File

Now, let’s save these logs in a file so we can keep track of errors, as well as when they occurred. To do this, update the configuration:

logging.basicConfig(filename='data_log.log', level=logging.DEBUG, 
                    format='%(asctime)s - %(levelname)s - %(message)s')

Here:

• asctime – The time when the event occurred.

• levelname – The type of the log (for example, DEBUG, INFO).

• message – The message we display.

Now, when you run the program, the log file will generate and save your logs, showing the exact timing, error type, and message. Like this:

How to Use Loggers for More Control

If you’re working on a large project, you might want a utility logger that you can use anywhere in the code. Let’s create this custom logger.

First, we’ll update the basicConfig to add the filename, line number, and ensure it writes everything, even special characters:

logging.basicConfig(
        filename=log_file,
        level=logging.DEBUG,
        format='%(asctime)s - %(levelname)s - %(filename)s:%(lineno)d - %(message)s', 
        filemode='w',
        encoding='utf-8' 
    )

Explanation:

• encoding='utf-8' — Ensures special characters are logged.

• %(filename)s:%(lineno)d — Logs the filename and line number where the log was generated.

Now, let’s set up a custom console logger:

  console_handler = logging.StreamHandler()
  console_handler.setLevel(logging.DEBUG)
  console_formatter = logging.Formatter('%(asctime)s - %(levelname)s - %(filename)s:%(lineno)d - %(message)s')  # Added line number
  console_handler.setFormatter(console_formatter)


   logging.getLogger().addHandler(console_handler)

This setup does the following:

• console_handler: Sends log messages to the console (stdout).

• console_formatter: Formats the log message with time, level, filename, line number, and the message.

• logging.getLogger().addHandler(console_handler): Adds the custom handler to the root logger, so the log messages are printed to the console.

Full Example Code

import logging
import os
from datetime import datetime

def setup_daily_logger():
    base_dir = os.path.dirname(os.path.abspath(__file__))
    log_dir = os.path.join(base_dir, 'logs')  
    os.makedirs(log_dir, exist_ok=True)


    current_time = datetime.now().strftime("%m_%d_%y_%I_%M_%p")
    log_file = os.path.join(log_dir, f"{current_time}.log")


    logging.basicConfig(
        filename=log_file,
        level=logging.DEBUG,
        format='%(asctime)s - %(levelname)s - %(filename)s:%(lineno)d - %(message)s', 
        filemode='w',
        encoding='utf-8' 
    )


    console_handler = logging.StreamHandler()
    console_handler.setLevel(logging.DEBUG)
    console_formatter = logging.Formatter('%(asctime)s - %(levelname)s - %(filename)s:%(lineno)d - %(message)s')  # Added line number
    console_handler.setFormatter(console_formatter)


    logging.getLogger().addHandler(console_handler)


    return logging.getLogger(__name__)

What Happens Now?

Now, whenever you run the program, a new log file will be created in the logs folder. Each time the program is executed, a new log file with a unique timestamp will be generated.

Like this:

These logs will give you a clear picture of your program’s behavior and help with debugging.

I hope this article helped you get a clearer picture of logs and their importance in programming.

Practical Real-World Examples

Now that you understand what logs are and how to set them up in Python, let’s look at real-world use cases.

1. Bot: Scraping Korea’s Largest Property Website

Here’s an example of a bot designed to scrape Korea’s biggest property website.

• The logs show every step the bot takes, making it easier to track progress.

• If an error occurs at any step, it gets recorded in the log file.

• Even if the bot crashes, I can check the logs to pinpoint where things went wrong.

One of the methods in this bot’s class uses logging to track whether the bot correctly selects the province.

Here:

• If an error or warning occurs, it’s saved in the log file.

• Later, you can review the logs and find out exactly what happened

2. Bot: Scraping Facebook Groups

Now, let’s see how logging helps in a Facebook group scraper.

Error Tracking

• At one point, the bot failed due to an error.

• Since we had logging in place, the error was saved in the log file.

• This allows you to quickly find out what went wrong.

Here, you see the exact filename and line number where the error occurs.

Once we identified and fixed the issue, the bot started working again.

It captures every detail in the log, saving hours of debugging by pinpointing where errors occur.

Debugging Made Easy

• The logs recorded every detail of the bot’s execution.

• This can save you hours of debugging because you’ll know exactly where the error occurred.

Conclusion

Logging is one of those things no one thinks about until something breaks. But when it does, logs become your best friend.

Remember:

• Logging isn’t just for error tracking—it helps you monitor your program’s flow.

• Instead of guessing what went wrong, check the logs. The answer is usually right there.

Make sure to add logging to your code. You’ll thank yourself later!

Stay Connected - @syedamahamfahim 🐬

A PID is a unique identifier that helps the operating system track and manage running programs.

In this article, we’ll explore what a Process ID (PID) is, why it’s important, and how you can use it to manage processes, including terminating a program when necessary.

Understanding PIDs: How Does a Computer Identify Running Programs?

Let’s consider two Python scripts:

• hello_maham.py → print("Hello Maham")

• hello_amna.py → print("Hello Amna")

How does the computer know that hello_maham.py should show the output "Hello Maham" and not "Hello Amna" from hello_amna.py?

If you think it just happens magically, then think again! This happens because of something called a Process ID (PID).

In any operating system, processes are constantly running in the background to execute tasks. Whether it’s a program you launched manually or a system task running automatically, each of these processes is assigned a unique PID.

Let’s break this down further.

What is a Process ID (PID)?

Simply put,

A Process ID (PID) is a unique identifier assigned to each process running in an operating system.

Let’s understand what’s going on in the background.

Whenever a program runs, no matter the language, it needs memory and time to execute. So, when you run a program, the operating system creates a new process for it. To identify the program, the computer assigns it a unique identifier – the Process ID – and then it begins execution.

Let’s revisit our previous example:

• When you run hello_maham.py, the system assigns a unique PID to it.

• Similarly, when you run hello_amna.py, it gets its own unique PID.

This is why the outputs of both scripts don’t overlap!

Now, you got it? Each time a new process is created, the system ensures that every process gets a different PID. This PID is used by the system to manage and interact with processes. Its called Uniqueness Of PIDs

How Does the Computer Handle This ID?

Now you may wonder, does the computer have millions of PIDs? After all, we could be running many programs at once.

The answer is no. Once a process ends, the PID becomes available again for reuse. This means that PIDs are reusable, and there is no shortage of them.

But Why and When Do I Need PIDs?

Now that you know what a PID is, you might be wondering: Why do I need this?

Well, PIDs are actually very useful for system administrators and developers. They help in:

System admins and developers manage processes. Like, if something’s not working properly, you need to be able to find and stop the specific process causing the issue, right?

PIDs are also important for resource management. The operating system uses them to allocate memory and CPU time to each process, so no one program hogs everything.

How to Find the PID of a Running Program

Up until now, we've covered the theoretical concepts. Now, you might be wondering: How do I actually find the PID of a program on my computer?

Well, here are some simple ways to find the PID of a running program using various commands in the terminal.

Note, that I’ve used Bash to execute the PID command and included a screenshot for it. But for other terminals like CMD and PowerShell, the respective commands are mentioned at the end.

Some of these methods include:

1. Using the ps Command

The ps command shows a snapshot of the current running processes and their PIDs.

ps aux | grep <program_name>

Here’s an example:

ps aux | grep python

This command will display all the Python processes running on the system, along with their PIDs.

2. Using the top Command

The top command shows real-time information about processes running on the system, including their PIDs.

top

Look under the PID column to find the process you're interested in.

How to Kill a Process Using its PID

What if you want to kill the program? Whether it’s a cron job or a program that is misbehaving or running for too long, how can you stop it using the PID?

Let’s go through how you can do that:

1. Using the kill Command

To terminate a process, use the kill command followed by the PID:

kill <PID>

Here’s an example:

kill 1234

This command will gracefully terminate the process with PID 1234.

2. Using the kill -9 Command (Force Kill)

If the process does not stop after using the regular kill command, you can force kill it using the kill -9 command:

kill -9 <PID>

Here’s an example:

kill -9 1234

This forcefully terminates the process and bypasses any shutdown procedures it may have, so make sure you use it with caution.

How to Stop Cron Jobs Using a PID – Practical Example

So, let’s say you’ve got a cron job running, and it’s acting up. How do you stop it?

Cron jobs are scheduled tasks that run automatically at specific intervals.

If you need to stop a running cron job, you can use the PID of the process running the cron job.

Stop a Running Cron Job

If you need to stop a running cron job, you can use the PID of the process running the cron job.

Here’s how to kill a cron job:

1. Find the PID: Use the ps or pgrep command to find the PID of the cron job. Example:

    ps aux | grep cron
   

2. Kill the Cron Job: Once you find the PID of the cron job, use the kill or kill -9 command to stop it.

Commands For Other Terminals:

Here’s how to manage processes in different terminals:

Conclusion

Understanding Process IDs is key to managing processes on your computer. With simple commands, you can easily find and stop problematic processes, ensuring smooth system operation.

So, stay in control of your system with PIDs!

Stay connected — @syedamahamfahim 🐬

In this article, you’ll explore how computers manage continuous values, including the concept of precision errors. We’ll examine the floating-point arithmetic problem, a universal issue that affects many programming languages. We’ll focus specifically on how JavaScript addresses this challenge.

Additionally, you’ll learn how binary operations work behind the scenes, the threshold at which JavaScript truncates numbers based on the IEEE 754 standard, and introduce BigInt as a solution for accurately handling larger numbers without precision loss.

First, let's consider an example. Can you guess the output of this operation?

console.log(0.1 + 0.2);

You may think the answer is 0.3, right? But no, the actual output is:

Output: 0.30000000000000004

You must be wondering why this is happening. Why so many extra zeros, and why does it end with a 4?

The answer is simple: the numbers 0.1 and 0.2 cannot be precisely represented in JavaScript (that is, "exactly" or "accurately.")

It sounds simple, right? But the explanation is a bit more complex.

So, what do you think—bug or feature?

Well, it’s not a bug. It’s actually a fundamental issue with how computers handle numbers, specifically floating-point numbers.

Why Does This Happen?

Let’s understand this with basic math.

The fraction 1/3 is represented in decimal by 0.33333... and it never ends. This means that 3 repeats itself infinitely. We can’t write it down exactly, so we approximate it to something like 0.333 or 0.333333 to save time and space.

Similarly, in a computer, we also have to approximate because 1/3 or 0.3333... would be a very large number and take up infinite space (which we don’t have).

This leads to what we call the floating-point arithmetic problem.

Floating-Point Arithmetic Problem

In simple terms, floating-point numbers are numbers that cannot be written down exactly, so we approximate them. In a computer, this kind of approximation can lead to small precision errors, which we call the floating-point arithmetic problem.

Binary Explanation

Now that we've covered the simple explanation, let’s also understand this in binary terms. JavaScript handles everything in binary behind the scenes.

Binary is a number system that only uses two digits: 0 and 1.

Why Can’t 0.1 and 0.2 Be Represented Exactly in Binary?

The core issue is that not all decimal numbers can be perfectly represented as binary fractions.

Let’s take 0.1 as an example:

When you try to represent 0.1 in binary, you’ll find out that it can’t be expressed as a finite binary fraction. Instead, it becomes a repeating fraction, much like how 1/3 in decimal becomes 0.333..., repeating forever.

In binary, 0.1 becomes:

0.0001100110011001100110011001100110011... (repeating infinitely)

Since computers have limited memory, they can’t store this infinite sequence exactly. Instead, they have to cut off the number at some point, which introduces a small rounding error. This is why 0.1 in binary is only an approximation of the actual value.

Like 0.1, 0.2 can’t be exactly represented in binary. It becomes:

0.00110011001100110011001100110011... (repeating infinitely)

Again, the computer truncates (cutting off part of a number to fit a limit or remove extra digits) this infinite binary sequence, leading to a small error in representation.

So, what happens when we add 0.1 + 0.2? When you add 0.1 + 0.2 in JavaScript, the binary approximations for 0.1 and 0.2 are added together. But since both values are only approximations, the result is also an approximation.

Instead of getting exactly 0.3, you get something close to this:

console.log(0.1 + 0.2); // Output: 0.30000000000000004

This slight error occurs because neither 0.1 nor 0.2 can be represented exactly in binary, so the final result has a small rounding error.

How Does JavaScript Truncate the Number?

Now, the question arises: how does JavaScript know when to truncate the value?

( Truncation means cutting off or shortening a number by removing extra digits beyond a certain point. )

There’s a maximum and minimum limit for it.

To handle this in the computer world, we have a standard that defines how floating-point numbers are stored and calculated.

IEEE 754 Standard

JavaScript uses the IEEE 754 standard to handle floating-point arithmetic.

The standard defines safe integer limits for the Number type in JavaScript without precision loss:

• Maximum Safe Integer: 2^53 - 1 or 9007199254740991

• Minimum Safe Integer: -(2^53 - 1) or -9007199254740991

Beyond these limits, JavaScript cannot accurately represent integers due to the way floating-point arithmetic works.

For this reason, JavaScript provides two constants to represent these limits:

• Number.MAX_SAFE_INTEGER

• Number.MIN_SAFE_INTEGER

What If I Need a Bigger Number?

If you need to work with numbers larger than the Maximum Safe Integer (like those used in cryptography or finance), JavaScript has a solution: BigInt.

Enter BigInt

BigInt is a built-in object that allows you to work with whole numbers beyond the safe integer limit. It enables you to represent numbers larger than 9007199254740991, so you don't need to worry about precision errors here!

To use BigInt, simply append an n to the end of an integer literal:

const bigNumber = 1234567890123456789012345678901234567890n;

Alternatively, you can use the BigInt constructor:

const bigNumber = BigInt("1234567890123456789012345678901234567890");

Operations with BigInt

You can perform arithmetic operations with BigInt, like addition, subtraction, multiplication, and even exponentiation. However, there’s a catch: you can’t mix BigInt with regular Number types in arithmetic operations without explicitly converting between them.

For example, this won’t work:

let result = bigNumber + 5; // Error: cannot mix BigInt and other types

You would need to convert the Number to BigInt first:

let result = bigNumber + BigInt(5); // Now it works!

Where Do We Use BigInt?

BigInt is particularly useful in areas requiring precision, such as:

• Cryptographic algorithms

• Handling large datasets

• Financial calculations requiring exactness

In Summary

• The safe integer limit in JavaScript ensures accurate number representation for integers between -(2^53 - 1) and 2^53 - 1.

• Precision errors occur due to floating-point arithmetic when handling certain numbers (like 0.1 + 0.2).

• If you need numbers bigger than the safe limit, BigInt is your friend. But remember, mixing BigInt and Number types require explicit conversions.