latency & real-time-ness.

latency & real-time-ness.

[Ben Greear]

I have been doing some tests with 2.4.19-pre2-ac2 with
regard to network latency.  When running a steady stream of
138byte UDP packets at 115 packets per second, I see about
.1% of the packets take more than 5 miliseconds to go from
user-space to user-space on a 1Ghz PIII machine.

At 50Mbps (bi directional), I see a much wider latency spread,
with some packets taking up to 300ms or higher to get from A
to B.  The CPU load ranges from about 30% to 80% utilization
at this speed...

I'm running the program at nice -18.

So, what kind of things can I do to decrease the latency?

Would the low-latency patch help me?

Are there any scheduling tricks I can use to tell the kernel
that my program should get to run as soon as it wants to?

Thanks,
Ben

-- 
Ben Greear <greearb@candelatech.com>       <Ben_Greear AT excite.com>
President of Candela Technologies Inc      http://www.candelatech.com
ScryMUD:  http://scry.wanfear.com     http://scry.wanfear.com/~greear

Re: latency & real-time-ness.

[Alan Cox]

> I'm running the program at nice -18.
> So, what kind of things can I do to decrease the latency?

Hack up the ksoftirq stuff to only fall back to ksoftirqd after about
500 iterations instead of one is one little detail to deal with

> Would the low-latency patch help me?

Yes

Re: latency & real-time-ness.

[Ben Greear]

Alan Cox wrote:

>>I'm running the program at nice -18.
>>So, what kind of things can I do to decrease the latency?
>>
> 
> Hack up the ksoftirq stuff to only fall back to ksoftirqd after about
> 500 iterations instead of one is one little detail to deal with


Can someone expound slightly on this?


> 
> 
>>Would the low-latency patch help me?
>>
> 
> Yes


Excellent, I'm compiling that now....

Thanks,
Ben



-- 
Ben Greear <greearb@candelatech.com>       <Ben_Greear AT excite.com>
President of Candela Technologies Inc      http://www.candelatech.com
ScryMUD:  http://scry.wanfear.com     http://scry.wanfear.com/~greear

Re: latency & real-time-ness.

[J Sloan]

Ben Greear wrote

>> Would the low-latency patch help me?
>>
>> Yes
>
>
>
> Excellent, I'm compiling that now.... 

Eh?

The full-on low latency patch from Andrew Morton?

You might want to make some diffs available
since AFIK that would have involved quite a bit
of hand editing to fix rejects...

Joe

Re: latency & real-time-ness.

[Ben Greear]

J Sloan wrote:

> Ben Greear wrote
> 
>>> Would the low-latency patch help me?
>>>
>>> Yes
>> Excellent, I'm compiling that now.... 
> Eh?
> 
> The full-on low latency patch from Andrew Morton?
> 
> You might want to make some diffs available
> since AFIK that would have involved quite a bit
> of hand editing to fix rejects...


I found this patch:
preempt-kernel-rml-2.4.19-pre2-ac2-1.patch

It applied cleanly...looks like maybe this isn't
the low-latency patch though now that I look at
it a little closer.

-- 
Ben Greear <greearb@candelatech.com>       <Ben_Greear AT excite.com>
President of Candela Technologies Inc      http://www.candelatech.com
ScryMUD:  http://scry.wanfear.com     http://scry.wanfear.com/~greear

Re: latency & real-time-ness.

[Robert Love]

On Sun, 2002-03-03 at 22:32, Ben Greear wrote:

> I found this patch:
> preempt-kernel-rml-2.4.19-pre2-ac2-1.patch
> 
> It applied cleanly...looks like maybe this isn't
> the low-latency patch though now that I look at
> it a little closer.

Right, it is not.  It is the preemptive kernel patch.  More information
can be found at http://tech9.net/rml/linux

	Robert Love

Re: latency & real-time-ness.

[J Sloan]

Ben Greear wrote:

>
> I found this patch:
> preempt-kernel-rml-2.4.19-pre2-ac2-1.patch
>
> It applied cleanly...looks like maybe this isn't
> the low-latency patch though now that I look at
> it a little closer.
>
You are correct sir - that is not the low latency
patch, although if you add the lock break patch
to the preempt patch, the results are said to be
similar to the low latency patch...

Joe

Re: latency & real-time-ness.

[Jussi Laako]

J Sloan wrote:
> 
> The full-on low latency patch from Andrew Morton?
> 
> You might want to make some diffs available
> since AFIK that would have involved quite a bit
> of hand editing to fix rejects...

There is also patch against 2.4.18 with following:

 - Latest Andre's IDE driver
 - Latest Lionel's SiS IDE driver
 - Latest Rik's rmap
 - Latest Ingo's O(1)
 - Andrew's full and mini lowlatency
 - My DRM lowlatency fixes (r128, radeon, mga) (in -ll)


Available at http://www.pp.song.fi/~visitor/linux/


 - Jussi Laako

-- 
PGP key fingerprint: 161D 6FED 6A92 39E2 EB5B  39DD A4DE 63EB C216 1E4B
Available at PGP keyservers

Re: latency & real-time-ness.

[J Sloan]

Alan Cox wrote:

