Normal view

There are new articles available, click to refresh the page.
Today — 22 July 2026Main stream

The Need for Speed: Internet Speed Measurement (or DIY?)

22 July 2026 at 14:00

Car enthusiasts want to know how quickly they can make a quarter mile. Weightlifters are forever trying to add one more plate to the bar. Internet denizens have their own favorite number to brag about: the result from a speed test.

The ritual is familiar. Close a few browser tabs, click the big “Go” button, and watch the needle climb. Perhaps you pay for gigabit service and see 940 megabits per second, which produces a satisfied nod. Perhaps you see 299 megabits and begin obsessing over network hardware. But before you get too excited either way, try another test. There is a fair chance it will give you a different answer.

That does not necessarily mean one test is lying. “Internet speed” is not a single physical quantity waiting to be measured. A speed test measures the performance of a particular device, over a particular local connection, through a particular ISP route, to a particular server, at a particular time using a particular test method. Change any of those things and the answer can change too.

The Usual Suspects

Ookla on a WiFi connection to a 1Gbit Ethernet network. The limiting factor is the 802.11s WiFi link between the computer’s Ethernet port and the router’s.

Speedtest by Ookla is probably the best-known test. It selects a nearby server, although you can choose another. It attempts to saturate the connection with multiple simultaneous transfers. That makes it good at answering the question most consumers are asking: approximately how much aggregate bandwidth can this Internet connection deliver?

Running several connections matters. A single TCP connection must gradually increase its sending rate while reacting to round-trip time, packet loss, receive-window limits, and congestion-control behavior. On a high-bandwidth or high-latency path, one connection may not fill the available pipe. Several parallel connections can ramp up independently and make it easier to reach the link’s aggregate capacity. That number is valid, but it represents something like a busy household, a large segmented download, or several applications operating at once. It does not necessarily predict the speed of one file transfer from one distant server.

Google’s built-in search speed test (search “speed test”) uses Measurement Lab’s Network Diagnostic Tool, or NDT. M-Lab describes NDT as a single-stream measurement of bulk-transport capacity. That makes it an interesting counterpoint to Ookla. A single flow may expose latency, loss, or TCP-window limitations that a multi-stream test can partially conceal. You can also use M-Lab’s own speed test directly.

While you may get similar numbers between the two approaches, you also may not get similar numbers, especially on high-latency connections where Ookla’s multiple streams will help hide latency.

Netflix’s Fast.com is deliberately simple. Open the page, and it immediately begins transferring data from Netflix infrastructure. By default it emphasizes download performance, since its original purpose was to answer a practical question: can this connection deliver Netflix video properly? Selecting “Show more info” adds upload speed and both unloaded and loaded latency.

Fast is barebones and measures speed to Netflix.

The use of Netflix servers is significant. Fast.com measures the route between you and Netflix’s content-delivery network, while Ookla may test against a server operated by your ISP only a few network hops away. A superb Ookla result and a poor Fast.com result do not prove deliberate throttling, but they do tell you that the destinations — or the routes to them — are behaving differently.

Cloudflare offers two related tests. Its Radar Network Quality Test provides a quick summary, while speed.cloudflare.com  gives an extremely detailed breakdown. The latter reports download and upload throughput, idle and loaded latency, jitter, packet loss, server location, and application-oriented quality estimates.

Cloudflare provides a wealth of stats and graphs.

Loaded latency is especially useful. An otherwise fast connection can become miserable when a large upload or download fills an oversized queue in the modem or router. Your idle ping might be 12 milliseconds, but under load it may jump to several hundred milliseconds. That is the classic symptom usually called bufferbloat.

If you want more options, there is testmy.net, which allows you to test upload and download speeds separately, and speedof.me, which keeps a history for you, among others. It isn’t always obvious which ones are measuring a single connection vs multiple ones, so you may have to dig through whatever documentation you can find.

Your WiFi Is Part of the Test

A browser speed test cannot automatically tell you what’s hurting your speed. A laptop connected through marginal WiFi may report 180 megabits per second even though the router has a flawless gigabit Internet connection.

In fact, once incoming Internet service reaches several hundred megabits per second, WiFi is frequently the limiting factor. The link rate displayed by the operating system is not the same thing as usable throughput. Wireless protocols have framing overhead, acknowledgments, contention, retransmissions, and half-duplex operation. The advertised 866, 1200, or 2400 megabit link rate is therefore not a promise that application data will move at that rate.

