Hi All, I’ve an uart hardware implemented on Xilinx FPGA image and it connects to host CPU(Intel based chip) on PCIe bus in Linux platform. The following parameters were fixed or varied when measuring the UART throughput in internal loopback mode(UART_RX and UART_TX pins were internally connected): • Uart baud rate • Parity Bit • Stop Bit(s) The primary factor affecting UART throughput is the baud rate, apart from this any other factors affect the UART throughput? For 4000000 bps uart baud rate, what should be the theoretical peak data throughput? -- Thanks, Sekhar
On Thu, Apr 05, 2018 at 10:08:14PM +0530, Muni Sekhar wrote:
Hi All,
I’ve an uart hardware implemented on Xilinx FPGA image and it connects to host CPU(Intel based chip) on PCIe bus in Linux platform.
The following parameters were fixed or varied when measuring the UART throughput in internal loopback mode(UART_RX and UART_TX pins were internally connected):
• Uart baud rate • Parity Bit • Stop Bit(s)
The primary factor affecting UART throughput is the baud rate, apart from this any other factors affect the UART throughput?
For 4000000 bps uart baud rate, what should be the theoretical peak data throughput?
Um, you do know what "baud rate" means, right? And how stop bits and parity are related to a baud rate? Throughput all depends on a whole raft of different things. How exactly have you measured this and where did you find any performance bottlenecks? thanks, greg k-h
The primary factor affecting UART throughput is the baud rate, apart from this any other factors affect the UART throughput?
UART CPU power interrupt latency all the usual suspects.
For 4000000 bps uart baud rate, what should be the theoretical peak data throughput?
Depends entirely what the uart is wired to, how it works and how the driver is written. If you've got bidirectional communication going on then you also need to consider latency and windowing. For a raw transfer over a decent UART with DMA with no post-processing I'd expect you can do the full line rate but it may eat a lot of CPU time. The uart code isn't particularly optimal for that kind of usage. It's not impossible to fix by fast-pathing the non N_TTY line discipline cases but nobody has found it a big enough pain to bother. Alan
participants (3)
-
Alan Cox -
Greg KH -
Muni Sekhar