| 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 | 
    
    
    
    
     
    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.R | Title | User | Personal Name | Date | Lines | 
|---|---|---|---|---|---|
| 919.1 | TAY1 site had same RSM/Backup/FDDI prob | BNGBNG::BOURGEOIS | NEI-South ISC | Tue Apr 06 1993 07:06 | 64 | 
| 
  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.2 | RSM note related? | COMICS::REYNOLDSJ | Mad Dogs and Englishmen | Tue Apr 06 1993 09:01 | 5 | 
|     
    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.3 | YUp 1372 is the problem | BNGBNG::BOURGEOIS | NEI-South ISC | Tue Apr 06 1993 09:20 | 13 | 
| 
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.4 | COMICS::REYNOLDSJ | Mad Dogs and Englishmen | Tue Apr 06 1993 10:47 | 7 | |
|     
    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.
    
 | |||||