[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

338.0. "Is there any way to change TRT_Req on DEFZA?" by TKTVFS::IDO (Naoki Ido, CSC/Tokyo, EWB/3FS) Tue Sep 03 1991 07:13

Hi,

I am now trying to connect our FDDIs to some other vendor's. I need
to change TRT_req in DEFZA on the testing because non-DEC vendor requests
it more than 8ms. I could change it on DECbridge500 or DECconcentrator500 with
DECelms but TRT_Neg is still 8ms since DEFZA is working with default 8ms.
I know TRT-Neg can be changed if we remove DS5000 from the ring, but Is there 
no way to change TRT_Req on current ULTRIX V4.2 ?  I also would like to know 
whether it's possible if ULTRIX PhaseV.       

Regards,
Naoki Ido

T.R	Title	User	Personal Name	Date	Lines
338.1		MIPSBX::thomas	The Code Warrior	`Tue Sep 03 1991 11:55`	2
	No possible. The driver has no support for changing any FDDI parameters. (Phase V just uses what the driver makes available).
338.2	8ms is OK! Why change?	ZPOVC::LESTERYUNG	T&N Mkt/Asia Region	`Wed Sep 04 1991 10:08`	12
	FWIW, why would you want to change it. It has been determined that 8ms is a very good value for most FDDI configurations. See paper by R.Jain "Performance Analysis of FDDI Token Ring Networks: Entity Effect of Parameters and Guidelines fro Setting TTRT". Proceedings of the ACM SIGCOMM'90 (sept. 1990) Very informative reading. Paper is available in ps form. Regards, Lester
338.3	...	STAR::SALKEWICZ	It missed... therefore, I am	`Wed Sep 04 1991 15:02`	23
	FWIW, you must have the capability to change these things to be able to claim "interoperability" and "conformance" to certain standards. (ANSI) While setting up the DEMFA for the Interop show, we were hit with requuests to change T_Req. Not that they really needed it changed to make the ring operate; they just wanted to see that it could be changed in case it needs to be. The previous reply correctly states that 8ms is goodness for "most" FDDI networks,.. however,,.. ANSI and our own FDDI architecture states that this is a parameter that may need to be adjusted,.. and every implementation should provide the means to change it. Speaking for Phase IV DECnet over FDDI, the initial release with V5.4-3 does not have this capability, but we are busily developing it (via extensions to NCP/NICE) for a release in the near future. Probably a dash release of 5.5. Stay tuned /Bill
338.4	Thank you.	TKTVFS::IDO	Naoki Ido, CSC/Tokyo, EWB/3FS	`Thu Sep 05 1991 08:03`	11
	> Speaking for Phase IV DECnet over FDDI, the initial release > with V5.4-3 does not have this capability, but we are busily > developing it (via extensions to NCP/NICE) for a release in the > near future. Probably a dash release of 5.5. Well, How about ULTRIX group ? Thank you, Naoki
338.5		UPSAR::THOMAS	The Code Warrior	`Thu Sep 05 1991 12:23`	1
	Supposedly it will be added in ULTRIX V4.3 but I haven't seen anything.
338.6		KONING::KONING	Brivu Latviju!	`Mon Sep 16 1991 16:10`	17
	Re .0: I think you misunderstood something. The rule in FDDI is that the smallest value of T_Req (Requested TTRT) is the value that is used. This is perfectly normal and doesn't bother anyone. If another node requested a larger one, it simply yields to the lower value. You're right in saying that the DS5000 causes the higher T_Req to be ignored and 8 ms to be used instead. But this is NOT a problem. In particular, there is NO REASON for the T_Req to be the same for all nodes. 8 ms is a good value, for reasons documented in detail in the report mentioned in other replies. It is occasionally useful to have a larger value, but only in very large networks. For any small to medium size network, increasing T_req above 8 ms is useless (and, in extreme cases, will hurt, though usually it makes no difference at all). paul