I'm having issues with horizontal lines and slow redraws on my SunRay
2FS. I'm running Sun V440s, have very few customers using the system
at this time, and the performance (slow draw and horizontal lines) are
unacceptable. The SunRays are on a LAN, and have zero WAN clients at
this time.

I been doing quite a bit a research and think I have my issue narrowed
down to the SunRay MTU (http://blogs.sun.com/ThinkThin/entry/
the_importance_of_mtu). I performed the ping test described in the
blog, and have determined that my MTU should be 1366 rather than 1500.

The blog says to change Option 23 on the DHCP server (I'm running a
Windows 2003 Server with DHCP) to reflect the adjusted MTU. I found
the Option, but the field will not accept 1366 or 0x556. It says it'll
only take values between 0 - 255 or it's hex equivalent.

Any suggestions?

kfhutch26@gmail.com writes:

>I'm having issues with horizontal lines and slow redraws on my SunRay
>2FS. I'm running Sun V440s, have very few customers using the system
>at this time, and the performance (slow draw and horizontal lines) are
>unacceptable. The SunRays are on a LAN, and have zero WAN clients at
>this time.

What type of switches and network cards are you using?

You are dropping network packets between the V440 and the
SunRay 2FS.

>I been doing quite a bit a research and think I have my issue narrowed
>down to the SunRay MTU (http://blogs.sun.com/ThinkThin/entry/
>the_importance_of_mtu). I performed the ping test described in the
>blog, and have determined that my MTU should be 1366 rather than 1500.

Why? (Typically everything is 1500 on a local network)

>The blog says to change Option 23 on the DHCP server (I'm running a
>Windows 2003 Server with DHCP) to reflect the adjusted MTU. I found
>the Option, but the field will not accept 1366 or 0x556. It says it'll
>only take values between 0 - 255 or it's hex equivalent.

That sounds like the value of the option, not the option itself
(it should be an integer)

Check that switches and Suns/Sun Ray are all using 100FDX (typically
they negotiate correctly but if you force one link partner to
FDX the other will use half-duplex unless it is also configured)

It might also be that you are using Gbe from the V440 and in that case
your switch needs to be able to buffer sufficent packets.

Casper
--
Expressed in this posting are my opinions. They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.

Casper, Thanks for the help. I think I've answered most of your
questions.

What type of switches and network cards are you using?
Cisco 6509 with 100Mb modules running fiber to the SunRay MTRJ ports.


Why? (Typically everything is 1500 on a local network)
I tried running a ping test from several areas in the network (with a
few different laptops). I had failures between my laptop and the V440s
when sending a packet at 1500 bytes and not allowing the packet to
fragment.


That sounds like the value of the option, not the option itself (it
should be an integer):
Any clue what value would equal 1366?


Check that switches and Suns/Sun Ray are all using 100FDX (typically
they negotiate correctly but if you force one link partner to FDX the
other will use half-duplex unless it is also configured)
When I took over this project, I noticed they had it miss configured
with half duplex. My Cisco guy went back reconfigured it for full
duplex. I'll go back and double check to ensure he correctly
configured the router.



It might also be that you are using Gbe from the V440 and in that case
your switch needs to be able to buffer sufficent packets.
I'm hoping the Cisco 6509 can handle the buffer. I'll have my guy
check to see if the buffer is having some problems handling the
traffic.



If you have any other suggestions or questions, I'll be monitoring.
Its driving me crazy.



On Sep 30, 3:30*pm, Casper H.S. Dik wrote:
> kfhutc...@gmail.com writes:
> >I'm having issues with horizontal lines and slow redraws on my SunRay
> >2FS. I'm running Sun V440s, have very few customers using the system
> >at this time, and the performance (slow draw and horizontal lines) are
> >unacceptable. The SunRays are on a LAN, and have zero WAN clients at
> >this time.
>
> What type of switches and network cards are you using?
>
> You are dropping network packets between the V440 and the
> SunRay 2FS.
>
> >I been doing quite a bit a research and think I have my issue narrowed
> >down to the SunRay MTU (http://blogs.sun.com/ThinkThin/entry/
> >the_importance_of_mtu). *I performed the ping test described in the
> >blog, and have determined that my MTU should be 1366 rather than 1500.
>
> Why? *(Typically everything is 1500 on a local network)
>
> >The blog says to change Option 23 on the DHCP server (I'm running a
> >Windows 2003 Server with DHCP) *to reflect the adjusted MTU. I found
> >the Option, but the field will not accept 1366 or 0x556. It says it'll
> >only take values between 0 - 255 or it's hex equivalent.
>
> That sounds like the value of the option, not the option itself
> (it should be an integer)
>
> Check that switches and Suns/Sun Ray are all using 100FDX (typically
> they negotiate correctly but if you force one link partner to
> FDX the other will use half-duplex unless it is also configured)
>
> It might also be that you are using Gbe from the V440 and in that case
> your switch needs to be able to buffer sufficent packets.
>
> Casper
> --
> Expressed in this posting are my opinions. *They are in no way related
> to opinions held by my employer, Sun Microsystems.
> Statements on Sun products included here are not gospel and may
> be fiction rather than truth.