The numbers printed on WiFi boxes add another layer of optimism. A router sold as “AC1800,” for example, does not provide an 1800-megabit connection to one device. The figure is normally the sum of the maximum advertised PHY rates on separate radios — perhaps 1300 Mb/s on 5 GHz plus 450 Mb/s on 2.4 GHz — with some rounding for marketing. A conventional WiFi client connects to one band at a time, so it cannot combine those rates. The total is better understood as the router’s theoretical aggregate capacity while serving multiple devices across both bands. Even then, protocol overhead, contention, signal quality, and client limitations make actual data throughput considerably lower. Newer WiFi 7 equipment can sometimes combine links using Multi-Link Operation, but that exception does not make the old ACxxxx arithmetic any less misleading.

WiFi also uses shared airtime. Devices on the same channel — including neighboring access points that can hear one another — must contend for opportunities to transmit. A slow or distant client takes longer to send a given amount of data and can consume disproportionate airtime while doing so. Modern access points may provide airtime fairness and other mitigations. One old device does not invariably drag every client down to its rate, but it can still reduce the capacity available to the rest of the network. Interference has a similar effect. A weak signal, a crowded channel, microwave noise, or an overlapping neighboring network causes frames to be delayed or retransmitted. Those retries consume airtime without delivering additional data.

Repeaters and wireless mesh backhaul add another complication. A simple same-channel repeater must receive each packet and then transmit it again over the same shared medium. In the worst case, each repeated hop can roughly halve the available throughput. Modern tri-band mesh systems can avoid much of that penalty by using a dedicated backhaul radio, and Ethernet backhaul avoids it almost entirely.

This means it is entirely reasonable to buy gigabit Internet service and obtain only 300 or 500 megabits per second from a WiFi laptop. Whether that represents a problem depends on the client, radio band, channel width, signal level, backhaul, and local RF environment.

For a meaningful ISP test, begin with a computer connected directly to the router by Ethernet. Stop large transfers and temporarily disable any VPN. Record the chosen server, latency, upload speed, and download speed rather than preserving only the most flattering number. Then run the same tests over WiFi. The difference is an approximate measurement of what the wireless portion of the network is costing you.

Remove the Internet From the Experiment

OpenSpeedTest running on an OpenWRT node.

Better still, remove the ISP from the test completely. OpenSpeedTest is a self-hostable, browser-based test. Run its server on a wired computer, NAS, or container, then visit it from laptops, phones, and tablets around the house. Because the traffic remains on your LAN, a slow result points toward WiFi, switching, cabling, or the client rather than the Internet connection.

It is possible to run this on the uhttpd server used with OpenWRT, although you’ll need to coax it to measure upload speeds since the server can’t handle the default method. The trick is to create a CGI script that accepts a large amount of data successfully and then configure uhttpd to run that.

A browser-based local test is convenient, but for serious diagnosis it is hard to beat iperf3, the client/server tool we recently used while testing mesh routers. On one machine (say, 192.168.1.100), start the server:

iperf3 -s

From another machine, run:

iperf3 -c 192.168.1.100

By default, iperf3 uses one TCP connection. Add -P 4 to try four parallel streams, or -R to reverse the direction so that the server sends and the client receives. Those variations can tell you something. If four streams are much faster than one, the network may have enough aggregate capacity but a single TCP flow is being limited by latency, loss, window growth, CPU performance, or offload behavior. If the reverse test is much faster, examine the weaker machine’s transmit path, drivers, antennas, or CPU.

iperf3 can also generate UDP traffic at a specified rate and report packet loss and jitter. That is often more informative for evaluating a wireless link than merely chasing the largest TCP number.

Can Linux Make It Faster?

Linux offers an impressive array of network tuning knobs, which naturally tempts us to turn them. But first, you need to understand what needs tweaking.

Check the negotiated Ethernet rate and interface counters:

ethtool eth0
ip -s link show eth0

A gigabit adapter that has negotiated 100 megabits per second usually has a cabling, connector, or switch-port problem. Increasing TCP buffers will not repair it. Rising interface errors and drops point toward a physical, driver, or congestion problem. TCP retransmits (view with ss -ti) may indicate loss elsewhere on the path.

You can inspect the active queue discipline with:

tc qdisc show

Linux supports queue disciplines such as fq_codel, which combines per-flow queueing with active queue management. It attempts to prevent one large transfer from building an enormous queue and delaying unrelated interactive packets. The kernel documentation specifically lists fq_codel as a sensible queue discipline that works without extensive configuration.

It can be selected as the default for newly created interfaces with:

sudo sysctl -w net.core.default_qdisc=fq_codel

