Any TCP Experts to Help With Performance Problems Printing to JetDirect?

I have a user on a subnet that prints by TCP to a JetDirect device that is
hooked to a USB printer. From her old computer, which has a built in
10/100 ethernet card, everything works fine. On her new computer, which
uses a Broadcom gigabit ethernet adapter, the print operation that used to
take five seconds now takes five minutes, consistently. The old computer
is on the same subnet as the JetDirect box. The new computer is on a
different subnet, connected by gigabit ethernet to a firewall that connects
into the JetDirect device on a separate subnet. The old client computer
that is fast runs Windows 2000 and the new computer that is slow runs
Windows 2003.

I tried several experiments including replacing her local ethernet switch,
her local ethernet cables, and installing a new/different gigabit ethernet
card, with the identical result.

I started the sniffer on the new computer that is not working correctly, and
what I see looks like the following. Her machine is O and the destination
Jetdirect device is J:

O: SYN // window size at 64512 and max segment size 1460
J: SYN,ACK // window size at 65532 and max segment size 1460
bytes...increased window size may be from the firewall in between rather
than endpoint
O: ACK

O: PSH,ACK // one to 104 bytes per transmit
J: ACK // I see one ACK for every transmit

The PSH,ACK followed by ACK repeats indefinitely for five minutes, followed
by a normal FIN,ACK and ACK at the end. The PSH,ACK is sending one byte to
nine bytes for the first few, and then finally goes to 104 bytes per
transmit. What's key in the above, is that every PSH,ACK is met with an
ACK, an exact one for one, and the data transmission size of 104 bytes is
far below the maximum transmit of 1460 allowed by either end of the
connection.

Now I do the same thing on the old computer that works quickly, and once we
get beyond the setup, it's remarkably different. What we see are seven
transmits all at once, followed by a single ACK, as follows:

O: SYN // window size reported at 64512 and max segment size 1460
bytes
J: SYN,ACK // window size reported at 11680 and max segment size 1460
bytes...reduced window because there is no firewall between end points
O: ACK

O: PSH,ACK // 1460 bytes
O: PSH,ACK // 1460 bytes
O: PSH,ACK // 1460 bytes
O: PSH,ACK // 1460 bytes
O: PSH,ACK // 1460 bytes
O: PSH,ACK // 1460 bytes
O: PSH,ACK // 1460 bytes
J: ACK // so one ACK for every seven large transmits

So the traffic pattern here shows that on the computer that prints quickly,
there are larger packets being sent, and they are being batched up together
with seven transmits for each ACK.

On the slow computer, the data sizes are being kept very trivial in size
(104 bytes) and each transmit is being forced to wait on an ACK.

Can anyone see the possible causes for this problem and suggest how we might
fix them? Obviously the introduction of the firewall between the two
endpoints is creating some performance issues. Given the firewall
(ISA Server 2004) is running on gigabit ethernet cards, I'm quite surprised
to see it impacting performance this way.

--
Will




Will

Just a follow up on the original thread: if we put the new system and
Jetdirect on the same subnet, printing is fast.

So it's the ISA 2004 firewall, or one of its cards, or a device driver on
the firewall, that appears to be introducing the changed behavior as seen in
the sniffer trace.

--
Will

"Will" <westes-(E-Mail Removed)> wrote in message
news:0eudnfULcdb1WavbnZ2dnUVZ_s-(E-Mail Removed)...
>I have a user on a subnet that prints by TCP to a JetDirect device that is
> hooked to a USB printer. From her old computer, which has a built in
> 10/100 ethernet card, everything works fine. On her new computer, which
> uses a Broadcom gigabit ethernet adapter, the print operation that used to
> take five seconds now takes five minutes, consistently. The old
> computer
> is on the same subnet as the JetDirect box. The new computer is on a
> different subnet, connected by gigabit ethernet to a firewall that
> connects
> into the JetDirect device on a separate subnet. The old client computer
> that is fast runs Windows 2000 and the new computer that is slow runs
> Windows 2003.
>
> I tried several experiments including replacing her local ethernet switch,
> her local ethernet cables, and installing a new/different gigabit ethernet
> card, with the identical result.
>
> I started the sniffer on the new computer that is not working correctly,
> and
> what I see looks like the following. Her machine is O and the
> destination
> Jetdirect device is J:
>
> O: SYN // window size at 64512 and max segment size 1460
> J: SYN,ACK // window size at 65532 and max segment size 1460
> bytes...increased window size may be from the firewall in between rather
> than endpoint
> O: ACK
>
> O: PSH,ACK // one to 104 bytes per transmit
> J: ACK // I see one ACK for every transmit
>
> The PSH,ACK followed by ACK repeats indefinitely for five minutes,
> followed
> by a normal FIN,ACK and ACK at the end. The PSH,ACK is sending one byte
> to
> nine bytes for the first few, and then finally goes to 104 bytes per
> transmit. What's key in the above, is that every PSH,ACK is met with an
> ACK, an exact one for one, and the data transmission size of 104 bytes is
> far below the maximum transmit of 1460 allowed by either end of the
> connection.
>
> Now I do the same thing on the old computer that works quickly, and once
> we
> get beyond the setup, it's remarkably different. What we see are seven
> transmits all at once, followed by a single ACK, as follows:
>
> O: SYN // window size reported at 64512 and max segment size
> 1460
> bytes
> J: SYN,ACK // window size reported at 11680 and max segment size 1460
> bytes...reduced window because there is no firewall between end points
> O: ACK
>
> O: PSH,ACK // 1460 bytes
> O: PSH,ACK // 1460 bytes
> O: PSH,ACK // 1460 bytes
> O: PSH,ACK // 1460 bytes
> O: PSH,ACK // 1460 bytes
> O: PSH,ACK // 1460 bytes
> O: PSH,ACK // 1460 bytes
> J: ACK // so one ACK for every seven large transmits
>
> So the traffic pattern here shows that on the computer that prints
> quickly,
> there are larger packets being sent, and they are being batched up
> together
> with seven transmits for each ACK.
>
> On the slow computer, the data sizes are being kept very trivial in size
> (104 bytes) and each transmit is being forced to wait on an ACK.
>
> Can anyone see the possible causes for this problem and suggest how we
> might
> fix them? Obviously the introduction of the firewall between the two
> endpoints is creating some performance issues. Given the firewall
> (ISA Server 2004) is running on gigabit ethernet cards, I'm quite
> surprised
> to see it impacting performance this way.
>
> --
> Will
>
>

