Re: e100 latency, cpu cycle saver and e1000...

[Corey Minyard]

My little program was crude at best.

You have to take into account what the machines are doing.  If you
notice, the "Min" latency is about the same, so it's not a CPU cycle
saver.  The long "Max" latencies mean you probably have something on IP2
that is blocking the execution of the IP stack (for, say up to 4.5ms). 
Are all the machine completely quiesced except for the test program? 
Have you tried switching the network connections to see if it is in the
network hardware?

-Corey

Paul Rolland wrote:

>Hello,
>
>A few days ago, there was a thread about e100 latency related to
>CPU Cycle Saver...
>
>Suggestion was to disabled it to return back to some "standard"
>latency.
>
>At the moment, I'm experiencing some strange behavior, not with
>an e100 but with an e1000 on a 2.4.20 kernel...
>
>Here are some traces, using Corey Minyard test application :
>
>[root@IP3 tmp]# ./test IP1 32000 10000 370
>Average: 201us, Max: 631us, Min: 200us
>[root@IP3 tmp]# ./test IP2 32000 10000 370
>Average: 422us, Max: 47581us, Min: 209us
>
>All three machines are using 2.4.20 and e1000 drivers, they are
>the same hardware.
>
>But, definitely, IP2 is exhibiting much higher max latency...
>
>Increasing the packet size up to 1200 bytes doesn't change the 
>global behavior : IP2 is always much "latent" than IP1...
>
>The problem is that it seems there is no CPU Cycle Saver on e1000
>NIC. Is there some equivalent ? Could someone give a guess on
>what's going on ?
>
>Regards,
>Paul
>
>-
>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>the body of a message to [e-mail]
>More majordomo info at  http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at  http://www.tux.org/lkml/
>  
>