Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Fri, 6 Apr 2018 12:42:47 +0100
From:   Alan Cox <gnomes@lxorguk.ukuu.org.uk>
To:     Muni Sekhar <munisekharrms@gmail.com>
Cc:     linux-serial <linux-serial@vger.kernel.org>,
        linux-kernel@vger.kernel.org,
        kernelnewbies <kernelnewbies@kernelnewbies.org>
Subject: Re: uart throughput
Message-ID: <20180406124247.551e26a9@alans-desktop>
In-Reply-To: <CAHhAz+io6_dS=+YO=Zd9rYuPomOOFtd2GsweKyvN1A4zKQZOVA@mail.gmail.com>
References: <CAHhAz+io6_dS=+YO=Zd9rYuPomOOFtd2GsweKyvN1A4zKQZOVA@mail.gmail.com>
Organization: Intel Corporation
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

> 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