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 articles
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[edit]

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]

Minimum IPG for Fast Ethernet[edit]

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]