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 08: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 10: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 10: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 11: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. |