Tarjei,

> The netware server is not supposed to do any ACKs at all.
> All data flows from the networker client to networker server.
> It is the server which do all acks.

Our snoop output says differently:

11:32:37.55209 server -> client TCP D=1005 S=9558 Ack=735426830
Seq=1248054096 Len=0 Win=27892
11:32:37.55211 server -> client TCP D=1005 S=9558 Ack=735429750
Seq=1248054096 Len=0 Win=24972
11:32:37.55214 server -> client TCP D=1005 S=9558 Ack=735430938
Seq=1248054096 Len=0 Win=32120
11:32:37.55215 client -> server TCP D=9558 S=1005 Push Ack=1248054096
Seq=735430938 Len=1112 Win=8992
11:32:37.55232 client -> server TCP D=893 S=893 Push Ack=1228575133
Seq=1611392463 Len=26 Win=6144
11:32:37.60006 server -> client TCP D=893 S=893 Ack=1611392489
Seq=1228575133 Len=0 Win=49640
11:32:37.60008 server -> client TCP D=1005 S=9558 Ack=735432050
Seq=1248054096 Len=0 Win=31008
11:32:37.62059 client -> server TCP D=9558 S=1005 Push Ack=1248054096
Seq=735432050 Len=132 Win=8992
11:32:37.62066 client -> server TCP D=9558 S=1005 Ack=1248054096
Seq=735432182 Len=1460 Win=8992
11:32:37.62069 client -> server TCP D=9558 S=1005 Ack=1248054096
Seq=735433642 Len=1460 Win=8992

The backup stream is running between ports 1005 and 9558. This traffic
is OK. It is the traffic on port 893 (in the above example) that I
believe to be _our_ problem. This traffic is only present on backups
initiated at the networker server. If we start the backup from the
NetWare client, there is no extra traffic and your statement that "The
netware server is not supposed to do any ACKs at all" is correct.

As you can see, Solaris delays the ACK for ~50ms. This kills our
performance. All along this has looked like a delayed ack issue,
especially since the delay is ~50ms and our networker server's
tcp_deferred_ack_interval is 50ms. Setting tcp_deferred_ack_interval to
1ms did not improve things. It was only this morning after reading

  http://www.sun.com/solutions/blueprints/0203/817-1657.pdf

that I realized that setting tcp_deferred_ack_interval to 1 does not
disable delayed acknowledgement. The proper way to do this is to set
tcp_deferred_acks_max to 1. Needless to say, I will be trying this shortly.

Also, an apology of sorts. I had written a lengthy email describing our
problem and its current state, but I have just realized that due to
operator error, it did not get posted to the list. My first reply to you
was based on my assumption that you had read my lengthy post.

ajs



Tarjei.Jensen AT akerkvaerner DOT com wrote:

Tony Skalski wrote:

Based on our testing, I'd have to disagree. We setup a brand
new SunFire V480 (Solaris 9) and a new NetWare server (using
an Intel server motherboard) connected them with a crossover
cable and we see terrible performance when the backup is
initiated at the Solaris server. When started from NetWare,
performance rocks.

At least in our case, we believe the poor performance is due
to delays ACKing packets sent from the NetWare box.

The netware server is not supposed to do any ACKs at all. All data flows
from the networker client to networker server. It is the server which do all
acks.

It might be that the gigE card on the netware server does not forward the
ACK packet to the netware tcp/ip stack in a timely manner. I'm not sure if
that is a likely scenario.


greetings,

--
Tony Skalski
Systems Administrator
507-646-3227
ajs AT stolaf DOT edu
-------------------------------------------------------
St. Olaf College                   1510 St. Olaf Avenue
Information and                          Northfield, MN
Instructional Technologies                   55057-1097
=======================================================

--
Note: To sign off this list, send a "signoff networker" command via email
to listserv AT listmail.temple DOT edu or visit the list's Web site at
http://listmail.temple.edu/archives/networker.html where you can
also view and post messages to the list.
=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=