That may improve queueing on traffic leaving the Linux machine. It does not, however, fix a large queue in the cable modem or Internet router. Queue management must be applied at the bottleneck. If the ISP link is limited to 20 megabits upstream, controlling a queue on a gigabit Ethernet interface after it has already handed packets to the router is too late.

For a home connection, the most effective bufferbloat treatment is usually Smart Queue Management on the router. OpenWrt’s SQM system supports both fq_codel and CAKE. CAKE generally provides better performance. However, fq_codel requires less CPU overhead.

High-latency paths introduce a different problem. TCP must keep enough data in flight to fill the bandwidth-delay product. Modern Linux generally autotunes TCP buffers, so the old advice to assign enormous fixed values to tcp_rmem and tcp_wmem is less universally useful than it once was. Before changing them, use ss -ti during a transfer and look for retransmissions, round-trip time, congestion-window size, and whether the receiver window is actually limiting the connection.

Linux also supports selectable TCP congestion-control algorithms:

sysctl net.ipv4.tcp_available_congestion_control
sysctl net.ipv4.tcp_congestion_control

Algorithms such as BBR can improve throughput and queue behavior on some long-distance or lossy paths. But changing the algorithm affects connections sent by that Linux machine; it does not control the remote speed-test server, repair poor WiFi, or eliminate a queue in the router. Congestion-control tuning is therefore a useful experiment for a server, VPN endpoint, or long-haul transfer machine — not a universal solution to slow networking.

Finally, inspect hardware offload features when a Linux system cannot keep up with a fast LAN:

ethtool -k eth0

Advanced network tuning is a bit beyond the scope of this post, but there are plenty of roadmaps down this rabbit hole.

The Lesson

The lesson here is that there is no universally correct speed-test result. Ookla tests how effectively multiple transfers can fill a route to one of its servers. M-Lab examines a single bulk flow. Fast.com tests the path to Netflix. Cloudflare pays unusual attention to latency under load and overall connection quality. OpenSpeedTest and iperf3 can determine whether the Internet connection is even the problem.

Run enough tests, and you will eventually obtain a number worth bragging about. Run the right tests, though, and you may find ways to truly increase real-world performance. If you want to chase that extra 1 kbit per second speed, be our guest — we know how it is. But the truth is that if the Internet is doing what you want it to do, then it is fast enough.

Yesterday — 21 July 2026Main stream
Before yesterdayMain stream

UDP Broadcasting and the Joys of IPv4 Subnetting

14 July 2026 at 10:00

In the previous installment on UDP broadcasting and service discovery, the basics of both were explored, including an implementation in the form of NyanSD and its protocol. Contained in the comment section was a very good demonstration of why one of the most exciting aspects of software development is the opportunity to share your latest creations with other people. This being the ability to get solid feedback on all the points – including any potential boneheaded omissions – that you really should address, whether intentional or accidental.

The most pertinent point raised was definitely that of broadcast addresses and IPv4 subnets, with the latter topic especially being something that the sysadmins at the office would talk about all the time, but which us software developers were always happy to ignore as something that didn’t concern us. Turns out the joke was on me and everyone else – like our esteemed readers – who thought that they could escape the fascinating world of subnets, as today we’ll take an in-depth look at what subnets are and how they are relevant to the world of UDP network discovery.

I somewhat alluded in the first article to the topic of ‘which broadcast address to use’ as being somewhat of a rough topic to figure out, which is clearly why I just stuck to a blatantly ‘works for me’ /24 subnet that usually will work on networks, until it does not.

Subnet And Conquer

Basic subnetting concept. (Credit: Michel Bakni, Wikimedia)
Basic subnetting concept. (Credit: Michel Bakni, Wikimedia)

The short version of ‘what is a subnet’ is to point at the subnet mask that we have been mostly mindlessly mashing into networking configuration dialogs along with the IPv4 address for many decades now. Usually this takes the form of 255.255.255.0, which is just the human-readable version of the actual bitmask. Here the loopback interface already tends to use 255.0.0.0 as its netmask, which is a detail that tends to be easy to gloss over as this is just one of those local OS things.

Putting netmasks in the crudest and simplest terms, they are a bitmask that is used to identify how an IPv4 pool of addresses is split up by defining which bits of the 32-bit IPv4 address identify a subnet. Normally we call the trailing part of an IPv4 address (the .123) the host identifier, with the preceding section the network identifier.

By masking part of this host ID and using it to create a subnet identifier, we can then use this for additional routing, just at the cost of a reduced number of possible host IDs within that subnet.

