Peakhour.IO - Networking

How MTU Fingerprinting Identifies VPNs and Mobile Users

2025-01-15T14:00:00+11:00

For traffic analysis, it helps to know how a user reached the service. Are they on a home network, a mobile connection, or a VPN? Deep packet inspection is invasive, but TCP handshake metadata can still carry useful context about the Maximum Transmission Unit (MTU) a connection appears to be using. By analysing those inferred MTU values, we can build "fingerprints" that point to the underlying network technology carrying the connection.

This article looks at how common technologies affect MTU values and shows how a SQL query can turn that data into useful network labels.

What is MTU and Why Does it Change?

The Maximum Transmission Unit (MTU) is the largest data packet, or frame, that a network-connected device can transmit. On standard Ethernet networks, this value is typically 1500 bytes. Larger payloads have to be split into chunks that fit that limit.

Encapsulation and Tunneling

The value starts to shift when tunnelling protocols are involved, including those used by VPNs and mobile networks. These protocols wrap the original data packet inside another packet, a process called encapsulation. The outer packet has its own headers for routing and management.

This encapsulation "steals" space from the original 1500 bytes available on the physical network. If a tunnelling protocol adds 60 bytes of headers, for example, the maximum size for the original data packet is now 1440 bytes (1500 - 60).

The Problem with Fragmentation

What happens if a device tries to send a 1500-byte packet through this 1440-byte tunnel? The packet has to be broken into smaller pieces, a process called fragmentation. It works, but it is inefficient. Fragmentation consumes CPU resources on the router performing it, adds header overhead to each fragment, and requires the receiving device to reassemble the pieces. The result is lower speed and higher latency.

To avoid that penalty, operating systems and network devices reduce the MTU of the connection to account for the tunnel's overhead. The amount of the reduction follows from the tunnelling protocol in use. That predictable drop is the basis for MTU fingerprinting.

A Guide to Common MTU Values

Different technologies add different overheads, which produces distinct MTU values.

WireGuard

WireGuard is a modern VPN known for its efficiency, but it still adds overhead.

IPv4 Overhead: 60 bytes (20-byte IPv4 header + 8-byte UDP header + 32-byte WireGuard header).
IPv6 Overhead: 80 bytes (40-byte IPv6 header + 8-byte UDP header + 32-byte WireGuard header).

On a standard 1500-byte network, that produces predictable MTU values:

1500 - 60 = 1440 bytes (WireGuard over IPv4)
1500 - 80 = 1420 bytes (WireGuard over IPv6)

There is a special case with ISPs that use DS-Lite (Dual-Stack Lite) to carry IPv4 traffic over an IPv6 network. This adds another 40-byte IPv6 header, reducing the MTU further.

1420 - 40 = 1380 bytes (WireGuard over DS-Lite)

OpenVPN

OpenVPN is another common VPN solution, but its fingerprint is less tidy. Instead of setting a static interface MTU, OpenVPN often uses a feature called mssfix. This dynamically adjusts the Maximum Segment Size (MSS) value within the TCP headers of encapsulated packets to prevent fragmentation.

The MSS is the MTU minus the IP and TCP header sizes (typically 40 bytes for IPv4). The exact MSS value, and therefore the effective MTU, depends on OpenVPN's configuration, including the transport protocol (UDP or TCP), cipher, MAC algorithm, and compression. As noted by security researcher ValdikSS, these unique MSS values can be used to fingerprint a connection with high precision. For example, a common configuration might result in an MSS of 1369, which corresponds to an effective MTU of 1409 (1369 + 40).

For general analysis, connections with an MTU around 1400 or 1380 bytes often indicate OpenVPN or other VPN usage, especially when seen with other factors.

Mobile Networks (LTE & 5G)

Mobile networks also modify MTU values. When your phone connects to the internet, its data is tunnelled through the carrier's network using the GPRS Tunnelling Protocol (GTP). This encapsulation adds its own layer of headers.

