[lkml]   [2004]   [Jul]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: gigabit trouble
    You are aware that this is a celeron at 400 mhz, and not whatever 400
    is or possibly isn't in that annoying new naming scheme? (Just

    Both systems are not overclocked, so are stable in that respect. The
    nonbooting thing was a loose ground wire touching my hard drive
    jumpers, making it think it was a slave. I'm surprised winxp managed
    to do anything at all. I've used both these systems for ages, never
    had any real trouble except for the strange pci slot/irq problems in
    my new computer, but that was mostly a work-or-not thing - although it
    also increases pci latency. I'm still not sure whether it's a card
    that's in there, a card that was in there, (I replaced my sound card,
    and can suddently get a much lower midi-to-wave playing latency - but
    the sound card has been known to click and pop randomly over several
    reconfigurations the last few days) or just a screwy motherboard. I
    should hope it's not the last, it's a brand board.

    Anyhow, on transmit from the celeron box, under extreme benchy
    circumstrances, I've seen it around 16Kints/s on transmit and 13k on
    receive. But under everyday nfs/samba, 6400 is about the best it does
    either way.

    The maximum amount of interrupts/s I've seen so far 22302 (including
    the 1000 in the kernel timer, 'course). Nothing much else changes,
    except the context switches raising from an idle 10~30 to 1000~1500
    to, sometimes 30000. Actually, using netio seems to busy the system

    # top -d 0.5 | grep Cpu\(
    Cpu(s): 8.8% us, 36.8% sy, 0.0% ni, 1.5% id, 0.0% wa, 13.2% hi, 39.7% si
    Cpu(s): 7.5% us, 38.8% sy, 0.0% ni, 0.0% id, 0.0% wa, 14.9% hi, 38.8% si
    Cpu(s): 5.7% us, 41.4% sy, 0.0% ni, 0.0% id, 0.0% wa, 14.9% hi, 37.9% si
    Cpu(s): 5.0% us, 44.0% sy, 0.0% ni, 0.0% id, 0.0% wa, 14.5% hi, 36.5% si
    Cpu(s): 4.4% us, 50.5% sy, 0.0% ni, 1.1% id, 0.0% wa, 12.1% hi, 31.9% si
    Cpu(s): 3.8% us, 50.9% sy, 0.0% ni, 0.0% id, 0.0% wa, 17.0% hi, 28.3% si

    But a to-winxp smb file transfer, hangin around 7, 8MB/s, doesn't:
    Cpu(s): 3.8% us, 50.0% sy, 0.0% ni, 17.9% id, 0.0% wa, 7.5% hi, 20.8% si
    Cpu(s): 5.0% us, 43.0% sy, 0.0% ni, 27.0% id, 0.0% wa, 7.0% hi, 18.0% si
    Cpu(s): 4.8% us, 40.4% sy, 0.0% ni, 29.8% id, 0.0% wa, 5.8% hi, 19.2% si
    Cpu(s): 5.1% us, 43.9% sy, 0.0% ni, 26.5% id, 0.0% wa, 5.1% hi, 19.4% si
    Cpu(s): 5.3% us, 42.5% sy, 0.0% ni, 26.5% id, 0.0% wa, 6.2% hi, 19.5% si
    Cpu(s): 5.9% us, 43.1% sy, 0.0% ni, 25.5% id, 1.0% wa, 5.9% hi, 18.6% si
    Cpu(s): 4.6% us, 41.7% sy, 0.0% ni, 25.9% id, 0.0% wa, 5.6% hi, 22.2% si
    Cpu(s): 6.2% us, 44.6% sy, 0.0% ni, 23.2% id, 0.0% wa, 5.4% hi, 20.5% si
    Cpu(s): 4.2% us, 34.7% sy, 0.0% ni, 38.9% id, 0.0% wa, 5.3% hi, 16.8% si

    It's not too consistent all over either; windows netio transmits
    slowly when packet sizes are >1k (the mtu?), as low as 5MB/s, while
    the receive speed for the same packet size goes at ~22MB

    Ooh, finally, a proper kernel pan --er, bug, it says. On my old
    computer this time.
    I know, incidentally, that the memory works; I recently did a three-hour memtest
    on this computer. Picture here:

    This may be due to fiddling with said wmem, etc values, I set some of them
    considerably larger. I did get a few percent apparent speed increase,
    incidentally, though that may have been wishful thinking.

    I guess I should try >= 2.6.8-rc2-mm1 next?

    --Bart Alewijnse
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 14:04    [W:0.026 / U:11.476 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site