UART throughput with small data chunks

GoogleGroups
1

Hi,

Is there any way of getting bigger speeds when sending small chunks of data (~50bytes)?

About my BBB:

Rev: C.
Kernel version: 3.8.13-bone70.
Distribution: Debian.

Scenario 1: looping big data chunks (4094 bytes):

Baud rate set to 1500000 with: stty -F /dev/ttyO4 1500000.
When I send (using write()) a buffer of 4094 bytes of data, and immediately after I read it (using read()), and count the number of loops for one second, I get around 160000 bytes (this means a throughput of ~1.3 Mbps).

Scenario 2: looping smaller data chunks (68 bytes):

Same baud rate, same method, I get around 30000 bytes in one second (~0.24 Mbps).

How can I achieve bigger speeds when reading small data chunks?

Is this test that I made relevant? (would be different if using another device that sends me data on UART (1500000 baud and aprox. 1.5 Mbps throughput)?)

Thanks.

2

Hi,

Is there any way of getting bigger speeds when sending small chunks of data (~50bytes)?

About my BBB:

Rev: C.
Kernel version: 3.8.13-bone70.
Distribution: Debian.

Scenario 1: looping big data chunks (4094 bytes):

Baud rate set to 1500000 with: stty -F /dev/ttyO4 1500000.
When I send (using write()) a buffer of 4094 bytes of data, and immediately after I read it (using read()), and count the number of loops for one second, I get around 160000 bytes (this means a throughput of ~1.3 Mbps).

Something's wrong with your test jig.

1.5Mbaud includes start bit & stop bit so each char frame is 10bits.
Thus max throughput is 150Kchars/sec.

Scenario 2: looping smaller data chunks (68 bytes):

Same baud rate, same method, I get around 30000 bytes in one second (~0.24 Mbps).

How can I achieve bigger speeds when reading small data chunks?

Is this test that I made relevant? (would be different if using another device that sends me data on UART (1500000 baud and aprox. 1.5 Mbps throughput)?)

There's a limit to how many syscalls/sec are possible and further limited by locks and atomics in the read() syscall for ttys.
A smaller read buffer will _always_ produce less throughput. Newer kernels will have better read() throughput though.

Regards,
Peter Hurley

3

That's right, I forgot about start/stop bits.

Do 4.x kernels still have this limitation?

4

A quick i/o test on 4.6.0-rc7 showed no difference in throughput
between 4096-byte reads and 68-byte reads @ 1.5Mbaud in raw mode.

Both averaged around 144Kchars/sec, or 96% b/w saturation, on
a not loaded BBB.

NB: the i/o test ran on a single BBB with uart4 sender
to uart5 receiver. IOW, I would expect similar results at
full-duplex.

Regards,
Peter Hurley

5

Thank you for testing!

What distribution are you using?

duminică, 15 mai 2016, 07:54:55 UTC+3, Peter Hurley a scris:

6

The test unit was Ubuntu 14.04.4 with not-quite-vanilla mainline kernel.

7

I have installed Arch Linux, with 4.6.0.3 Kernel version and performed the same speedtest.

Almost the same, from ~0.25Mbps to ~0.35Mbps.

Do you have any idea why? Why would the distribution matter?

I choose to install Arch Linux because it came by default with 4.6.x Linux Kernel, and I didn’t need to compile a custom one.

luni, 16 mai 2016, 01:12:36 UTC+3, Peter Hurley a scris:

8

I doubt the distribution matters; I think there’s probably something different/wrong with either your test or your h/w setup. What are you using to generate i/o and what are you measuring? What are your termios settings?