As detailed by Nick vs Networking, the typical overhead for GTP traffic over an Ethernet transport network is 50 bytes:

14 bytes for the Ethernet header
20 bytes for the outer IPv4 header
8 bytes for the UDP header
8 bytes for the GTP header

For a mobile carrier using a standard 1500-byte MTU on its transport network, the maximum MTU available to the user's device is 1450 bytes (1500 - 50).

Mobile devices don't guess this value; they are explicitly told what MTU to use by the network during the connection setup process (via Protocol Configuration Options). Mobile operators have two choices to avoid fragmentation:

Increase Transport MTU: Enable jumbo frames (for example, 1600 bytes or more) on their internal network to accommodate the 50-byte overhead and still provide a full 1500-byte MTU to the user.
Lower Advertised MTU: Advertise a lower MTU to the user's device. This is why values such as 1450 are common. Some operators may configure a more conservative MTU, such as 1300 bytes, to maintain stability across all parts of their network.

Other Common Values

Standard Ethernet: The baseline is 1500 bytes.
PPPoE: Common for DSL connections, adds 8 bytes of overhead, resulting in an MTU of 1492 bytes.
IPv6 Minimum: The IPv6 specification mandates a minimum MTU of 1280 bytes, so this value is also a significant marker.

Analysis with SQL

With this context, we can analyse network logs to classify user connections. The following SQL query buckets and attributes MTU values from a large dataset, turning raw numbers into meaningful labels.

The query works in several stages:

Extract Data: It parses the MTU from a fingerprint string in the logs.
Bucket MTUs: It uses a CASE statement to group MTUs. Specific known values, such as 1500, 1440, 1420, and 1380, go into their own buckets. Jumbo frames (>1500) are grouped into 100-byte buckets, and everything else is grouped into 20-byte buckets.
Attribute Buckets: In the final SELECT, another CASE statement translates those numeric buckets into human-readable descriptions based on the fingerprints we've identified.

The Query

