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

Re: 2.4 kernel performance?



An alternative solution could be to implement char-by-char interrupt driven
input så you don't have to flush the fifos.

Another way could be to create a raw serial driver that skips the tty layer
so that a read(buf,count) would wait for count characters and then return.
(Either by setting up the DMA to that length or by interrupt driven I/O
counting the received bytes. )

I believe Mikael has worked on a raw driver that support up to 6.5Mbps
without loosing characters, perhaps that could be used as a base
once it is tested and released.

/Johan

----- Original Message -----
From: Adam Felson <afelson@xxxxxxx.com>
To: <dev-etrax@xxxxxxx.com>
Sent: Tuesday, May 08, 2001 15:28
Subject: Re: 2.4 kernel performance?


>
> 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?
>
>
>
>
>
>