Perhaps this is redundant, but it does sound like an MTU limitation on
the ISA server. This link may help you get pointed in the right
direction. It tells how to change the MTU setting for your NIC within
the registry.

http://www.isaserver.org/tutorials/I...Fosbenner.html
(Section III covers MTU setting).

I'm not as up on ISA server as I am the network side, but the theory
should be the same for any ethernet-based connection.

Hope this helps!


Brian Crittenden, MS



On May 1, 11:03 pm, "Will" <westes-...@noemail.nospam> wrote:
> Just a follow up on the original thread: if we put the new system and
> Jetdirect on the same subnet, printing is fast.
>
> So it's the ISA 2004 firewall, or one of its cards, or a device driver on
> the firewall, that appears to be introducing the changed behavior as seen in
> the sniffer trace.
>
> --
> Will
>
> "Will" <westes-...@noemail.nospam> wrote in message
>
> news:0eudnfULcdb1WavbnZ2dnUVZ_s-(E-Mail Removed)...
>
>
>
> >I have a user on a subnet that prints by TCP to a JetDirect device that is
> > hooked to a USB printer. From her old computer, which has a built in
> > 10/100 ethernet card, everything works fine. On her new computer, which
> > uses a Broadcom gigabit ethernet adapter, the print operation that used to
> > take five seconds now takes five minutes, consistently. The old
> > computer
> > is on the same subnet as the JetDirect box. The new computer is on a
> > different subnet, connected by gigabit ethernet to a firewall that
> > connects
> > into the JetDirect device on a separate subnet. The old client computer
> > that is fast runs Windows 2000 and the new computer that is slow runs
> > Windows 2003.
>
> > I tried several experiments including replacing her local ethernet switch,
> > her local ethernet cables, and installing a new/different gigabit ethernet
> > card, with the identical result.
>
> > I started the sniffer on the new computer that is not working correctly,
> > and
> > what I see looks like the following. Her machine is O and the
> > destination
> > Jetdirect device is J:
>
> > O: SYN // window size at 64512 and max segment size 1460
> > J: SYN,ACK // window size at 65532 and max segment size 1460
> > bytes...increased window size may be from the firewall in between rather
> > than endpoint
> > O: ACK
>
> > O: PSH,ACK // one to 104 bytes per transmit
> > J: ACK // I see one ACK for every transmit
>
> > The PSH,ACK followed by ACK repeats indefinitely for five minutes,
> > followed
> > by a normal FIN,ACK and ACK at the end. The PSH,ACK is sending one byte
> > to
> > nine bytes for the first few, and then finally goes to 104 bytes per
> > transmit. What's key in the above, is that every PSH,ACK is met with an
> > ACK, an exact one for one, and the data transmission size of 104 bytes is
> > far below the maximum transmit of 1460 allowed by either end of the
> > connection.
>
> > Now I do the same thing on the old computer that works quickly, and once
> > we
> > get beyond the setup, it's remarkably different. What we see are seven
> > transmits all at once, followed by a single ACK, as follows:
>
> > O: SYN // window size reported at 64512 and max segment size
> > 1460
> > bytes
> > J: SYN,ACK // window size reported at 11680 and max segment size 1460
> > bytes...reduced window because there is no firewall between end points
> > O: ACK
>
> > O: PSH,ACK // 1460 bytes
> > O: PSH,ACK // 1460 bytes
> > O: PSH,ACK // 1460 bytes
> > O: PSH,ACK // 1460 bytes
> > O: PSH,ACK // 1460 bytes
> > O: PSH,ACK // 1460 bytes
> > O: PSH,ACK // 1460 bytes
> > J: ACK // so one ACK for every seven large transmits
>
> > So the traffic pattern here shows that on the computer that prints
> > quickly,
> > there are larger packets being sent, and they are being batched up
> > together
> > with seven transmits for each ACK.
>
> > On the slow computer, the data sizes are being kept very trivial in size
> > (104 bytes) and each transmit is being forced to wait on an ACK.
>
> > Can anyone see the possible causes for this problem and suggest how we
> > might
> > fix them? Obviously the introduction of the firewall between the two
> > endpoints is creating some performance issues. Given the firewall
> > (ISA Server 2004) is running on gigabit ethernet cards, I'm quite
> > surprised
> > to see it impacting performance this way.
>
> > --
> > Will- Hide quoted text -
>
> - Show quoted text -