As an example, the common 255.255.255.0 mask identifies the first 24 bits (3 bytes) of the 32-bit (4-byte) IPv4 address, hence the mask being referred to as /24. With this mask, the remaining host ID bits allow for 256 hosts, of which two are not used for hosts: the first (e.g. 192.168.0.0) and last (e.g. 192.168.0.255) in the range. The last host ID in the range forms the broadcast address for that subnet.

This is why, for a /24 subnet, you can generally get away with just slapping a .255 on the end of an interface’s address, but also why for other subnet configurations it’s likely to explode violently.

To get briefly back to the loopback’s /8 style netmask, this means a single subnet with a maximum of 16,777,214 hosts, which ought to be sufficient for local system networking shenanigans. Its opposite extreme would be the /31 style netmask, which with just two potential host IDs is practically useless.

IPv6 subnetting is similar, but due to the much larger address pool and differences in the protocol this is a whole other kettle of fish that is as likely to send a network administrator’s heart racing in excitement as it is to make the average software developer run away screaming. This can be a fun topic for another day, perhaps.

This overview of IPv4 subnetting also skips over details like the different classes of IPv4 subnets beyond the Class A type here, but those are happily left to sysadmins and kin for now.

Sub-casting

In order to thus obtain the broadcast address for a given network interface you need to know two things: the IPv4 address and its associated netmask. From this you can then tell three things: the subnet ID, the broadcast address in that subnet, and the current host ID. Of these we only really care about the the second item.

Although you can obtain the broadcast address yourself by applying the netmask to the address, the OS’s APIs tend to happily give you the precomputed broadcast address. If that’s not your style or not an option, a manual procedure is to:

  1. Determine the number of host ID bits using the netmask.
  2. Set all bits to 1 in these bits to get the highest possible host ID.
  3. Use this value along with the original masked (i.e. network ID) bits to obtain the broadcast address.

If we thus start with a 192.168.0.0/24 network, we end up with 192.168.0.255, while for a 192.168.0.0/26 network with just six bits available the maximum value is 64, ergo we get 192.168.0.63, since we start counting at 0.

With this we can now broadcast UDP packets on any interface without any (major) worries.

Local Broadcast Address

A small glitch in the whole above story is that there’s actually another broadcast address, one which is always the same for each interface and can be considered to make the whole preceding explanation completely irrelevant. This being the local, or limited, broadcast address, which is either the best thing since sliced bread or the worst sin ever committed in the history of IP networking, depending on whom you ask.

This cheat code takes the form of the address 255.255.255.255 and if you send a packet on a UDP socket to it, you’ll get happy UDP responses from any service that is listening on the specified port. This raises the point of why you’d not just use this broadcast address on all interface, rather than bother with all the earlier described nonsense.

The only major difference between this local broadcast address and the earlier described directed broadcast address is that the latter can also be used to target a foreign network, instead of just the local network. This makes it a very attractive option if you just want to query the local network with UDP broadcast packets.

As for why you’d not want to use a local broadcast address, I couldn’t really find any references or citations on why this would be the case. Both would appear to be perfectly valid approaches to broadcasting, each with its own pros and cons.

Bugs

One final topic was my mistaken hardcoding of a /24 style broadcast address in NyanSD. Here reader ziew helpfully pointed me towards the Poco::Net::NetworkInterface::broadcastAddress() function, which seemed perfect. Unfortunately Poco’s implementation at least on Windows 10 appears to be rather broken.

After getting only 0.0.0.0 as broadcast address from this function, I had a bit of a look at what was happening, including checking what I got as subnet mask both for the default index parameter and for the next index. Across two different Windows 10 installations and both GCC in MSYS2 as well as MSVC 2017/2022 with various versions of Poco the returned values were… interesting enough to file a bug report on the Poco issue tracker.

Clearly this isn’t going to be fixed just yet, but on the bright side the horrific atrocity that I committed by hardcoding a /24 broadcast address will still work on basically every home LAN out there that NymphCast is likely to be used on.

Maybe I could just switch to a local broadcast address and that’d be even better. Feel free to torch down this idea in the comments, just be sure to provide solid reasoning and cite your sources.

A Complex Topic

Writing out the above pretty much clarifies I think why past me got a bit overwhelmed when trying to ‘just do a UDP broadcast thing’. Even just scratching the surface of IPv4 subnets and not even venturing into IPv6 territory makes one already feel a bit antsy.

Certainly, one could totally argue that anything other than a /24 network is unlikely to be encountered outside of certain government and business networks with either very specific needs, very enthusiastic sysadmins, or both, but it’s always better to design software with such real-life scenarios in mind.

