linux-kernel - Re: uart throughput

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20180406124247.551e26a9@alans-desktop>
Date:   Fri, 6 Apr 2018 12:42:47 +0100
From:   Alan Cox <gnomes@...rguk.ukuu.org.uk>
To:     Muni Sekhar <munisekharrms@...il.com>
Cc:     linux-serial <linux-serial@...r.kernel.org>,
        linux-kernel@...r.kernel.org,
        kernelnewbies <kernelnewbies@...nelnewbies.org>
Subject: Re: uart throughput

> 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