UART throughput with small data chunks

[marius.m...@gmail.com]

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.

[Peter Hurley]

On 05/13/2016 02:45 AM, marius.m...@gmail.com wrote:
> 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

[marius.m...@gmail.com]

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

Do 4.x kernels still have this limitation?

[Peter Hurley]

On 05/14/2016 08:49 AM, marius.m...@gmail.com wrote:
> That's right, I forgot about start/stop bits.
>
> Do 4.x kernels still have this limitation?

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

[marius.m...@gmail.com]

Thank you for testing!

What distribution are you using?

[Peter Hurley]

On 05/15/2016 11:35 AM, marius.m...@gmail.com wrote:

Thank you for testing!

What distribution are you using?

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

[marius.m...@gmail.com]

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.

[Peter Hurley]

On 05/23/2016 10:05 AM, marius.m...@gmail.com wrote:

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.

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?

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

On 05/15/2016 11:35 AM, marius.m...@gmail.com wrote:

Thank you for testing!

What distribution are you using?

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

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

On 05/14/2016 08:49 AM, marius.m...@gmail.com wrote:
> That's right, I forgot about start/stop bits.
>
> Do 4.x kernels still have this limitation?

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

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/338aa8c7-be2b-406d-a53a-7ed63f209093%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.