-- Bucketing logic and attribution informed by research from:
-- https://ripx80.de/posts/06-wg-mtu/ (WireGuard)
-- https://medium.com/@ValdikSS/detecting-vpn-and-its-configuration-and-proxy-users-on-the-server-side-1bcc59742413 (OpenVPN)
-- https://nickvsnetworking.com/mtu-in-lte-5g-transmission-networks-part-1/ (Mobile Networks)
WITH base_data AS (
    SELECT
        toInt32OrNull(splitByChar(':', splitByChar(',', synner_fingerprint)[1])[4]) AS mtu,
        toInt32OrNull(splitByChar(':', splitByChar(',', synner_fingerprint)[1])[5]) AS wsize,
        toInt32OrNull(splitByChar(':', splitByChar(',', synner_fingerprint)[2])[1]) AS scale,
        (tls.handshake_rtt_us - tcp.min_rtt_us) >= 65000 AS is_high_latency
    FROM logs.client_logs
    WHERE time >= '2025-07-01' AND shielded = 0
),
main_aggs AS (
    SELECT
        CASE
            WHEN mtu = 1500 THEN 1500
            WHEN mtu = 1440 THEN 1440
            WHEN mtu = 1420 THEN 1420
            WHEN mtu = 1380 THEN 1380
            WHEN mtu > 1500 THEN 1501 + intDiv(mtu - 1501, 100) * 100
            ELSE intDiv(mtu, 20) * 20
        END AS mtu_bucket,
        countIf(is_high_latency) AS high_latency_count,
        countIf(not is_high_latency) AS normal_latency_count,
        round(avg(wsize * pow(2, scale))) AS avg_real_wsize
    FROM base_data
    WHERE mtu IS NOT NULL AND wsize IS NOT NULL AND scale IS NOT NULL
    GROUP BY mtu_bucket
),
top_wsizes AS (
    SELECT
        mtu_bucket,
        groupArray((wsize, cnt)) AS top_wsizes
    FROM
    (
        SELECT
            CASE
                WHEN mtu = 1500 THEN 1500
                WHEN mtu = 1440 THEN 1440
                WHEN mtu = 1420 THEN 1420
                WHEN mtu = 1380 THEN 1380
                WHEN mtu > 1500 THEN 1501 + intDiv(mtu - 1501, 100) * 100
                ELSE intDiv(mtu, 20) * 20
            END AS mtu_bucket,
            wsize,
            count() AS cnt,
            row_number() OVER (PARTITION BY mtu_bucket ORDER BY cnt DESC) AS rn
        FROM base_data
        WHERE mtu IS NOT NULL AND wsize IS NOT NULL AND scale IS NOT NULL
        GROUP BY mtu_bucket, wsize
    )
    WHERE rn <= 5
    GROUP BY mtu_bucket
),
top_scales AS (
    SELECT
        mtu_bucket,
        groupArray((scale, cnt)) AS top_scales
    FROM
    (
        SELECT
            CASE
                WHEN mtu = 1500 THEN 1500
                WHEN mtu = 1440 THEN 1440
                WHEN mtu = 1420 THEN 1420
                WHEN mtu = 1380 THEN 1380
                WHEN mtu > 1500 THEN 1501 + intDiv(mtu - 1501, 100) * 100
                ELSE intDiv(mtu, 20) * 20
            END AS mtu_bucket,
            scale,
            count() AS cnt,
            row_number() OVER (PARTITION BY mtu_bucket ORDER BY cnt DESC) AS rn
        FROM base_data
        WHERE mtu IS NOT NULL AND wsize IS NOT NULL AND scale IS NOT NULL
        GROUP BY mtu_bucket, scale
    )
    WHERE rn <= 5
    GROUP BY mtu_bucket
)
SELECT
    CASE
        WHEN mtu_bucket IN (1500, 1440, 1420, 1380) THEN toString(mtu_bucket)
        WHEN mtu_bucket > 1500 THEN concat(toString(mtu_bucket), '-', toString(mtu_bucket + 99))
        ELSE concat(toString(mtu_bucket), '-', toString(mtu_bucket + 19))
    END AS mtu_range,
    CASE
        WHEN mtu_bucket = 1500 THEN 'Standard Ethernet'
        WHEN mtu_bucket = 1480 THEN 'Likely PPPoE (e.g., 1492)'
        WHEN mtu_bucket = 1460 THEN 'Likely DS-Lite/GRE Tunnel'
        WHEN mtu_bucket = 1440 THEN 'Likely Mobile LTE/5G (e.g., 1450) / WireGuard over IPv4'
        WHEN mtu_bucket = 1420 THEN 'WireGuard over IPv6'
        WHEN mtu_bucket = 1400 THEN 'Likely OpenVPN / Mobile'
        WHEN mtu_bucket = 1380 THEN 'Likely OpenVPN / WireGuard over DS-Lite / Mobile'
        WHEN mtu_bucket = 1300 THEN 'Likely Mobile LTE/5G configured'
        WHEN mtu_bucket = 1280 THEN 'IPv6 Minimum'
        WHEN mtu_bucket > 1500 THEN 'Jumbo Frame'
        ELSE 'Other'
    END AS mtu_attribution,
    high_latency_count,
    normal_latency_count,
    round(high_latency_count / (high_latency_count + normal_latency_count), 2) AS high_latency_ratio,
    top_wsizes,
    top_scales,
    avg_real_wsize
FROM main_aggs
LEFT JOIN top_wsizes USING (mtu_bucket)
LEFT JOIN top_scales USING (mtu_bucket)
WHERE (high_latency_count + normal_latency_count) > 10000
ORDER BY mtu_bucket
LIMIT 50 FORMAT Vertical

Why Jumbo Frames Matter

Jumbo frames (MTU values greater than 1500 bytes) are a useful edge case in MTU fingerprinting. These frames, typically ranging from 9000-9216 bytes, are primarily used in high-performance computing environments, data centres, and enterprise networks where throughput optimisation is important.

