We're currently building a chain of linux tools to do some realtime encoding for video broadcast purposes. In order to archieve this, we created a program in C++ that spawns some ffmpeg decoder processes (for both audio and video), pipe this output to the encoders (ffmpeg & mpeg2enc) through fifo's, and then pipe the encoded output to our muxer which caches a few MB of data and then outputs the muxed file through an ASI output card.
In debian 5, this setup works flawlessly, and generally doesn't even create a high CPU load. On debian 6 and Ubuntu 10.04 however, the internal buffer of the muxer gradually decreases until it hits zero, after which frequent output hickups start to occur.
Using nice and ionice doesn't seem to fix this issue. I've also tried various custom kernel compile options (increased frequency, preemptation, etc) but this also doesn't seem to work.
Altough it might be possible that there has been serious regression in either ffmpeg or mpeg2enc, I'm guessing that the problem has to do with the way the new kernel/distro handles FIFO's.
Does anybody know what could be causing this problem? Or what have been recent changes in both Debian or it's kernel configuration (between version 5 and 6) and Ubuntu that could possibly caused this undesired behaviour?
Related
I'm trying to achieve this on a Raspberry Pi 4:
Less then 10 seconds boot time
Custom UI ( build with python/Gtk for example )
I already tried editing the /boot/config.txt with
# Disable the rainbow splash screen
disable_splash=1
# Disable bluetooth
dtoverlay=pi3-disable-bt
#Disable Wifi
dtoverlay=pi3-disable-wifi
dtoverlay=sdtweak,overclock_50=100
# Set the bootloader delay to 0 seconds. The default is 1s if not specified.
boot_delay=0
# Overclock the raspberry pi. This voids its warranty. Make sure you have a good power supply.
force_turbo=1
Also I have an A2 class 10 SdCard and I have disabled almost every service that I don't need.
My best results are 14 seconds boot time until my app started, but I need to make it faster....
I would like to achieve something like this in terms of speed, but using GTK, not QT:
https://www.youtube.com/watch?v=TTcP3xeLrEY
I am also currently trying to reach fast boot time with my Raspberry Pi 4, but I cannot breach the wall of 10s without radical solutions such as buildroot or unikernel.
What do you need on your system ? On Raspbian you can use those two commands to verify what is slowing down the boot process :
systemd-analyze critical-chain
and
systemd-analyze blame
Critical chain will show in red the services blocking the boot.
On my setup I could desactivate all those services :
hciuart #GPIOs
nmbd
smbd
wpa_supplicant
systemd-timesyncd
rpi-eeprom-update.service
raspi-config.service
networking
Just use sudo systemctl disable SERVICE , I guess there are others that are not critical for your application.
Also, in the cmdline.txt file in /boot you can add quiet fastboot , it will decrease boot time further
GTK is a toolkit coded in C and callable from C code.
In practice, Python can be 10x slower than equivalent C code.
Did you consider starting Xorg with a minimal window manager and a single client coded in C? Without a single line of Python? Of course, read more about X windows systems protocols and architecture then about EWMH.
So, remove the Python interpreter on your RaspBerryPi (probably /usr/bin/python) and replace every old Python script by an equivalent ELF executable coded in C or in C++ and compiled with optimizations (so gcc -O3 with GCC). See also linuxfromscratch.org for inspiration and guidance.
I would like to achieve something like this in terms of speed, but using GTK
Of course, you want to use a GCC cross-compiler.
If that still does not work (after weeks of effort), replace your hardware by something more powerful.
It would be easier for you to install a Linux distribution such as Debian on your development laptop or desktop. Because most of what you would learn on your development computer (e.g. Advanced Linux Programming) can be applied to the RaspBerrry Pi. And cross-building on a Debian laptop for a Raspbian RaspBerryPi is really easy. Focus on learning low-level things starting from their C code. E.g. code your GUI directly with Xlib (no GTK, no Qt) in C. The same C code is very likely to be easily portable -if you write it carefully- from x86/Debian to your Raspberry Pi.
You could read the From powerup to to bash prompt howto; most of that document is relevant for a RaspBerryPi running RaspBian.
You could even avoid starting any Xorg or other display server (e.g. WayLand) on your RaspBerryPi. That certainly would make it boot faster.
You could replace your /sbin/init program by your own one coded in C entirely. That process starts within less than a second, and forks all other processes. Your custom GUI could be just Xorg with your single X11 client coded in C.
Observe that you could have the source code (millions of source lines) of all the code running on RaspBian. Then download it, study it, and optimize it. Of course this could take decades.
First, this is a poorly formed question. You've provided no details on what your boot process is or what OS/configuration you're running with for people to help.
Regardless, you appear primarily focused on a short boot time. So since your question is generic... here is a generic answer: there is nothing magical about the boot process. There is no config file with a fast_boot=1 option that gets you up in 0 seconds instead of 15. You want to boot faster? Do less.
Throw out slow crap like Python
Remove unnecessary application loading from your init system (sysvinit/systemd/whatever)
Remove unnecessary driver loading from the kernel startup. Start by trimming down your device tree to only the hardware you really need to initialize.
Optimize your bootloader (u-boot?) to only initialize the hardware you really need (obviously turn off any prompt and timer it may implement)
That's how you boot faster.
Is there a way to fully dump the configuration of an Intel HDA-based audio codec, including current hardware state?
The interface at /proc/asound/card0/codec#0 only reflects what's known to the kernel, not the real hardware state.
The PCI configuration space (read with lspci -x) doesn't show much (it doesn't even show volume/amplifier gain values).
For context : I'm trying to debug an audio issue with my laptop, where headphones output white noise when resuming from standby. The white noise doesn't change when increasing volume, but disappears only when powering down the codec.
This leads me to believe that the issue is likely caused by either a buggy ACPI or a change in the codec's configuration, or even both. My goal is to get as much data as I can on before/after states and compare them, but both methods described above failed for me.
I found that hdajackretask as part of the alsa-tools-gui package on my Debian Stretch GNU/Linux Os looks very interesting in getting the internal parts of the sound-card in the right configuration for what I wanted.
I'm just looking to see whether it is portable to my other OS as I have only seem to have stereo audio on FreeBSD and I think this would help. In your case it might help your to decode how things are configured and to spot any changes. The normal screen is at least helpful in determining which connection is which:
What looks more interesting is the "Advanced override":
I am about to reboot and see whether I have managed to turn the grey connector be the "side"-channel outputs....
Im looking for a way how to get rid of (kernel?) messages that appear in my ncurses app. I wrote the app myself, so i would prefer a API that redirects these messages to /dev/null. I mean messages like, a USB stick that is inserted.
I tried to add this, but unfortunately it doesn't work
freopen("/dev/null", "w", stderr);
I'm not running X, just ncurses direct from the console.
I mean messages like, a USB stick that is inserted.
Thanks!
UPDATE 1:
Someone votes to close this question because it would not be related to programming. But it is, i wrote the ncurses app myself, i'm looking for a way how to disable the kernel message. I updated the question.
UPDATE 2:
Let me explain what i'm doing, and whats the problem in more detail:
I'm using Tiny Core linux, thats after boots starts (self written) ncurses program. Now when you for example connect a USB drive, a message (i suspect kernel) is shown over my program. I guess the message is written straight into the framebuffer. Im using TC 5.x since i need 32 bit, im running as root and have full access to the os.
You should be able to use openvt to have your program run on a new Virtual Terminal.
I'll also note that it should be possible to embed control for the VTs yourself if you prefer to break the external dependency, but note that structures used may not be stable between kernel versions, and may require recompilation.
See the KBD project's sources, specifically openvt.c to see how it works.
Try configuring the kernel through boot parameters with the option:
loglevel=3 (or a lower value)
0 (KERN_EMERG) system is unusable
1 (KERN_ALERT) action must be taken immediately
2 (KERN_CRIT) critical conditions
3 (KERN_ERR) error conditions
4 (KERN_WARNING) warning conditions
5 (KERN_NOTICE) normal but significant condition
6 (KERN_INFO) informational
7 (KERN_DEBUG) debug-level messages
source: https://www.kernel.org/doc/Documentation/kernel-parameters.txt
See also: Change default console loglevel during boot up
It might be impossible to block some other process with sufficient access from writing to /dev/console but you may be able to redefine console as some other device, at boot time by setting console=ttyS0 (first serial port), see:
https://unix.stackexchange.com/questions/60641/linux-difference-between-dev-console-dev-tty-and-dev-tty0
Also if we know exactly which software is sending the message it may be possible to reconfigure it (possibly dynamically) but it would help to know the version and edition of Tiny Core Linux you are using?
E.g. this website has a "Core", "TinyCore" and "CorePlus" versions 1.x up to 7
http://tinycorelinux.net/downloads.html
This would help reproducing the exact same behavior and testing potential solutions.
I'm midway through a VHDL class and have been able to play relatively nice with the ISE and Digilent toolchain in Linux... until trying to reflash a PicoBlaze program. For details, I am currently running and targeting,
Fedora 21 64-bit (3.19.3-200.fc21.x86_64)
Nexys2 development board from Digilent (with a Spartan3)
Xilinx ISE 14.7
Adept 2.16.1 Runtime
Adept 2.2.1 Utilities
I've been able to run ISE and program the Nexys2 bit files with iMPACT just fine so far in Linux, but this current project is to write an assembly program for the PicoBlaze soft core processor, compile and update the memory of the running vector without having to resynthesize any VHDL.
Using the steps from Kris Chaplin's post, I can compile a PSM to HEX and then convert that HEX file to an SVF in dosbox. From here I can use Digilent's Adept tool in Windows to program a top_level.bit file which has the PicoBlaze already synthesized, I could also do this in ISE's iMPACT in Linux. After the design is running, I can use Adept to program the SVF file into the running memory of the design and everything is peachy. However, trying to load the SVF into iMPACT in Linux throws an exception,
EXCEPTION:iMPACT:SVFYacc.c:208:1.10 - Data mismatch.
The only issue I've found online with that error shows that there should be an '#' symbol that needs to be removed, but I haven't seen any '#'s anywhere in the SVF.
I also tried to convert the SVF to XSVF. iMPACT doesn't throw an error loading the XSVF, but programming/executing the XSVF freezes the design instead of running the new program.
Adept doesn't have a comparable GUI in Linux that I've seen, just a cmd line tool 'djtgcfg'. Just like iMPACT, I've been able to program the toplevel.bit file fine with
$ djtgcfg prog -d Nexys2 -i 0 -f ../../toplevel.bit
but attempting to program the svf file with the same call doesn't seem to affect anything. It says it should take a few minutes and immediately reports "Programming succeeded" but I don't see any change on the device.
I'd really like to keep my environment all in Linux if I can, I don't have quite enough room on my laptop to juggle between two VMs.
Is it possible to use use iMPACT to write an SVF file to the Nexus2? Or can/should I be using the Adept utility differently?
Has anyone gotten this to work? Thanks a ton!
There are many better ways to reconfigure the PicoBlaze InstructionROM without resynthesizing:
use Xilinx's data2mem tool
This toll is shipped with ISE and can patch BlockRAM contents in bit-files
=> requires FPGA reprogramming
use PicoBlaze's embedded JTAGLoader6
Enable the embedded JTAGLoader6 design in the template file. Use JTAG_Loader_RH_64 binary or JTAG_Loader_Win7_64.exe to upload a hex-file via JTAG into the PicoBlaze ROM.
=> reconfigure ROM at runtime, no FPGA reprogramming needed
The manual from Ken Chapman offers several pages on how to use JTAG_Loader. Additionally, have a look into the PicoBlaze discussions at forums.xilinx.com. There are some discussions regarding bugs and issues around JTAG_Loader and how to solve them.
Also have a look into opbasm from Kevin Thibedeau as an alternative and improved PicoBlaze assembler. It is also shipped with an ROM patch tool.
I know it's a little bit late for the original poster, but I suspect I am taking the same class and I believe I have found a solution to upload picoblaze code on linux.
Download the KCPSM3 zip file from Xilinx IP Download, extract the contents and move the executables from the JTAG_loader folder to your working directory.
In dosbox run hex2svfsetup.exe for the nexys2 board select menu options 4 - 0 - 1 - 8
Use the assembler to create the .hex file
In dosbox run hex2svf.exe to create the svf file
Then run svf2xsvf.exe -d -i < input.svf > -o < output.xsvf >
The contrary to the JTAG_Loader_quick_guide.pdf in the initial zip file use impact and open the xsvf file and program using the xsvf file.
I am doing project on Pandaboard using Embedded Linux (UBUNTU 12.10 Server Prebuild image) to optimize boot time. I need techniques or tools through which I can find boot time and techniques to optimize the boot time. If anyone can help.
Just remove application which is not required from /etc/init.d/rc file also put echo after every process initialization and check which process is taking much time for starting,
if you find application which is taking more time then debug that application and so on.
There is program that can be helpful to know the approximate boot-up time. Check this link
Time Stamp.
First of all the best you have to do is to compile yourself your own made kernel, get the source on the internet and do a make xconfig and then unselected everythin you don't need.
In a second time create your own root filesystem using Buildroot and make xconfig to select/unselect everything you need or not.
Hope this help.
I had the same problem and do that way, now it's clearly not the same ;)
EDIT: Everything you need will be here
to analyze the boot process, you can use Bootchart2, its available on github: https://github.com/mmeeks/bootchart
or Bootchart, from the Ubuntu packages:
sudo apt-get update
sudo apt-get install bootchart pybootchartgui
There are broadly 3 areas where you can reduce boot time
Bootloader:
Modify the linker script to initialize only the required h/w. Also, if you are using an SD card to boot, merge kernel and bootloader image to save time.
Kernel:
Remove unwanted modules from kernel config. Also try using compressed and uncompressed image. If your CPU is good enough to handle it go compressed image and check uncompression time required for different compression types.
Filesystem:
FS size can be significantly reduced by removing the unwanted bins and libs. Check for dependencies and use only the one's that are required.
For more techniques and information on tools that help in measuring the boot time please refer to the following link.
Refer to Training Material
The basic rule is: the fastest code is code that never gets loaded and
run, so remove everything you don't need:
in U-Boot: don't load and run the full U-Boot at all; use FALCON
mode and have the SPL load the Linux kernel and DTB directly
in Linux: remove all drivers and other stuff you don't really need;
load all drivers that are not essential for your core application as
modules - and load them after your application was started. If you
take this serious, you may even want to start only one CPU core
initially (and start the remaining ones after your application is
running).
in user space: minimize the size of the root file system. throuw
out anything you don't need; configure tools (like busybox) to
contain only the really needed functionality; use efficient code
(for example, link against musl libc instead of glibc) etc.
What can be acchieved by combining all these measures can be seen in
this video - and yes, the complete code for this optimization is
available here.
Optimizing embedded Linux Boot process , needs modifications in three level of embedded Linux design.
Note: you will need the source codes of bootloader and kernel
Boot : the first step in optimizing and reducing boot time of board is optimizing boot loader. first you should know what is your bootloader is. If your bootloader is an opensource bootloader like u-boot than you have the opportunity to modify and optimize it. In u-boot we have a procedure that we can skip unnecessary system check and just upload kernel image to ram and start. the documentation and instruction for this is available in u-boot website. by doing this you will save about 4 ~ 5 second in boot.
Kernel : for having a quicker kernel , you should optimize kernel in many sections. for editing you can use on of Linux config menu. I always use a low graphic menu. it need some dependency you can use it by this command:
$ make menuconfig
our goal for Linux kernel is to have smaller kernel image and less module to load in boot. first change the algorithm of compression from gzip to LZO. the point of this action is gzip algorithm will take much time to extract kernel. by using LZO we have a quicker kernel decompression process. the second , disable any unnecessary driver or module that you don’t have it on your board or you don’t use it any more. by doing this , you will lose some device access and cannot use them in Linux but you will have two positive points: less Ram usage , quicker boot time.
but please remind that some driver are necessary for Linux and by disabling them you will lose some of main features (for example if you disable I2C driver in Linux you will no longer have a HDMI interface) that you need or in worst case you will have a boot problem (such as boot-loop). The third is to disable some of unusable filesystem to reduce kernel size and boot time. The Fourth is to remove some of compression algorithm to have smaller kernel image.
the last thing , If you are using a u-boot bootloader create a uImage instead of zImage. the following steps , are general and main actions , for having quicker boot as 1 second after power attach you should change more option.
after two base layer modifications, now we should optimize boot process in user-space (root file system). depend on witch system are you using , we have different changes to do. in abstract root file system of Linux that have necessary package and system to boot Linux we should use systemd instead of Unix systemv , because systemd have a multi-task init. system and it is faster , after that is udev that you should modify some of loading modules. if you have a graphical user-interface , we can use an easy trick to have a big boot time reduction by initing GUI first and load other module after loading GUI.
if you do all of following tasks , you can have quick boot time and fast system to work with.