The Death of Physical Media and the Real Challenges to Software Archiving

13 July 2026 at 10:00

Along with the many displays of outrage, gnashing of teeth and other displays of profound grief at the recent news that Sony will no longer manufacture physical game discs come 2028, we have also heard some voices pipe up with a variety of statements, such as that this decision makes game archiving basically impossible. Of course, the truth of the matter is that software archiving in general has become much harder already over the past decades, while game consoles are just late to the archiving-hostile party.

As an example, one merely has to contrast Sony’s PlayStation with e.g. the Valve Steam store and software by juggernauts like Adobe and Autodesk. Here the former moved after the Creative Suite (CS6) series of Photoshop and other tools fully over to the Creative Cloud (CC) subscription model, where DRM and constant rental software renewals are in order. Unlike that disc copy of CS6 Master Collection that will stay good practically forever, there’s nothing really to archive with Adobe’s CC software.

Similarly, with digital game downloads and their constant patches now put inside a heavily encrypted environment that relies on a special launcher, preserving video games has been turned into into a virtual nightmare for many years now.

Why Archive

Archiving is about accumulating historical records or materials. The scope and reason for a particular archive can differ, such as a company’s archive with financial records, an engineering department’s archive of technical references, or a museum’s archive of physical artefacts. Whatever the reason, the same goal applies: the maintaining or creating of a historical timeline that can be later referenced as needed.

An essential part of archives is to act as a primary reference source: where possible archives contain only the original documents and artefacts, making them as close to an objective source of history as possible. This is both extremely useful for a company when the tax office does a surprise inspection, but it is also for anyone who wishes to do any kind of historical research. This includes research into the development of a certain kind of software over the centuries and all types of related hardware.

Within the world of software archiving not much changes about this primary mission, except for the digital aspect that earns it the title of digital preservation. At least until fairly recently this meant mostly making copies of physical storage media and any associated physical media like documentation and manuals, but increasingly the subject of such preservation and archiving entails digital data that never was bound to or accompanied by any kind of physical media.

Such digital preservation is a big part of organizations like the Internet Archive, whose archives contain copies of software and games that might otherwise have been lost to the ages. The cases of retro enthusiasts coming across a floppy disk or CD containing some obscure game or set of drivers and uploading a copy to the Internet Archive are both numerous and an excellent example of digital preservation.

Other archives like the Video Game History Foundation (VGHF) have a more narrow focus, as their name implies. Their basic mission is no different, of course, with creating an archive that preserves history. Here the best part about digital preservation is that it makes it possible to create virtually infinite bit-perfect copies of the materials, making it incredibly easy to share and enjoy multimedia, gaming, and other content from these archives.

Digital Restrictions

Early 2000s meme about copyright infringement, inspired by similarly titled campaign.
Early 2000s meme about copyright infringement, inspired by similarly titled campaign.

Of course, if that was all that there is to be said about digital archiving and preservation then this is basically where we could conclude merrily that all is well, and that whether software is distributed digitally or on some kind of physical storage media is of no concern. In this scenario said software can be copied around to one’s heart’s content, burned to optical media and so on without restrictions, ensuring its preservation.

With distributors of software having had fits about how easy it is to copy and distribute said software since at least the 1980s, it’s little wonder that they haven’t seen fit to rely on the fact that copyright infringement is illegal, and instead sought to make it impossible to copy the data of software. This led to a wide variety of copy restriction implementations, including on floppy disks, such as Electronic Arts’ Interlock system, while Nintendo’s game cartridges mostly relied on this more obscure format to keep people from creating their own cartridges.

In the face of these hurdles, the US Library of Congress notes that, for some software, it’s not enough to have the software on some medium, but also the console or hardware to play it on.

These copy restriction mechanisms are a form of digital restrictions management (DRM), euphemistically called ‘rights management’, since DRM only removes rights. As software became decoupled from physical media by the late 90s along with multimedia content like MP3 music, alternate DRM schemes were developed that restrict copying, generally through encryption and a convoluted decryption scheme that even includes hardware-level encryption such as High-bandwidth Digital Content Protection (HDCP).

The upshot of all these copy restriction schemes is that you have to jump through many hoops to still create a copy, whether it involves breaking a floppy copying scheme, using an HDMI splitter that accidentally forgets to re-apply HDCP before sending the content off to a capture card, catching a lucky break with a leaky DVD CSS implementation, or using the analog hole to create that ‘good enough’ copy.

