Conference 7.286::fddi

>Why does a change in the TVX value, on a concentrator in my tests, cause the
>concentrator to initialise the ring ? (I'm seeing the inits by checking the
>counters using ELMS).
    
    	Timing parameters, such as TVX and Requested TRT (T_REQ), as 
    	programmed into the MAC chip.  Any changes to these values 
    	requires that the chip be turned off, the new value loaded, and
    	then turned back on.
    
>Setting tvx in a bridge 500 doesn't cause a ring init. The bridge is running 
>v2.2 and the concentrator is the same with both v2.3 and v3.0.2ft (I don't 
>have a real v3 to try).
    
    	You should see the exact same behavior with the bridge, ie., if you
    	set a new TVX value (different from the previous), then the ring
    	should reinitialize.
    
>Also, why should my bridge show 2 "ring initialisation received" for each
>single init from the concentrator ? 
    
    	Because the ring is initialized when the MAC is turned off on the
    	concentrator and then again when it is turned back on after the
    	new parameter value is loaded into the chip.
    
    

Thanks for the info but I'm not seeing the same on the bridge as the con;  

>>    	You should see the exact same behavior with the bridge, ie., if you
>>    	set a new TVX value (different from the previous), then the ring
>>    	should reinitialize.

There are no ring inits on the bridge (v2.2 or v3), and no inits received on the
con.

IS this a problem, and if so where (bridge or con)? I almost hope the bridge is
correct as I don't see much need to init the ring when tvx changes as this is a
local-to-station parameter (although I realise it may be necessary depending on
how the MAC is implimented)


Also;
>>   	Because the ring is initialized when the MAC is turned off on the
>>    	concentrator and then again when it is turned back on after the
>>    	new parameter value is loaded into the chip.
   
I'm still a bit confused here, the bridges show 2 ring inits RECEIVED, so who
is causing the first ring init (con only shows 1 init). Is this  timing 
related, ie when the MAC turns off does this cause an init due to tvx expiry
(does it really take this long to turn off/on the MAC) or what?

Thanks,

Steve

>There are no ring inits on the bridge (v2.2 or v3), and no inits received on the
>con.
    
    I'll take a look at how the firmware is behaving; something sounds
    funny here - it could be the SMT implementation or the RBMS agent.
    
>           I don't see much need to init the ring when tvx changes as this is a
>local-to-station parameter (although I realise it may be necessary depending on
>how the MAC is implimented)
    
    It is because of the way that the MAC is implemented.  The timing
    parameters are stored in registers which are writeable only when the
    chip is off.
    
    

	It looks like you've found a bug in the DECbridge 500 firmware.
	The values that you set for TVX and T_REQ are not getting programmed
	into the MAC chip correctly by the management agent code on the bridge.

	This problem affects only the FDDI Line TVX, T_REQ, and T_MAX 
	parameters.  The Phy Port LEM Threshold is not affected.

    	The problem resides in V2.1, V2.2, and 3.0 FT (field test).
    
	The problem is that the values are stored in the bridge's internal 
	management database and NVRAM but are not programmed into the chip.  
	The bridge must be power-cycled or reset by a management command for 
	the new values to be programmed into the MAC chip.

	Any management reads of the bridge will return the new values that
	were set.  These values will not reflect the actual operational values
	until the bridge is reset.

	This problem will be fixed in the version of the DECbridge 500 firmware
	which introduces SNMP set capability.  I don't know what version number
	it will be.

    	Paul C