[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference 7.286::fddi

Title:FDDI - The Next Generation
Moderator:NETCAD::STEFANI
Created:Thu Apr 27 1989
Last Modified:Thu Jun 05 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:2259
Total number of notes:8590

1779.0. "Increasing Token Rotation Timer" by 42498::BALDAR () Tue Aug 15 1995 11:42

    I have a user with Silicon graphics systems connected to the FDDI ring
    and DEChub900.
    The are suffering performance problems on there backups.
    Silicon Graphics have request that the Token Rotation Timer be 
    increased on the DEChub900 and DECconcentrator.
    They are currently set to 7.987 ms. What effect would increasing this
    value to 168 ms as requested by Silicon Graphics.
    
    I am also looking for the  (DEC-TR-655) Technical Report on FDDI
    performance. Note 29.4 locates it at
    FILES::NET$ARCH:[PAPERS]FDDI_PERF.PS
    but can't find it.
    
    Thanks Araz
      
T.RTitleUserPersonal
Name
DateLines
1779.1NETCAD::STEFANIMachines to humanizeTue Aug 15 1995 12:498
    >>They are currently set to 7.987 ms. What effect would increasing this
    >>value to 168 ms as requested by Silicon Graphics.
    
    It doesn't really make sense to increase the MACTReq value, but
    HUBwatch does a good job of allowing you to change this value for your
    DECconcentrator modules.  See your HUBwatch documentation for more info.
    
    /l
1779.2NETCAD::B_CRONINFri Aug 25 1995 10:5937
    
    As usual, the answer is, it depends......
    
    First off, the DECHub 900 does not have an FDDI MAC, so it 
    does not contribute to the setting of TRT. It sounds like 
    there are only 3 nodes in this network, the DECconn 900 and the 
    two SGI machines. 
    
    SGI has long advocated the use of very high TRT values because 
    theoretically the ring's utilization under load increases from
    80% to 90+ % . They ignore the fact that latency also will go up. 
    
    I'm again assuming that there are only 3 nodes in this ring. If 
    you raise T_Req of the concentrator to 168 ms, one of the SGI machines
    will win the claim, and set the value of T_Neg. You will be able
    to see this value via hubwatch, on the FDDI MAC Summary screen.
    When the change is made, T_Neg will change from 7.99 to the value
    determined by the SGI machine. That value will be, effectively,
    the maximum time that they can transmit before having to give up the 
    token. 
    
    Now, if the station has the ring all to itself, all you do is increase
    the number of back to back packets that got out of its transmitter
    before it gives up the token. Since it is effectively the only station 
    that wants the token, it doesn't seem that you will get much of a 
    change in performance. If you do, it may be because of something
    in their adapter besides just the setting of TTRT. 
    
    Its worth trying though, just to see what we can learn about these SGI 
    stations behaviors. Please post the results back here so that we can 
    see what happened. 
    
    If you have an FDDI analyzer, try to get before and after pictures
    of the packets on the wire. I'd be curious to know how many back to
    back packets get transmitted under each condition.