Nobody buys games on DVDs anymore, however. When a digital game is provided via an online store service, how can this be preserved in a digital archive? Since all of these rely on an internet-dependent DRM scheme which fails the moment there’s an issue anywhere in the chain, or if said authentication servers are turned off in N years from now, all preservation schemes here are by definition flawed or at least legally awkward.

A Digital Void

When EA created its Interlock copy restriction scheme it was likely not concerned with whether or not copies of their games would survive into the 2020s, never mind whether anyone would still be using FDDs. It does however indicate the central problem here, one that goes far beyond a black-and-white physical media vs digital-only show-off. Especially since physical media could be argued to be flawed enough that it deserved it to die.

In today’s inevitable march towards a future in which we’re all consuming content using ‘our’ Smart Terminal Devices that rely on any number of paid subscriptions to gain access to the actual content stored on the servers of our benevolent Content Overlords, what probably rankles people the most about the PlayStation physical media announcement is less the demise of physical media and more a reminder of how much has already been taken from us.

In a statement made by VGHF director Frank Cifaldi on the end of physical PlayStation discs – and the concurrent announcement of the shutdown of the PlayStation 3 and Vita online stores – this is put in the broader context of the digital void that we’re facing, in which a large part of video game history simply cannot be legally preserved.

The Legal Conundrum

Here we have to address the rather sizeable elephant in the room, in the form of copyright infringement. Here we see large groups of very nice people in friendly online communities who carefully strip any offending DRM that may even prevent the game from working, while ensuring that the freely provided bundle is kept up to date with only the best patches and anything of relevance.

Within these communities you can find entire swathes of video game history preserved for the enjoyment of connoisseurs, including tutorials, manuals, carefully curated collections mods and extensions, plus everything else that would make a professional digital archivist salivate.

But these ‘shadow archives’ are definitely illegal according to copyright law, ergo the only option available to VGHF and other organizations that are trying to stay on the light side of the law might be to wait a few decades, see which games enter the legal grey zone of ‘abandonware‘ and see whether they’ll still get hit by DMCA takedown request in 2050 for a game that ceased being offered for sale in 2026.

C’est la vie.

Know Your Food: Organic Production

2 July 2026 at 10:00

A few weeks ago we published the first in a new series of articles, Know Your Food. It was born out of the realisation that most people know surprisingly little about what they eat, and to apply a bit of Hackaday curiosity to received opinion on the subject. As we put it then: “To know both how common foodstuffs should be made, as well as how they are made industrially, should be an essential for everyone” We’ll continue in that vein, with a look at organic food.

If you buy your food in a supermarket it’s likely that in the vegetable aisle you’ll be presented with a choice. On one hand you will have the normal vegetable, and on the other and usually for a slightly higher price, the organic version of the same vegetable. What’s going on?

So What Is This Organic Stuff All About?

A watercolour picture of a bucolic scene with a farmhouse surrounded by trees, and some cows in the foreground.
It is unlikely that a typical organic farm in the 2020s will resemble this John Constable painting. John Constable, Public domain.

Organic production is a system of agriculture that emphasises natural fertilisers, pesticides, and farming methods over synthetic or intensive ones. It has its roots in the first half of the 20th century, and as the decades progressed it has become an important sector of agricultural industry. I grew up steeped in organic agriculture because my grandfather was an early adherent in the years following the war, so I’ve seen it from the sharpest end. There is a lot to commend organic production for and plenty of reasons to embrace it, but with that come some problematic aspects, and even dubious claims. Here I’ll try to unpick some of that.

It’s tempting to believe that all organic production is somehow a return to a 19th century rural idyl, complete with the obligatory chickens in the farmyard. Some organic producers do take a slice of this back-to-the-land approach to their craft, but the reality of organic farming is a very modern approach to managing the ecosystem. Organic farmers are not wary of progress, and neither are they reluctant to use pesticides or other chemicals. Instead they do so according to the principles of organic agriculture, so any techniques they use are designed to be beneficial to the ecosystem, and any chemicals have a natural origin.

The rear view of a tractor towing a manure spreader driving away from the viewer while spreading manure onto a grass field. It's a misty winter day, and leafless trees are visible in the distance.
If you spend time around organic agriculture, you become a manure expert. Ray Bird, CC BY-SA 2.0.

