9

I'm wondering if my math here is correct. If my baud rate is 9600 then that means 9600 bits are sent every second, right? If so, then:

9600 bit/sec <=> 1000 ms/ 9600 bit = 0.1042 ms/bit

So, sending 32KB should take:

32,000*(8+2) bits = 320,000 bits -- (8+2) because 8 data bits + 1 start bit + 1 stop bit
320,000 bits*0.1042 ms/bit = 33344 ms = 33.344 sec

Is that correct?

Mike
  • 47,263
  • 29
  • 113
  • 177
Nate
  • 26,164
  • 34
  • 130
  • 214
  • 2
    32KB = 32 * 1024 = 32768 bytes. Other than that, and assuming no handshake delays or the transmitter lagging behind the driver, yes. – Hans Passant Sep 28 '12 at 22:42
  • 5
    Your question is incomplete, because you only specify a "serial" connection. Serial connections could be synchronous or asynchronous. The more common "serial" connection is of course EIA-232 (aka RS-232) async. For async serial connection, the *baud rate* only specifies the *bit rate* for the bits **in the character frame**. The *asynchronous* attribute means that the timing between character frames is unspecified. So a "time to send" over an async serial connection can only come up with a minimum time, and is unbounded on the max time. – sawdust Sep 29 '12 at 10:37
  • 3
    Technically, the baud rate specifies the number of *symbols* per second; rather than bits. If I remember correctly, telephone line modems peaked at 9600 baud, but by encoding more bits per symbol, we're able to achieve 14.4kbps to 57.6kbps. Otherwise, I think your math is right, ignoring any other factors like error correction. – Ian Clelland Oct 02 '12 at 00:38
  • For all the *traditionalists* out there fighting over in which cases "kilo" means 1024, an in which 1000: stop this already. Please. Kilo means 1000×. Kibi means 1024×. [Period.](https://en.wikipedia.org/wiki/Timeline_of_binary_prefixes) – ulidtko Mar 11 '20 at 18:07

2 Answers2

14

Indeed but you have lost precision by multiplying your approximation of the bit width, such that then specifying the time to three decimal places is incorrect.

To avoid loss of precision, do not use a rounded intermediate expression, but rather: 

bytes x bits_per_character / bits_per_second

So in your case:

32000 x 10 / 9600 = 33.333(recurring) seconds.

Traditionally however 32Kb refers to 32 x 1024 bytes, so in that case: 

32 x 1024 x 10 / 9600 = 34.1333(recurring) seconds.
Clifford
  • 88,407
  • 13
  • 85
  • 165
  • 1
    An answer of six significant digits is unwarranted, since the correct answer requires the words "at least" prepended to the value. You cannot stipulate or assume that there is absolutely zero dead time between every character frame. BTW *"32Kb refers to 32 x 1024 bytes"* should be capital "B" in "Kb". – sawdust Sep 29 '12 at 19:38
  • @sawdust: Feel free to edit the Kb if you *really truly* think it is at all important or in any way clearer! Regarding inter-character spacing, of course that is valid. But one would perhaps assume that if this calculation is at all important, then the design would ensure that the UART remained fed with data throughout the transmission - which would not normally be a problem at low data rates such as this. – Clifford Sep 29 '12 at 22:39
8

If you need to roughly check the magnitude (whether it's 3s or 30 or 300), remember that 9600 kbps ~ 1KB/second (10 bits if you have 2 extra parity/stop bits), so 32KB -> around 32 seconds.

makapuf
  • 1,370
  • 1
  • 13
  • 23
  • Fair enough for an approximation, but the question states the time to three decimal places; so perhaps more than an approximation is required? – Clifford Sep 29 '12 at 13:15
  • So you could say it takes about one millisecond per byte, right? – mvermand Jan 17 '17 at 20:25