SunRay 2FS MTU - SUN

This is a discussion on SunRay 2FS MTU - SUN ; 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 ...

+ Reply to Thread
Results 1 to 5 of 5

Thread: SunRay 2FS MTU

  1. SunRay 2FS MTU

    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?

  2. Re: SunRay 2FS MTU

    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.

  3. Re: SunRay 2FS MTU

    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.



  4. Re: SunRay 2FS MTU

    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.

  5. Re: SunRay 2FS MTU

    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...

+ Reply to Thread