When we detect jumbo frame MTUs in our analysis, they often indicate:

Enterprise Users: Corporate networks frequently enable jumbo frames for internal communications
Data Centre Traffic: Cloud services and CDNs often use jumbo frames between their infrastructure
High-Performance Applications: Video streaming, large file transfers, and backup operations can benefit from larger frame sizes
Network Misconfiguration: Jumbo frames sometimes appear because of network equipment misconfiguration

The presence of jumbo frames can help distinguish consumer and enterprise traffic, adding useful context for traffic classification and security analysis.

Practical Use Cases and Applications

MTU fingerprinting is useful across several security and operational domains:

Security Applications

VPN Detection for Compliance: Organisations can identify employees bypassing corporate network policies with personal VPNs, supporting compliance with data governance requirements.

Bot Traffic Classification: Automated traffic from residential proxy networks often shows consistent MTU patterns that differ from genuine residential users, improving bot detection.

Threat Intelligence Enhancement: Correlating MTU patterns with other indicators helps build broader threat profiles and improves attack attribution.

Network Operations

Performance Optimisation: Understanding the MTU distribution of your user base helps optimise content delivery and reduce fragmentation-related performance issues.

Infrastructure Planning: MTU analysis reveals the underlying network technologies your users employ, informing CDN placement and capacity planning decisions.

Quality of Service: Different MTU patterns correlate with connection quality, enabling proactive support for users on constrained networks.

Business Intelligence

Market Analysis: Geographic and demographic patterns in MTU distribution reveal technology adoption trends and market characteristics.

User Experience Optimisation: Identifying users on mobile or constrained networks enables adaptive content delivery and interface optimisation.

Dynamic Analysis vs Static IP Databases

MTU fingerprinting is a dynamic signal, which makes it useful alongside static IP reputation databases. It has several practical advantages:

Real-Time Adaptation

Static IP databases go stale. A residential IP address might be flagged as malicious based on historical activity, but MTU fingerprinting analyses the current network configuration. This dynamic approach captures the infrastructure being used at the moment of connection, providing more accurate and timely intelligence.

Circumvention Resistance

Attackers can rotate IP addresses or use clean residential proxies to bypass static blacklists. It is harder to manipulate the network characteristics that influence MTU values, because MTU is determined by the underlying network infrastructure.

Granular Classification

Where IP databases provide binary classifications (malicious/benign), MTU fingerprinting offers more detail on the specific technologies and configurations in use. This granularity enables more sophisticated risk assessment and response strategies.

Reduced False Positives

Static databases often flag legitimate users sharing IP addresses with malicious actors, which is common with residential ISPs and mobile carriers. MTU fingerprinting focuses on network behaviour rather than IP reputation, reducing false positive rates while maintaining security effectiveness.

Infrastructure Transparency

MTU analysis reveals the network path and technologies involved in a connection, providing transparency that static IP databases cannot match. This visibility enables more informed security decisions and a better understanding of threat actor capabilities.

Conclusion

MTU fingerprinting turns network metadata into useful context about the infrastructure behind a connection. Unlike static databases that rely on historical reputation, this dynamic analysis technique provides real-time insight into network technologies, user behaviours, and potential security threats.

By understanding MTU patterns, security teams can identify VPN usage, classify mobile traffic, detect residential proxy abuse, and optimise network performance. Its resistance to circumvention and low false-positive rates make it a useful addition to modern security architectures.

As network technologies continue to evolve, MTU fingerprinting provides a stable way to understand and classify traffic based on fundamental network characteristics rather than short-lived indicators. That makes it a practical signal for network security and operations.

Efficiently Generating and Printing All IPv4 Addresses in a Random Order

2023-05-15T13:00:00+10:00