An important thing to understand is that the line between organic and non-organic agriculture is not sharply drawn. Crop rotation for example is long established farming practice, as are techniques such as contour ploughing in areas with soil erosion. As for fertiliser, there will be very few farming operations whose work does not include manure in some form, or who do not take advantage of nitrogen fixing crops. Pesticides such as the insecticide pyrethrum – originally derived from chrysanthemum root – or Bordeaux Mixture as a fungicide – a solution containing copper ions, so called because of its origin in French vineyards who applied lime solutions from copper containers – find uses where applicable in both organic and conventional agriculture. The important distinction lies in the organic farmers not going further than this, into synthetic amonium nitrate fertiliser for example, or glyphosate herbicide, which you might know as Roundup.

That’s the organic sales pitch, and it’s a compelling one. Now, we’ll go through the not so positive aspects, both of the movement and of the business.

Organic status is not simply conferred to produce by virtue of being organically grown. Instead it’s a legally protected designation, enforced through a system of certification performed by designated organisations. Where I grew up in the UK for example, organic certification is performed by the Soil Association. This is good because it preserves trust in organic status, but it suffers the flaw that it’s a profitable business for the certifier, and an expensive one for the producer. This in turn favours larger producers who can afford certification, and leaves the smaller producer unable to afford certification and thus unable to label their produce as organic. They can describe it as “Organically grown” of course, but they lose the cachet of the organic label. Since many small producers are by necessity organic, this affects a large number of producers if not a significant sector of the market.

Is Organic Food Really Better?

Then there is the produce itself. Is it better than the non-organic stuff? Here we enter complex territory, because the answer differs depending upon the circumstances.

In terms of what advertising people like to call “goodness”, by which I mean nutrients, vitamins and minerals, and the like, in many cases it’s difficult to make a case for the organic product being superior to the non organic one. There will be exceptions such as apples, where a typical non-organic commercial dessert apple is overwatered to the point of diluting the beneficial properties it might have in search of the elusive “crunch”. But in the more ordinary case, that organic zucchini is unlikely to have more nutritional value than its non organic equivalent. It’s important to note that the organic product will lack any pesticide residues which may be present on its non organic equivalent, however it must be remembered that pesticide residue levels in food are subject to their own stringent regulation.

A sign advertising Wynford Farm Shop, selling local Organic Aberdeen Angus beef.
If you’re looking for the best organic food, seek out places with signs like this. Stanley Howe, CC BY-SA 2.0.

In terms of flavour, yet again it’s a mixed bag. An organic product grown in as intensive a manner as can be got away with under the rules, is not likely to taste better than the equivalent. It’s difficult even to pin down what in the husbandry governs the flavour of the finished product in a scientific sense, however as someone who grew up around organic production I’d offer the view that the longer something took to produce, the better its flavour is likely to be.

The Slow Food movement champions products made in this way, usually traditionally produced foods, heritage varieties, and foods with a particular terroir. If you’re looking for better tasting food then you may not find it with a supermarket organic label, but it’s quite likely that one of those small organic producers will have what you are looking for, simply because their methods are less intensive.

Finally, if you’re looking at the benefit to the environment, it’s likely that in most cases the organic product will impose less stress on the ecosystem and the wider environment than its non organic equivalent. If that’s your concern you should also look further than the means of production and into food miles; how far did the food in front of you travel to your plate? Here in Europe the strawberry is in season from around May to September, so does it make sense to fly them from the other side of the world in January, however nice they taste?

So now I hope you have more of an idea about organic food than you did at the start of this piece. You’ll know something about its benefits and problems, and you’ll know when it’s better than its non-organic equivalent. I hope you’ll find the food you like, and if you do, I hope it’s from a small producer, they need your business. Bon appetit!

Header: MichelM10, CC0.

How Airspeed Sensors Work

30 June 2026 at 10:00

When you’re driving your car, you’re probably regularly looking at the speedometer to make sure you comply with the local speed limits. The method by which it works is simple enough: the rotation of the wheels is sent mechanically via a cable to a dial on the dash, or an electronic sensor counts the rotations of the drivetrain and an electronically-controlled needle or display shows the speed.

But what about if you were in an aircraft, and the wheels had nothing to do with how fast you were going? How would you even begin to measure speed? There are two ways: there’s a convenient solution to this problem rooted in simple fluid mechanics, and a far-more-complex modern solution. Today, we’ll explore how planes and helicopters are able to figure out how fast they’re going, by the old ways and the new.

Classical Methods

Measuring airspeed can be achieved by measuring stagnation pressure with a pitot tube, and comparing this to static pressure. This can be done at different points on the aircraft, or a pitot-static tube can be used, which measures both stagnation pressure and static pressure in a single probe. Credit: Chaos386, CC BY-SA 3.0

