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