lkml.org 
[lkml]   [2003]   [May]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRE: how to measure scheduler latency on powerpc? realfeel doesn' t work due to /dev/rtc issues
    Date

    > From: Chris Friesen [mailto:cfriesen@nortelnetworks.com]
    >
    > William Lee Irwin III wrote:
    >
    > > I don't understand why you're obsessed with interrupts. Just run your
    > > load and spray the scheduler latency stats out /proc/
    >
    > I'm obsessed with interrupts because it gives me a higher sampling rate.
    >
    > I could set up and itimer for a recurring 10ms timeout and see how much
    extra I
    > waited, but then I can only get 100 samples/sec.
    >
    > With /dev/rtc (on intel) you can get 20x more samples in the same amount
    of time.

    Okay, crazy idea here ...

    You are talking about a bladed system, right? So probably you
    have two network interfaces in there [it should work only with
    one too].

    What if you rip off the driver for the network interface and
    create a new breed. Set an special link with a null Ethernet
    cable and have one machine sending really short Ethernet frames
    to the sampling machine.

    Maybe if you can manage to get the Ethernet chip to interrupt
    every time a new frame arrives, you can use that as a sampling
    measure. I'd say the key would be to have the sending machine
    be really precise about the sending ... I guess it can be worked
    out.

    I don't know how fast an interrupt rate you could get, OTOH
    rough numbers ... let's say 100 MBit/s is 10 MByte/s, use
    a really small frame [let's say a few bytes only, 32], add
    the MACS {I don't remember the frame format, assuming 12 bytes
    for source and destination MACs, plus 8 in overhead [again, I
    made it up], 52 bytes ... let's round up to 64 bytes per frame.

    So

    10 MB/s / 64 B/frame = 163840 frames/s

    I don't know how really possible is this or my calculations
    are screwed up, but it might be worth a try ...

    I did a quick test; from one of my computers, m1, I did:

    m1:~ $ while true; do cat BIGFILE; done | ssh m2 cat > /dev/null

    while on m2, I did:

    m2:~ $ grep eth0 /proc/interrupts; sleep 2m; grep eth0 /proc/interrupts
    18: 77457 68483 IO-APIC-level eth0
    18: 397390 412559 IO-APIC-level eth0
    m2:~ $

    total 319933 + 344076 = 664009
    in 120 seconds ... 664009 / 120 = 5533 Hz ~ 2500 Hz per CPU.

    not bad, wouldn't this work?

    [this is with a 1500 MTU through a hub ... or a switch, I
    don't really know ...]

    Iñaky Pérez-González -- Not speaking for Intel -- all opinions are my own
    (and my fault)

    18: 77457 68483 IO-APIC-level eth0
    18: 397390 412559 IO-APIC-level eth0

    total 319933 + 344076 = 664009
    in 120 seconds ... 664009 / 120 = 5533 Hz ~ 2500 Hz per CPU.

    \
     
     \ /
      Last update: 2005-03-22 13:35    [W:0.028 / U:242.476 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site