Talk:Interpacket gap

	This article is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of computers, computing, and information technology on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.ComputingWikipedia:WikiProject ComputingTemplate:WikiProject ComputingComputing
Low	This article has been rated as Low-importance on the project's importance scale.
	This article is supported by Networking task force (assessed as Low-importance).

Talk

There is a link on the article that I did not know how to correctly create. I want to link to an article, but to a specific section in the article, while keeping the link an internal (inter-wiki) link. Can someone please take care of this? JonathonReinhart 09:17, 14 February 2007 (UTC)[reply]

Fibre Channel also has an IFG. Possibly, it should be added to this article. FC's IFG consists of IDLE primitives. The minimum IFG is 6 IDLEs. Also, R_RDY primitives can be inserted during the IFG as opposed to IDLEs for buffer-to-buffer credit management. If credit management is being used, two IDLEs must be sent after a frame and before the next frame. All other IDLEs can be replaced with the R_RDY primitive. So the minimum IFG with credit management enabled and two credits pending for transmission would appear as:

(END OF FRAME)|IDLE|IDLE|R_RDY|R_RDY|IDLE|IDLE|(START OF FRAME)

--Brac.Webb 21:30, 1 August 2007 (UTC)[reply]

Is it wise to encourage ping flooding wikipedia.org? Perhaps this should be anonymized to use example.org. 41.241.14.250 (talk) 08:38, 20 January 2009 (UTC)[reply]

An engineer here. I wanted to provide some context. Maybe somebody who is a better writer could include this. One of the main reasons that we need a gap is that clocks are not perfect. If "A" talks to "B" they do so at an agreed upon speed. The issue is that "A" and "B" have their own clocks, they will never match exactly. If "A" is sending faster than "B" is running, then it will eventually not be able to keep up, even if "A" is only going 0.001% faster. So we need to have a gap that can be shortened if necessary. This gap is determined by the maximum data payload size and the tolerances of clock specifications. If the gap needs to be smaller, then you need better clock oscillators, which drives up cost. Some info here: https://www.ieee802.org/3/interp/interp-1-1109.pdf — Preceding unsigned comment added by 4.4.73.98 (talk) 16:26, 14 July 2025 (UTC)[reply]

Minimum IPG for Fast Ethernet

Zac67 has added a 96-bit minimum for Fast Ethernet but acknowledges that no minimum is specified here. Fast Ethernet can use repeaters so the gap can be shortened in transit so 96 doesn't seem right. I assume the lack of specification was an oversight by standards developers and should be indicated as such as it formerly was. ~Kvng (talk) 15:18, 27 October 2021 (UTC)[reply]

@Kvng: I think that's a misconception. For all speeds, the IPG is the standard length of 96 bits for transmission. Since no shrinkage on reception is allowed for Fast Ethernet, see IEEE 802.3 4.4.2, it's the same length as for transmission. If the 96 bits already counts as WP:OR, I'd be fine with no shrinkage allowed as well. However, that might raise more questions for the casual reader than it answers. --Zac67 (talk) 17:46, 27 October 2021 (UTC)[reply]

Zac67 I've read 4.4.2 and don't see any discussion of minimum received IPG for Fast Ethernet. All other variants either have a specification or do not support repeaters. ~Kvng (talk) 14:48, 28 October 2021 (UTC)[reply]

The possible IPG shrinkages are defined in 4.4.2. Since there is no such shrinkage for FE defined, its received minimum IPG is equal to the transmitted minimum IPG. Repeaters are only one possible cause for IPG shrinkage but note that shrinkages are defined for 10G+ speeds which don't define repeaters at all. --Zac67 (talk) 17:22, 28 October 2021 (UTC)[reply]

Zac67 We need to find a secondary source about this. The fact that no shrinkage is mentioned for Fast Ethernet in the standard could be because none is allowed or because of course it happens but editors neglected to mention it. From a technical standpoint, I don't understand how a repeater could work if no shrinkage is allowed. ~Kvng (talk) 13:37, 2 November 2021 (UTC)[reply]

@Kvng: Agreed, but that could get difficult, given the 'obscurity' of the topic. I've also wondered how no shrinkage may appear for FE. There's some explanation in IEEE 802.3 Annex 27A (it talks about the not disappearing IPG). As I understand it, the forwarding delay delta between any two egress ports must be so small that any of them switching to ingress cannot eat into the IPG. (A 'low-delay' egress port A enters the idle state before a 'high-delay' egress port B. If that port A then switches to ingress and the delay to B is much smaller than for the former transmission, the IPG would shrink.) If all port combinations have the same or at least very similar delays, there's no cause for IPG shrinkage. --Zac67 (talk) 14:50, 2 November 2021 (UTC)[reply]

Zac67 It's not clear how much agreement we have here. I assume we're agreed that a secondary source would be useful. I don't think we're agreed on whether the IPG can shrink on FE. My position is that the intent of the standard is not clear. You've edited the article to indicate definitely no shrinkage. The only support I see for that is something that doesn't appear in the standard. ~Kvng (talk) 15:28, 2 November 2021 (UTC)[reply]

@Kvng: We're agreeing on that a second source would be really useful. Have you checked out Annex 27A? It states proper operation of the network requires that repeaters do not cause the interpacket gap (IPG) to disappear which should refer to the lack of shrinkage. Multi-port repeaters are just one cause of such a shrinkage though.

In any case, an IPG shrinkage is only possible/allowed where the standard says so and it doesn't for FE. But that's what we started with. --Zac67 (talk) 18:21, 2 November 2021 (UTC)[reply]

@Zac67: OK, I've looked at 27A. Disappearing IPG is not the same as shrinking it. There's also indication here that the reason they've not specified some parameters directly is for "implementation flexibility". ~Kvng (talk) 22:43, 2 November 2021 (UTC)[reply]