Feb 26 2012

Trick to going faster than light: loosen some cables

Evidently the first thing the folks at OPERA should have done when going over all their lab results after they found neutrinos beating the speed of light by 60ns (also covered further, and further still, previously on my blog), was to check all the cables.

According to sources familiar with the experiment, the 60 nanoseconds discrepancy appears to come from a bad connection between a fiber optic cable that connects to the GPS receiver used to correct the timing of the neutrinos’ flight and an electronic card in a computer. After tightening the connection and then measuring the time it takes data to travel the length of the fiber, researchers found that the data arrive 60 nanoseconds earlier than assumed.

Since this time is subtracted from the overall time of flight, it appears to explain the early arrival of the neutrinos. New data, however, will be needed to confirm this hypothesis.

As a relatively high-level computer geek, this is one of the troubleshooting steps that I often forget myself. If the software is working, and everything seems to be fine, but things are slightly slow or packet-lossy, I usually suspect something foreign stealing all the bandwidth before I’ll suspect the physical cords, no matter how long it’s been since said cords have been touched or checked or replaced. And this same mentality has bit me in the ass in the past, even once I get to the physical part of the troubleshoot. Cords that I “know” are good, turn out to be bad or loose very seldom, but certainly often enough that I should think to check them now and again. And yet I’ll repunch the Cat5 jack before I’ll think to check the cable to the switch or to the computer.

There’s another way to look at this though. Maybe the trick to going faster than light is to just loosen all the cables running your FTL starship engine. No wonder Scotty’s solutions were all bubble gum and scotch tape. (Heh. Scotch. Get it?) Anyway, Star Trek universe, here we come!


Skip to comment form

  1. 1


    I actually remember (just to be a Sad Sally) telling my friend (uber geek, super psyched about this when he heard about it) it was probably a bad fiber connection somewhere. I can’t wait to gloat.

    Never mind I was also squealing about this. He doesn’t know that.

  2. 2
    'Tis Himself

    Recently I had a printer problem where I reloaded the printer driver and then, when the printer still didn’t work, fixed the problem by putting the O-N/O-F-F switch into the O-N position.

  3. 3
    Philip Legge

    Heh. An instrumentation problem was always a more likely hypothesis for the timing anomaly than a violation of physical law when as I had already observed (here) there are already well-justified and tight constraints on neutrino velocity. I still have some doubts the set-up is sufficiently stringent overall to demonstrate sub-luminal velocities, which is what the new theory of neutrino scintillation requires.

  4. 4

    Universal troubleshooting law, applicable to both hardware and software: the part which is so obviously right that you don’t need to check it is the part which is wrong.

  5. 5

    One of the first steps in troubleshooting is often “Is the device plugged in”. This is not because the techs think people are dumb, it’s because it solves the problem so often.

  6. 6

    Scientist: “Our machine shows neutrinos are moving faster than light, laying to waste the theory of relativity and throwing most of physics on its head.”

    Tech support: “Have you tried turning it off and on again?”

    Scientist: “Tried that. Still have the same issue.”

    Tech support: “How about reseating the cables?”

    Scientist: “That’s just silly. How could that possibly… Oh, that’s fixed it. I can’t believe I didn’t think of that. Thanks.”

    That was approximately 60% of my calls when I was doing telephone tech support for HP and Microsoft.

  7. 7

    I agree, Jason. And yet, at least three labs are wasting their time by double-checking their data cables prior to replicating the OPERA experiment. We could be designing time-travel cars right now, where jiggling the plug jumps you back and adjusting the oscillator sends you forward.

  8. 8

    I’m trying to build a hybrid vehicle using a Flux Capacitor and an Overthrusting Oscillator. I already know the clamps on the Flux Capacitor must not be too tight or it breaks, causing a flux leak which is a major PITA to clean up (don’t ask me how I know). Also, the bearings on the Overthrusting Oscillator have to have just the right clearance or it won’t oscillate. Maybe I should dial in just a tad extra clearance on both…

  9. 9
    John Horstman

    I suggest keeping a (long enough for most applications) test cable around that you never use for anything other than testing connections and keep out of harm’s way when not in use. Cat5e is pretty cheap, though the cheap stuff doesn’t tend to handle abuse well in my experience (it’s mostly the plugs that go; I wind up having to replace a lot of them, though a re-crimp usually works the first time or two). Also, you can use an ohmmeter to verify that the connections are clean across cables that are reporting connections but still showing packet loss. And, of course, make sure you don’t have anything auto-switching down to half-duplex or a lower data rate on damaged-but-not-broken cables, as that can mask the problem (unless you’re looking at applications where performance-hampered uptime is preferable to any downtime).

    Basically what I’m saying is that I always check the cables right after the software configuration/hard reset check, as I’ve still only ever had 1 RJ-45 jack break on me (and never the ethernet controller itself, though I have had BIOS updates break one or more jacks on multi-jack/multi-controller boards) over 12 years of system-building, LAN parties, and general for-the-hell-of-it tinkering; if it’s not software, it’s always the cable.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite="" class=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>