PS: The whole forum of clublife.no turned to sour bitches last time I was there. They were also people who sided with KvR in their time. So it`s not like that is not already happening.
Peace Be With you.
Making 3 posts in a row basically bitching about people doesn't exactly jive with "Peace Be With You".
Anyway, I've heard it say before that the kernel itself actually behaves resonably well and its the stacks above the kernel like X that introduce a lot of latency. I've also heard others suggest that a low latency kernel will solve all problems. Neither side really spends their time actually attempting to prove their position with actual evidence though, so if you're not just guessing why don't you back it up with actual stats? Or just go ahead and continue to insult people who are doing exactly what you are doing. Either one.
xorg mouse input delays when there are lots of threads (apps count as at least one thread) up to 30ms, idk where the original msg is but it should be clear from provided what its about
and iv been learning assembly a bit lately (its not as hard as ppl think) and as i see it switching between (too many) threads costs more then any kernel scheduler overhead
(console kit last time i checked spawned over 50 threads on my system, and i got a single core cpu; then i removed it)
also for the ones that dont read what they install; CK (Con Kolivas, the man that brought you that low latency scheduler) stated that cfs (the default scheduler) has lots of potential to be better then BFS, i believe he sayd in latency too
i dont wanna google for the next 10min to where he stated that, you'l learn a lot from reading everything he wrote
edit2: id say a brainless person could presume that over 16 threads running at a time on a 4 core 2 thread per core cpu is too much
even when that brainless person would not know about modern cpu cache organizing, branch predicting, register renaming and lots more "hidden" stuff that a cpu does that would make you bang your head against the wall bleeding until you understand half of it (at least that's how i feel reading the manuals)
Some realtime people are doing work with "light threads".
Anyway what I am doing is giving myself a good experience on the desktop. I doubt that hardware itself and pure hardware configurations will give much variation on that.
If you like smooth OpenGL, good performance, and low latency, that is what I am trying to optimize all the time. I think there is not much left now though. Unfortunately threadedirqs is not working on my machine, and I am going to look into that.
i have not got a clue how you could make threads "lighter" since as far as the cpu cares its all a diferent program
and changing between programs requieres a context switch, what takes time
as cpu's are made thinking about multitasking, they save process contexts in special... forgot whats it called (its a small "cache" you could call it, but its specialized)
but it can store just so many contexts till it has to "reload" the program from the L2(or some, L3) cache or even worse main memory (RAM)
sry for being vauge, i read it yestrday and its still hazy
either way a video "glitching" is a throuput problem, not latency
(try running it directly with ffmpeg)
as for openGL, theres lots of driver specific settings to reduce latency (like not using triple buffering to be obvious, or even double buffering; but not using double buffering is a double edged sword)
CK patch has been proven to have worse thruput, but lower latency
on my cpu it causes glitching of unbearable proportions
id focus on the whole stack leading to the app you want to make run as best as it can
also process grouping and lighter programs (less cache misses) might help you a lot with your goal of the perfect desktop (that on the other hand means abandoning PA, unity, gnome, lots of small programs i find to be running uselessly on a default distro(at least for me) etc...)
i see you got lots of free time, maybe start your own distro? (with everything compiled using -Os ofc )
PS the cpu matters A LOT when dealing with latency's, but the quality of programs that are using it matters more (burn console kit and dance around the fire (i know programing threads is hard, but that's just too much))
edit: disclaimer, i dont know all that much about the kernel, but i know opengl depends more on the drivers and raw power
i learn what i want to know (since nobody's paying me to learn anything else )
here for you, dont be turned off by the fact that the tests are in a windows environment
basically, turn off vsync and turn on frame rate limiting and your fine
if going to extremes, use open source nvidia drivers as they dont have "smart" scheduling yet (afaik)
scheduler in the kernel should have little effect on the scheduler in the graphics drivers (check the time stamp counter, HPET is somewhere there too)
i see you are willing to learn and change your opinion ever so slightly, but insulting windows for no reason(windows isnt that bad technically, just... complicated for advanced users to customize its behavior(im not talking about M$, just windoz as a system)) and insulting everybody that dosent agree with you 100% (theres always idiots, only problem when they try to put their uneducated opinion on others)
so il quit posting here, no offense, i just dont like prejudice
computing(opengl included) IS a science, so much that its called computer science
you should stop doing drugs (if your not doing drugs, you should start doing them; i suggest the peace plant, even thou its hard to call it a drug)
again, no offense
PS note that(if compiled with CK patches) your kernel would bring my computer to a crawl, making it jittery as hell and a little slower overall
i have no idea why, but its so and that says it needs testing on more cpu's/configurations
also note i am a happy linux user for years now, especially as linux lets me do things that are in many cases just dumb (like turning off swap) but in some help