[LONG] Re: Performance of FreeBSD vs NetBSD (was: Re: Performance of -current vs -stable)
(sorry for the delay in following-up to this thread; when the Big Blue Room is cloudless and approaching 25 degrees at this time of year, I feel an uncontrollable craving to lock myself in that room most of the day) I wrote: Hmmm, a few weeks ago I did some totally unscientific testing, noting that -current was much slower than -stable, by playing an mp3 with an And then a lot of people responded. So let me attempt to restate things, and possibly clear things up thereby. Or, you can just skip straight to the end, where I reveal just what I did to restore similar performance with FreeBSD that I saw under NetBSD, which shall terminate this thread. One can hope. My observations were as follows: o) I had problems doing ``work'' and listening to mp3s with a native mpg123 binary under both FreeBSD-CURRENT and 4.5-STABLE. o) I had no problems with a comparable native binary and NetBSD-current. o) Both FreeBSD-CURRENT and FreeBSD-stable performed roughly identically, both with and without the kernel WITNESS option, so I wasn't seeing the killer performance there that others have noted, just as a side note. I then asked if any of the config options I posted from part of my kernel configuration for -STABLE were known show-stoppers to be avoided. By the time I had updated my archive of the mailing lists a day or two later, nobody had pointed an accusing finger, so I've decided to do somewhat more extensive testing. Seat-of-the-pants observation with `top' showed an apparent improvement by a factor of two in CPU usage when running the native NetBSD binary under NetBSD. Other observations I've made, that I'll be using as datapoints later, are that a normal `buildworld' for both -current and -stable on this 75MHz hardware take somewhere arount 1000 to 1100 minutes or so; also, a `nice'd `installworld' (out of necessity niced in order to get relatively real-time audio playback with only a few pauses each minute) took two or three hours when running mpg123. Then I took one of the FreeBSD binaries and re-linked it statically, in order to run it under NetBSD as well as both FreeBSDen. With this, the FreeBSD performance was unchanged, whilst that of NetBSD actually improved by `top' to a ratio of ~3:1 CPU usage by FreeBSD. Now I'll be doing other tests, to guess whether this is a real system- like issue, or if it only affects mpg123, or my audio setup, or what. Ideas include timing a comparable build process under NetBSD (which does rather differ from that of FreeBSD, so perhaps only for amusement value), and attempting to run the same build process with both Net- and FreeBSD. Other tests limited to a `buildkernel' may be tried, so I can get more results than a build per day and a half. Hey, oboyoboy, one -STABLE FreeBSD test gave these results: bash-2.05a$ time /usr/obj/ports/5.0/usr/ports/audio/mpg123/work/mpg123-0.59r/mp g123-static-O3-current -t -v /usr/home/mp3/hr-XXL-chillout-11.aug.mp3 [...] Playing MPEG stream from hr-XXL-chillout-11.aug.mp3 ... Junk at the beginning MPEG 1.0, Layer: III, Freq: 44100, mode: Joint-Stereo, modext: 2, BPF : 522 Channels: 2, copyright: No, original: Yes, CRC: No, emphasis: 0. Bitrate: 160 Kbits/s, Extension value: 0 Audio: 1:1 conversion, rate: 44100, encoding: signed 16 bit, channels: 2 Frame# 308633 [0], Time: 134:22.24 [00:00.00], [120:20] Decoding of hr-XXL-chillout-11.aug.mp3 finished. real35m43.727s user33m41.078s sys 0m19.797s bash-2.05a$ This seems to imply that at 35 realtime minutes for a 120 minute file, FreeBSD-STABLE can play back at about 3 1/2 times realtime on a lightly loaded system. Much closer to the NetBSD `top' CPU ratio. This points to the actual sound k0deZ as being responsible for the slowdown that I experience. Now I'll try to respond to points others have made and further muddy the waters, or something. Martin Ankerl noted: One real test is to measure how long your machine needs to decode a stream without threads with 100% CPU. Using mpg123 you can do this with time mpg123 -t mp3stream.mp3 Good idea. Here's NetBSD-current compared with FreeBSD-current (same static binary on all three OSen): (time /usr/obj/ports/5.0/usr/ports/audio/mpg123/work/mpg123-0.59r/mpg123-static- O3-current -t -v /usr/home/mp3/hr-XXL-chillout-21.okt.mp3 ) NetBSD: [...] Playing MPEG stream from hr-XXL-chillout-21.okt.mp3 ... Junk at the beginning MPEG 1.0, Layer: III, Freq: 44100, mode: Joint-Stereo, modext: 2, BPF : 417 Channels: 2, copyright: No, original: Yes, CRC: No, emphasis: 0. Bitrate: 128 Kbits/s, Extension value: 0 Audio: 1:1 conversion, rate: 44100, encoding: signed 16 bit, channels: 2 Frame# 382927 [0], Time: 166:42.99 [00:00.00], [174:13] Decoding of hr-XXL-chillout-21.okt.mp3 finished. real49m56.748s user48m10.644s sys 0m18.401s FreeBSD-CURRENT: [...] Frame# 382927 [0], Time: 166:42.99 [00:00.00], [174:13] Decoding of hr-XXL-chillout-21.okt.mp3 finished. real
Re: Performance of FreeBSD vs NetBSD (was: Re: Performance of -current vs -stable)
--- Kris Kennaway [EMAIL PROTECTED] wrote: As you are no doubt aware there are significant infrastructural changes in -current relating to SMP scalability. It's in a very interim state at the moment, and one of the downsides is increased interrupt latency and lock contention for certain operations (yes, audio playback is one of them). Basically, it's a known issue. Yep. I agree with Kris, as this issue was discussed in the -current list somewhere. And also, I have been running CURRENT for a while now (around 7/8 months), and it has been going pretty smoothly in the tasks I do. I use mpg123, and xamp for a while with CURRENT and although there are lock issues, but they will be solved by either me, or someone else who can do it. (as I am running an SMP test CURRENT system) __ Do You Yahoo!? Try FREE Yahoo! Mail - the world's greatest free email! http://mail.yahoo.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Performance of FreeBSD vs NetBSD (was: Re: Performance of -current vs -stable)
On Monday 11 March 2002 03:25 am, Kris Kennaway wrote: | On Sun, Mar 10, 2002 at 09:05:28PM +0100, BOUWSMA Beery wrote: | I built both a WITNESS and a WITNESSless kernel with more recent | k0deZ, and in the case of playing an mp3 file with `mpg123', I | saw practically no difference between the two, based on %cpu as | shown by `top' (like I say, completely unscientific and inaccurate) | | As you are no doubt aware there are significant infrastructural | changes in -current relating to SMP scalability. It's in a very | interim state at the moment, and one of the downsides is increased | interrupt latency and lock contention for certain operations (yes, | audio playback is one of them). | | Basically, it's a known issue. At -stable as well as -current or at -current only? The original report here was there a provious thread had established some issues with -current, but he did some testing and there are issues with -stable as well. Are those known issues, too? | | Kris -- Brian T. Schellenberger . . . . . . . [EMAIL PROTECTED] (work) Brian, the man from Babble-On . . . . [EMAIL PROTECTED] (personal) ME -- http://www.babbleon.org http://www.eff.org -- GOOD GUYS -- http://www.programming-freedom.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Performance of FreeBSD vs NetBSD (was: Re: Performance of -current vs -stable)
On Mon, Mar 11, 2002 at 08:23:38AM -0500, Brian T.Schellenberger wrote: On Monday 11 March 2002 03:25 am, Kris Kennaway wrote: | On Sun, Mar 10, 2002 at 09:05:28PM +0100, BOUWSMA Beery wrote: | I built both a WITNESS and a WITNESSless kernel with more recent | k0deZ, and in the case of playing an mp3 file with `mpg123', I | saw practically no difference between the two, based on %cpu as | shown by `top' (like I say, completely unscientific and inaccurate) | | As you are no doubt aware there are significant infrastructural | changes in -current relating to SMP scalability. It's in a very | interim state at the moment, and one of the downsides is increased | interrupt latency and lock contention for certain operations (yes, | audio playback is one of them). | | Basically, it's a known issue. At -stable as well as -current or at -current only? What I'm talking about is a -current issue only. I don't recall reading the earlier thread. Kris msg32691/pgp0.pgp Description: PGP signature
Re: Performance of FreeBSD vs NetBSD (was: Re: Performance of -current vs -stable)
On Monday 11 March 2002 08:54 am, Kris Kennaway wrote: | On Mon, Mar 11, 2002 at 08:23:38AM -0500, Brian T.Schellenberger wrote: | On Monday 11 March 2002 03:25 am, Kris Kennaway wrote: | | On Sun, Mar 10, 2002 at 09:05:28PM +0100, BOUWSMA Beery wrote: | | I built both a WITNESS and a WITNESSless kernel with more recent | | k0deZ, and in the case of playing an mp3 file with `mpg123', I | | saw practically no difference between the two, based on %cpu as | | shown by `top' (like I say, completely unscientific and inaccurate) | | | | As you are no doubt aware there are significant infrastructural | | changes in -current relating to SMP scalability. It's in a very | | interim state at the moment, and one of the downsides is increased | | interrupt latency and lock contention for certain operations (yes, | | audio playback is one of them). | | | | Basically, it's a known issue. | | At -stable as well as -current or at -current only? | | What I'm talking about is a -current issue only. I don't recall | reading the earlier thread. Well, the original article in *this* thread stated: In fact, the %cpu needed by `mpg123' seemed identical between -current, both with and without W[I]TNESS, and -stable. Look: [55% CPU to decode for all three cases] In both -current and -stable, the audio is usually smooth but periodically has a hiccup or two and loops briefly. But the very same hardware, booted into NetBSD off the same disk, running a NetBSD-native binary of mpg123 on NetBSD-current shows this: [37% CPU to decode] So I don't think that your explanation covers the observed behavior. Though the *system* time and *interrupt* time seem to track as one might expect for this issue, there still seems to be something *else* going on per the mpg123 time and idle time. Ref: http://docs.freebsd.org/cgi/getmsg.cgi?fetch=13691+0+current/freebsd-hackers | | Kris -- Brian T. Schellenberger . . . . . . . [EMAIL PROTECTED] (work) Brian, the man from Babble-On . . . . [EMAIL PROTECTED] (personal) ME -- http://www.babbleon.org http://www.eff.org -- GOOD GUYS -- http://www.programming-freedom.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Performance of FreeBSD vs NetBSD (was: Re: Performance of -current vs -stable)
As I already asked: what compile time options were used in the two cases ? They surely can make a huge difference. cheers luigi On Mon, Mar 11, 2002 at 09:29:25AM -0500, Brian T.Schellenberger wrote: Though the *system* time and *interrupt* time seem to track as one might expect for this issue, there still seems to be something *else* going on per the mpg123 time and idle time. Ref: http://docs.freebsd.org/cgi/getmsg.cgi?fetch=13691+0+current/freebsd-hackers To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Performance of FreeBSD vs NetBSD (was: Re: Performance of -current vs -stable)
--- Luigi Rizzo [EMAIL PROTECTED] wrote: As I already asked: what compile time options were used in the two cases ? They surely can make a huge difference. cheers luigi Could it also be a possibility, that the NetBSD defaults differ from the FreeBSD defaults, I think this could make some difference too. :) Regards, -- Hiten Pandya -- [EMAIL PROTECTED] __ Do You Yahoo!? Try FREE Yahoo! Mail - the world's greatest free email! http://mail.yahoo.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Performance of FreeBSD vs NetBSD (was: Re: Performance of -current vs -stable)
On Mon, 11 Mar 2002 07:10:31 -0800 (PST) Hiten Pandya [EMAIL PROTECTED] wrote: --- Luigi Rizzo [EMAIL PROTECTED] wrote: As I already asked: what compile time options were used in the two cases ? They surely can make a huge difference. cheers luigi Could it also be a possibility, that the NetBSD defaults differ from the FreeBSD defaults, I think this could make some difference too. :) actually he mentioned in his post that he used the _same_ binary on fbsd and netbsd (statically linked, netbsd with fbsd emu layer) -- /\ http://corecode.ath.cx/ \ / \ ASCII Ribbon Campaign / \ Against HTML Mail and News msg32695/pgp0.pgp Description: PGP signature
Re: Performance of FreeBSD vs NetBSD (was: Re: Performance of -current vs -stable)
On Mon, Mar 11, 2002 at 04:26:31PM +0100, Simon 'corecode' Schubert wrote: On Mon, 11 Mar 2002 07:10:31 -0800 (PST) Hiten Pandya [EMAIL PROTECTED] wrote: --- Luigi Rizzo [EMAIL PROTECTED] wrote: As I already asked: what compile time options were used in the two cases ? They surely can make a huge difference. cheers luigi Could it also be a possibility, that the NetBSD defaults differ from the FreeBSD defaults, I think this could make some difference too. :) actually he mentioned in his post that he used the _same_ binary on fbsd and netbsd (statically linked, netbsd with fbsd emu layer) actually later in the same message he mentioned he used a different binary, and the top output showed two different names. luigi To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Performance of FreeBSD vs NetBSD (was: Re: Performance of -current vs -stable)
If you measure this using the 'time' command, what is the result? In particular, how do the %user and %system vary between FreeBSD and NetBSD? This could point us at differences in the sound infrastructure, if the extra CPU you're seeing is a result of increased kernel activity. If it's more user activity, maybe it's a library/memory/alignment/... issue. Robert N M Watson FreeBSD Core Team, TrustedBSD Project [EMAIL PROTECTED] NAI Labs, Safeport Network Services On Sun, 10 Mar 2002, BOUWSMA Beery wrote: [replies sent directly to me may timeout and bounce, since I'm not online as often as I should be, but I'll check the list archives] I wrote a while back, in an old freebsd-current list thread, in which it was determined that WITNESS was to be avoided in -current if one wanted decent performance... Hmmm, a few weeks ago I did some totally unscientific testing, noting that -current was much slower than -stable, by playing an mp3 with an [...] explain why FreeBSD's mpg123 takes ~60% CPU and NetBSD's ~30% (vs the ~90+% usage by -current)... Oh, I'll try rebuilding -current Real Soon^W^W later today, without WITNESS, and compare, just to stay on-topic for this list. And so I did. (build sans WITNESS, not stay on-topic) The results were, well, interesting. I built both a WITNESS and a WITNESSless kernel with more recent k0deZ, and in the case of playing an mp3 file with `mpg123', I saw practically no difference between the two, based on %cpu as shown by `top' (like I say, completely unscientific and inaccurate) That's interesting, because the previous -current+WITNESS reported a sound-related lock order reversal and mpg123 took 90% cpu, while neither of the more recent kernels had this lock order reversal. In fact, the %cpu needed by `mpg123' seemed identical between -current, both with and without WETNESS, and -stable. Look: Stable CPU states: 52.7% user, 0.0% nice, 2.3% system, 5.8% interrupt, 39.2% idle PID USERNAME PRI NICE SIZERES STATETIME WCPUCPU COMMAND 272 beer 45 0 344M 908K RUN 3:10 56.10% 56.10% mpg123-O3 260 root 28 0 1440K 1176K RUN 0:04 0.24% 0.24% top Current+WITNESS CPU states: 51.9% user, 0.0% nice, 8.3% system, 12.4% interrupt, 27.4% idle PID USERNAME PRI NICE SIZERES STATETIME WCPUCPU COMMAND 305 beer 1150 113M 960K RUN 2:06 55.91% 55.91% mpg123-O3 10 root -160 0K12K RUN 1:52 27.39% 27.39% idle 29 root -60 -179 0K12K WAIT 0:14 5.96% 5.96% irq5: sbc0 12 root -48 -167 0K12K WAIT 0:07 2.00% 2.00% swi6: tty:sio 313 root 970 1544K 1264K RUN 0:02 1.19% 1.17% top Current-without CPU states: 54.0% user, 0.0% nice, 6.8% system, 10.6% interrupt, 28.7% idle PID USERNAME PRI NICE SIZERES STATETIME WCPUCPU COMMAND 322 beer 1170 97400K 1384K RUN 4:44 55.18% 55.18% mpg123-O3 10 root -160 0K12K RUN 5:38 26.95% 26.95% idle 29 root -60 -179 0K12K WAIT 0:35 6.01% 6.01% irq5: sbc0 12 root -48 -167 0K12K WAIT 0:19 2.83% 2.83% swi6: tty:sio 313 root 970 1544K 1252K RUN 0:16 1.07% 1.07% top In both -current and -stable, the audio is usually smooth but periodically has a hiccup or two and loops briefly. But the very same hardware, booted into NetBSD off the same disk, running a NetBSD-native binary of mpg123 on NetBSD-current shows this: CPU states: 38.1% user, 0.0% nice, 1.5% system, 1.0% interrupt, 59.4% idle PID USERNAME PRI NICE SIZE RES STATE TIME WCPUCPU COMMAND 229 beer 100 308K 3828K aud_wr 1:17 37.16% 37.16% mpg123 245 root 280 164K 860K CPU0:00 0.89% 0.29% top This machine can happily do a second task without it needing to be `nice'd and still exude clean audio. Not possible with FreeBSD. Just in case I had botched the optimizations for the FreeBSD versions of mpg123, I compiled them statically (I couldn't get the NetBSD version to run under FreeBSD tho), and ran those under NetBSD with the COMPAT_FREEBSD kernel option. Under FreeBSD I saw no change in CPU needed, whilst surprisingly, the static FreeBSD binary run under NetBSD on the same hardware needed *less* cpu than before: CPU states: 20.3% user, 0.0% nice, 1.0% system, 0.0% interrupt, 78.7% idle PID USERNAME PRI NICE SIZE RES STATE TIME WCPUCPU COMMAND 241 beer 360 512K 2020K RUN0:24 21.71% 21.63% mpg123-stati 268 root 280 164K 860K CPU0:00 0.74% 0.24% top I'm concerned. I know this isn't at all scientific, but why would NetBSD require about 1/3 the CPU to run the same binary as either -stable or -current FreeBSD on the same hardware? Can I be slowing my FreeBSD OSen by using a kernel option
Re: Performance of FreeBSD vs NetBSD (was: Re: Performance of -current vs -stable)
Well, it is not the same binary, and compile options may make a huge
difference. Browsing in the FreeBSD port of mpg123 I note this message:
@${ECHO_MSG} +++
@${ECHO_MSG} Note: you can set OPT_ARCH to optimize for your hardware.
@${ECHO_MSG} (e.g. make OPT_ARCH=i486).
@${ECHO_MSG} Valid values are: i486, i586, 3dnow
@${ECHO_MSG} +++
and none of these seems to be used as default
cc -O -pipe -DINET6 -Wall -ansi -pedantic -funroll-all-loops -ffast-math -fomi
t-frame-pointer -DROT_I386 -DI386_ASSEM -DREAL_IS_FLOAT -DREAD_MMAP -DUSE_MMAP
-DOSS -DTERM_CONTROL -I/usr/local/include -c mpg123.c
cheers
luigi
On Sun, Mar 10, 2002 at 09:05:28PM +0100, BOUWSMA Beery wrote:
...
I wrote a while back, in an old freebsd-current list thread, in which it
was determined that WITNESS was to be avoided in -current if one wanted
...
Stable
CPU states: 52.7% user, 0.0% nice, 2.3% system, 5.8% interrupt, 39.2% idle
PID USERNAME PRI NICE SIZERES STATETIME WCPUCPU COMMAND
272 beer 45 0 344M 908K RUN 3:10 56.10% 56.10% mpg123-O3
260 root 28 0 1440K 1176K RUN 0:04 0.24% 0.24% top
Current+WITNESS
CPU states: 51.9% user, 0.0% nice, 8.3% system, 12.4% interrupt, 27.4% idle
PID USERNAME PRI NICE SIZERES STATETIME WCPUCPU COMMAND
305 beer 1150 113M 960K RUN 2:06 55.91% 55.91% mpg123-O3
10 root -160 0K12K RUN 1:52 27.39% 27.39% idle
29 root -60 -179 0K12K WAIT 0:14 5.96% 5.96% irq5: sbc0
12 root -48 -167 0K12K WAIT 0:07 2.00% 2.00% swi6: tty:sio
313 root 970 1544K 1264K RUN 0:02 1.19% 1.17% top
Current-without
CPU states: 54.0% user, 0.0% nice, 6.8% system, 10.6% interrupt, 28.7% idle
PID USERNAME PRI NICE SIZERES STATETIME WCPUCPU COMMAND
322 beer 1170 97400K 1384K RUN 4:44 55.18% 55.18% mpg123-O3
10 root -160 0K12K RUN 5:38 26.95% 26.95% idle
29 root -60 -179 0K12K WAIT 0:35 6.01% 6.01% irq5: sbc0
12 root -48 -167 0K12K WAIT 0:19 2.83% 2.83% swi6: tty:sio
313 root 970 1544K 1252K RUN 0:16 1.07% 1.07% top
In both -current and -stable, the audio is usually smooth but
periodically has a hiccup or two and loops briefly.
But the very same hardware, booted into NetBSD off the same disk,
running a NetBSD-native binary of mpg123 on NetBSD-current shows this:
CPU states: 38.1% user, 0.0% nice, 1.5% system, 1.0% interrupt, 59.4% idle
PID USERNAME PRI NICE SIZE RES STATE TIME WCPUCPU COMMAND
229 beer 100 308K 3828K aud_wr 1:17 37.16% 37.16% mpg123
245 root 280 164K 860K CPU0:00 0.89% 0.29% top
This machine can happily do a second task without it needing to be
`nice'd and still exude clean audio. Not possible with FreeBSD.
Just in case I had botched the optimizations for the FreeBSD versions
of mpg123, I compiled them statically (I couldn't get the NetBSD
version to run under FreeBSD tho), and ran those under NetBSD with
the COMPAT_FREEBSD kernel option. Under FreeBSD I saw no change
in CPU needed, whilst surprisingly, the static FreeBSD binary run
under NetBSD on the same hardware needed *less* cpu than before:
CPU states: 20.3% user, 0.0% nice, 1.0% system, 0.0% interrupt, 78.7% idle
PID USERNAME PRI NICE SIZE RES STATE TIME WCPUCPU COMMAND
241 beer 360 512K 2020K RUN0:24 21.71% 21.63% mpg123-stati
268 root 280 164K 860K CPU0:00 0.74% 0.24% top
I'm concerned. I know this isn't at all scientific, but why would
NetBSD require about 1/3 the CPU to run the same binary as either
-stable or -current FreeBSD on the same hardware? Can I be slowing
my FreeBSD OSen by using a kernel option that I shouldn't, or is
something else coming into play?
Another thing of note, with this hardware, under FreeBSD, it takes
some seconds (ten or so) from the time I start mpg123 until it stops
pegging the CPU and starts to play audio, while with NEtBSD, playing
starts immediately with both binaries. If that means anything.
-stable: ls: /etc/malloc.conf: No such file or directory
-current: /FreeBSD-CURRENT/etc/malloc.conf - aj
sound card: sbc0: ESS ES1868 at port 0x220-0x22f,0x388-0x38b,0x330-0x331 irq 5
drq 1,0 on isa0
pcm0: ESS 18xx DSP on sbc0
cpu: CPU: Pentium/P54C (75.00-MHz 586-class CPU)
Origin = GenuineIntel Id = 0x524 Stepping = 4
Features=0x1bfFPU,VME,DE,PSE,TSC,MSR,MCE,CX8
real memory = 75497472 (73728K bytes)
(entire dmesg on request if of interest)
kernel config options used, if something is obviously a hog, -stable:
options INET
Re: Performance of FreeBSD vs NetBSD (was: Re: Performance of -current vs -stable)
Hmmm, a few weeks ago I did some totally unscientific testing, noting that -current was much slower than -stable, by playing an mp3 with an [...] explain why FreeBSD's mpg123 takes ~60% CPU and NetBSD's ~30% (vs the ~90+% usage by -current)... from http://www.mpg123.de: -- The benchmarking lie? Let's write a few notes about benchmarking the different mp3 decoders, which are available. 'top' is NOT a benchmark, it's a simple check on how a program performs. The sad thing with 'top' (or better the linux kernel) is, that it has some problems with the measurement of threaded programs or programs only requesting short chunks of processor time. One real test is to measure how long your machine needs to decode a stream without threads with 100% CPU. Using mpg123 you can do this with time mpg123 -t mp3stream.mp3 or time mpg123 -s mp3stream.mp3 /dev/null if you additionally want to measure the I/O time. If you find a player, which claims to be 10 or even more times faster than the current players: just don't believe it. A factor of 2 MAY BE possible -- Martin To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
