I think this would be a better answer if it discussed what the physical limitations are to bandwidth, signal, and noise.

Maximum data rate depends in some measure upon one's willingness to tolerate errors that can only be "corrected" via retransmission, especially in cases where noise power may vary in unknown ways, but the average is well below the maximum.

I have some reservations with the stuff about bandwidth at the end. USB3's "simple on-off signal" is actually pretty carefully tailored to make the best use possible of all of the spectrum between 0 and 5 GHz.

At least plug the minimum possible noise — vacuum fluctuations, i.e. shot noise at 0$^\circ$ — into the formula. Then you're getting an answer that meets the spirit of the question.

@supercat: Retransmission is taken into account by Shannon's formula. It doesn't help you. (And when the noise power varies in unknown ways, Shannon's formula tells you to integrate and not take the average noise.)

@PeterShor: Shannon's formula assumes a constant level of noise. If the amount of noise in any one-second period has an independent 99% probability of being below some level S/3, and a 1% probability of being 1000S, the "average" noise would be 10S, one would achieve a transfer rate of 2B, 99% of the time, and roughly zero, 1% of the time, for an average of about 1.98B if re-transmissions are allowed.

@PeterShor: If retransmissions aren't allowed, one would need to include enough forward error correction that one would be acceptably unlikely to lose any critical combination of packets. That would in turn require a lot of overhead that wouldn't be needed if retransmission is acceptable.

Okay ... maybe not Shannon's formula, but Shannon's theorem, which gives a more general formula that holds in the case when the noise isn't constant.

@hobbs You can AC couple USB3 with a fairly small cap, so it definitely isn't using the spectrum near 0. USB cable is very carefully constructed to pass signals up to multiple GHz, but I don't think it's used efficiently by comparison to what you could theoretically shove through GHz of bandwidth. Take gigabit ethernet for example, admittedly it's slower but that only needs ~125MHz of bandwidth which is why it goes much further over cheaper cable. The tradeoff is in the chip required to drive it.

@PeterShor I chose to stick thermal noise in because that's a hard physical limit, and for most earth based purposes that's a higher limiting factor than shot noise. I did link to the wiki article on electronic noise for anyone who cares to look at the others.

@supercat The maximum practical data rate does depend on retransmissions (and modulation scheme etc etc), however this is the maximum theoretical data rate with a theoretical perfect algorithm. If you have a time varying noise power, this equation is still true instantaneously and could be integrated over time to show the maximum data it's possible to transfer in your scenario.

@patstew: If one knows the noise power in advance, that is true. In many real-world situations, a transmitter will have no way of knowing what noise will arrive at the receiver when its signal does.

@supercat I agree that real life is more complicated. Nonetheless you can't do better than the Shannon limit, so it's a useful physical upper bound. Just like you can't build a Carnot engine, but the idea is useful because you can't make a heat engine more efficient than a Carnot engine.

If the noise level changes over time and the bit rate changes to reflect that, integrating the bit rate would give an upper bound for communications throughput for the scenario where noise-level changes are known in advance. Applying the worst-case noise level would give a lower bound for cases where nothing was known about noise behavior beyond the worst-case limit. Retransmission is important because it allows one to achieve performance that is closer to the upper limit than would otherwise be possible.

@supercat: Shannon information theory says that in the limit of long messages, you can find a code that works without knowing the noise-level changes in advance. You just need to know the total capacity. If you have some reference that says otherwise, please give it. If you're just going on intuition here, be aware that intuition gives the wrong answer.

@PeterShor: Consider two scenarios: (1) I want to send some data using 1MHz of bandwidth and a 1024:1 signal-to-noise ratio between 1:00am and 1:04am. (2) I want to send some data between 1:00am and 2:00am, using 1MHz of bandwidth. During the one-minute intervals from 1:05 to 1:06, 1:31 to 1:32, 1:47 to 1:48, and 1:53 to 1:54, the signal-to-noise ratio will be 1024:1. At all other times it will be 0.001:1. (3) Similar scenario, but knowing only that there will be four one-minute intervals of "quiet" without knowing when they will occur. Information capacity in the second scenario...

...should be essentially as good as on the first (maybe losing a bit each time communication starts up and shuts down). I don't think there's any way to come anywhere close to that capacity in the third scenario unless one has a bunch of information, wants to deliver 1/30 of it, and doesn't care about which 1/30 gets delivered. I guess that may be useful from a theoretical sense, but if one has a bunch of information and wants to know how long it will take to deliver all of it, knowing noise profiles in advance, or being able to react to them, will definitely help performance.

@supercat: Suppose that I want to send you $mn$ bits, and I am allowed to encode them in $n+1$ messages, each of $m$ bits. But I know that exactly one of these messages will be destroyed (although you will know which $n$ of the $n+1$ messages you got). Is there any way to get you all $nm$ bits?

The answer: yes. You take the $mn$ bits and encode them in the first $n$ messages. Now, you take the $n+1$st message, and send negative the sum of all the other messages mod $2^m$. Since you know that all the messages add up to $0$, if one of the messages fails to get through, you can reconstruct it by adding up all the others mod $2^m$ and taking the negative. Doing something similar for your scenario (3) also works, although it's much more complicated.