Re: 2.6.12 Performance problems

From: Danial Thom (danial_thom_at_yahoo.com)
Date: 08/25/05

  • Next message: Danial Thom: "Re: Petition for gas grices"
    Date:	Thu, 25 Aug 2005 13:45:08 -0700 (PDT)
    To: Ben Greear <greearb@candelatech.com>
    
    

    --- Ben Greear <greearb@candelatech.com> wrote:

    > Danial Thom wrote:
    >
    > > The tests I reported where on UP systems.
    > Perhaps
    > > the default settings are better for this in
    > 2.4,
    > > since that is what I used, and you used your
    > > hacks for both.
    >
    > My modifications to the kernel are unlikely to
    > speed anything
    > up, and probably will slow things down ever so
    > slightly.
    >
    > I can try with a UP kernel, but my machine at
    > least has a single
    > processor. I'm using the SMP kernel to take
    > advantage of HT.
    >
    > > Are you getting drops or overruns (or both)?
    > I
    > > would assume drops is a decision to drop
    > rather
    > > than an overrun which is a ring overrun.
    > Overruns
    > > would imply more about performance than
    > tuning,
    > > I'd think.
    >
    > I was seeing lots of NIC errors...in fact, it
    > was showing a great many
    > more errors than packets sent to it, so I just
    > ignored them.
    >
    > I increased the TxDescriptors and RxDescriptors
    > and that helped a little.
    >
    > Increasing the transmit queue for the NIC to
    > 2000 also helped a little.
    >
    > > I wouldn't think that HT would be appropriate
    > for
    > > this sort of setup...?
    >
    > 2.6.11 seems to be faster when running SMP
    > kernel on this system.

    HT and SMP are not the same animal, are they? My
    understanding is that an HT aware scheduler is
    likely to make things worse most of the time,
    particularly for systems not running a lot of
    threads..

    > >
    > > You're using a dual PCI-X NIC rather than the
    > > onboard ports? Supermicro runs their onboard
    >
    > Of course. Never found a motherboard yet with
    > decent built-in
    > NICs. The built-ins on this board are tg3 and
    > they must be on
    > a slow bus, because they cannot go faster than
    > about 700Mbps
    > (using big pkts).

    If its the P8SCI or the same design they are on a
    1X PCIE thats shared with the PCI-X. Pretty hokey
    stuff. Its also a low-end controller amongst the
    broadcom parts.

    Danial

                    
    ____________________________________________________
    Start your day with Yahoo! - make it your home page
    http://www.yahoo.com/r/hs
     
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/


  • Next message: Danial Thom: "Re: Petition for gas grices"

    Relevant Pages

    • Re[2]: reproducible watchdog timeout in bge
      ... JR> device = 'BCM5750A1 NetXtreme Gigabit Ethernet PCI Express' ... JR> The only issue I have seen using these NICs in 6.2R is if I nail up the ... SMP and APIC kernel. ...
      (freebsd-net)
    • Re: [opensuse] unable to access website after 10.2 install
      ... Default IS a SMP. ... Its the same kernel. ... On smp hardware it runs smp, on single processor ... another machine 32bit with old nics, ...
      (SuSE)
    • 2.6.12-rc5-mm2 bug report
      ... stable smp machine has gone a little less stable after I installed some more ... Reiser4 demanded the use of -mm branch of kernel. ... Jun 4 19:32:26 router vmunix: PREEMPT SMP ... # Performance-monitoring counters support ...
      (Linux-Kernel)
    • Re: [GIT PATCH] ACPI patches for 2.6.25-rc0 (#2)
      ... ACPI: add newline to printk ... SMP ... Kernel panic - not syncing: ... # Infrared-port device drivers ...
      (Linux-Kernel)
    • Re: [FreeBSD 5.3 STABLE/RC2] SMP crashes
      ... While compiling ATLAS library and working with some other applications, ... With SMP disabled, the box was now stable for over 7 days, also under heavy load. ... > I was in good luck taking the panic kernel report. ... > resetting SCSI bus! ...
      (comp.unix.bsd.freebsd.misc)