Tiny Core Linux
Tiny Core Extensions => TCE Talk => Topic started by: Daniel on February 22, 2011, 03:44:54 AM
-
Hi evevy body,
I have to modify tce kernel (change splash image, add video card ... suppress unused drivers ... ).
Before doing anything, i want to generate mods + kernel in order to verify i do that correctly (it is my first time doing this ... but not the last).
The compilation is ok (with downloaded sources from the 2.6.33.3 kernel).
I've found bzImage ... but i don't know where to find mods ... or what i have to do with files generated!
(not found any specific documentation)
More : when i use the generated kernel, supposed identical, it doesn't work (reboot).
The compilation is done under Ubuntu 10.04 ...(i will try under tcl) ...
Thanks
Daniel.
-
I'd suggest you compile using tinycore and using the patched kernel source and tinycore .config - note that you will need the bash and perl5 extensions as well as compiletc.
I'm not sure if you'd like to suppress unused modules compiled into the kernel (in which case they are compiled into bzImage) or suppress loadable modules (in which case you just need to delete them)?
You can search on *ko to find the loadable modules in the source tree or "make modules install" will install them to the default path (/usr/lib I guess), but you can pass a switch to install them to the tinycore default path - see kernel readme files)
-
I compile now under TCL :)
with X-7.5 ... machine configuration ok!
On my new install, i almost put
- compiletc.tcz
- ncurses-dev.tcz
- perl5.tcz
the compilation ends ok :)
I've found the bzImage in /usr/srv/linux/arch/x86/boot/
but i don't know where is the tinycore.gz, or how to generate it!
Daniel.
PS
my bzImage gererated replacing the tcl bzImage is ok!!! :D
I can now make little modifications ... (TCL splash image ...)
-
but i don't know where is the tinycore.gz, or how to generate it!
tinycore.gz is not generated by compiling the kernel source (although it does contain modules generated by compiling the kernel).
If you'd like to edit tinycore.gz, you can have a look at the re-mastering section of the wiki
-
I will see if i need that!
Thank you.
And for that : http://www.gentoo-wiki.info/HOWTO_Linux_Logo_Hack
It's running!
With a 1280x1024 logo splash image :)
(I have only a little cursor up left corner)
Daniel.
-
I have a testing application.
With my compiled kernel (with splash image ... but i don't think it is the cause), my test give me 3 seconds.
With the original kernel, it was 2.5s.
The only test differences is kernel!
I loose 18 % of performances :(
where is it comming from ?
What can i do ?
Thanks,
Daniel.
-
Can somebody tell me why performances are better with the original TCL kernel than with the given sources compiled with the given parameters ?
On TCL
With TCL packages
Thanks,
Daniel.
PS: the tcl choice was done with original tcl kernel performances.
But i can't have the sames after compilation :-\
-
That highly depends on what your app is doing, what config options you changed etc.
-
First, i wanted to test the compilation ... with no change (same application).
When i succeed, i control performances : :(
I'm doing again the same test : a new build all with the original .config
[Edit] : same bad perf. result.( Original size : 2294848 bytes. My size : 2296000 byte )
Thanks,
Daniel.
ps:
The first modification wanted is changing splash image ... I don't think it can modify anything ...
-
Does anybody do the same test ?
Please, tell me if it is my configuration, or if it is "normal" with the given sources and parameters ?
Thanks,
Daniel.
-
How can anyone comment when you have not provided any performance figures.
-
The test is very simple!
Install TCL!
Install all tools and source for TCL configuration and compilation.
Install a bench program (for example : a flash fp_meter)
Do test.
After compilation : replace kernel on your machine.
Do Test again and compare results.
My application is a flash caroussel with time displayed after one rotation, thats why i propose flash pf meter.
Thanks
Daniel.
-
The test is very simple!
Install TCL!
Install all tools and source for TCL configuration and compilation.
Install a bench program (for example : a flash fp_meter)
Do test.
After compilation : replace kernel on your machine.
Do Test again and compare results.
My application is a flash caroussel with time displayed after one rotation, thats why i propose flash pf meter.
Thanks
Daniel.
Install all tools...
Install a bench program (for example... )
Nice, exact definition. And a flash pf meter (?)
In such case I would say the reason is a local distorsion of the gravitation which is inflencing the q-factor of the 49-th dimension (possibly 50th, must be checked)
;D
-
I can't join my FpsMeter ...
but it is here
http://git.forwardbias.in/?p=npploader.git;a=commitdiff;h=792d2f0c349320b551aa7bf717d312e0132b6bdc (http://git.forwardbias.in/?p=npploader.git;a=commitdiff;h=792d2f0c349320b551aa7bf717d312e0132b6bdc)
Don't forget to use firefox and flash plugin ... or standalone flashplayer
Try in full screen ...
Thanks,
Daniel.
-
Hi Daniel
First of all read this http://forum.tinycorelinux.net/index.php?topic=8717.msg47128#msg47128, pay close
attention to the sections about disabling options, then read those sections 3 more times so that they sink in.
Simply switching an option OFF and right back ON can change something else in the config file. If you use the
patched source files, and the .config file from the repository, and the same compiler version, and create the
same tinycore.gz file, you will get the same results as the original. Your bzImage file is 1152 bytes larger
then the original, so there is at least one thing you did different. Until you reproduce the original you cannot
benchmark any changes.
"The first modification wanted is changing splash image ... I don't think it can modify anything ..."
I doesn't matter what you think, just what you know, in the end reality will prevail. Here's a good motto to live
by, "Trust but verify".
It also helps if you provide details of what you've done and what you are trying to achieve, you didn't mention
installing bash.
Easy there bmarkus, he may not know how to spell performance.
-
I confirm that i don't do any modification in the original .config file! (make menuconfig not done).
Effectively, seeing kernel size, something is different!
Certainly in my configuration, if anyone has done the same test and has 'good' results!
I just want to have same performances, with finding the problem origin!
If I have the problem, some others can have it, without notice.
then, 20% better performances is goog, isn't it ? :)
Thanks
Daniel.
-
I certainly have not seen even one reported performance measurement.
Reputable benchmarks should be used.
-
Graphical performances are what i want!
This FpS meter is very good for that (and cpu calculation).
I have 2 hardware machines.
After finishing one, i will set the intel emgd graphic driver corresponding to my hardware.
Without it, i have very very bad graphical performances with original kernel.
...
-
Hey, I'm jus joking :) Don't take it serious...
:)
-
:D
-
It's not unexpected to get slightly different size even with the same config. I believe the parallel options (-jX to make) can alter the build order, and thus compression.
-
As could different uninitialized data in partially filled blocks.
-
Hi Daniel
Ok, now we finally know your goal, graphics performance. How fast are your machines, how
much RAM, and which video cards are you using. As a general rule the kernel is the last place
to look if you are having performance issues. The first suspects are applications and drivers.
If it's a driver issue you can use modprobe to install a different driver without touching the kernel.
It's not unexpected to get slightly different size even with the same config. I believe the parallel options
(-jX to make) can alter the build order, and thus compression.
Exactly. The compiler's output is based on it's input and what you tell it to do. If you use the same tools,
sources, switches, and options you will get the same output.
-
Exactly. The compiler's output is based on it's input and what you tell it to do. If you use the same tools,
sources, switches, and options you will get the same output.
Sure about that? I'm not...
-
Hi hiro
Pretty sure. You can have multiple copies of the compiler running off and generating
object files in parallel, but when it comes time to link only one process can be
writing to an output file for a given link command. Plus the makefiles list the order in
which to add individual object files into output files.
-
Rich,
Yes, i want graphical performances as best as possible.
The video driver is verry important : Intel 945GSE (GMA950) with shared 224Mb.
1Gb RAM
But, this is not the actual problem:
The problem is the performances differences between original kernel and its compiled sources.
Before i try to win more better performances, i've loose 20%!!!
:(
I expect this is comming from my configuration, and when repared, i'm shure i will have best performances as possible!
Thanks all
Daniel.
-
Hmmmmm,
Sounds like the flux capacitor may need a re-alignment...
Miller.
-
Hi,
I've build all again : same result.
I'm trying to do an other TCL install and doing all again!
(it is possible in less than 15 mn).
If anybody can do the same test, we will see if I have a problem, or if the result is 'normal' with downloaded sources and configuration ... ???
Thanks
Daniel.
-
I was looking sources to download all again ...
To do my tests, i download (and compile) kernel 2.6.33 patched ... but date is 2010-Apr-27.
And the 3.4 TCL (my original install) is after!
If i am not wrong, what have i to do to have exactly the same sources to be compiled to have same performances résults ?
Or modifications are only in mods ?
D.
-
There are also some patches (see the dates), which were applied after the generation of said kernel you downloaded.
Not sure how this would change performance, but you might give it a try :)
Perhaps it will only be fast enough if you pray to your god a little more?
http://distro.ibiblio.org/pub/linux/distributions/tinycorelinux/3.x/release/src/kernel/33-patch-series/
-
Is it necessary to use all patches, or only thoses corresponding to be done after kernel date?
What is the reason of having patch witch are almost applied ?
D.
-
3 patches were applied.
No better performace :(
D.
-
The squashfs patches were used to update the squashfs module, after the original kernel builds.
-
I've build all again : same result.
Confirmed. On standard TC 3.5 with standard TC compile tools, the distributed kernel source ("linux-2.6.33.3-patched.tbz2") plus the distributed kernel configuration file ("config-2.6.33.3-tinycore") do NOT generate the same binary kernel ("bzImage") that is distributed with TC.
Daniel, as you described previously, the generated kernel is larger (2296000 bytes) than the kernel that comes with TC (2294848 bytes). In addition, a "cmp -b -l [...] | wc -l" between the two kernels shows 2283120 differing bytes.
After applying the three squashfs patches that cooperated ("squashfs-warning.patch" did not), there were still 2283073 differing bytes.
Trying to apply the remaining (non-squashfs) patches showed that they HAD already been applied.
Gentlemen, the situation is a mess. You may wish to do some spring-cleaning while your collection of applied and non-applied patches is still halfway manageable.
-
Couldn't the differing result be due to the fact that some of all involved tools have been updated since the repo kernel was compiled?
Once there is a difference of ~1KB I'd doubt that result of comparing compressed binaries by using 'cmp' could be of much relevance...
-
Thanks for the test, Frank!
I stop my investigations and wait for what i have to do to have correct way of compiling (or patch ... etc).
I can make specific tests if necessary :)
Tell me!
Daniel.
-
As mentioned, it's expected to get a different binary. Both order of objects and any uninitialized fields can affect compression.
Try with any two files, tar cvzf test1.tgz a b; tar cvzf test2.tgz b a
-
i'm not worring about crc or size!
But about performances!
Compilation can be made as anybody want!
But if link edition has not same results, it has to be ordered done!
Same for initialisations!
But i'm more thinking of a compilation / link optimisation option, or an unknown patch ...
D.
-
There has been a lot of speculation and claims, but still not one bit of
documentation of any performance issues.
-
If you re-read the thread you will find that the performance issue was described on page 1. Daniel's Flash application in fullscreen mode takes 2.5 seconds with the original TC kernel, but takes 3 seconds with a rebuilt TC kernel -- all else being held equal. On page 2 you can find that the performance difference between original and rebuilt kernel is not an isolated "glitch," but is replicable.
-
In order to test performances, you can use the Fps meter i describe before ...
you flash play it with original kernel, and compiled kernel ... see the differences!
D.
-
So I let that flash thing run for about 1 minute and got fluctuation between 25-35 fps...
You mention a performance difference of 18% between 2 kernels, when with one and the same kernel it could be much higher, based on that...
-
In order for measurements to be useful, you must know exactly what you are measuring.
-
Daniel have you tried tce-remove flash10?
My performance is skyrocketing now!
-
Hiro,
No, i don't.
But that is not the problem!
With same configuration and changing only kernel, performances are not identical!
And i will absolutly need to compile kernel!
Thanks
Daniel.
-
I also get better performance in full noon nights, I know nobody will believe me, but you might still want to give it a try.
I hate to troll along here, but s since you seem to ignore gerald clark's and tinypoodle's and curagas objections that's the only argument I can make.
-
Exuses me, i'v don't see tinypoodle message :(
My 'test program' isn't the FpsMeter!
It is a complete application runnung under Ubuntu 10.04.
I will try to give an extract (ask to application programer).
[Edit] or tell more precisions on tests conditions
Thanks,
Daniel.
-
I've done again the FpsMeter test!
For me, in full screen (1280x1024) the FpS results (32Fps) move about .5 Fps !
in both cases.
Use full screen and only 3 images.
Daniel.
PS: i'm using X 7.5 ...
-
About the only logical conclusion to be drawn from that would be that this flash applet is totally unsuitable for any benchmarking of kernel performance (and I doubt it would be intended for such a purpose in the first place...).
-
i will do tests soon! (necessary).
i have see performances differences with my application (java + flash with ip communication).
only compiled kernel changed : exactly same application condition!!!
I will provide a bench to prove what i say if necessary. (or find a full system bench : if known, tell me :) )
Daniel.
-
I want to do new tests with http://dl.free.fr/koX82B1WT (http://dl.free.fr/koX82B1WT)
it's FpsMeter.swf with 10.02 standalone flashplayer.
When it will run, i will do tests on TCL original kernel and on my compiled kernel.
Daniel.
-
Actually, i don't succed to have better performances as i have with original kernel!
Now, with both compiler and original kernel, i have same performances (not best).
I don't know why.
During fururs tests, configurations and application installation, if i have exact cases with process, i will open again the / a thread.
Thanks for everybody!
Daniel.
-
http://openbenchmarking.org/ might be a good source for benchmarking.