July 4, 2022 edit: this article was updated with new calculations for LHC Run 3, starting tomorrow.

The Large Hadron Collider was successfully tested as a particle accelerator for the first time on September 10, 2008. A beam of protons was accelerated and completed several loops through the whole structure (26,659 m), clockwise and counter-clockwise. These first tests did not involve particle collisions, and the LHC will not be used as a collider before Spring 2009 because of a serious incident.
When the power of this machine is discussed, the energy of the proton beam is often mentioned: the protons each have an energy of 7 TeV. What does it mean?

At low velocities (conceivable for human beings), the energy $E$ of a point object is measured by:

$$ E = \frac{1}{2} m v^2 $$

However, this formula can not be applied at speeds close to the speed of light. We must use Einstein’s theory of Special relativity, which gives:

$$ E = \gamma m c^2 $$

where $m$ is the mass at rest and $\gamma$ is the Lorentz factor, defined as

$$ \gamma = \frac{1}{\sqrt{1-\frac{v^2}{c^2}}} $$

When the particle is at rest ($v = 0$), this yields the famous equivalence between mass and energy:

$$ E = \frac{1}{2} m c^2 $$

The original version of this article contained a mistake, now fixed; thanks to Ian Bryce for spotting it!

The energy reported by the LHC is only the kinetic energy of the particles, it doesn’t include the rest energy. Indeed, the rest energy of a proton is around 938 MeV, whereas accelerators such as Linac 2 at CERN accelerate particles at 50 MeV.

With $E$ being the total energy, $K E$ the kinetic energy, $m_0$ the mass at rest, $m$ the relativistic mass (equal to $\gamma m_0$) and $E_0$ the rest energy, we have the following:

$$ E = m c^2 $$ $$ E = E_0 + K E $$ $$ K E = E - E_0 $$ $$ K E = m c^2 - m_0 c^2 $$ $$ K E = {\gamma}m_0 c^2 - m_0 c^2 $$ $$ 1 + \frac{K E}{m_0 c^2} = \frac{1}{\sqrt{1-\frac{v^2}{c^2}}} $$ $$ \sqrt{1-\frac{v^2}{c^2}} = \frac{1}{1 + \frac{K E}{m_0 c^2}} $$ $$ 1-\frac{v^2}{c^2} = \left(\frac{1}{1 + \frac{K E}{m_0 c^2}} \right)^2 $$ $$ \frac{v}{c} = \sqrt{1 - \left(\frac{1}{1 + \frac{K E}{m_0 c^2}} \right)^2} $$

With $E$ = 7 TeV:

• $v$ = 99.9999991% the speed of light or about 2.69 m/s slower than the speed of light.
• The Lorentz factor has a value of about 7,460.

July 4, 2022 update: Tomorrow is the first day of “LHC Run 3” after years of upgrades, bringing the energy level to an unprecedented 13.6 TeV – almost twice as much as the original 7 TeV. Here are the new calculations for particle velocity after this upgrade:

With $E$ = 13.6 TeV:

• $v$ = 99.999999762% the speed of light or about 0.7134 m/s slower than the speed of light.
• The Lorentz factor has a value of about 14,490.

The time implications are always fascinating. At such a speed, the particle experiences time differently. The ratio between the two “clock speeds” is given by:

$$ \frac{t}{t_0} = \gamma $$

This means that time passes 7,460 times more slowly for the particles than it does for us observers. A clock traveling at that speed from Earth to Proxima Centauri would measure a journey time of under 5 hours, while an observer who would remain on Earth would have aged over 4 years (Proxima Centauri is about 4.243 light-years away from us).

Update for LHC Run 3: with a Lorentz factor of 14,490 the travel time experienced by a particle going to Proxima Centauri would now only be 2 hours and 34 minutes.

When getting very close to $c$, the energy difference between two particles going at almost the same speed can be very large. A famous example of a very high-energy particle detected on Earth is the so-called “Oh-My-God particle”, probably a proton detected at a speed close to 0.9999999999999999999999951 c:

The energy of the Oh My God particle seen by the Fly’s Eye is equivalent to 51 joules—enough to light a 40 watt light bulb for more than a second—equivalent, in the words of Utah physicist Pierre Sokolsky, to “a brick falling on your toe.” The particle’s energy is equivalent to an American baseball travelling fifty-five miles an hour. […] After traveling one light year, the particle would be only 0.15 femtoseconds—46 nanometers—behind a photon that left at the same time.