In this article, we explored an efficient way to generate and print all possible IPv4 addresses in a random order using
a Linear Congruential Generator (LCG). The LCG, a pseudorandom number generator, helps generate the full range of IP
addresses without consuming vast amounts of memory, making this approach suitable for systems with memory constraints.
We also provided a Python script demonstrating the concept, along with a test case to verify its correctness.

We then delved into the importance of randomising IP addresses, highlighting its critical role in areas like security
testing, load balancing, enhancing privacy, and web scraping. However, while using this technique, it's essential to
respect privacy and legality, as misuse can lead to legal repercussions.

In summary, the ability to generate and print all IPv4 addresses in a random order is a powerful tool, especially in the
realm of networking and cybersecurity, and can be achieved efficiently using the LCG approach.

In networking, some tasks require generating and printing every possible IPv4 address. Doing that in random order without a large memory footprint is less straightforward. The IPv4 address space contains 2^32, or 4,294,967,296, values. Storing all of them in memory at once is not feasible for most systems.

This article uses a Linear Congruential Generator (LCG) to generate the full range without holding it in memory.

Linear Congruential Generator

A Linear Congruential Generator is a type of pseudorandom number generator that can run without storing the whole sequence. It generates each next value from a linear equation based on the previous value. The basic form of the LCG is:

X_(n+1) = (a*X_n + c) mod m

Here, a, c, and m are constants, and X_n is the nth number in the sequence. The initial seed or starting point of the sequence is X_0.

If we choose parameters such that the period of the LCG is maximum (equal to the modulus), and the modulus equals the range of numbers we're generating (the number of possible IPv4 addresses in this case), then the LCG should generate each number in the range exactly once before repeating.

Here is that idea in Python:

import ipaddress

def lcg(modulus, a, c, seed):
    """Linear congruential generator."""
    while True:
        seed = (a * seed + c) % modulus
        yield seed

start_ip_str = '0.0.0.0'
end_ip_str = '255.255.255.255'

start_ip = int(ipaddress.IPv4Address(start_ip_str))
end_ip = int(ipaddress.IPv4Address(end_ip_str))

modulus = end_ip - start_ip + 1
a = 1664525
c = 1013904223
seed = 1  # Arbitrary seed

generator = lcg(modulus, a, c, seed)

for _ in range(modulus):
    ip_int = start_ip + next(generator)
    ip = ipaddress.IPv4Address(ip_int)
    print(ip)

The script first defines the parameters of the LCG. a, c, and seed are set to values used in Numerical Recipes' LCG, a well-known and widely used LCG. The modulus is set to the total number of possible IPv4 addresses.

The function lcg() is implemented as a Python generator, yielding the next number in the sequence each time it is called.

The loop then generates and prints each IP address. It adds the output of the LCG to the start IP address, converts it back to an IP address string, and prints it.

This script generates and prints each IP address in random (more precisely, pseudorandom) order using very little memory. Each IP address is printed exactly once, assuming the period of the LCG is maximum.

The point is that a small pseudorandom number generator can walk a large range without materialising the whole list. The code can still be tweaked and optimised for specific requirements and constraints.

The Importance of Randomising IP Addresses

Randomising IP addresses has practical uses in several networking workflows:

1. Security Testing and Penetration Testing

In cybersecurity, randomising IP addresses can help simulate attacks on a network from various sources. By using a range of IP addresses in no particular order, penetration testers can mimic the unpredictable nature of real-world cyber threats and build more robust test scenarios.

2. Load Balancing and Network Traffic Simulation

Randomising IP addresses is also useful in network traffic simulations. Network engineers and administrators can use this approach to test network resilience and capacity. By sending requests to servers from randomised IP addresses, they can evaluate how well their load balancing strategies are functioning and whether the network can handle high traffic loads from various sources.

3. Anonymity and Privacy

In some cases, randomising IP addresses can help with privacy and anonymity. While it is not a foolproof method, using a different IP address for each request can make it more challenging for online trackers to monitor user activity. It is a common practice among privacy-focused internet users and is also used in some VPN (Virtual Private Network) services.