Sounds stupid, but you don't have a duplex mis-match somewhere do you ?

"Will" wrote:

> Just a follow up on the original thread: if we put the new system and
> Jetdirect on the same subnet, printing is fast.
>
> So it's the ISA 2004 firewall, or one of its cards, or a device driver on
> the firewall, that appears to be introducing the changed behavior as seen in
> the sniffer trace.
>
> --
> Will
>
> "Will" <westes-(E-Mail Removed)> wrote in message
> news:0eudnfULcdb1WavbnZ2dnUVZ_s-(E-Mail Removed)...
> >I have a user on a subnet that prints by TCP to a JetDirect device that is
> > hooked to a USB printer. From her old computer, which has a built in
> > 10/100 ethernet card, everything works fine. On her new computer, which
> > uses a Broadcom gigabit ethernet adapter, the print operation that used to
> > take five seconds now takes five minutes, consistently. The old
> > computer
> > is on the same subnet as the JetDirect box. The new computer is on a
> > different subnet, connected by gigabit ethernet to a firewall that
> > connects
> > into the JetDirect device on a separate subnet. The old client computer
> > that is fast runs Windows 2000 and the new computer that is slow runs
> > Windows 2003.
> >
> > I tried several experiments including replacing her local ethernet switch,
> > her local ethernet cables, and installing a new/different gigabit ethernet
> > card, with the identical result.
> >
> > I started the sniffer on the new computer that is not working correctly,
> > and
> > what I see looks like the following. Her machine is O and the
> > destination
> > Jetdirect device is J:
> >
> > O: SYN // window size at 64512 and max segment size 1460
> > J: SYN,ACK // window size at 65532 and max segment size 1460
> > bytes...increased window size may be from the firewall in between rather
> > than endpoint
> > O: ACK
> >
> > O: PSH,ACK // one to 104 bytes per transmit
> > J: ACK // I see one ACK for every transmit
> >
> > The PSH,ACK followed by ACK repeats indefinitely for five minutes,
> > followed
> > by a normal FIN,ACK and ACK at the end. The PSH,ACK is sending one byte
> > to
> > nine bytes for the first few, and then finally goes to 104 bytes per
> > transmit. What's key in the above, is that every PSH,ACK is met with an
> > ACK, an exact one for one, and the data transmission size of 104 bytes is
> > far below the maximum transmit of 1460 allowed by either end of the
> > connection.
> >
> > Now I do the same thing on the old computer that works quickly, and once
> > we
> > get beyond the setup, it's remarkably different. What we see are seven
> > transmits all at once, followed by a single ACK, as follows:
> >
> > O: SYN // window size reported at 64512 and max segment size
> > 1460
> > bytes
> > J: SYN,ACK // window size reported at 11680 and max segment size 1460
> > bytes...reduced window because there is no firewall between end points
> > O: ACK
> >
> > O: PSH,ACK // 1460 bytes
> > O: PSH,ACK // 1460 bytes
> > O: PSH,ACK // 1460 bytes
> > O: PSH,ACK // 1460 bytes
> > O: PSH,ACK // 1460 bytes
> > O: PSH,ACK // 1460 bytes
> > O: PSH,ACK // 1460 bytes
> > J: ACK // so one ACK for every seven large transmits
> >
> > So the traffic pattern here shows that on the computer that prints
> > quickly,
> > there are larger packets being sent, and they are being batched up
> > together
> > with seven transmits for each ACK.
> >
> > On the slow computer, the data sizes are being kept very trivial in size
> > (104 bytes) and each transmit is being forced to wait on an ACK.
> >
> > Can anyone see the possible causes for this problem and suggest how we
> > might
> > fix them? Obviously the introduction of the firewall between the two
> > endpoints is creating some performance issues. Given the firewall
> > (ISA Server 2004) is running on gigabit ethernet cards, I'm quite
> > surprised
> > to see it impacting performance this way.
> >
> > --
> > Will
> >
> >
>
>
>