Re: [patch] Real-Time Preemption, -RT-2.6.10-rc1-mm2-V0.7.1

Mark_H_Johnson_at_raytheon.com
Date: 11/04/04

  • Next message: Greg KH: "Re: [PATCH 2.6.10-rc1 0/4] driver-model: manual device attach"
    To: Ingo Molnar <mingo@elte.hu>
    Date:	Thu, 4 Nov 2004 11:52:22 -0600
    
    

    >Perhaps "should be fine" but the test I just ran indicates otherwise.
    >The kernel is -V0.7.7 plus the patch you just sent me.
    >All IRQ and /# tasks were set to RT priority 99.

    A follow up to my previous message since the test just completed
    with the following results:

    2.6.10-rc1-mm2-RT-V0.7.7
    181 packets lost (5%)
    0.343, 2525.872, 213979, 21685 (min, average, max, deviation)
    elapsed time was 3090 seconds

    There was a burst of lost packets between seq 1777 and 1959,
    that appears to cover all the lost ones. There was also a big
    delay (up to 27305 msec) at seq 1665 through 1699 but no lost
    packets. If I throw out those data points, the max drops to
    something like 1800 msec and the average is in the 0.4 to 0.5
    msec range.

    The display lockup on the top test was a little odd. The window
    that should have shown top appeared blank, stayed on the screen
    for several seconds and then disappeared by itself. Apparently
    top didn't even get enough CPU time to display the first cycle
    before its time ran out. The audio test continued to run a while
    after than & then stopped itself when the script noticed that top
    was done.

    The display lockups on the other tests (network and disk I/O)
    were much less severe though still present at times.

    --Mark H Johnson
      <mailto:Mark_H_Johnson@raytheon.com>

    -
    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: Greg KH: "Re: [PATCH 2.6.10-rc1 0/4] driver-model: manual device attach"

    Relevant Pages

    • Re: Multicast log question
      ... c-quality value drops to 60 percent, and it doesn't go up again for the ... My guess is that when the client lost 13 packets that weren't recoverable ... >> Based on past testing we've found that WMP can only recover one lost packet ...
      (microsoft.public.windowsmedia.server)
    • Re: Determining if it is "safe" to send UDP packets
      ... IMHO for "reliable" UDP you need to use some Quality of service ... Maybe your network is QoS enabled and your traffic gets classified as "below ... > the sender's OS that is throwing the UDP packets away. ... > next 100%-x% are not send, they are almost all completely lost. ...
      (microsoft.public.win32.programmer.kernel)
    • Re: Determining if it is "safe" to send UDP packets
      ... As we are sending on a wireless link (but assuming we are the ... the sender's OS that is throwing the UDP packets away. ... Another problem with TCP is its assumption that a lost packet is due to ...
      (microsoft.public.win32.programmer.kernel)
    • Multicast log anamoly
      ... Unicast retransmission/failback is disabled. ... which always results in lost packets. ... it's able to recover 1 packet out of every 11. ...
      (microsoft.public.windowsmedia.server)