The article gives the range as $3.2{\pm}0.9{\times}10^{20}$eV, or 36.85 to 65.69 joules. The midpoint of $3.2{\times}10^{20}$eV is where this figure of 51.27 joules comes from.

51 joules is an incredible amount of energy for a single particle. For comparison, the 7 TeV achieved in the LHC corresponds to 1.122 µJ, so 51.27 joules is over 45 million times more energy.

We can validate the calculation in the quote with Wolfram Alpha, which for 51.27 joules gives the velocity of this particle as 0.99999999999999999999999570145229 $c$ and the time behind a photon as 0.14 femtoseconds or 40.64 nanometers after one year.

This small difference in velocity in absolute terms is responsible for a massive difference in energy. Plotting the Lorentz factor as a function of $v$ shows how fast the energy grows when approaching $c$:

γ as a function of v
(Image courtesy of Wikipedia)

I read Stephen Hawking’s A Brief History Of Time recently, and it was a fascinating book. It inspired me to look up the science behind these numbers and learn more about the topic.

This article about PHP’s zvals inspired me to tell the story of a bug related to this data structure.

A few days ago, we experienced a strange bug that seemed to happen only in our production environment: A PHP5 script is run periodically by cron to compute a value and insert it into a data cache. When the web servers were trying to read this value from the cache, it wasn’t found. The strange thing was that another cron script was using the same cache package, with its result successfully inserted and extracted.

I got assigned this bug, and proceeded to try and reproduce it on my local development machine, which runs a cache. Sure enough, both scripts were working fine.

Thinking this might be a cache configuration problem, I connected to the test server that we use before going into the production environment, and tried to reproduce the bug there. Working again on that cache.

Unable to reproduce this locally, we examined the cache on the production servers, and found out that the web servers were not looking for the data where the cron scripts had put it…

Our cache is using a key → value model, but we use several storage units. In order to find out in which unit the data is, the key is sent to this function:

function getStorageUnit($key) {
    return abs(crc32($key) % NUMBER_OF_CACHE_UNITS);
}

With the key “userPageData” and a total of 10 cache storage units, crc32 modulo 10 returns 1495715863 % 10 = 3. This means the data for this key is actually stored in the “cache_3” unit.

While “userPageData” was working fine, the key “homePageData” wasn’t:

On my 64-bit development machine, its data was stored in cache unit 1, and the web code was successfully fetching the data from the same unit. On the 32-bit test machine, the cache number was 5. (The raw CRC32 is 0xB40B0545).

In production, the cron scripts were running on 64-bit machines, inserting the data into cache unit #1, while the 32-bit web front-ends were computing the key differently and trying to fetch the value from cache unit #5.
This behavior is documented.

When PHP computes values, it uses an internal structure called zval. A zval can hold different types of values, of different sizes. It also has portability problems.
note – All C code © Zend.

This is how PHP stores values (Zend/zend.h):

typedef union _zvalue_value {
        long lval;                       /* long value */
        double dval;                     /* double value */
        struct {
                char *val;
                int len;
        } str;
        HashTable *ht;                   /* hash table value */
        zend_object_value obj;
} zvalue_value;

struct _zval_struct {
        /* Variable information */
        zvalue_value value;      /* value */
        zend_uint refcount;
        zend_uchar type;         /* active type */
        zend_uchar is_ref;
};

And this is how a CRC32 value is written to a new zval in the PHP function (ext/standard/crc32.c):

register php_uint32 crc;
        /* ... actually computing the value here ... */      
RETVAL_LONG(crc^0xFFFFFFFF);

RETVAL_LONG is a macro, expanding to setting the value of return_value->value.lval, thus writing a uint32 into a signed long. On our build running on i686, the long is 32 bits, its leftmost bit representing the sign of the value it’s holding.On our build running on x86_64, the long is 64 bits, with one sign bit, 31 zeros, and then 32 bits with the CRC value. A fix exists for this function:

$crc = abs(crc32($string));
if( $crc & 0x80000000){        $crc ^= 0xffffffff;
        $crc += 1;
}

This works on Intel 32 and 64, but I’m not sure it works as expected on other platforms. Also I wouldn’t be surprised if this problem was present in other functions as well.