Hello folks...
Host A: p166, ISA NE2K, linux-2.4.12-ac4
Host B: p2-400, rtl-8129, WinXP (heh, not my box though ;)
Load: smbmount connection from host A to the host B, and getting
large files.
Result:
a) modem dies completely - drops ppp packets at the rate of 75%,
irqtune doesnt affect this behaviour at all
b) mpg123 sound becomes corrupted, as if its interrupted
with rate of 100Hz for a very little amount of time,
irqtune doesnt affect this behaviour at all
c) CPU load does not depend on whether mpg123 is started,
ie at the moment mpg123 exits, system cpu usage pops up.
d) complete stopping sound (killing esd which leads to
the fact that soundcard stops to emit interrupts), increases
network copy performance by the factor of 1.2
e) renicing ksoftirqd doesnt affect the behaviour at all
f) renicing mc increases copy performance my the factor of 1.2
Now i`m compiling the 2.4.13-linus to test it either...
cheers, Samium Gromoff
On Thu, Oct 25, 2001 at 11:30:18PM +0400, Samium Gromoff wrote:
> Hello folks...
>
> Host A: p166, ISA NE2K, linux-2.4.12-ac4
> Host B: p2-400, rtl-8129, WinXP (heh, not my box though ;)
>
> Load: smbmount connection from host A to the host B, and getting
> large files.
Solution: replace NE2K with a decent network card.
-ben
> Host A: p166, ISA NE2K, linux-2.4.12-ac4
> Host B: p2-400, rtl-8129, WinXP (heh, not my box though ;)
>
> Result:
> a) modem dies completely - drops ppp packets at the rate of 75%,
> irqtune doesnt affect this behaviour at all
This sounds like you dont have ide unmasking enabled and have an old
IDE setup
> On Thu, Oct 25, 2001 at 11:30:18PM +0400, Samium Gromoff wrote:
> > Hello folks...
> >
> > Host A: p166, ISA NE2K, linux-2.4.12-ac4
> > Host B: p2-400, rtl-8129, WinXP (heh, not my box though ;)
> >
> > Load: smbmount connection from host A to the host B, and getting
> > large files.
>
> Solution: replace NE2K with a decent network card.
The ne2k driver goes to great pains to keep interrupts enabled it isnt the
culprit as far as I can tell
On Thu, 25 Oct 2001, Alan Cox wrote:
> > On Thu, Oct 25, 2001 at 11:30:18PM +0400, Samium Gromoff wrote:
> > > Hello folks...
> > >
> > > Host A: p166, ISA NE2K, linux-2.4.12-ac4
> > > Host B: p2-400, rtl-8129, WinXP (heh, not my box though ;)
> > >
> > > Load: smbmount connection from host A to the host B, and getting
> > > large files.
> >
> > Solution: replace NE2K with a decent network card.
>
> The ne2k driver goes to great pains to keep interrupts enabled it isnt the
> culprit as far as I can tell
I had an AMD K6 200 with an ISA NE2K card whan I started using Linux...
I started using kernel 2.0 and that card worked very nice.
I could even play quake while sending out data at 10Mbit/s, I didn't even
notice that the transfer had started.
Then I upgraded to kernel 2.2 and I was no longer able to play quake while
tranmitting at 10Mbit/s with the exact same hardware. Sometimes I could
hardly even play mp3's :(
Then a friend of mine that also upgraded to kernel 2.2 began complaining
that his machine also became extremely slow and unresponsive while
transitting at 10Mbit/s, in fact that machine was even slower than mine
during the transfers and his cpu was a bit faster than mine (also AMD).
Then I upgraded that machine to pIII 700 and even that machine slows to a
crawl while transmitting with that bloody ISA NE2K. It's the same thing in
kernel 2.4 too. These days I simply don't use that card anymore...
So something seems to have taken a wrong turn between 2.0 and 2.2
I don't think this is a problem intruduced in 2.4.
/Martin
Never argue with an idiot. They drag you down to their level, then beat you with experience.
> Then I upgraded that machine to pIII 700 and even that machine slows to a
> crawl while transmitting with that bloody ISA NE2K. It's the same thing in
> kernel 2.4 too. These days I simply don't use that card anymore...
>
> So something seems to have taken a wrong turn between 2.0 and 2.2
> I don't think this is a problem intruduced in 2.4.
A faster machine will take as long as a slow machine with an ne2000. It
doesn't matter if its an 8Mb 386 or a dual athlon, it will spend almost all
of its ne2000 handling time poking bytes across an 8MHz bus.
On Thu, Oct 25, 2001 at 09:54:46PM +0100, Alan Cox wrote:
> A faster machine will take as long as a slow machine with an ne2000. It
> doesn't matter if its an 8Mb 386 or a dual athlon, it will spend almost all
> of its ne2000 handling time poking bytes across an 8MHz bus.
Put another way: if you want a kernel that's optimised for 386es, use 2.0.
-ben
On Thu, 25 Oct 2001, Samium Gromoff wrote:
> Hello folks...
>
> Host A: p166, ISA NE2K, linux-2.4.12-ac4
> Host B: p2-400, rtl-8129, WinXP (heh, not my box though ;)
>
> Load: smbmount connection from host A to the host B, and getting
> large files.
You don't say if any of the tests you did are related to smbfs. I suspect
this reasoning is completely irrelevant (not, that it has stopped me
before ... :)
smbfs is not the fastest thing around. I think the slowness on some
operations is related to how it waits after sending each request.
process A process B
get semaphore
request 4096 bytes wait on semaphore
... wait for network ...
read packet
read packet
read packet
release semaphore
get semaphore
request 4096 bytes
It could send the second request without waiting for the first to complete
(if it knew how to separate the responses). Doing that should speed things
up.
If you play mp3's over smbfs while also doing something else I suppose the
delay could become noticable. I can't explain the other effects, so
possibly this is unrelated to smbfs.
You could make me happy by repeating the tests, but generating the network
load with something else (http?).
/Urban
" Urban Widmark wrote:"
> > Hello folks...
> >
> > Host A: p166, ISA NE2K, linux-2.4.12-ac4
> > Host B: p2-400, rtl-8129, WinXP (heh, not my box though ;)
> >
> > Load: smbmount connection from host A to the host B, and getting
> > large files.
>
> You don't say if any of the tests you did are related to smbfs. I suspect
> this reasoning is completely irrelevant (not, that it has stopped me
> before ... :)
>
> smbfs is not the fastest thing around. I think the slowness on some
> operations is related to how it waits after sending each request.
>
> process A process B
> get semaphore
> request 4096 bytes wait on semaphore
> ... wait for network ...
> read packet
> read packet
> read packet
> release semaphore
> get semaphore
> request 4096 bytes
>
> It could send the second request without waiting for the first to complete
> (if it knew how to separate the responses). Doing that should speed things
> up.
>
> If you play mp3's over smbfs while also doing something else I suppose the
> delay could become noticable. I can't explain the other effects, so
> possibly this is unrelated to smbfs.
>
> You could make me happy by repeating the tests, but generating the network
> load with something else (http?).
>
> /Urban
>
>
>
1. /dev/hda is -u1d1 `ed, and the disc load is near to not existent
2. mp3 is placed locally
cheers, Samium Gromoff
Benjamin LaHaise wrote:
>
> > Host A: p166, ISA NE2K, linux-2.4.12-ac4
> Solution: replace NE2K with a decent network card.
Load of NE2k running at full 10 Mbps is 60% on P100 running OpenBSD...
- Jussi Laako
--
PGP key fingerprint: 161D 6FED 6A92 39E2 EB5B 39DD A4DE 63EB C216 1E4B
Available at PGP keyservers
" Jussi Laako wrote:"
>
> Benjamin LaHaise wrote:
> >
> > > Host A: p166, ISA NE2K, linux-2.4.12-ac4
> > Solution: replace NE2K with a decent network card.
>
> Load of NE2k running at full 10 Mbps is 60% on P100 running OpenBSD...
ISA-based one?
sane service? (i mean not smb, but smth like ftp)
thanks in advance...
>
>
> - Jussi Laako
>
> --
> PGP key fingerprint: 161D 6FED 6A92 39E2 EB5B 39DD A4DE 63EB C216 1E4B
> Available at PGP keyservers
>
cheers, Samium Gromoff
> > right, so more fragmentation-assembly increases the CPU load,
> > no surprise there.
> damn, i have a mtu of 1500 and i dont quite see abt what frag/reassembly
> are you talking about while the problems start to pop out on _256_ bytes
> large packets (yes 256+smth like 32 or more)
Its nothing to do with reassembly. My guess is that the irq handling or the
other driver locks on the ISA driver are holding off the sound.
> look: we have 2.0 serving NIC interrupts more efficintly than 2.4, and you
> say that we even dont need to know _why_ its so!?
Oh thats easy. 2.0 performs like crap on SMP boxes.
The newer code is intended to do sensible things for NE2K drivers however so
I am curious what is fouling up. It even goes to the trouble to avoid
disabling all interrupts during a transmit event.
What might be interesting would be to edit 8390.c and change
/* Mask interrupts from the ethercard.
SMP: We have to grab the lock here otherwise the IRQ handler
on another CPU can flip window and race the IRQ mask set. We end
up trashing the mcast filter not disabling irqs if we dont lock
*/
spin_lock_irqsave(&ei_local->page_lock, flags);
outb_p(0x00, e8390_base + EN0_IMR);
spin_unlock_irqrestore(&ei_local->page_lock, flags);
to use
/* this is the missing spin_trylock_irqsave longhand.. */
save_flags(flags);
__cli();
if(!spin_trylock(&ei_local->page_lock))
{
restore_flags(flags);
return 1;
}
outb_p(0x00, e8390_base + EN0_IMR);
spin_unlock_irqrestore(&ei_local->page_lock, flags);
Unfortunately, this will most likely fall under
'almost nobody interested in fiddling with old hw' category...
On Saturday 08 December 2001 19:58, Samium Gromoff wrote:
> " Martin Josefsson wrote:"
> > I had an AMD K6 200 with an ISA NE2K card whan I started using Linux...
> > I started using kernel 2.0 and that card worked very nice.
> > I could even play quake while sending out data at 10Mbit/s, I didn't even
> > notice that the transfer had started.
> >
> > Then I upgraded to kernel 2.2 and I was no longer able to play quake
> > while tranmitting at 10Mbit/s with the exact same hardware. Sometimes I
> > could hardly even play mp3's :(
> >
> > Then a friend of mine that also upgraded to kernel 2.2 began complaining
> > that his machine also became extremely slow and unresponsive while
> > transitting at 10Mbit/s, in fact that machine was even slower than mine
> > during the transfers and his cpu was a bit faster than mine (also AMD).
> >
> > Then I upgraded that machine to pIII 700 and even that machine slows to a
> > crawl while transmitting with that bloody ISA NE2K. It's the same thing
> > in kernel 2.4 too. These days I simply don't use that card anymore...
> >
> > So something seems to have taken a wrong turn between 2.0 and 2.2
> > I don't think this is a problem intruduced in 2.4.
>
> The question is whether anybody is interesting in investigation of
> such broken behaviour.
> i`ve made a further research and discovered the fact that
> ping -l 99999999 - does not corrupt the sound
> ping -l 99999999 -s 256 - does not corrupt the sound
> ping -l 99999999 -s 512 - significantly corrupts the sound
> ping -l 99999999 -s 16384 - heavily corrupts the sound with stalls
>
> as a reminder -l xxxx option forces ping to spit out data as fast as
> possible making it a great bandwidth loader...
>
> Initial look at the result makes me think that at certain level the
> interrupt handler just takes too long time and preempts the sound driver
> or whatever.
> My thinking is that if 2.0 was better than 2.4 in this case, we
> definitely need to find out why was it so and use its strong side.
--
vda
" Martin Josefsson wrote:"
>
> > > > Hello folks...
> > > >
> > > > Host A: p166, ISA NE2K, linux-2.4.12-ac4
> > > > Host B: p2-400, rtl-8129, WinXP (heh, not my box though ;)
> > > >
> > > > Load: smbmount connection from host A to the host B, and getting
> > > > large files.
> > >
> > > Solution: replace NE2K with a decent network card.
> >
> > The ne2k driver goes to great pains to keep interrupts enabled it isnt the
> > culprit as far as I can tell
>
> I had an AMD K6 200 with an ISA NE2K card whan I started using Linux...
> I started using kernel 2.0 and that card worked very nice.
> I could even play quake while sending out data at 10Mbit/s, I didn't even
> notice that the transfer had started.
>
> Then I upgraded to kernel 2.2 and I was no longer able to play quake while
> tranmitting at 10Mbit/s with the exact same hardware. Sometimes I could
> hardly even play mp3's :(
>
> Then a friend of mine that also upgraded to kernel 2.2 began complaining
> that his machine also became extremely slow and unresponsive while
> transitting at 10Mbit/s, in fact that machine was even slower than mine
> during the transfers and his cpu was a bit faster than mine (also AMD).
>
> Then I upgraded that machine to pIII 700 and even that machine slows to a
> crawl while transmitting with that bloody ISA NE2K. It's the same thing in
> kernel 2.4 too. These days I simply don't use that card anymore...
>
> So something seems to have taken a wrong turn between 2.0 and 2.2
> I don't think this is a problem intruduced in 2.4.
The question is whether anybody is interesting in investigation of
such broken behaviour.
i`ve made a further research and discovered the fact that
ping -l 99999999 - does not corrupt the sound
ping -l 99999999 -s 256 - does not corrupt the sound
ping -l 99999999 -s 512 - significantly corrupts the sound
ping -l 99999999 -s 16384 - heavily corrupts the sound with stalls
as a reminder -l xxxx option forces ping to spit out data as fast as possible
making it a great bandwidth loader...
Initial look at the result makes me think that at certain level the
interrupt handler just takes too long time and preempts the sound driver
or whatever.
My thinking is that if 2.0 was better than 2.4 in this case, we definitely
need to find out why was it so and use its strong side.
regards, Samium Gromoff
" Mark Hahn wrote:"
>
> > > I had an AMD K6 200 with an ISA NE2K card whan I started using Linux...
> ...
> > such broken behaviour.
>
> the only thing broken is that the nic is pitiful and eats CPU.
>
> > i`ve made a further research and discovered the fact that
> > ping -l 99999999 - does not corrupt the sound
> > ping -l 99999999 -s 256 - does not corrupt the sound
> > ping -l 99999999 -s 512 - significantly corrupts the sound
> > ping -l 99999999 -s 16384 - heavily corrupts the sound with stalls
>
> right, so more fragmentation-assembly increases the CPU load,
> no surprise there.
damn, i have a mtu of 1500 and i dont quite see abt what frag/reassembly
are you talking about while the problems start to pop out on _256_ bytes
large packets (yes 256+smth like 32 or more)
>
> > My thinking is that if 2.0 was better than 2.4 in this case, we definitely
> > need to find out why was it so and use its strong side.
>
> your particular case is not worth fixing; I doubt it applies to machines
> with modern CPU, modern dram, modern nics.
>
>
but why? 2.0 is ok, 2.4 is broken.
look: we have 2.0 serving NIC interrupts more efficintly than 2.4, and you
say that we even dont need to know _why_ its so!?
why do you neglect the possible improvement of that case?
cheers, Samium Gromoff
> What might be interesting would be to edit 8390.c and change
>
> /* Mask interrupts from the ethercard.
> SMP: We have to grab the lock here otherwise the IRQ handler
> on another CPU can flip window and race the IRQ mask set. We end
> up trashing the mcast filter not disabling irqs if we dont lock
> */
>
> spin_lock_irqsave(&ei_local->page_lock, flags);
> outb_p(0x00, e8390_base + EN0_IMR);
> spin_unlock_irqrestore(&ei_local->page_lock, flags);
>
> to use
>
> /* this is the missing spin_trylock_irqsave longhand.. */
> save_flags(flags);
> __cli();
> if(!spin_trylock(&ei_local->page_lock))
> {
> restore_flags(flags);
> return 1;
> }
> outb_p(0x00, e8390_base + EN0_IMR);
> spin_unlock_irqrestore(&ei_local->page_lock, flags);
building the kernel is in the progress, so i`ll report asap...
I`m so glad somebody still cares of the good ol` boxes :-)
regards, Samium Gromoff