These attacks are usually done over a fast connection (maybe buy a machine in the same datacenter as your target), and through lots of measurements averaged together and measured for statistical significance.
We don't know where this function is used, so this might actually be a non-issue. We need someone more familiar with OpenSSL to comment.
Brumley and Boneh's 2003 paper ("Remote timing attacks are practical") on this is the typical reference: http://crypto.stanford.edu/~dabo/papers/ssl-timing.pdf
You can measure differences of thousands or maybe even hundreds of cycles, but not single cycles. That's below the noise level of a modern computer.
Particularly the section titled "You can’t possibly measure that, can you?"
Any, really, if you hit it with enough copies of each potential input so that you can get enough results to separate the timing difference from the noise. Though the faster, the more samples you can do per unit time, and the closer in network topology, the less sources of variability in latency that make it take more samples you'll have. At least, that's my understanding.
Read Crosby and Wallach's "Opportunities and Limits" paper; the shorthand result of the paper is that across Ethernet you have a window of 100ns, and across an IP network something closer to 30us. The memcmp distinguisher is well below the IP network threshold.
On many versions, memcmp will return exactly when it sees a difference between the two buffers. Because it returns immediately one can figure out what byte it failed at due to timing and construct the correct input.
Some others have pointed out that it's a static function, which I stupidly overlooked. Others have pointed out it's not really used anymore so the title doesn't accurately reflect the issue. -- I will probably delete this thread.