Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

[802.3_10SPE] Fairness Assessment - some thoughts on REPLENISH state

Thank you for the excellent presentation (!


I want to discuss the REPLENISH state shown on slide 9. Any time I see something that requires multiple devices to know what each other is doing I get nervous. I am not against it, and often it cannot be avoided, I just want to explore if we can remove that inter-device dependency. Specifically I am looking at “max(remote_credits)”. I believe the intent here is to give stations the chance to build credits faster if they know other stations on the network are not going to be transmitting for a while. This is evaluated each time the Beacon is seen.


My thinking is that if stations aren’t transmitting then the Beacons are going to occur more quickly  (see slide 4 of and you’re going to replenish your local_credits faster. The end result being that stations wishing to transmit packets will be able to transmit at a faster rate if other stations aren’t transmitting. This may not be as quick to respond as the proposed use of remote_credits, but it removes all inter-device dependencies and related problems associated with remote device “synchronization” behaviors (i.e. remote_credits can change based on resets, etc).


Assuming I’m understanding the intent of the REPLENISH state; what do you think?


If this makes sense then I see an additional step we could take. If we can expose the BEACON signal to 802.1 we could put the credit replenish logic in the driver. Now we can make all kinds of tweaks to the logic with software updates and not affect the PHY. This just becomes another type of 802.1 shaper that accumulates credits based on BEACONs rather than some other clock source, and we can apply all kinds of priority handling integrated with the shaper solution.


Craig Gunther

Harman International





To unsubscribe from the STDS-802-3-10SPE list, click the following link: