[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: 2.4 kernel performance?




Better kick up the flush timeout up to at least 4.  I was getting timeouts
on my software even though the slave board was
responding in 3 ms.    You may have to tinker around with the flush timeout
and the timer rate, but once tinkered, it seems to work well.  Increasing
the max flush time to 4 only added 1.5ms to the total ping/pong cycle time.
---
Adam Felson
HID Corporation - Engineering
11674 N. Huron Street
Denver, CO 80234-2924
(303) 453-3362



                                                                                             
                    Adam Felson                                                              
                    <afelson@xxxxxxx.com                         
                    com>                  cc:                                                
                    Sent by:              Subject:     Re: 2.4 kernel performance?           
                    owner-dev-etra                                                           
                    x@xxxxxxx.com                                                               
                                                                                             
                                                                                             
                    05/08/01 07:28                                                           
                    AM                                                                       
                                                                                             
                                                                                             





Part of the problem is the linux default timer rate of 100hz.  This just
isn't suitable for fast polling.  Unmodified I get turnaround rates for a 3
byte ping followed by a 3 byte pong to be around 150ms.  My solution has
been to kick up the timer tick rate to as high as 3200hz.  This drops the
ping/pong time to 4ms.

prefix/axis/devboard_lx/os/linux/
arch/cris/drivers/serial.c
     set max flush time to 1

include/asm-cris/param.h
     set HZ to 3200

arch/cris/kernel/time.c
     at the bottom where the divisor from 19200hz is 192, change the
divisor to 6

I dunno what this last module is;  it wasn't in e-linux, but complains
about the higher clock rate.
include/linux/timex.h
     between define SHIFT_HZ=10 and the endif, add:
     #elif HZ >= 1536 && HZ < 3072
     # define SHIFT_HZ   11
     #elif HZ >= 3072 && HZ < 6144
     # define SHIFT_HZ   12

go back to devboard_lx
make kernel; make files;  make images

---
Adam Felson
HID Corporation - Engineering
11674 N. Huron Street
Denver, CO 80234-2924
(303) 453-3362




                    "Johan

                    Adolfsson"              To:
<matthew.hook@xxxxxxx.nz>,
                    <johan.adolfsson        <dev-etrax@xxxxxxx.com>

                    @xxxxxxx.com>              cc:

                    Sent by:                Subject:     Re: 2.4 kernel
performance?
                    owner-dev-etrax@

                    axis.com



                    05/08/01 01:29

                    AM







The serial drivers are differently, some features of the elinux driver
has not been ported to 2.4 yet.
One thing that is different is the DMA timeout handling,
in 2.4 it's 8 jiffies (MAX_FLUSH_TIME) and not configurable as
it is in elinux (it probably should be configurable).
If you have short messages used for handshaking this could have
a big impact.
You can try decreasing MAX_FLUSH_TIME in arch/cris/drivers/serial.c
and see if that helps.

/Johan

----- Original Message -----
From: <matthew.hook@xxxxxxx.nz>
To: <dev-etrax@xxxxxxx.com>
Sent: Tuesday, May 08, 2001 06:24
Subject: 2.4 kernel performance?


> Has anyone noticed whether the 2.4 kernel on the Etrax 100LX has
> significantly slower
> performance than uClinux?
>
> I've spent the best part of an afternoon observing that code compiled
> running on uClinux
> runs about 4 times faster than code on the 2.4.... however, it might be
> e.g. the com port
> drivers under 2.4... my software basically reads data from one com port
and
> writes it to another
> and vice versa, but the throughput has dropped by more than 1/4 on Linux
> 2.4.
>
> Has anyone noticed anything similar?