FBSD & SCHED_4BSD/SCHED_ULE. - BSD

This is a discussion on FBSD & SCHED_4BSD/SCHED_ULE. - BSD ; I don't see any speed increase between SCHED_4BSD and SCHED_ULE on a desktop system core-x2 do you? From what I've read SCHED_ULE is far superior to 4BSD, don't see any difference in my end. What do you guys use and ...

+ Reply to Thread
Results 1 to 11 of 11

Thread: FBSD & SCHED_4BSD/SCHED_ULE.

  1. FBSD & SCHED_4BSD/SCHED_ULE.

    I don't see any speed increase between SCHED_4BSD and SCHED_ULE on a
    desktop system core-x2 do you? From what I've read SCHED_ULE is far
    superior to 4BSD, don't see any difference in my end.

    What do you guys use and why?



  2. Re: FBSD & SCHED_4BSD/SCHED_ULE.

    On Mon, 18 Aug 2008 21:32:51 +0000 (UTC)
    kargl@troutmask.apl.washington.edu (Steven G. Kargl) wrote:

    > In article <6Rlqk.7$Ac.4@newsfe01.iad>,
    > Timmy writes:
    > > I don't see any speed increase between SCHED_4BSD and SCHED_ULE on a
    > > desktop system core-x2 do you? From what I've read SCHED_ULE is far
    > > superior to 4BSD, don't see any difference in my end.

    >
    > Perhaps, you're no looking at the right benchmark.


    I don't see any noticeable difference in everday use. I will install
    lapack and check out flops.


    > > What do you guys use and why?
    > >

    >
    > I use ULE because it has grown cpu affinity and cpusets and
    > a few other nice features.
    >



  3. Re: FBSD & SCHED_4BSD/SCHED_ULE.

    On Mon, 18 Aug 2008 21:53:17 +0000 (UTC)
    kargl@troutmask.apl.washington.edu (Steven G. Kargl) wrote:

    > In article <8Ylqk.9$Ac.7@newsfe01.iad>,
    > Timmy writes:
    > > On Mon, 18 Aug 2008 21:32:51 +0000 (UTC)
    > > kargl@troutmask.apl.washington.edu (Steven G. Kargl) wrote:
    > >
    > >> In article <6Rlqk.7$Ac.4@newsfe01.iad>,
    > >> Timmy writes:
    > >> > I don't see any speed increase between SCHED_4BSD and SCHED_ULE
    > >> > on a desktop system core-x2 do you? From what I've read
    > >> > SCHED_ULE is far superior to 4BSD, don't see any difference in
    > >> > my end.
    > >>
    > >> Perhaps, you're no looking at the right benchmark.

    > >
    > > I don't see any noticeable difference in everday use. I will install
    > > lapack and check out flops.
    > >

    >
    > That won't show you anything. You need to look at
    >
    > http://people.freebsd.org/~kris/scal...ql-freebsd.png


    Wow! huge increase in using SCHED_ULE.


  4. Re: FBSD & SCHED_4BSD/SCHED_ULE.

    On 19 Aug 2008 02:10:52 GMT
    Andrew Reilly wrote:

    > On Mon, 18 Aug 2008 05:59:46 -0400, Timmy wrote:
    >
    > > On Mon, 18 Aug 2008 21:53:17 +0000 (UTC)
    > > kargl@troutmask.apl.washington.edu (Steven G. Kargl) wrote:
    > >
    > >> In article <8Ylqk.9$Ac.7@newsfe01.iad>,
    > >> Timmy writes:
    > >> > On Mon, 18 Aug 2008 21:32:51 +0000 (UTC)
    > >> > kargl@troutmask.apl.washington.edu (Steven G. Kargl) wrote:
    > >> >
    > >> >> In article <6Rlqk.7$Ac.4@newsfe01.iad>,
    > >> >> Timmy writes:
    > >> >> > I don't see any speed increase between SCHED_4BSD and
    > >> >> > SCHED_ULE on a desktop system core-x2 do you? From what I've
    > >> >> > read SCHED_ULE is far superior to 4BSD, don't see any
    > >> >> > difference in my end.
    > >> >>
    > >> >> Perhaps, you're no looking at the right benchmark.
    > >> >
    > >> > I don't see any noticeable difference in everday use. I will
    > >> > install lapack and check out flops.
    > >> >
    > >> >
    > >> That won't show you anything. You need to look at
    > >>
    > >> http://people.freebsd.org/~kris/scal...ql-freebsd.png

    > >
    > > Wow! huge increase in using SCHED_ULE.

    >
    > There *is* a flip-side, though.
    >
    > I've got an old P3-500 machine that I use for audio processing
    > experiments and also music playback. It's got an M-Audio Delta1010
    > card in it, which (in its most native mode) has ten channels in and
    > twelve out, all 24/32-bit. I use the 4front-tech driver, because the
    > native one doesn't do multi-channel (yet). I recently "upgraded" the
    > OS on that box from 6-stable to 7-stable, since I've had such good
    > experiences with 7 (and SCHED_ULE) on my desktop and server systems
    > (and 4front now supports 7). Unfortunatly, for this application,
    > this was a seriously retrograde step, at first: no matter how I
    > fiddled the blocking factors and IO sizes, I couldn't stop the system
    > from glitching (audio buffer underruns). It seemed that any network
    > activity would take priority over the audio, even though I had the
    > audio task set to rtprio=10. Loging in to the box with ssh was a
    > guaranteed sound glitcher. I'm pleased to report that switching back
    > to SCHED_4BSD has retrieved the situation, and my audio task is now
    > rock solid and stable again.
    >
    > I've been thinking about writing up a mailing list post or PR about
    > the issue, but I haven't figured out how to generate a minimally
    > failing example that anyone else would be able to verify. Maybe I'll
    > just go ahead and re-post this message, to see if anyone has any
    > suggestions.


    If I were you I would go ahead and post to the mailing list.

    > Given the emphasis of _ULE on multi-processor scalability and total
    > system throughput (at which it seems to rock), I suspect that the
    > answer may well be: "use a more suitable operating system". I hope
    > not.


    I checked out: http://people.freebsd.org/~kris/scal...ql-freebsd.png

    What I want is more gigaflop/s. I have a cluster of older computers
    running in parallel over a lan. I run benchmarks with linpack, yeah,
    don't laugh, that is what I was using - live and learn I guess.

    I'm going to run some new benchmarks using lapack - with
    SCHED_4BSD & SCHED_ULE and crunch the numbers/times and see what's best
    for my computer/s a la desktop.


  5. Re: FBSD & SCHED_4BSD/SCHED_ULE.

    In article <6Rlqk.7$Ac.4@newsfe01.iad>,
    Timmy writes:
    > I don't see any speed increase between SCHED_4BSD and SCHED_ULE on a
    > desktop system core-x2 do you? From what I've read SCHED_ULE is far
    > superior to 4BSD, don't see any difference in my end.


    Perhaps, you're no looking at the right benchmark.

    >
    > What do you guys use and why?
    >


    I use ULE because it has grown cpu affinity and cpusets and
    a few other nice features.

    --
    Steve
    http://troutmask.apl.washington.edu/~kargl/

  6. Re: FBSD & SCHED_4BSD/SCHED_ULE.

    In article <8Ylqk.9$Ac.7@newsfe01.iad>,
    Timmy writes:
    > On Mon, 18 Aug 2008 21:32:51 +0000 (UTC)
    > kargl@troutmask.apl.washington.edu (Steven G. Kargl) wrote:
    >
    >> In article <6Rlqk.7$Ac.4@newsfe01.iad>,
    >> Timmy writes:
    >> > I don't see any speed increase between SCHED_4BSD and SCHED_ULE on a
    >> > desktop system core-x2 do you? From what I've read SCHED_ULE is far
    >> > superior to 4BSD, don't see any difference in my end.

    >>
    >> Perhaps, you're no looking at the right benchmark.

    >
    > I don't see any noticeable difference in everday use. I will install
    > lapack and check out flops.
    >


    That won't show you anything. You need to look at

    http://people.freebsd.org/~kris/scal...ql-freebsd.png

    among other things you can find at freebsd.org.

    --
    Steve
    http://troutmask.apl.washington.edu/~kargl/

  7. Re: FBSD & SCHED_4BSD/SCHED_ULE.

    On Mon, 18 Aug 2008 05:59:46 -0400, Timmy wrote:

    > On Mon, 18 Aug 2008 21:53:17 +0000 (UTC)
    > kargl@troutmask.apl.washington.edu (Steven G. Kargl) wrote:
    >
    >> In article <8Ylqk.9$Ac.7@newsfe01.iad>,
    >> Timmy writes:
    >> > On Mon, 18 Aug 2008 21:32:51 +0000 (UTC)
    >> > kargl@troutmask.apl.washington.edu (Steven G. Kargl) wrote:
    >> >
    >> >> In article <6Rlqk.7$Ac.4@newsfe01.iad>,
    >> >> Timmy writes:
    >> >> > I don't see any speed increase between SCHED_4BSD and SCHED_ULE on
    >> >> > a desktop system core-x2 do you? From what I've read SCHED_ULE is
    >> >> > far superior to 4BSD, don't see any difference in my end.
    >> >>
    >> >> Perhaps, you're no looking at the right benchmark.
    >> >
    >> > I don't see any noticeable difference in everday use. I will install
    >> > lapack and check out flops.
    >> >
    >> >

    >> That won't show you anything. You need to look at
    >>
    >> http://people.freebsd.org/~kris/scal...ql-freebsd.png

    >
    > Wow! huge increase in using SCHED_ULE.


    There *is* a flip-side, though.

    I've got an old P3-500 machine that I use for audio processing
    experiments and also music playback. It's got an M-Audio Delta1010 card
    in it, which (in its most native mode) has ten channels in and twelve
    out, all 24/32-bit. I use the 4front-tech driver, because the native one
    doesn't do multi-channel (yet). I recently "upgraded" the OS on that box
    from 6-stable to 7-stable, since I've had such good experiences with 7
    (and SCHED_ULE) on my desktop and server systems (and 4front now supports
    7). Unfortunatly, for this application, this was a seriously retrograde
    step, at first: no matter how I fiddled the blocking factors and IO
    sizes, I couldn't stop the system from glitching (audio buffer
    underruns). It seemed that any network activity would take priority over
    the audio, even though I had the audio task set to rtprio=10. Loging in
    to the box with ssh was a guaranteed sound glitcher. I'm pleased to
    report that switching back to SCHED_4BSD has retrieved the situation, and
    my audio task is now rock solid and stable again.

    I've been thinking about writing up a mailing list post or PR about the
    issue, but I haven't figured out how to generate a minimally failing
    example that anyone else would be able to verify. Maybe I'll just go
    ahead and re-post this message, to see if anyone has any suggestions.

    Given the emphasis of _ULE on multi-processor scalability and total
    system throughput (at which it seems to rock), I suspect that the answer
    may well be: "use a more suitable operating system". I hope not.

    Cheers,

    --
    Andrew

  8. Re: FBSD & SCHED_4BSD/SCHED_ULE.

    In article <2Erqk.33428$KZ.29302@newsfe03.iad>,
    Timmy writes:
    > On 19 Aug 2008 02:10:52 GMT
    > Andrew Reilly wrote:
    >
    >> On Mon, 18 Aug 2008 05:59:46 -0400, Timmy wrote:
    >>
    >> > On Mon, 18 Aug 2008 21:53:17 +0000 (UTC)
    >> > kargl@troutmask.apl.washington.edu (Steven G. Kargl) wrote:
    >> >
    >> >> In article <8Ylqk.9$Ac.7@newsfe01.iad>,
    >> >> Timmy writes:
    >> >> > On Mon, 18 Aug 2008 21:32:51 +0000 (UTC)
    >> >> > kargl@troutmask.apl.washington.edu (Steven G. Kargl) wrote:
    >> >> >
    >> >> >> In article <6Rlqk.7$Ac.4@newsfe01.iad>,
    >> >> >> Timmy writes:
    >> >> >> > I don't see any speed increase between SCHED_4BSD and
    >> >> >> > SCHED_ULE on a desktop system core-x2 do you? From what I've
    >> >> >> > read SCHED_ULE is far superior to 4BSD, don't see any
    >> >> >> > difference in my end.
    >> >> >>
    >> >> >> Perhaps, you're no looking at the right benchmark.
    >> >> >
    >> >> > I don't see any noticeable difference in everday use. I will
    >> >> > install lapack and check out flops.
    >> >> >
    >> >> >
    >> >> That won't show you anything. You need to look at
    >> >>
    >> >> http://people.freebsd.org/~kris/scal...ql-freebsd.png
    >> >
    >> > Wow! huge increase in using SCHED_ULE.

    >>
    >> There *is* a flip-side, though.
    >>
    >> I've got an old P3-500 machine that I use for audio processing
    >> experiments and also music playback. It's got an M-Audio Delta1010
    >> card in it, which (in its most native mode) has ten channels in and
    >> twelve out, all 24/32-bit. I use the 4front-tech driver, because the
    >> native one doesn't do multi-channel (yet). I recently "upgraded" the
    >> OS on that box from 6-stable to 7-stable, since I've had such good
    >> experiences with 7 (and SCHED_ULE) on my desktop and server systems
    >> (and 4front now supports 7). Unfortunatly, for this application,
    >> this was a seriously retrograde step, at first: no matter how I
    >> fiddled the blocking factors and IO sizes, I couldn't stop the system
    >> from glitching (audio buffer underruns). It seemed that any network
    >> activity would take priority over the audio, even though I had the
    >> audio task set to rtprio=10. Loging in to the box with ssh was a
    >> guaranteed sound glitcher. I'm pleased to report that switching back
    >> to SCHED_4BSD has retrieved the situation, and my audio task is now
    >> rock solid and stable again.
    >>
    >> I've been thinking about writing up a mailing list post or PR about
    >> the issue, but I haven't figured out how to generate a minimally
    >> failing example that anyone else would be able to verify. Maybe I'll
    >> just go ahead and re-post this message, to see if anyone has any
    >> suggestions.

    >
    > If I were you I would go ahead and post to the mailing list.
    >
    >> Given the emphasis of _ULE on multi-processor scalability and total
    >> system throughput (at which it seems to rock), I suspect that the
    >> answer may well be: "use a more suitable operating system". I hope
    >> not.

    >
    > I checked out: http://people.freebsd.org/~kris/scal...ql-freebsd.png
    >
    > What I want is more gigaflop/s. I have a cluster of older computers
    > running in parallel over a lan. I run benchmarks with linpack, yeah,
    > don't laugh, that is what I was using - live and learn I guess.
    >
    > I'm going to run some new benchmarks using lapack - with
    > SCHED_4BSD & SCHED_ULE and crunch the numbers/times and see what's best
    > for my computer/s a la desktop.
    >


    If you have a single cpu (or a cpu without multiple cores), then
    you should see no difference unless you really load the system.
    If I were in your situation, I'd use 4BSD. If you have a SMP
    system, then use ULE.

    PS: The lapack benchmarks won't show anything. The mysql benchmarks
    are impressive because its a threaded app and it can take advantage
    of ULE.

    --
    Steve
    http://troutmask.apl.washington.edu/~kargl/

  9. Re: FBSD & SCHED_4BSD/SCHED_ULE.

    On Tue, 19 Aug 2008 05:22:54 +0000, Steven G. Kargl wrote:

    > If you have a single cpu (or a cpu without multiple cores), then you
    > should see no difference unless you really load the system. If I were in
    > your situation, I'd use 4BSD. If you have a SMP system, then use ULE.


    Well, that's what I'm doing for now. It's been my experience, though,
    that the nature of these sorts of things is that the old one will
    eventually be relegated to the bit-bucket, to avoid the headache of extra
    maintenance and testing work. I'd like to see if ULE can be convinced to
    perform as well as 4BSD, in the ways that matter to me, before that
    happens...

    Cheers,

    --
    Andrew

  10. Re: FBSD & SCHED_4BSD/SCHED_ULE.

    On 19 Aug 2008 06:25:56 GMT,
    Andrew Reilly wrote:
    > On Tue, 19 Aug 2008 05:22:54 +0000, Steven G. Kargl wrote:
    >
    >> If you have a single cpu (or a cpu without multiple cores), then you
    >> should see no difference unless you really load the system. If I were in
    >> your situation, I'd use 4BSD. If you have a SMP system, then use ULE.

    >
    > Well, that's what I'm doing for now. It's been my experience, though,
    > that the nature of these sorts of things is that the old one will
    > eventually be relegated to the bit-bucket, to avoid the headache of extra
    > maintenance and testing work. I'd like to see if ULE can be convinced to
    > perform as well as 4BSD, in the ways that matter to me, before that
    > happens...


    It should, or the job isn't finished. The ULE and threading support is
    impressive, but if it is allowed to cause regressions that break valid
    use cases that then remain unfixed will eventually relegate FreeBSD from
    a rock-solid all-round workhorse to someone's kernel hacking toy-os.

    The seemingly increasing attitude progression against supporting more
    obscure corner cases, thus arbitrarily re-definining ``valid use case''
    into narrower straits on grounds of developer laziness to care for hard
    problems but that are of lesser interest to said developers has me
    somewhat nervous for FreeBSD in the long run in that regard.

    Let's not forget, though, that the scheduler and the threading model are
    major projects spanning the better part of the decade, so the fact that
    there are issues to resolved yet even when the major part is all but
    done isn't particularly surprising. We'll see how it pans out.

    In the meantime, yes, giving feedback is the least you can do.


    --
    j p d (at) d s b (dot) t u d e l f t (dot) n l .
    This message was originally posted on Usenet in plain text.
    Any other representation, additions, or changes do not have my
    consent and may be a violation of international copyright law.

  11. Re: FBSD & SCHED_4BSD/SCHED_ULE.

    Timmy wrote:
    > > not.

    >
    > I checked out: http://people.freebsd.org/~kris/scal...ql-freebsd.png
    >
    > What I want is more gigaflop/s. I have a cluster of older computers
    > running in parallel over a lan. I run benchmarks with linpack, yeah,
    > don't laugh, that is what I was using - live and learn I guess.
    >
    > I'm going to run some new benchmarks using lapack - with
    > SCHED_4BSD & SCHED_ULE and crunch the numbers/times and see what's best
    > for my computer/s a la desktop.
    >


    Whatever scheduler will not change anything to scientific computing.
    All you want is your computer to spend most of its time on your
    computations and not being responsive or scheduling, so the best
    solution is to decrease HZ, for example at 100 hz. On the other hand,
    if you want to switch a lot of tasks at high speed and being very
    responsive, increasing HZ and using ULE will be beneficial.

    --

    Michel TALON


+ Reply to Thread