Skip to main content

Timeline for Does bridging add delay?

Current License: CC BY-SA 4.0

10 events
when toggle format what by license comment
S Jan 9, 2019 at 14:27 history suggested nufuniliza CC BY-SA 4.0
Get rid of Edit edit edit
Jan 9, 2019 at 10:35 review Suggested edits
S Jan 9, 2019 at 14:27
Jan 8, 2019 at 16:19 comment added Ron Maupin The serialization delay is at wirespeed, so it is not much of a delay. Most modern enterprise-grade switches will switch at wirespeed, so any delay is very, very small, probably caused by congestion and queuing on an oversubscribed interface.
Jan 8, 2019 at 14:24 history edited Marc 'netztier' Luethi CC BY-SA 4.0
added 321 characters in body
Jan 8, 2019 at 14:17 comment added Marc 'netztier' Luethi @psmears The serialization delay when the bridge sends out the frame at the far end will occur in any case, agreed. As for the receiving side... Let's imagine a otherwise identical "direct" cable bypassing the bridge, where the same bit sequence is sent synchronously, but bypassing the bridge. In the cable, bits just propagate down the line, while the bridge is waiting for the last bit to start processing... Oh. you're right, Thanks! Time for an edit, then.
Jan 8, 2019 at 13:44 comment added psmears Haven't had my coffee so may not be thinking straight, but does adding a bridge necessarily add two times the serialization delay? Obviously it will always add one serialization delay (unless there's some sort of cut-through going on), but the "sending" serialisation happens in parallel with the next receiver's deserialisation, (which was always going to happen anyway), so isn't it only effectively one extra delay in total? Sorry if that's not very clear...
Jan 8, 2019 at 10:40 history edited Marc 'netztier' Luethi CC BY-SA 4.0
added 32 characters in body
Jan 8, 2019 at 10:12 vote accept nufuniliza
Jan 8, 2019 at 10:06 history edited Marc 'netztier' Luethi CC BY-SA 4.0
added 100 characters in body
Jan 8, 2019 at 9:59 history answered Marc 'netztier' Luethi CC BY-SA 4.0