[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

919.0. "BIG MPsync-Decnet/FDDI" by COMICS::REYNOLDSJ (Mad Dogs and Englishmen) Mon Apr 05 1993 15:26

    
    
    
    
     
    A customer is finding the following problem with large Decnet file transfers
    over FDDI (eg RSM backups):
    
    The transfer takes around 4 times as long to complete than when it was
    done over an Ethernet circuit. This is a 4-processor 6000 system and is
    seen to be running at around 80% MPsync.
    He is running with a Decnet buffer size for MFA-0 of 1498 and LRPsize
    of 4541 (VMS 5.5-2) as recommended. DEMFA is at v1.4
    
    I take it that you shouldn't *have* to fiddle with pipeline quota or
    number of receive buffers, but maybe this might help?
    
    The ethernet and FDDI interfaces are across a Decbridge from each other
    but Decnet is not started on the ethernet interface and it therefore
    runs with its hard address. No protocols run on both interfaces excpet maybe
    LAV-C which is performing ok.
    
    I don't know how many people out there have DEMFAs on multiprocessor
    systems but this sounds like a big performance hit. I am aware that the
    DEMFAs performance per se isn't as good as the DEMNA (more i/o per
    instruction) but this, I think, is the reason why the DEMFA isnt 'FDDI 
    times faster' than the (ethernet) DEMNA rather than 4 times slower.
    
    Is this a problem with Decnet's interface to FXdriver or is it the fact
    that Decnet happens to generate most traffic during these transfers, so
    really its the DEMFA/FXdriver at issue?
    
    The customer has heard a rumour via info-vax that this could be related
    to the DEMFAs use of buffer I/O and is fixed in VMS version 6.1 ??!
    
    Any comments on this ?
    
    
    John Reynolds, UK CSC, Comms.
    
    
     (cross posted in Decnet-VAX)
    
T.RTitleUserPersonal
Name
DateLines
919.1TAY1 site had same RSM/Backup/FDDI probBNGBNG::BOURGEOISNEI-South ISCTue Apr 06 1993 08:0664

  John,


     When the TAY1 site here in Littleton MA USA moved their 6000-based
    cluster to FDDI to"speed up" their network backups via RSM they saw
    the saem problem.

     I believe it was a problem with RSM. 

     I will track down the fix and let you know here what it was.  Backups
     are now running fine, and faster at the TAY1 site due to FDDI as expected.




        <<< Note 919.0 by COMICS::REYNOLDSJ "Mad Dogs and Englishmen" >>>
                          -< BIG MPsync-Decnet/FDDI >-

    
    
    
    
     
    A customer is finding the following problem with large Decnet file transfers
    over FDDI (eg RSM backups):
    
    The transfer takes around 4 times as long to complete than when it was
    done over an Ethernet circuit. This is a 4-processor 6000 system and is
    seen to be running at around 80% MPsync.
    He is running with a Decnet buffer size for MFA-0 of 1498 and LRPsize
    of 4541 (VMS 5.5-2) as recommended. DEMFA is at v1.4
    
    I take it that you shouldn't *have* to fiddle with pipeline quota or
    number of receive buffers, but maybe this might help?
    
    The ethernet and FDDI interfaces are across a Decbridge from each other
    but Decnet is not started on the ethernet interface and it therefore
    runs with its hard address. No protocols run on both interfaces excpet maybe
    LAV-C which is performing ok.
    
    I don't know how many people out there have DEMFAs on multiprocessor
    systems but this sounds like a big performance hit. I am aware that the
    DEMFAs performance per se isn't as good as the DEMNA (more i/o per
    instruction) but this, I think, is the reason why the DEMFA isnt 'FDDI 
    times faster' than the (ethernet) DEMNA rather than 4 times slower.
    
    Is this a problem with Decnet's interface to FXdriver or is it the fact
    that Decnet happens to generate most traffic during these transfers, so
    really its the DEMFA/FXdriver at issue?
    
    The customer has heard a rumour via info-vax that this could be related
    to the DEMFAs use of buffer I/O and is fixed in VMS version 6.1 ??!
    
    Any comments on this ?
    
    
    John Reynolds, UK CSC, Comms.
    
    
     (cross posted in Decnet-VAX)
    

919.2RSM note related?COMICS::REYNOLDSJMad Dogs and EnglishmenTue Apr 06 1993 10:015
    
    Thanks for the info  - I have checked out NOTED::RSM and found note
    1372  - is this the same problem as the one you saw?
    
    John. 
919.3YUp 1372 is the problemBNGBNG::BOURGEOISNEI-South ISCTue Apr 06 1993 10:2013
RE: .2
    
>>    Thanks for the info  - I have checked out NOTED::RSM and found note
>>  1372  - is this the same problem as the one you saw?
>>  
>>  John. 

  Yup that was the problem.  something to due with how RSM sets up routing.
  As you can see there was a work-around, but I do not know if a fix to RSM
  was ever engineered or not.

Brian B.
919.4COMICS::REYNOLDSJMad Dogs and EnglishmenTue Apr 06 1993 11:477
    
    thanks, I think I'm on the right track now  -looks like there is a 
    QAR open (ref VINO::RSM_BUGS #65)  - I'll follow up on this,
    
    
    John.