urandom solves latency issues ?

So it really doesn't matter the 64bit.

Hogging cpu0 and using acpi=off and isolcpuc=1 thus moving IRQ timer into cpu1 seems to produce the best results, I ran the test with a full screen glxgears, two windowed glxgears and from time to time I would ran a disk usage scan or open Firefox. Max jitter is less than 6k ns after a test of 12h+.

I tried the boot parm nosmp without success, latency-test doesn't even ran.
Btw, nohalt seems only to produce results on ia64 arch, at least was what I understood from the kernel documentation you posted before. And my tests shows no impact whatsoever on this machine.

If forgot to mention two things, one is that initially I had 3Gb of RAM installed on the machine in three of the four slots the main board has, this produced spikes specially when maximizing windows. After disabling compiz and trying different video cards I left only 2Gb, one on each slot of the dual channel memory bus. It fixed the spike issue. The second thing which I'm testing currently was to change the urandom hack with a while(1) do nothing program launched with nice -n19, so far it improves launching Firefox and jitter is still on the same numbers, let's see if it holds up for 12h.

The second thing which I'm testing currently was to change the urandom hack with a while(1) do nothing program launched with nice -n19,

I don't think anyone has thought of launching a cpu hog but giving it reduced priority before. That is an interesting concept and should consume CPU time but allow other user space programs to grab it.
Interested to see how that goes.

initially I had 3Gb of RAM installed on the machine in three of the four slots the main board has, this produced spikes specially when maximizing windows.

I have certainly see something like that before. On an old machine with 2 x 256MB RAM I once put another stick of 256MB that was in another machine to boost the memory.
The mismatch made the machine run far worse than with just 512MB
Motherboard manuals always used to be very proscriptive about what modules you could put in which slots, for that reason.

6K is realistically about as good as it gets with proper loading, looks like you have a good candidate there

regards

Seems a good improvement to me, UI feels a bit more responsive.

I don't known if we should expect exactly the same number for each test done but:
Without nice -n19 max jitter is 6175ns 5151ns, with nice -n10 max jitter is 7402ns 6155ns.

This bring me to a question, should I use the exact number i.e. 6155 ou should I use some headroom like 7k or 10k ?

This bring me to a question, should I use the exact number i.e. 6155 ou should I use some headroom like 7k or 10k ?

If you mean the figure you enter into stepconf, the exact figure you get or maybe round up to the nearest K as a fudge factor

If you are setting your base period manually, I normally start by tripling the number and then fine tune from there. So I would start with say 20000 in the base thread period in the ini file, which is pretty fast when you consider the default is 5 x that.
Then you can test rapids and acceleration, try reducing the figure until you get errors.

If the base thread is too fast, you can get problems with the userspace parts like the GUI, not being able to update properly due to lack of processor time before the next poll, so it is a balance as with everything

regards