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.
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
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
Thank you for testing!
What distribution are you using?
duminică, 15 mai 2016, 07:54:55 UTC+3, Peter Hurley a scris:
The test unit was Ubuntu 14.04.4 with not-quite-vanilla mainline kernel.
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:
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?