lowlatency 2.2.19

lowlatency 2.2.19

[William Montgomery]

I am testing Ingo's lowlatency patch on the 2.2.19 kernel and have
a strange problem.  I applied the most recent patch I could find, 
lowlatency-2.2.16-A0 and fixed a few failed hunks.  The kernel appears
stable after many (~24) hours of stress testing with Benno's latencytest
suite and others.  The scheduling jitter is usually under 1msec with
spikes up to 2.5msec on my system - UP PIII 700MHz, 129MRam, 20G SCSI.

In order to locate the spikes I built another kernel; applying Andrea's
ikd patch.  I applied the most recent I could find, 2.2.18pre15aa1-ikd1
and fixed a few failed hunks.  I then applied the lowlatency patch over
that and started testing.  Strangely, the big spikes dissappeared.  Either
the ikd patch has fixed some kernel latency or the timing has changed to
obscure longer latency paths through the kernel.  Again the testing
was performed continuously over a 24 hour period and this time no spikes
over 1msec were observed.

Anyone have any ideas?  

Wm

Re: lowlatency 2.2.19

[Andrea Arcangeli]

On Sun, Jun 03, 2001 at 10:38:34AM -0400, William Montgomery wrote:
> Anyone have any ideas?  

Which options did you enabled? In theory the ikd patch could only make
the latency worse ;), there are no performance improvements in it but
only runtime debugging stuff.

Andrea

Re: lowlatency 2.2.19

[William Montgomery]

On Mon, 4 Jun 2001, Andrea Arcangeli wrote:

> On Sun, Jun 03, 2001 at 10:38:34AM -0400, William Montgomery wrote:
> > Anyone have any ideas?  
> 
> Which options did you enabled? In theory the ikd patch could only make
> the latency worse ;), there are no performance improvements in it but
> only runtime debugging stuff.
> 
I am including a snippet from my .config:
#
# Kernel hacking
#
CONFIG_MAGIC_SYSRQ=y
# CONFIG_KMSGDUMP is not set
CONFIG_KERNEL_DEBUGGING=y
# CONFIG_SEMAPHORE_DEADLOCK is not set
# CONFIG_DEBUG_KSTACK is not set
# CONFIG_KSTACK_METER is not set
# CONFIG_DEBUG_SOFTLOCKUP is not set
# CONFIG_PROFILE_GCC is not set
CONFIG_TRACE=y
CONFIG_TRACE_SIZE=16384
CONFIG_TRACE_TIMESTAMP=y
# CONFIG_TRACE_TRUNCTIME is not set
CONFIG_TRACE_PID=y
CONFIG_TRACE_CPU=y
CONFIG_DEBUG_MCOUNT=y
# CONFIG_PRINT_EIP is not set
# CONFIG_MEMLEAK is not set
# CONFIG_KDB is not set

-------
I cant see anything that could make latency better either but
I can induce 1 to 2.5msec jitter in a 2.2.19 kernel with only 
lowlatency patch after a few minutes stress testing.  

The kernel with both ikd and lowlatency patches tests fine
after 24 hrs of stress testing - jitter always under 1msec.

Wm

Re: lowlatency 2.2.19

[safemode]

this is just a general question about low latency patches on 2.2,   I 
remember hearing about low latency patches for 2.4 not playing well with X 
4.x, is this true for 2.2 low latency patches as well?   

Re: lowlatency 2.2.19

[Andrew Morton]

safemode wrote:
> 
> this is just a general question about low latency patches on 2.2,   I
> remember hearing about low latency patches for 2.4 not playing well with X
> 4.x, is this true for 2.2 low latency patches as well?

Yes, it would be the case.

Some video cards have a PCI cheat-mode in which they keep
the PCI bus busy until they are ready to accept new
commands, rather forcing a retry.  Figures of up to
twenty milliseconds have been mentioned.  Your X server
*may* support the `PCIRetry' config option which will
defeat this.

Info:

http://www.lib.uaa.alaska.edu/linux-kernel/archive/2001-Week-02/1566.html
http://www.zefiro.com/vgakills.txt
http://www.zdnet.com/pcmag/news/trends/t980619a.htm
http://www.research.microsoft.com/~mbj/papers/tr-98-29.html

-

Re: lowlatency 2.2.19

[William Montgomery]

On Mon, 4 Jun 2001, safemode wrote:

> this is just a general question about low latency patches on 2.2,   I 
> remember hearing about low latency patches for 2.4 not playing well with X 
> 4.x, is this true for 2.2 low latency patches as well?   
> 
Not sure.  My testing uses XFree86 3.3.6.

Wm

Re: lowlatency 2.2.19

[Pierre Etchemaite]

Le 05-Jun-2001, Andrew Morton écrivait :
> Some video cards have a PCI cheat-mode in which they keep
> the PCI bus busy until they are ready to accept new
> commands, rather forcing a retry.  Figures of up to
> twenty milliseconds have been mentioned.  Your X server
> *may* support the `PCIRetry' config option which will
> defeat this.

Just FYI (I think it's S3 Virge specific, but maybe not), I solved my RX
packets loss on my ADSL interface after I read the message

        http://www.xfree86.org/pipermail/xpert/2000-November/003402.html

and used

Section "Device"
        Identifier      "Generic Video Card"
        Driver          "s3virge"
        Option "fpm_vram"
        Option "fifo_aggressive"
        Option "pci_burst" "on"
        Option "pci_retry" "on"
        Option "XaaNoCPUToScreenColorExpandFill"
EndSection

in my XFConfig-4.

(The whole thread seems to be worth a read.)

Best regards,
Pierre.


-- 
We are the dot in 0.2 Kb/s