Eric Roman wrote:
> But when
> we started doing 64 processor runs we got some horrible performance.
> Here's an example:
> 
>  Name Class   NC      Time      Mop/s Mop/s/proc Version Filename
>  CG   A        1     65.91      22.71      22.71     2.3 cg.A.1.egcs3-t3
...
>  CG   A       64     28.72      52.11       0.81     2.3 cg.A.64.egcs3
> 
> Speedup of 2 for 64 processors?  Does this make any sense whatsoever?

        Those benchmarks are used to test the network speed of millions dollars
parallel computers that usually have specially tuned network cards and
protocols. And 100Mb ethernet+TCP/IP network is awful for that because
it has _not_ been designed for it : if an ethernet packet meets another
one on the wire, the ethernet protocols automatically delays new packets
for a random-calculated amound of time. And Ethernet performance drops
to less than 20% of the maximum throughput if you overload it.

        If you want to improve this situation, you may need to try non-ethernet
nic, that are usually a little bit more expensive than ethernet. If you
can't change your network and want to improve performance anyway for
short messages, try the patch from Andrea Arcangeli <[EMAIL PROTECTED]>
that follows :

Index: linux/net/ipv4/tcp_input.c
===================================================================
RCS file: /var/cvs/linux/net/ipv4/tcp_input.c,v
retrieving revision 1.1.1.11
diff -u -r1.1.1.11 tcp_input.c
--- linux/net/ipv4/tcp_input.c  1999/05/16 20:56:05     1.1.1.11
+++ linux/net/ipv4/tcp_input.c  1999/05/21 01:26:02
@@ -1575,6 +1591,25 @@
        }
 }
 
+static __inline__ int tcp_nr_packets_not_acked(int nr, struct sock *
sk,
+                                              struct tcp_opt * tp)
+{
+       int __nr = 0;
+       struct sk_buff * skb = (struct sk_buff *) &sk->receive_queue;
+
+       while ((skb = skb->prev) != (struct sk_buff *)
&sk->receive_queue)
+       {
+               if (TCP_SKB_CB(skb)->end_seq > tp->last_ack_sent)
+               {
+                       if (++__nr >= nr)
+                               return 1;
+               }
+               else
+                       break;
+       }
+       return 0;
+}
+
 /*
  * Check if sending an ack is needed.
  */
@@ -1603,7 +1638,14 @@
            /* We entered "quick ACK" mode or... */
            tcp_in_quickack_mode(tp) ||
            /* We have out of order data */
-           (skb_peek(&tp->out_of_order_queue) != NULL)) {
+           !skb_queue_empty(&tp->out_of_order_queue) ||
+           /*
+            * With TCP_NODELAY we allow at most two not acked packet to
+            * stay in the receive queue to allow better responsiveness
+            * without losing the nice delayed ack feature of merging
the
+            * ack in the next packet sent. -Andrea
+            */
+           (sk->nonagle == 1 && tcp_nr_packets_not_acked(2, sk, tp))) {
                /* Then ack it now */
                tcp_send_ack(sk);
        } else {

Hope it helps,

-- 
Pierre Brua       Parall�lisme & Solutions Linux
PARALLINE Sarl                                mail: [EMAIL PROTECTED]
71, avenue des Vosges  67000 STRASBOURG       http://www.paralline.com
T�l:+33 3 88 14 17 40  Fax:+33 3 88 14 17 41  GSM : 06 16 01 46 65
-
Linux SMP list: FIRST see FAQ at http://www.irisa.fr/prive/mentre/smp-faq/
To Unsubscribe: send "unsubscribe linux-smp" to [EMAIL PROTECTED]

Reply via email to