Serial over USB 2.0. Is it really faster than standard serial?

Question

A member of our scientific collaboration designed a data acquisition box with with 4 channels @ 1 kHz that synchronizes time with GPS. He uses USB 2.0 to have the box communicate with a computer, and the COM serial interface with a baud rate of 115200 is used to transfer data to the computer in ASCII format. The manufacturer calls this "virtual serial" over USB 2.0. Consequently, all configurations such as parity, workflow control, etc... does not matter in the serial interface, but only the baud rate has to be set to 115200 for this to work.

My question is: Does this number 115200 really represent the number of bytes per second that can be maximally transferred through this port, creating a limitation of what the USB 2.0 port can do? Or does this number really not matter and the real transfer rate is about 480 Mbits/s as standard USB 2.0?

What are the factors that decide this?

Why asking? The box currently uses uni-directional serial communication to deliver data, which causes problems of losing bytes some times on computer overload. The reliable solution would be to make the connection bi-directional with checksums and ask for packets and re-ask when data is corrupted. However, if we're really limited by 115 kB/s, this means we cannot transfer 4 channels @ 1 kHz.

If you require any additional information, please ask.

Solution

Serial over USB 2.0. Is it really faster than serial?

Your terminology is sloppy.
"Serial over USB 2.0" could refer to using USB-to-RS232 adapters, or refer to CDC/ACM.
Your last reference to "serial" presumably is to RS-232.

My question is: Does this number 115200 really represent the number of bytes per second that can be maximally transferred through this port, creating a limitation of what the USB 2.0 port can do?

115200 is the baudrate, which (in this case) is bits per second (and not bytes per second).
Since this is an asynchronous channel, each character/byte is individually framed with one start bit and 1/1.5/2 stop bits. So there's a framing overhead of 25% (assuming the typical configuration of 8N1).

USB is a bus, and can handle more than one data channel.
The asynchronous RS-232 data is packetized for transmission over synchronous USB, and shares the total bandwidth of the USB 2.0's 480 Mbs. (Although the typical USB-to-RS232 adapter uses only USB 1.1.)

I've witnessed four simultaneous 115200 baud RS-232 channels transmit over a single USB 1.1 connection without any hiccups.

Or does this number really not matter and the real transfer rate is about 480 Mbits/s as standard USB 2.0?

The number does matter because it is the baudrate configurured for that channel.

What are the factors that decide this?

The maximum baudrate is typically limited by the hardware and the supporting software.

Why asking? The box currently uses uni-directional serial communication to deliver data, which causes problems of losing bytes some times on computer overload.

Your data loss appears to be a case of system buffer overrun. The data is arriving faster than it's being read/processed by the application program. No flow control is being employed on the data channel to prevent the overrun.

Comments

[user694733]

I think it depends on how it is implemented. If MCU doesn't have built-in USB support, it could have separate serial-to-USB chip to provide the functionality. Then the speed can be limited to baudrate between the chips.

[The Quantum Physicist]

@cybernard Just 8x that? Because I'm comparing 115 kB/s with 480 Mbits/s or 60 MB/s (or with some reasonable tolerance 20 MB/s, like you said). This means that such usb-to-serial systems can never be competitive with a full USB 2.0.

[cybernard]

For many serial to USB chips that is the limit, but others go higher. I have seen implementations on motherboards that allow as much as 8x that. A native USB solution gives you 60+mb/s under the right conditions. Generally for a USB hdd 25mb/s max usb 2.0

[cybernard]

@TheQuantumPhysicist you are correct, that is why serial connections are being abandon left and right.

[The Quantum Physicist]

@user694733 If it has built-in USB, will that make it go to 480 Mbits/s (or even close)?

[The Quantum Physicist]

@cybernard Thanks for the information! This means we should abandon serial-over-usb if we want anything efficient.

[cybernard]

USB will give you 480Mbits/s minus protocol overhead. Obviously conversion from IDE, SATA has a high protocol overhead.

[The Quantum Physicist]

@cybernard Just to be sure, sorry for over-emphasizing this. I'm talking about serial interface that uses USB. All the cables are USB, but it just looks like serial on the computer. So this will never be as fast as full USB 2.0 (which is 480 Mbits/s minus overhead).

[cybernard]

what I said refers to all of the serial com port world. There is a tiny conversion chip that converts from serial to native USB and that chip is the limiting factor. Given no one uses serial ports any more no manufacturer has a financial incentive to make them go faster. Native USB even though USB uses 2 wires for data those 2 wires are operating at frequencies no serial port can match.

[sawdust]

@cybernard " Given no one uses serial ports any more" -- That's an ignorant statement, and probably reflects a PC-centric view. Home computers don't use RS-232 any more, but it's still widely used on industrial equipment. And if you use Linux on a single-board computer such as RPi, then you'd know of the console on the serial port.

[Ramhound]

"So this will never be as fast as full USB 2.0 " - Says whom? If you design serial hardware with that capability then it would indeed be possible.

[cybernard]

@Ramhound If you design the serial hardware The cost of doing this is going to be crazy. Hundreds of hours of development, testing, and certification. They you have to buy them in giant volumes. My raspberry Pi does not have one unless its just a header. SSH works way better than whatever serial can do on a Pi. If serial was a priority for them it would have a full 9 pin com port.

[sawdust]

@cybernard - "My raspberry Pi does not have one unless its just a header" -- It's 3.3V logic-level UART output on a 4-pin (or 3?) header. A (large/huge) DB-9 connector would also require an RS-232 transceiver chip and caps, and the foundation had to limit costs everywhere they could (and manage board real estate). "SSH works way better..." -- SSH is not available when your kernel fails to boot. See superuser.com/questions/440857/…

[Jairo Andres Velasco Romero]

480 Mbps are only achieved on USB 2.0 Hi-Speed profile, but CDC adapters are implemented on USB 2.0 Full-Speed which is 12 Mbps