A key thing most aviators want to know is how fast their aircraft is going. Specifically, it’s nice to know how fast it’s moving relative to the airstream around it, which is referred to as airspeed. This is important, because it’s the aircraft’s velocity relative to the flow, such as wind, that determines the performance of the airfoils, how much lift is generated, and whether or not the aircraft is approaching a stall condition where it might fall out of the sky.

Bernoulli’s equation, rearranged to find airspeed (u), by subtracting static pressure from stagnation pressure, multiplying it by 2, dividing by fluid density, and taking the square root of that result.

Measuring airspeed is most commonly achieved with the use of a device called a Pitot tube. The pitot tube is a tube with a hole in one end that points directly into the airflow in the direction of travel of the aircraft.

As air flows in, it reaches a dead end and the flow slows to a stop, or stagnates, since it has nowhere to go. This allows a pressure sensor or a manometer or other device to measure the stagnation pressure at this point. The stagnation pressure measurement is related to the flowspeed of the incoming air since the kinetic energy of the flow is converted to pressure as the flow comes to a halt.

A secondary tube, pointing perpendicular to the airflow, is then used to measure the static pressure of the surrounding air, without the ram effect of the air being forced in by the aircraft’s forward motion. Then, it’s possible to calculate the velocity of the aircraft relative to the airstream by plugging the stagnation pressure and static pressure into a rearranged Bernoulli’s equation.  If the pitot tube and static tube are hooked up to electronic sensors, the airspeed can be calculated electronically, and fed to a display or digital gauge.

A classic airspeed indicator has the pitot tube and static tube feeding right into the gauge in the cockpit. The pressure differential causes the diaphragm to expand as the airspeed increases, which mvoes a mechanism causing the needle to move on the gauge. Credit: FAA, public domain

Alternatively, it’s possible to effectively do this “calculation” mechanically. In earlier days, static and stagnation pressure captured by each tube would be fed to a gauge. Inside, the stagnation pressure would be fed to a diaphragm which moved due to the difference relative to the static pressure which is fed into the gauge body, and the movement of the diaphragm would, via a simple mechanism, shift the needle on the gauge.

A small General Aviation aircraft might mount a single pitot tube on the aircraft, feeding the air speed instrument in the cockpit. Commercial aircraft might mount two or more for safety’s sake, in case one becomes inoperable, while large airliners may have four or even more to provide a high level of redundancy and error checking. Heaters are commonly included on pitot tubes to ensure they can be kept free of ice, which can otherwise completely block a tube and make it impossible to obtain an airspeed reading.

Pitot tubes sticking out in the airstream underneath a Boeing 777-381. Credit: Cassiopeia sweet, public domain

For pilots, not knowing how fast (or slow) the aircraft is going can be highly dangerous, as it can lead to entering unstable flight regimes such as stall. Thus, it’s imperative that the pitot tubes remain unobstructed and functional for safe flight. Many aircraft accidents have occurred because of blocked or malfunctioning pitot tubes or airspeed instruments.

The New Way

Of course, you could fuss about with pitot tubes and pressure sensors and deicing measures, but that’s all very fiddly and old hat. There is an entirely different way to figure out a plane’s speed, though it’s only been available for the last few decades. It’s as simple as throwing a GNSS receiver on the aircraft.

Yes, whether your particular poison is GPS, Baidou, GLONASS, or Galileo, any major satellite navigation system will be able to tell you the speed of your receiver. Simply measuring the change in the receiver’s position over time is enough to calculate out the speed, and any off-the-shelf receiver will present this information as standard. It’s generally not used as a primary indicator in aircraft, because it reports ground speed, not airspeed, the latter being more relevant for aviation purposes. Still, it can prove to be a useful sense check when traditional airspeed indicators are non-operative or reporting confusing data, and GNSS devices are widely used on many aircraft today.

Flying High

Many modern aircraft have so-called “glass cockpit” displays that include feeds from GNSS receivers, which can provide supplementary data such as satellite-based ground speed measurements. However, these readings are generally not used for the primary task of flying the aircraft. Credit: Bluedisk, CC BY-SA 3.0

If you’ve ever wondered how an aircraft measures its speed as it floats through the amorphous gas cloud we call an atmosphere, now you know. Even to this day, where electronics and computer wizardry control our fanciest aircraft, airspeed measurements are still done with the same simple physics, just with some fancier sensors for help. The fundamentals haven’t changed at all. Now you know, you can always dig deeper into the many other rich applications of Bernoulli’s equation and fluid mechanics in general. Happy learning.

❌
❌