On Fri, 11 Jan 2002 20:01:26 +0100
Theo Wribe <[EMAIL PROTECTED]> wrote:
> On Thu, Jan 10, 2002 at 07:51:19AM +0800, csj wrote:
> > On Tue, 8 Jan 2002 23:11:46 +0100
> > Theo Wribe <[EMAIL PROTECTED]> wrote:
> >
> > > On Tue, Jan 08, 2002 at 02:00:27PM -0800, Brian Nelson wrote:
> > > > It's all
On Thu, Jan 10, 2002 at 07:51:19AM +0800, csj wrote:
> On Tue, 8 Jan 2002 23:11:46 +0100
> Theo Wribe <[EMAIL PROTECTED]> wrote:
>
> > On Tue, Jan 08, 2002 at 02:00:27PM -0800, Brian Nelson wrote:
> > > It's all about scsi baby...
> > >
> > > /dev/sdb:
> > > Timing buffer-cache reads: 128 MB i
On Tue, 8 Jan 2002 23:11:46 +0100
Theo Wribe <[EMAIL PROTECTED]> wrote:
> On Tue, Jan 08, 2002 at 02:00:27PM -0800, Brian Nelson wrote:
> > It's all about scsi baby...
> >
> > /dev/sdb:
> > Timing buffer-cache reads: 128 MB in 0.78 seconds =164.10 MB/sec
> > Timing buffered disk reads: 64 M
Thus spake martin f krafft:
> folks, sorry if i am posting this here, but i am sort of clueless, and
> i'd love some advise from you wise people!
>
> i have this AMD Thunderbird 1.3 GHz machine with 512Mb of SD-RAM, a 1Gb
> swap partition on a 20Gb 5400 seagate IDE drive. that's quite powerful,
>
Hi
On 2002.01.07 00:48 martin f krafft wrote:
also sprach dman <[EMAIL PROTECTED]> [2002.01.06.2127 +0100]:
> | i even went as far as to renice xmms to -20 *and*
> | rsync/bzip/gzip/make-kpkg to 20, but it doesn't really help.
>
> Well, kernel compilation is very CPU intensive, and bzip2 can do
On Wednesday 09 January 2002 00:00, Brian Nelson wrote:
> csj <[EMAIL PROTECTED]> writes:
> > On Mon, 7 Jan 2002 15:59:20 +0100
> >
> > martin f krafft <[EMAIL PROTECTED]> wrote:
> > > also sprach Christoph Simon <[EMAIL PROTECTED]> [2002.01.07.1547
+0100]:
> > > > > is this good or bad? hda2 is m
On Tue, Jan 08, 2002 at 02:00:27PM -0800, Brian Nelson wrote:
> It's all about scsi baby...
>
> /dev/sdb:
> Timing buffer-cache reads: 128 MB in 0.78 seconds =164.10 MB/sec
> Timing buffered disk reads: 64 MB in 1.62 seconds = 39.51 MB/sec
My Western Digital 80G 7200RPM is pretty good too.
csj <[EMAIL PROTECTED]> writes:
> On Mon, 7 Jan 2002 15:59:20 +0100
> martin f krafft <[EMAIL PROTECTED]> wrote:
>
> > also sprach Christoph Simon <[EMAIL PROTECTED]> [2002.01.07.1547 +0100]:
> > > > is this good or bad? hda2 is my swap partition:
> > >
> > > This is bad (<1/6).
> >
> > what do
/dev/hda2:
Timing buffer-cache reads: 128 MB in 0.99 seconds = 129.29 MB/sec
Timing buffered disk reads: 64 MB in 21.93 seconds = 2.92 MB/sec
>>>
>>> /dev/hda1:
>>> Timing buffer-cache reads: 128 MB in 0.77 seconds =166.23 MB/sec
>>> Timing buffered disk reads: 64 MB
On Mon, 7 Jan 2002 15:59:20 +0100
martin f krafft <[EMAIL PROTECTED]> wrote:
> also sprach Christoph Simon <[EMAIL PROTECTED]> [2002.01.07.1547 +0100]:
> > > is this good or bad? hda2 is my swap partition:
> >
> > This is bad (<1/6).
>
> what do you mean?
>
> > > /dev/hda2:
> > > Timing buffer
On Mon, 07 Jan 2002, martin f krafft wrote:
> also sprach dman <[EMAIL PROTECTED]> [2002.01.07.1736 +0100]:
> > Ok, this sounds contrary to what I've heard before. I've heard that
> > ALSA, unlike OSS, allows multiple processes to output sound
> > simultaneously. How, then, can it allow that if a
On Mon, 07 Jan 2002, Pietro Cagnoni wrote:
> > another. With dumb xmms, it cannot help but cause skips. Use something
> > better, with huge output buffers, and you will not have so much trouble. Or
> > patch the kernel.
>
> xmms output buffer size is configurable:
Good. It still won't help unless
On Mon, Jan 07, 2002 at 03:25:45PM +0100, martin f krafft wrote:
> also sprach Graham/Aniartia <[EMAIL PROTECTED]> [2002.01.07.0231 +0100]:
> > Well it might not be the CPU that's at fault, what's your soundcard &
> > mobo, even with the most sorted latency on VIA chipsets I'm still
> > getting pro
On Mon, Jan 07, 2002 at 05:53:36PM +0100, martin f krafft wrote:
> also sprach Dave Sherohman <[EMAIL PROTECTED]> [2002.01.07.1709 +0100]:
> > Although I think that ALSA sounds like the most likely source of trouble,
> > based on previous responses, I'll also point out that, with load in the
> > 3-
> 2.4.x vanilla is a PoS in certain areas. The VM is one. The latency is
> another. With dumb xmms, it cannot help but cause skips. Use something
> better, with huge output buffers, and you will not have so much trouble. Or
> patch the kernel.
xmms output buffer size is configurable:
[little butt
also sprach dman <[EMAIL PROTECTED]> [2002.01.07.1736 +0100]:
> Ok, this sounds contrary to what I've heard before. I've heard that
> ALSA, unlike OSS, allows multiple processes to output sound
> simultaneously. How, then, can it allow that if all processes need to
> have /dev/dsp open? Isn't on
On Sun, 06 Jan 2002, martin f krafft wrote:
> but any process with nice value -20 should take absolut precedence over
> other processes at higher nice levels, especially when the
> resource-hog-process runs at nice level +20!!!
But that just will not happen with current unpatched kernels. High IO
also sprach Dave Sherohman <[EMAIL PROTECTED]> [2002.01.07.1709 +0100]:
> Although I think that ALSA sounds like the most likely source of trouble,
> based on previous responses, I'll also point out that, with load in the
> 3-4 range but CPU at 75% idle, your major bottleneck is most likely I/O,
>
On Mon, Jan 07, 2002 at 03:33:19PM +0100, martin f krafft wrote:
| also sprach Dmitriy <[EMAIL PROTECTED]> [2002.01.07.0704 +0100]:
| > Did you check if XMMS uses any wacky output plugins like ESD?
|
| it writes OSD to /dev/dsp. then there's alsa that converts it to line
| data.
Ok, this sounds c
On Sun, Jan 06, 2002 at 04:52:14PM +0100, martin f krafft wrote:
> Linux piper 2.4.9 #1 Tue Sep 11 15:39:28 CEST 2001 i686 unknown
> 16:45:25 up 13 days, 1:17, 7 users, load average: 3.40, 3.56, 3.70
> 84 processes: 83 sleeping, 1 running, 0 zombie, 0 stopped
> CPU states: 0.8% user, 22.3% sy
also sprach Christoph Simon <[EMAIL PROTECTED]> [2002.01.07.1614 +0100]:
> > jealous! what's the RPM on your drive?
>
> No idea. How can I find out?
no idea. look at the drive? find the drive product description with
hdparm -I and look on the vendor website?
> > ps: please don't cc me on replies
On Mon, 7 Jan 2002 15:59:20 +0100
martin f krafft <[EMAIL PROTECTED]> wrote:
> > > /dev/hda2:
> > > Timing buffer-cache reads: 128 MB in 0.99 seconds = 129.29
> > > MB/sec Timing buffered disk reads: 64 MB in 21.93 seconds =
> > > 2.92 MB/sec
> >
> > /dev/hda1:
> > Timing buffer-cache
also sprach Christoph Simon <[EMAIL PROTECTED]> [2002.01.07.1547 +0100]:
> > is this good or bad? hda2 is my swap partition:
>
> This is bad (<1/6).
what do you mean?
> > /dev/hda2:
> > Timing buffer-cache reads: 128 MB in 0.99 seconds = 129.29 MB/sec
> > Timing buffered disk reads: 64 MB
also sprach Noah Meyerhans <[EMAIL PROTECTED]> [2002.01.07.0656 +0100]:
> Yes, there's something very wrong. I can easily do a good deal of work
> (several concurrent kernel compiles, for example) on my 600 MHz
> workstation + 256 MB RAM with no skips from my mp3 player.
:(
>
> One thing that I
On Mon, 7 Jan 2002 15:24:04 +0100
martin f krafft <[EMAIL PROTECTED]> wrote:
> is this good or bad? hda2 is my swap partition:
This is bad (<1/6).
> /dev/hda2:
> Timing buffer-cache reads: 128 MB in 0.99 seconds = 129.29 MB/sec
> Timing buffered disk reads: 64 MB in 21.93 seconds = 2.92
also sprach Dmitriy <[EMAIL PROTECTED]> [2002.01.07.0704 +0100]:
> Did you check if XMMS uses any wacky output plugins like ESD?
it writes OSD to /dev/dsp. then there's alsa that converts it to line
data.
> Did you try other players?
mpg123 with the same problem...
--
martin; (gre
also sprach Graham/Aniartia <[EMAIL PROTECTED]> [2002.01.07.0433 +0100]:
> Any South Bridge/VIA 686* North Bridge (hope that's the right way round) with
> untweaked PCI latency = missing of data on anything atached to the PCI bus :(
is this a BIOS setting?
also sprach Dries Kimpe <[EMAIL PROTECTED]> [2002.01.07.0254 +0100]:
> First of all (stupid question): you aren't using esd or something
> alike? Because although XMMS may get all the time it needs, esd may be
> starved...
alsa...
> Second: Even though one has -20 and the other 20 doesn't mean th
also sprach Graham/Aniartia <[EMAIL PROTECTED]> [2002.01.07.0231 +0100]:
> Well it might not be the CPU that's at fault, what's your soundcard & mobo,
> even with the most sorted latency on VIA chipsets I'm still getting problems
> with sound cards @ high CPU loads (specialy when building & compr
also sprach Christoph Simon <[EMAIL PROTECTED]> [2002.01.07.0156 +0100]:
> I think, something's wrong with your system. I've some 2/3 of your CPU
> and RAM (but more disk), and can run xmms on mp3, while compiling a
> kernel, writing a CD, compressing files... without actually loosing
> responsiven
On Sun, Jan 06, 2002 at 04:52:14PM +0100, martin f krafft wrote:
> folks, sorry if i am posting this here, but i am sort of clueless, and
> i'd love some advise from you wise people!
>
> i have this AMD Thunderbird 1.3 GHz machine with 512Mb of SD-RAM, a 1Gb
> swap partition on a 20Gb 5400 seagate
On Sun, Jan 06, 2002 at 04:52:14PM +0100, martin f krafft wrote:
> in such a situation, xmms (or mpg123 without X, it doesn't matter)
> continuously skips on MP3s and it's *very* annoying. i even went as far
> as to renice xmms to -20 *and* rsync/bzip/gzip/make-kpkg to 20, but it
> doesn't really h
On Sun, Jan 06, 2002 at 11:48:41PM +0100, martin f krafft wrote:
| also sprach dman <[EMAIL PROTECTED]> [2002.01.06.2127 +0100]:
| > | i even went as far as to renice xmms to -20 *and*
| > | rsync/bzip/gzip/make-kpkg to 20, but it doesn't really help.
| >
| > Well, kernel compilation is very CPU i
On Monday 07 January 2002 1:54 am, Dries Kimpe wrote:
> on the original and copy. While I was doing that, load also got up to 3-4.
> Looking at top, I saw that some kernel daemon (think kupdated) got *AlOT*
> of CPU. The system also started responding slow (missing eth0 traffic,
> ...)
>
> Maybe it
>
> Linux piper 2.4.9 #1 Tue Sep 11 15:39:28 CEST 2001 i686 unknown
> 16:45:25 up 13 days, 1:17, 7 users, load average: 3.40, 3.56, 3.70
> 84 processes: 83 sleeping, 1 running, 0 zombie, 0 stopped
> CPU states: 0.8% user, 22.3% system, 1.0% nice, 75.9% idle
On Sunday 06 January 2002 3:52 pm, martin f krafft wrote:
> folks, sorry if i am posting this here, but i am sort of clueless, and
> i'd love some advise from you wise people!
>
> i have this AMD Thunderbird 1.3 GHz machine with 512Mb of SD-RAM, a 1Gb
> swap partition on a 20Gb 5400 seagate IDE dri
On Mon, 7 Jan 2002 01:36:18 +0100
martin f krafft <[EMAIL PROTECTED]> wrote:
> also sprach Shri Shrikumar <[EMAIL PROTECTED]> [2002.01.07.0143 +0100]:
> > only thing I can think of is to try xmms without the cpu hogging stuff
> > to make sure that it is the cpu causing the skips and not a slow
> >
also sprach Shri Shrikumar <[EMAIL PROTECTED]> [2002.01.07.0143 +0100]:
> only thing I can think of is to try xmms without the cpu hogging stuff
> to make sure that it is the cpu causing the skips and not a slow
> internet connection.
>
> I dont enough about how all the stuff works in linux but it
On Sun, 2002-01-06 at 15:52, martin f krafft wrote:
> folks, sorry if i am posting this here, but i am sort of clueless, and
> i'd love some advise from you wise people!
>
> i have this AMD Thunderbird 1.3 GHz machine with 512Mb of SD-RAM, a 1Gb
> swap partition on a 20Gb 5400 seagate IDE drive. t
also sprach dman <[EMAIL PROTECTED]> [2002.01.06.2127 +0100]:
> | i even went as far as to renice xmms to -20 *and*
> | rsync/bzip/gzip/make-kpkg to 20, but it doesn't really help.
>
> Well, kernel compilation is very CPU intensive, and bzip2 can do lots
> of computation as well. What you have is
On Sun, Jan 06, 2002 at 04:52:14PM +0100, martin f krafft wrote:
| folks, sorry if i am posting this here, but i am sort of clueless, and
| i'd love some advise from you wise people!
|
| i have this AMD Thunderbird 1.3 GHz machine with 512Mb of SD-RAM, a 1Gb
| swap partition on a 20Gb 5400 seagate
folks, sorry if i am posting this here, but i am sort of clueless, and
i'd love some advise from you wise people!
i have this AMD Thunderbird 1.3 GHz machine with 512Mb of SD-RAM, a 1Gb
swap partition on a 20Gb 5400 seagate IDE drive. that's quite powerful,
isn't it?
Linux piper 2.4.9 #1 Tue Sep
42 matches
Mail list logo
