Re: IDE Performance lack !
> The answer for both of you is:
>
> hdparm -d1 /dev/hd{whatever}
>
> Without DMA enabled, performance is going to suck. 1.9 MB/sec is actually pretty
> good without DMA ;)
I agree.
I get around 4MB/s without and 35.75MB/s with...
hdparm -c3 -d1 -m16 /dev/hda
on a KT133 (A7V) and 45GB IBM DTLA hard drive.
no data corruption, even with a sblive, an scsi
adapter, 2 hard drives...
François Cami
> --
> .
> : [EMAIL PROTECTED] : And I see the elder races, :
> :.: putrid forms of man:
> : Jakob Østergaard : See him rise and claim the earth, :
> :OZ9ABN : his downfall is at hand. :
> :.:{Konkhra}...:
> -
--
All that is gold does not glitter,
Not all those who wander are lost,
The old that is strong does not wither,
Deep roots are not touched by the frost.
From the ashes a fire shall be woken,
A light from the shadows shall spring,
Renewed shall the blade that was broken,
The crownless again shall be king.
The Riddle of Strider
JRR Tolkien
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: IDE Performance lack !
The answer for both of you is:
hdparm -d1 /dev/hd{whatever}
Without DMA enabled, performance is going to suck. 1.9 MB/sec is actually pretty
good without DMA ;)
I agree.
I get around 4MB/s without and 35.75MB/s with...
hdparm -c3 -d1 -m16 /dev/hda
on a KT133 (A7V) and 45GB IBM DTLA hard drive.
no data corruption, even with a sblive, an scsi
adapter, 2 hard drives...
François Cami
--
.
: [EMAIL PROTECTED] : And I see the elder races, :
:.: putrid forms of man:
: Jakob Østergaard : See him rise and claim the earth, :
:OZ9ABN : his downfall is at hand. :
:.:{Konkhra}...:
-
--
All that is gold does not glitter,
Not all those who wander are lost,
The old that is strong does not wither,
Deep roots are not touched by the frost.
From the ashes a fire shall be woken,
A light from the shadows shall spring,
Renewed shall the blade that was broken,
The crownless again shall be king.
The Riddle of Strider
JRR Tolkien
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
3C905C and error e401 : problem solved
Hi Mr Morton and all linux-kernel, I have been experimenting with the 3C905C, trying to get rid of the annoying e401 error (too much work in interrupt). I've tried using 64 as max_interrupt_work and it solves completely the e401 problem on this particular machine : - yoda.rez-gif.supelec.fr (dns/proxy for 500 clients, on a 10Mbits/s direct Internet connexion, local network is 100Mbits/s) ASUS P2B-DS dual PII-350 512MB RAM (2*128+1*256) 3*IBM 18GB 10KT U2W SCSI 3C905C S3 Virge Linux Slackware-current, 2.2.19 or 2.4.4 both built for smp with APIC. Before setting max_interrupt_work at 64, the e401 error could occur 20 times a day. Now it doesn't occur anymore. I have waited for a long time to test that on the SMP PC because it is critical for our network. I have tried to link these e401 messages with another activity on the PC, like heavy I/O, to no avail. The 3C905C does 10 times as many interruptions as the SCSI controller does. Lowering the max_interrupt_work creates a lot more errors in the logs (all are e401). On that second PC, the message still appears (very rarely though, about once in two or three days. I cannot relate those occurences to anything). It used to appear very often (about 40 times a day). I have tried to put the machine under stress (4 heavy FTP transfers at once, each 400MB long, with 4 different clients, connected in 100 MBits FD). The e401 message has not appeared... I'm a bit at a loss here. - lando.rez-gif.supelec.fr (FTP for the same network) ABIT LX6 PII300 128MB RAM IBM 8.4GB IDE (1st Master) + Maxtor 60GB IDE (2nd Master) 3C905C S3 Virge Linux Slackware-current, 2.4.4, ProFTPD All our network is 100MBits Full Duplex, switched with 3COM switches. Best regards, thanks for all your work François Cami - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
3C905C and error e401 : problem solved
Hi Mr Morton and all linux-kernel, I have been experimenting with the 3C905C, trying to get rid of the annoying e401 error (too much work in interrupt). I've tried using 64 as max_interrupt_work and it solves completely the e401 problem on this particular machine : - yoda.rez-gif.supelec.fr (dns/proxy for 500 clients, on a 10Mbits/s direct Internet connexion, local network is 100Mbits/s) ASUS P2B-DS dual PII-350 512MB RAM (2*128+1*256) 3*IBM 18GB 10KT U2W SCSI 3C905C S3 Virge Linux Slackware-current, 2.2.19 or 2.4.4 both built for smp with APIC. Before setting max_interrupt_work at 64, the e401 error could occur 20 times a day. Now it doesn't occur anymore. I have waited for a long time to test that on the SMP PC because it is critical for our network. I have tried to link these e401 messages with another activity on the PC, like heavy I/O, to no avail. The 3C905C does 10 times as many interruptions as the SCSI controller does. Lowering the max_interrupt_work creates a lot more errors in the logs (all are e401). On that second PC, the message still appears (very rarely though, about once in two or three days. I cannot relate those occurences to anything). It used to appear very often (about 40 times a day). I have tried to put the machine under stress (4 heavy FTP transfers at once, each 400MB long, with 4 different clients, connected in 100 MBits FD). The e401 message has not appeared... I'm a bit at a loss here. - lando.rez-gif.supelec.fr (FTP for the same network) ABIT LX6 PII300 128MB RAM IBM 8.4GB IDE (1st Master) + Maxtor 60GB IDE (2nd Master) 3C905C S3 Virge Linux Slackware-current, 2.4.4, ProFTPD All our network is 100MBits Full Duplex, switched with 3COM switches. Best regards, thanks for all your work François Cami - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PIO disk writes using 100% system time and performing poorly with VIA vt82c686b on kernels 2.2 & 2.4
Ignacio Monge wrote: > > Hi. > I have VIA686a too and a UDMA100 hard disk. So do I. > This is my cat /proc/ide/via: > > --VIA BusMastering IDE Configuration > Driver Version: 3.23 > South Bridge: VIA vt82c686a > Revision: ISA 0x22 IDE 0x10 > Highest DMA rate: UDMA66 > ---drive0drive1drive2drive3- > Transfer Mode:DMA UDMA PIO PIO > Address Setup: 30ns 30ns 120ns 120ns > Cmd Active: 90ns 90ns 480ns 480ns > Cmd Recovery:30ns 30ns 480ns 480ns > Data Active: 90ns 90ns 330ns 330ns > Data Recovery: 30ns 30ns 270ns 270ns > Cycle Time: 120ns 60ns 600ns 600ns > Transfer Rate: 16.5MB/s 33.0MB/s 3.3MB/s 3.3MB/s What is odd here is the 33MB/s on drive 1. If it was operating at UDMA66, that would be more like 66MB/s (see my own /proc/ide/via). I guess you should try putting a drive on IDEO as master and the second on IDE1 (which seems empty) as master too. > As you can see, l use UDMA66 instead UDMA100. I don't know why. Maybe VIA > vt82c686a doesn't support it? I have answering in this list a days ago about this > problem. but none seems to have a question. 686a maxes out at UDMA66. 686b does UDMA100. > Like you, my system goes down when I try to compile so > mething (I have a 394 Mb of RAM and a 1 Ghz processor). I'm clueless, my 686a with IBM DTLA works fine (board is ASUS A7V, kernel 2.4.3, Duron700, 256MB PC133). The new VIA IDE fixes in the kernel _might_ be the cause, but I'm not sure. > Although, my hdparm output is this: > /dev/hde2: > Timing buffer-cache reads: 128 MB in 0.79 seconds =162.03 MB/sec > Timing buffered disk reads: 64 MB in 2.44 seconds = 26.23 MB/sec > and sometime looks better. > > I don't know is this is a problem with the VIA kernel driver or not. But the > system doesn't seem to work fine since 2.4.2 or 2.4.1 kernel. I hope (plz!) this > problem will be fixed in future. > Luck. > > PS: in cat /proc/ide/via I see "Cable Type: 40w > > 40w"... Is it right? I have a 80w cable, not 40. > > I see 80w in mine, maybe your cable is broken... Did you put the blue end of the cable on the motherboard ? Also detecting a 40w cable disables UDMA66 I guess. Here's my /proc/ide/via : --VIA BusMastering IDE Configuration Driver Version: 3.20 South Bridge: VIA vt82c686a Revision: ISA 0x22 IDE 0x10 BM-DMA base:0xd800 PCI clock: 33MHz Master Read Cycle IRDY:0ws Master Write Cycle IRDY:0ws BM IDE Status Register Read Retry: yes Max DRDY Pulse Width: No limit ---Primary IDE---Secondary IDE-- Read DMA FIFO flush: yes yes End Sector FIFO flush: no no Prefetch Buffer: yes no Post Write Buffer:yes no Enabled: yes yes Simplex only: no no Cable Type: 80w 40w ---drive0drive1drive2drive3- Transfer Mode: UDMA PIO DMA PIO Address Setup: 30ns 120ns 60ns 120ns Cmd Active: 90ns 90ns 90ns 90ns Cmd Recovery:30ns 30ns 90ns 90ns Data Active: 90ns 330ns 90ns 330ns Data Recovery: 30ns 270ns 90ns 270ns Cycle Time: 30ns 600ns 180ns 600ns Transfer Rate: 66.0MB/s 3.3MB/s 11.0MB/s 3.3MB/s François Cami -- All that is gold does not glitter, Not all those who wander are lost, The old that is strong does not wither, Deep roots are not touched by the frost. From the ashes a fire shall be woken, A light from the shadows shall spring, Renewed shall the blade that was broken, The crownless again shall be king. The Riddle of Strider JRR Tolkien - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [3C905x e401]
okay, testing will begin monday (when it's under load). any advice on which value i begin with ? (20 ?) François Cami Andrew Morton wrote: > > Francois Cami wrote: > > > > Vibol Hou wrote: > > ... > > > > > Apr 17 16:10:12 omega kernel: eth0: Too much work in interrupt, status e401. > > > > I got that one too, PC is ASUS P2B-DS with two PII-350, 384MB RAM, > > 3C905B. > > If you were getting this message occasionally, and if increasing the > max_interrupt_work module parm makes it stop, and everything > is always working fine, then it's an OK thing to do. > > Question is: why is it happening? We're failing to get out > of the interrupt loop after 32 loops. Each loop can reap > up to 16 transmitted packets and 32 received packets. > That's a lot. > > My suspicion is that something else in the system is > causing the NIC interrupt routine to get held up for long > periods of time. It has to be another interrupt. > > All reporters of this problem (ie: both of them) were using > aic7xx SCSI. I wonder if that driver can sometimes spend a > long time in its interrupt routine. Many times. Rapidly. > > Very odd. > > Ah. SMP. Perhaps the other CPU is generating the transmit > load, some other interrupt source is slowing down *this* > CPU. > > Could you test something for me? Try *decreasing* the > value of max_interrupt_work. See if that increases > the frequency of the message. Then, it if does, try to > correlate the occurence of the message with some other > form of system activity (especially disk I/O). > > Thanks. > > - - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [3C905x e401]
okay, testing will begin monday (when it's under load). any advice on which value i begin with ? (20 ?) Franois Cami Andrew Morton wrote: Francois Cami wrote: Vibol Hou wrote: ... Apr 17 16:10:12 omega kernel: eth0: Too much work in interrupt, status e401. I got that one too, PC is ASUS P2B-DS with two PII-350, 384MB RAM, 3C905B. If you were getting this message occasionally, and if increasing the max_interrupt_work module parm makes it stop, and everything is always working fine, then it's an OK thing to do. Question is: why is it happening? We're failing to get out of the interrupt loop after 32 loops. Each loop can reap up to 16 transmitted packets and 32 received packets. That's a lot. My suspicion is that something else in the system is causing the NIC interrupt routine to get held up for long periods of time. It has to be another interrupt. All reporters of this problem (ie: both of them) were using aic7xx SCSI. I wonder if that driver can sometimes spend a long time in its interrupt routine. Many times. Rapidly. Very odd. Ah. SMP. Perhaps the other CPU is generating the transmit load, some other interrupt source is slowing down *this* CPU. Could you test something for me? Try *decreasing* the value of max_interrupt_work. See if that increases the frequency of the message. Then, it if does, try to correlate the occurence of the message with some other form of system activity (especially disk I/O). Thanks. - - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re:
Vibol Hou wrote: > > Hi, > > I'm using 2.4.4-pre3 and get this message occasionally when the system is > loaded: > > Apr 17 16:10:12 omega kernel: eth0: Too much work in interrupt, status e401. > Apr 17 16:10:12 omega kernel: eth0: Too much work in interrupt, status e401. I got that one too, PC is ASUS P2B-DS with two PII-350, 384MB RAM, 3C905B. I've tried 3C905C to no avail. The e401 status seems to be that there is too much load on the card to be treated in the 20 (2.2.17) or 32 (2.2.19, 2.4.x) loops of the interruption check routine (stop/hit me if i'm wrong please). I think we should try (MM. Donald Becker or Andrew Norton, is this a Bad Thing ?) to change max_interrupt_work (3c59x.c, row 171) to 64 or maybe even higher. Haven't had the guts to try on the production machine right now =) > The nic is a 3Com 3c905B. Is this a bad thing? I heard they work fine... François Cami There And Back Again - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re:
Vibol Hou wrote: Hi, I'm using 2.4.4-pre3 and get this message occasionally when the system is loaded: Apr 17 16:10:12 omega kernel: eth0: Too much work in interrupt, status e401. Apr 17 16:10:12 omega kernel: eth0: Too much work in interrupt, status e401. I got that one too, PC is ASUS P2B-DS with two PII-350, 384MB RAM, 3C905B. I've tried 3C905C to no avail. The e401 status seems to be that there is too much load on the card to be treated in the 20 (2.2.17) or 32 (2.2.19, 2.4.x) loops of the interruption check routine (stop/hit me if i'm wrong please). I think we should try (MM. Donald Becker or Andrew Norton, is this a Bad Thing ?) to change max_interrupt_work (3c59x.c, row 171) to 64 or maybe even higher. Haven't had the guts to try on the production machine right now =) The nic is a 3Com 3c905B. Is this a bad thing? I heard they work fine... Franois Cami There And Back Again - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.3 - Module problems?
hi Matthew and everyone I use a 3COM Etherlink III ISA and a 3C905C PCI in my firewall box (i440BX mobo). (distro is slackware 7.1, kernels are either 2.2.19 or 2.4.3, modutils 2.3.1 (slackware 7.1 default) ). The 3C905C was never a problem (and i guess your R8029 isn't either), however to make the 3C509 ISA work, I had to disable PnP in the card's firmware, with 3COM tools : see http://www.3com.com/products/html/prodlist.html?family=570=20=download=cat=Network%20Interface%20Cards%20%26%20Adapters to download the DOS tools to configure your card without PnP, i.e. manually assigning an IRQ and address to it. You'll have to declare to your BIOS that this particular IRQ is taken by a non-PNP ISA card too. Now it works well, whether i use a separate module or build the module into the kernel. I hope that helps. François CAMI (new to the list) [EMAIL PROTECTED] "Matthew W. Lowe" wrote: > > Hey, Thanks for all the help everyone. So far this is my exact > configuration: > Two NICs, 3COM Etherlink III ISA, Realtek 8029 PCI (Covered by the > NE2000 PCI module). Both cards are setup for PnP, the modules have been > built into the kernel. (It worked in my old version with them build into > the kernel.) > > I have upgraded to the latest modutils, and it appeared to fix the > problem with the 3COM Etherlink III card. > > Alan Cox: > You mentioned turning PnP off if I was building the modules into the > kernel? Is there something in the later versions of the kernel that is > setup like that, or ?? (** didn't quite understand what you meant **) > > Thanks, >Matt > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.3 - Module problems?
hi Matthew and everyone I use a 3COM Etherlink III ISA and a 3C905C PCI in my firewall box (i440BX mobo). (distro is slackware 7.1, kernels are either 2.2.19 or 2.4.3, modutils 2.3.1 (slackware 7.1 default) ). The 3C905C was never a problem (and i guess your R8029 isn't either), however to make the 3C509 ISA work, I had to disable PnP in the card's firmware, with 3COM tools : see http://www.3com.com/products/html/prodlist.html?family=570cat=20pathtype=downloadtab=catselcat=Network%20Interface%20Cards%20%26%20Adapters to download the DOS tools to configure your card without PnP, i.e. manually assigning an IRQ and address to it. You'll have to declare to your BIOS that this particular IRQ is taken by a non-PNP ISA card too. Now it works well, whether i use a separate module or build the module into the kernel. I hope that helps. Franois CAMI (new to the list) [EMAIL PROTECTED] "Matthew W. Lowe" wrote: Hey, Thanks for all the help everyone. So far this is my exact configuration: Two NICs, 3COM Etherlink III ISA, Realtek 8029 PCI (Covered by the NE2000 PCI module). Both cards are setup for PnP, the modules have been built into the kernel. (It worked in my old version with them build into the kernel.) I have upgraded to the latest modutils, and it appeared to fix the problem with the 3COM Etherlink III card. Alan Cox: You mentioned turning PnP off if I was building the modules into the kernel? Is there something in the later versions of the kernel that is setup like that, or ?? (** didn't quite understand what you meant **) Thanks, Matt - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
