1. Home
  2. Ethernet LAN
  3. Pause Frame transmission

Pause Frame transmission

I would like to understand in more detail on how often should I transmit Pause frame from the chip I am designing.

The Pause frame timer value inserted in the frame depends on:

  1. The Buffer on my side is getting almost full
  2. The Network cable length (round trip delay to the other end)

I need to clarify the following issues:

  1. I need some equation, that I need to base on, to compute the timer value that Needs to be inserted in the pause frame . I have a programmable pause timer register that is used to get the value to be inserted.

  1. If my buffer is still almost full even after transmitting the first pause frame, what is the timer value I need to insert in the second Pause frame.

  2. Second case where my buffer is not full anymore, after transmitting the first pause. But I don't want the other end to wait any more. Should I consider sending another Pause at this time with 0 timer value Or I should have the correct value that should have been sent on the first pause frame.

  1. Pause frame is 512 bit time means ??? Does it mean Val= Timer Value * 512 and Every time I transfer 8 bits, the "val" should decrement by 8.

Please answer my questions. If you have any papers that describe about Pause frames, Please send me the URL.

thanks, Nikki

Reply to
niki_tech
Loading thread data ...

This subject is discussed in detail in Chapter 8 of "The Switch Book" (shameless plug admitted). Rarely does anyone try to compute the "correct" value for pause_time, i.e., predicting how much time the device will need to reduce its buffers to some acceptably low level. The more common algorithm is:

(1) Determine *when* to send a PAUSE frame, based on the round-trip delay, the characteristics of the flow control protocol, and the amount of buffering available in the sending device.

(2) Always send PAUSE frames with a pause_time of 0xFFFF when crossing this "high water mark."

(3) Determine when the buffers will drop to an acceptable "low water mark". Send a PAUSE frame with a pause_time of 0x0000 prior to that "low water" time, again basing the offset on the characteristics of the flow control protocol.

"The Switch Book" describes exactly how to compute these times and offsets.

Every PAUSE frame takes 512 bit times to transmit, i.e., they are all minimum-length Ethernet frames. I don't understand the rest of the question you pose.

"The Switch Book" is available at any technical bookstore (including Amazon and other online sources). It is also available in electronic form, at:

formatting link
Chapter 8 deals specifically with the operation of PAUSE flow control.

-- Rich Seifert Networks and Communications Consulting 21885 Bear Creek Way (408) 395-5700 Los Gatos, CA 95033 (408) 228-0803 FAX

Send replies to: usenet at richseifert dot com

Reply to
Rich Seifert

In addition to the explanation and references given by Seifert you could also check out chapter 13.3 in "Principles and practices of interconnection networks" by William J. Dally . It discuss several aspects of flow control, but not the timing issues you describe.

Reply to
Sven-Arne Reinemo

Was there ever a specific reason for including a configurable pause time instead of a pure on/off scheme? To me it seems hard to make any good use of the pause timer.

Reply to
Sven-Arne Reinemo

I suppose having the time option saves you from having to transmit the second "pause off" frame.

Bert

Reply to
Albert Manfredi

True, but only if you are able to calculate the correct pause time. If you wait for the maximum pause time to expire you risk leaving the link unnecessary idle. Since the sender will not be notified as soon as the receiver has room for more frames.

Reply to
Sven-Arne Reinemo

In *theory*, one can make a reasonable estimate of the required pause_time, and optimize operation at both ends of the link. In

*practice*, the benefit doesn't make much difference; in fact, in *practice*, PAUSE flow control is turned off (at least at speeds up to 1000 Mb/s).

In the standards committee, we discussed a pure "on-off" scheme at great length (commonly called XON/XOFF, the flow control method of RS-232). The problem is that there is no guarantee of receiving the "XON" message after receiving an "XOFF" which would cause a link to hang indefinitely. That's the reason we put in the timer, which automatically expires after a pause_time. Thus, if a PAUSE with pause_time = 0x0000 is send but not received, the system at least clears the hang after a time. That time can be quite long, however; at 10 Mb/s, 0xFFFF is a pause of over 3 seconds. That's another reason to use a better estimate for pause_time than just 0xFFFF (although both schemes "work").

-- Rich Seifert Networks and Communications Consulting 21885 Bear Creek Way (408) 395-5700 Los Gatos, CA 95033 (408) 228-0803 FAX

Send replies to: usenet at richseifert dot com

Reply to
Rich Seifert

(snip)

It would seem most useful on mixed speed bridges, with the data going out a slower link. Also, though probably less often, when multiple hosts are sending data to one server. TCP may be able to do those with reasonable buffer sizes, assuming it is TCP.

Three seconds isn't so long most of the time, and presumably it will mostly happen on faster links.

-- glen

Reply to
glen herrmannsfeldt

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.