Linux Serial Console Driver Lands Patch For Possible ~25% Performance Improvement

[tuxd3v]

Per wikipedia, the 16550 was originally introduced in 1987, which was actually before the 486. That being said, they are still around. Not in the original form, but some tiny speck of dust in the corner of the system chipset that emulates the original device. So still limited by the 16 byte buffer. On my laptop (that doesn't even have a rs-232 port):

$ dmesg|grep ttyS
[ 2.332159] 0000:00:16.3: ttyS4 at I/O 0x3060 (irq = 19, base_baud = 115200) is a 16550A
[ 69.425124] dw-apb-uart.1: ttyS5 at MMIO 0x604110f000 (irq = 20, base_baud = 115200) is a 16550A

Because the system is telling you that you have a 16550A, doesn't mean it is really a 16550A, it means the driver it is using has that capability... its compatible..
But It could be that you are still using ancient technology in 2022,
But I would suppose that you were using, at least, a last iteration of it, and by that I mean a 16850/16950..or any knew part developed in the 21 century..

• 8250, 16450, early 16550: Obsolete with 1-byte buffers
• 16550, 16550A, 16C552: 16-byte buffers, TL=1,4,8,14; 115.2 kbps standard, many support 230.4 or 460.8 kbps( this part were present in 486 devices.. )
• 16650: 32-byte buffers. 460.8 kbps
• 16750: 64-byte buffer for send, 56-byte for receive. 921.6 kbps
• 16850, 16C850: 128-byte buffers. 460.8 kbps or 1.5 mbps
• 16950

This is one of the reasons why ARM CPUs have great uarts, some of them with baud rates in excess of 1.5 mbps

[jabl]

Because the system is telling you that you have a 16550A, doesn't mean it is really a 16550A, it means the driver it is using has that capability... its compatible..

Yeah, or like I wrote (quoting myself):

Not in the original form, but some tiny speck of dust in the corner of the system chipset that emulates the original device.

So there is some device that advertises itself as a 16550A, and the software driver can thus work with it just like if it was a "real" 16550A. But it also means that it inherits the limitations of the original 16550A, like the 16-byte FIFO.

But It could be that you are still using ancient technology in 2022,
But I would suppose that you were using, at least, a last iteration of it, and by that I mean a 16850/16950..or any knew part developed in the 21 century..

Nah, the laptop in question is only a couple of years old. For another data point, the desktop machine where I'm writing this message is something like 5 years(?) old, and also advertises a 16550A.

Looking at the Linux 8250 driver, it's capable of handling newer chips like the 16850 too. But maybe the Windows serial driver only supports the 16550A so there's no incentive for PC chipset manufacturers to spend $$$ and transistors on more capable IP? ARM might be different, as I'd guess the embedded world might have usecases for more capable serial interfaces.

[sinepgib]

ARM might be different, as I'd guess the embedded world might have usecases for more capable serial interfaces.

You pretty much need the serial console for hardware bring up on those devices, so there's a lot more motivation. For example, you'll often want to read what u-boot outputs during boot when it fails to launch your kernel.

[jabl]

You pretty much need the serial console for hardware bring up on those devices, so there's a lot more motivation. For example, you'll often want to read what u-boot outputs during boot when it fails to launch your kernel.

Serial consoles are also very common in (x86) server platforms, and I've never seen anything but 16550A there either. For a serial console, the 115.2 kpbs that it's capable of is sufficient. I was assuming many embedded platforms would be using serial for some custom communication, hence a need for a somewhat more capable interface (without having to go to some more modern, expensive and complicated link).

[sinepgib]

Serial consoles are also very common in (x86) server platforms, and I've never seen anything but 16550A there either. For a serial console, the 115.2 kpbs that it's capable of is sufficient. I was assuming many embedded platforms would be using serial for some custom communication, hence a need for a somewhat more capable interface (without having to go to some more modern, expensive and complicated link).

Hmmmm, well, being common and being a must are very different things. I'm not sure how often you really need to use the serial interface on those servers. Then again, I have no experience working with those, so my ignorance of it doesn't make it not the case.
GSM modules work pretty much like a UART from the OS POV, but I have no idea if they actually use a serial controller for communication. But if they do, there's a pretty big incentive for them to be fast.

[tuxd3v]

Nah, the laptop in question is only a couple of years old. For another data point, the desktop machine where I'm writing this message is something like 5 years(?) old, and also advertises a 16550A.

Looking at the Linux 8250 driver, it's capable of handling newer chips like the 16850 too. But maybe the Windows serial driver only supports the 16550A so there's no incentive for PC chipset manufacturers to spend $$$ and transistors on more capable IP? ARM might be different, as I'd guess the embedded world might have usecases for more capable serial interfaces.

Yeah, It can be the case..
Because its a low speed device, they don't bother to update the hardware of it..

In the laptops nowadays, serials are not even available from the outside( but they are good to troubleshooting something in the motherboard ),
But in desktop/Embedded use cases, yeah serials are available and are used for a lot of different things..

I agree with you, we in the Linux world still have a limitation on hardware..
Hardware is created based on what MS Windows, can support..its a shame but its what we have..

Now on new Servers, they should take some care, because Linux occupy a great share part of the Datacenter now, but I believe they continue to release hardware based on the support is has for Windows..