Networker

Re: [Networker] Novell NDPS - Slow Backups

2003-10-16 11:10:28
Subject: Re: [Networker] Novell NDPS - Slow Backups
From: "Tarjei T. Jensen" <Tarjei.Jensen AT AKERKVAERNER DOT COM>
To: NETWORKER AT LISTMAIL.TEMPLE DOT EDU
Date: Thu, 16 Oct 2003 16:09:56 +0100
It looks like the server gigE card blindly follows the Window size and does
not honour the TCP PSH (push) flag.

Or there is some funny business with the push on the server side. Notice
that the server ACKs does not have the push bit set. It might be that the
ACKs are delayed in the hope that there will be data to piggyback the ACK
to.

It is of course wrong that the client never sends any acks. It just sends
the same ACK all the time.

In the snip you sendt, the delayed ACKs are in both TCP streams. The (893
893) stream gets ACKed before the (9558 1005).

greetings,


> -----Original Message-----
> From: Tony Skalski [mailto:ajs AT stolaf DOT edu]
> Sent: 16. oktober 2003 16:23
> To: NETWORKER AT LISTMAIL.TEMPLE DOT EDU
> Cc: Jensen, Tarjei KOGAS
> Subject: Re: [Networker] Novell NDPS - Slow Backups
>
>
> 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.
=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=