4. Web Scraping

Web scraping is another area where randomising IP addresses is useful. To prevent being blocked by anti-bot measures, web scrapers often need to rotate their IP addresses. By using a different IP address for each request, they can avoid being detected and blocked by the sites they are scraping.

Randomising IP addresses can be useful in these cases, but privacy and legality still matter. Unauthorised network scanning, privacy breaches, and cyberattacks are illegal and punishable under law.

Generating and printing every possible IPv4 address in a random order is a valuable technique with various applications, from network testing to privacy enhancement. With the Linear Congruential Generator approach, we can do it efficiently.

IP Threat Intelligence

2022-07-15T13:00:00+10:00

Threat intelligence helps organisations make earlier decisions about cyber attacks. One of the most common forms of threat intelligence in cyber security is IP reputation lists. For example, a given IP address might have a poor reputation for spam, ddos attacks, malware, and several other categories. IP reputation lists often form a front line of defence in Web Application Firewalls and cyber security solutions.

How Peakhour uses IP threat intelligence

Peakhour supports threat intelligence across more than 20 categories, including:

Active DDoS attacks
Brute forcing
Active attackers
Computers infected with malware
Anonymous Proxies
Forum Spammers
TOR anonymous users
IPs with poor reputation
Unroutable and unassigned IPs
Robots and web scrapers
Datacenter
Hosting Providers
Crawlers
And more

Customers have access to all 10 lists, which can be enabled as blocklists or used as part of a custom firewall rule, rate limiting rule, or page rule. For example, you may want to disallow POSTs from forum spammers, rate limit proxies, and outright deny traffic from known brute-forcing IPs.

Creating a spammer can't post rule

How does Peakhour assemble these lists?

The IP reputation lists are sourced from third-party sources, including open source intelligence feeds (OSINT), commercial feeds, community feeds, and our own threat intelligence. IPs are categorised into our pre-defined lists and made available to the WAF and rules engine. Each list is re-evaluated and updated based on the data provider's update schedule; some are updated every minute.

Internally managed feeds include bot sources that are verified using reverse DNS lookups, PTR record lookups, and WHOIS verification (such as Facebook IPs). WAF hits across customers are consolidated and made available as the Active Attacker list, which is updated in near real time. Our Malware and C&C nodes lists are generated from various partnerships.

The Anonymous Proxies list contains known open proxies, services that relay traffic without authentication, whilst our targeted VPN list tracks known third-party VPN services.

IPs are fed back into our system for re-evaluation to help identify emerging behaviour within our customer data.

Data visualisation

Requests from IPs that match a blocklist are tagged with the lists they belong to. Firewall events are enriched with this information, providing visibility into security threats. This context helps you decide how to handle requests, whether they should be blocked, rate limited or observed.

Firewall events generated by reputation matches

Blocks generated by our reputation lists can also be viewed in our analytics section.

Firewall events generated by reputation matches

Future work

We are working on additional data sources to further refine and expand our lists. This includes further segregating our data centre lists and categorising IPs that appear on several lists. We are also introducing our threat research centre to discover possible threats and enrich data blocked only by our WAF.

IP threat intelligence adds another layer of security to a cyber defence system. Peakhour sources and maintains up-to-date threat intelligence, helping our clients better protect themselves against would-be attackers.

See how Peakhour's IP threat intelligence supports the first line of defence for your applications. Contact our team to discuss your security requirements.

Setting Up A Chia Hobby Farm

2021-04-30T13:00:00+10:00

Here at Peakhour, when we're not making websites faster and more secure, we like new tech and we like a good scheme. We ran Seti@home while at uni, and mined some bitcoin back in its early days (unfortunately we don’t have them anymore). Just recently we decided to set up a Chia farm, not the super-food Chia, but the new crypto coin Chia!

What is Chia?