>>I'm running the program at nice -18.
>>So, what kind of things can I do to decrease the latency?
>>
>
>Hack up the ksoftirq stuff to only fall back to ksoftirqd after about
>500 iterations instead of one is one little detail to deal with
>
>>Would the low-latency patch help me?
>>
>
>Yes
>
It might be very difficult to fix up the
low latency patch for the latest -ac,
but the mini-low-latency patch should
go right in - that should fix the worst
of it, and I've run 2.4.19-pre2-ac1 with
the mini low-latency patch.

It's part of the -aa patch collection, just
look for "00_lowlatency-fixes-4" or so.

Joe

Re: latency & real-time-ness.

[Alan Cox]

> It might be very difficult to fix up the
> low latency patch for the latest -ac,

You should be able to just dump out the vm part of it - Rik put that into
rmap anyuway afaik

Re: latency & real-time-ness.

[J Sloan]

Alan Cox wrote:

>>It might be very difficult to fix up the
>>low latency patch for the latest -ac,
>>
>
>You should be able to just dump out the vm part of it - Rik put that into
>rmap anyuway afaik
>
Ah, excellent - good to know, I'll check
that out tonight -

BTW 2.4.19-pre2-ac1 was pretty good for
me - The GUI remained snappy and the
mp3s played smoothly all while running
dbench 128 - The O(1) scheduler and rmap
stuff look like a win -

Joe

Re: latency & real-time-ness.

[Erik Andersen]

On Mon Mar 04, 2002 at 01:33:01AM +0000, Alan Cox wrote:
> > It might be very difficult to fix up the
> > low latency patch for the latest -ac,
> 
> You should be able to just dump out the vm part of it - Rik put that into
> rmap anyuway afaik

Any chance we will see mini-ll or the full-ll patches
in an -ac release anytime?

 -Erik

--
Erik B. Andersen             http://codepoet-consulting.com/
--This message was written using 73% post-consumer electrons--

Re: latency & real-time-ness.

[Dieter Nützel]

On Montag, 4. März 2002 03:45:27, Robert Love wrote:
> On Sun, 2002-03-03 at 22:32, Ben Greear wrote:
>
> > I found this patch:
> > preempt-kernel-rml-2.4.19-pre2-ac2-1.patch
> >
> > It applied cleanly...looks like maybe this isn't
> > the low-latency patch though now that I look at
> > it a little closer.
>
> Right, it is not.  It is the preemptive kernel patch.  More information
> can be found at http://tech9.net/rml/linux

Robert I am running 2.4.19-pre2-ac2 + preemption + lock-break.
It is very snappy due to lock-break I think.
But lock-break failed on vmscan.c and I didn't apply it by hand this time.
There was another fail but it was small and easily fixable.
We need a new lock-break, soon.

Sadly it is relative hard to put sched-O1-2.4.18-pre8-K3.patch and preemption 
on top of 2.4.19pre2aa1 which I did for several weeks before. The throughput 
with -aa VM maintenance is much better then with -ac.

Latest -aa is 2.4.18-pre8-K3-VM-24-preempt-lock.

Regards,
	Dieter

Re: latency & real-time-ness.

[Robert Love]

On Mon, 2002-03-04 at 11:20, Dieter Nützel wrote:

> Robert I am running 2.4.19-pre2-ac2 + preemption + lock-break.
> It is very snappy due to lock-break I think.
> But lock-break failed on vmscan.c and I didn't apply it by hand this time.
> There was another fail but it was small and easily fixable.
> We need a new lock-break, soon.

-ac2 has rmap and lock-break is not designed for the rmap VM.  You can
just ignore the rejects.  Further, rmap has some conditional schedules
so you are taken care of.

If rmap finds its way into 2.5, I and others have some ideas about ways
to optimize the algorithms to reduce lock hold time and benefit from
preemption.  For example, Daniel Phillips has some ideas wrt
zap_page_range.

> Sadly it is relative hard to put sched-O1-2.4.18-pre8-K3.patch and preemption 
> on top of 2.4.19pre2aa1 which I did for several weeks before. The throughput 
> with -aa VM maintenance is much better then with -ac.
>
> Latest -aa is 2.4.18-pre8-K3-VM-24-preempt-lock.

	Robert Love

Re: latency & real-time-ness.

[Rik van Riel]

On 4 Mar 2002, Robert Love wrote:

> If rmap finds its way into 2.5, I and others have some ideas about ways
> to optimize the algorithms to reduce lock hold time and benefit from
> preemption.  For example, Daniel Phillips has some ideas wrt
> zap_page_range.

Feel free to help resolve these issues before rmap code gets
merged. I'd prefer to be able to introduce rmap in small bits
and pieces without breaking anything.

regards,

Rik
-- 
"Linux holds advantages over the single-vendor commercial OS"
    -- Microsoft's "Competing with Linux" document

http://www.surriel.com/		http://distro.conectiva.com/

Re: latency & real-time-ness.

[Robert Love]

On Mon, 2002-03-04 at 18:48, Rik van Riel wrote:

> > If rmap finds its way into 2.5, I and others have some ideas about ways
> > to optimize the algorithms to reduce lock hold time and benefit from
> > preemption.  For example, Daniel Phillips has some ideas wrt
> > zap_page_range.
> 
> Feel free to help resolve these issues before rmap code gets
> merged. I'd prefer to be able to introduce rmap in small bits
> and pieces without breaking anything.

The above was just an optimization ... rmap and preempt work fine
together.

What Andrew Morton, I, and others intend to do for 2.5 is work on the
algorithms and locking issues to work on latency issues cleanly.

But I'll surely work on the issues wrt rmap ;)

	Robert Love