kfhutch26@gmail.com writes:

>Casper, Thanks for the help. I think I've answered most of your
>questions.

>What type of switches and network cards are you using?

>Cisco 6509 with 100Mb modules running fiber to the SunRay MTRJ ports.

Any dropped packets (the Cisco should keep a count)

And the V440 is also using a 100 FDX? (Check that the Cisco
and the Sun all negotiate and that they don't "force"
FDX. The Sun Ray requires the switch to negotiate
(except with newer firmware)


>Why? (Typically everything is 1500 on a local network)
>I tried running a ping test from several areas in the network (with a
>few different laptops). I had failures between my laptop and the V440s
>when sending a packet at 1500 bytes and not allowing the packet to
>fragment.

That may not a proper test; the "ping" adds a IP header; or did
you make sure that both are sending 1500 byte packets (including
the IP header)


>That sounds like the value of the option, not the option itself (it
>should be an integer):
>Any clue what value would equal 1366?


>Check that switches and Suns/Sun Ray are all using 100FDX (typically
>they negotiate correctly but if you force one link partner to FDX the
>other will use half-duplex unless it is also configured)
>When I took over this project, I noticed they had it miss configured
>with half duplex. My Cisco guy went back reconfigured it for full
>duplex. I'll go back and double check to ensure he correctly
>configured the router.

Ah, if they are configured for "half-duplex" then most
systems will work in half-duplex and it would actually work.

If you configure the cisco to "force full duplex", then anything
connected to them will use "half-duplex" because that is the
default if no negotiation is used.

Also, check the the Gbe interface is using flow control.

(I recently found that my software had flow control disabled;
it gave pretty much what you described)

Casper
--
Expressed in this posting are my opinions. They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.

Casper H.S. Dik wrote:
> That may not a proper test; the "ping" adds a IP header; or did you
> make sure that both are sending 1500 byte packets (including the IP
> header)

Indeed, and an ICMP header of IIRC 8 bytes, so the maximum payload
before IP fragmenation (assuming no IPv4 options) would match that for
UDP or 1472 bytes.

> >Check that switches and Suns/Sun Ray are all using 100FDX (typically
> >they negotiate correctly but if you force one link partner to FDX the
> >other will use half-duplex unless it is also configured)

That is the way autoneg is supposed to work - hardcoding causes
autoneg to "fail" and when autoneg "fails" the side trying to autoneg
is required by the spec to use half-duplex on the presumtion it is
communicating with a peer which can only do half-duplex.

> >When I took over this project, I noticed they had it miss
> >configured with half duplex. My Cisco guy went back reconfigured it
> >for full duplex. I'll go back and double check to ensure he
> >correctly configured the router.

> Ah, if they are configured for "half-duplex" then most systems will
> work in half-duplex and it would actually work.

> If you configure the cisco to "force full duplex", then anything
> connected to them will use "half-duplex" because that is the default
> if no negotiation is used.

To expand on that a bit

How 100Base-T Autoneg is supposed to work:

When both sides of the link are set to autoneg, they will "negotiate"
the duplex setting and select full-duplex if both sides can do
full-duplex.

If one side is hardcoded and not using autoneg, the autoneg process
will "fail" and the side trying to autoneg is required by spec to use
half-duplex mode.

If one side is using half-duplex, and the other is using full-duplex,
sorrow and woe is the usual result.

So, the following table shows what will happen given various settings
on each side:

Auto Half Full

Auto Happiness Lucky Sorrow

Half Lucky Happiness Sorrow

Full Sorrow Sorrow Happiness

Happiness means that there is a good shot of everything going well.
Lucky means that things will likely go well, but not because you did
anything correctly Sorrow means that there _will_ be a duplex
mis-match.

When there is a duplex mismatch, on the side running half-duplex you
will see various errors and probably a number of _LATE_ collisions
("normal" collisions don't count here). On the side running
full-duplex you will see things like FCS errors. Note that those
errors are not necessarily conclusive, they are simply indicators.

Further, it is important to keep in mind that a "clean" ping (or the
like - eg "linkloop" or default netperf TCP_RR) test result is
inconclusive here - a duplex mismatch causes lost traffic _only_ when
both sides of the link try to speak at the same time. A typical ping
test, being synchronous, one at a time request/response, never tries
to have both sides talking at the same time.

Finally, when/if you migrate to 1000Base-T, everything has to be set
to auto-neg anyway.

--
Process shall set you free from the need for rational thought.
these opinions are mine, all mine; HP might not want them anyway...
feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...