Chia is not just a cryptocurrency; it is a brand new blockchain and smart transaction platform that implements the first new Nakamoto consensus algorithm since Bitcoin. It was invented by the engineer behind BitTorrent, Bram Cohen, who set out to address the shortcomings of Bitcoin.

The Chia network is set to officially launch on May 3rd, and the crypto world is going crazy getting ready.

I thought Bitcoin was great, what’s wrong with it?

The major flaws that Chia sets out to address are:

The environmental impact

Without getting too technical, Bitcoin relies on very intensive computations to verify transactions (Proof of work). These computations are carried out by 'miners' who are rewarded for their efforts from an ever decreasing pool of possible bitcoin. As the blockchain gets older, the verification gets harder, and as a result the Bitcoin network is now consuming as much electricity as a mid-sized country like Argentina. Huge mining operations have been set up in China, and some even have dedicated power plants. One poster child for the environmental impacts of bitcoin is an Australian startup looking to reopen a decommissioned coal power plant to power its mining operations.

Possibility of manipulation

The huge energy requirements have led to massive server farms in cool regions near cheap electricity, concentrating mining in the hands of a few large players. This centralisation opens up Bitcoin to the possibility of manipulation as anyone with 50% of the network can effectively change the blockchain.

How does Chia address these issues with Bitcoin?

Chia has implemented a new consensus algorithm called proof of space and time. It relies on unused hard disk space, which lots of people have and can use free of charge. Again, without getting too technical, 'Farmers' seed unused space on their hard drive/SSD with 'plots' of cryptographic numbers. When verifying transactions, the network issues a challenge to the farmers, who then scan their plots for the closest answer. The farmer passes this answer back to a server on the network known as a 'timelord'. The farmer with the closest answer is rewarded with a coin.

The more 'plots' a farmer has, the higher the chance of winning a coin.

Setting up the Farm

We got excited about the idea of Chia being the next big thing and decided to hitch a ride on the bandwagon. We had a spare old computer lying around, so we decided to fill it up with as much storage as we could find and farm some Chia!

To set up a farm you need as much space for plots as you can get your hands on. The speed of this space is not critical, so you can use spinning drives. We found 12-terabyte NAS drives to be the sweet spot for bang for buck, and opted for 4x Seagate Ironwolf NAS drives from Scorptec. (Note: they’ve gone up $40 since we bought them!)

Seeding the plots, however, is VERY disk intensive, so you need speedy and reliable SSDs. Since they don't have moving parts you'd think that SSDs would be very reliable, but just like spinning drives, they wear out and eventually die. SSDs come with a TBW (Terabytes Written) rating which estimates the amount of writes you can do before the drive will die. Popular consumer SSDs like a 500GB Samsung EVO 870 have a TBW rating of 300. Chia recommends getting server-grade SSDs that have ratings into the Petabytes, but of course they come with a price to match.

We were limited by the age of our available motherboard, so we could only choose from SATA3-compatible drives. Appropriate enterprise SSDs were also unavailable, so in the end we settled on 500GB Seagate Firecuda 120s that are rated at 700 TBW (also from Scorptec). We decided on two so we could double the plotting rate.

Now we had our hands on the drives, we just had to install everything. Within a few hours of transferring components and wiring it up we were good to go and started plotting.

Our Chia Farm!

Final Thoughts

Our old hardware limits the speed of the SSDs and therefore the number of plots we generate. We're managing around 10 plots a day and will need close to 500 before we’ve filled the available storage.

When we bought our equipment (28th April) the chia calculator showed that we’d be earning around a coin a day when fully plotted. However, with the official launch of Chia imminent, the network has exploded in growth, passing 1 Exabyte (1000 Terabytes) just one day ago. It's now up to 1.68 Exabytes! So unfortunately our estimated time to a coin is down to one every 7 days. That’s still pretty good though, and if Chia does end up supplanting Bitcoin we might just make back the setup costs. It has been a fun exercise, even if we did spend too long on it, and if it does end up being a flash in the pan we can always use the drives for something else….