Re: [boot-time]

On 1/8/25 15:19, Bird, Tim wrote:
>> Cases:
>>
>> - #1 quiet: cmdline w/ quiet, no kernel or userspace output up to the
>> serial login console
>>
>> - #2 normal: cmdline w/o quiet, serial console @115200 baud
>>
>> - #3 normal_baud9600: cmdline w/o quiet, serial console @9600 baud
>>
>>
>> Main outcomes:
>>
>> - kernel timestamps "Run /sbin/init as init process"
>>
>> #1: "1.714458", #2: "3.011701", #3: "16.108101"
> 
> Wow from 1.7 seconds to 16.1 seconds.  That's a pretty huge
> difference.  I guess this particular technique is still
> very relevant!

CONFIG_EARLY_PRINTK output is emitted before interrupts are enabled 
(last I checked they didn't kick in until RIGHT before PID 1 gets forked 
off), so the early output drivers spin waiting for the next character to 
go into the buffer (the memory mapped register ones look something like 
"while (MASK&*status); *output = *data++;" in a for loop) and the 
printk() call can't return until all the data has been queued to the 
serial hardware, so you spend a lot of time blocked in printk().

With 9600 baud 8n1 output, 9600/9 = 1066 characters per second, or 
approximately a 1ms wait between each character, blocking in printk when 
the hardware FIFO buffer fills up, so 16k of output data takes 16 
seconds to write if the rest of the boot is doing NOTHING. Even a 1k 
hardware FIFO is only 1 second of output, and that's assuming all 1k is 
outgoing rather than split between in/out.

Your options are:

1) disable early printk so it all goes into a malloced buffer until 
interrupts are enabled and it can be asynchronously flushed (meaning if 
something DOES go wrong in early boot you can't see it)
2) set your FIFO speed as fast as possible
3) have your default boot use the "quiet" option (similar to disabling 
EARLY_PRINTK but at least you have the option to yank quiet from your 
bootloader args without rebuilding the kernel.)

Faster UART speeds mean shorter serial cables (although there's also 3 
volt vs 5 volt, wire thickness/capacitance, and some other stuff, Jeff 
Dionne walked me through the math last year but I don't have my notes in 
front of me). Modern hardware can do up to 4 megabits/second but outside 
"this serial chip immediately talks to a USB chip and then it's 
transported as USB with the funky noise-cancelling signaling over VERY 
twisted pair to actually leave the board"), I wouldn't trust that over 
any real length of cable.

Alas 
https://tldp.org/HOWTO/Remote-Serial-Console-HOWTO/serial-distance.html 
is from the dawn of time and only goes up to 56k over wires made from 
recycled drainpipes. 
https://novatel.com/support/known-solutions/maximum-cable-length-vs-data-rate 
says 115200 is 2.5 meters. It LOOKS like it scales linearly with twice 
the speed being half the cable, so a megabit would be about 1 foot of 
serial cable before the bits get all mushy.

Rob