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 <[email protected]> <Ben_Greear AT excite.com>
President of Candela Technologies Inc http://www.candelatech.com
ScryMUD: http://scry.wanfear.com http://scry.wanfear.com/~greear
> 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
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 <[email protected]> <Ben_Greear AT excite.com>
President of Candela Technologies Inc http://www.candelatech.com
ScryMUD: http://scry.wanfear.com http://scry.wanfear.com/~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
>
>>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
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
> 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
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
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 <[email protected]> <Ben_Greear AT excite.com>
President of Candela Technologies Inc http://www.candelatech.com
ScryMUD: http://scry.wanfear.com http://scry.wanfear.com/~greear
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
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
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--
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
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
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
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/
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