| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
I wanted to jump in on this one too. See below.
Thanks,
Brad
Brad Booth
bbooth@xxxxxxxxxx
Level One Communications, Austin Design Center
(512) 407-2135 office
(512) 589-4438 cellular
-----Original Message-----
From: Roy Bynum [SMTP:RBYNUM/0004245935@xxxxxxxxxxx]
Sent: Wednesday, August 04, 1999 1:50 PM
To: Ariel Hendel; stds-802-3-hssg
Subject: Re: Data rate standards vs internal switching standards
Ariel,
Where would the additional bytes of the variable IPG originate?
The MAC would be the originator as it is the only one that generates IPG.
Where
would they go?
The WAN (OC-192) would strip the IPG while loading the packets into its buffer. The WAN PHY requires a buffer anyways for the insertion of the SONET overhead.
What would happen to them between the MAC and the PHY?
They are transferred over the media independent interface for stripping in the WAN PHY.
What happens when the MAC at 10.0 gb is operationally overloaded?
Like Ariel said, higher layer issue as there is no way within 802.3 to overload the MAC.
How do you tell that the PHY is operationally overloaded beyond 9.584
gb?
If the data rate to the WAN PHY is lower the payload data rate of the OC-192 SONET frame, then there shouldn't be an issue unless there is a break in the line or the MAC at the other end is issuing a flow control message.
Would not putting a limit on effective transfer rate at the MAC by the
PHY be the same as putting the limit on the MAC to start with?
The effective transfer rate at the MAC is not being limited. The transfer rate (packets + IPGs) at the MAC would always be 10.0 Gb/s, but depending on which PHY is being used (WAN or LAN), the data transfer rate (packets only) for the WAN PHY would be 9.58464 Gb/s.
I
personally can not see any difference, except that you loose
visibility of the start of overloading conditions at the network
management level.
Using a variable IPG with a 10 Gb/s MAC would give you the visibility as using 9.58464 Gb/s MAC.
The whole argument of 10.0 versus 9.584 has to do will transfer rate
saturation and overloading. How the internal functions of the switch
handles the saturation and overloading conditions, becomes very
critical when there is a difference between the effective transfer
rate of the MAC and the PHY. When the internal functions can clock the
data into the MAC at a transfer rate higher than what the MAC can transfer
it out, can create a major problem.
That would be assuming that data into the MAC is at 10 Gb/s. But that is something that the designers of the systems have to take into account. That is an architectural issue, not a standards issue.
If the internal switch functions can not transfer data to the MAC at
a rate that is higher than what the MAC can transfer it out, then it
becomes an internal control issue. Individual vendors can resolve
the blocking issue by, for example issuing flow control frames out
the input ports. Without direct visibility to the transfer rate, that
becomes more difficult.
Again, that's an architectural/implementation issue. There are no ways within 802.3 to overload the MAC. The MAC requests a frame to transmit; it's not told to transmit a frame.
Thank you,
Roy Bynum
MCI WorldCom
Date: Wed Aug 04, 1999 11:12 am CST
Source-Date: Wed, 04 Aug 1999 10:11:26 -0700 (PDT)
From: Ariel Hendel
EMS: INTERNET / MCI ID: 376-5414
MBX: Ariel.Hendel@xxxxxxxxxxx
TO: Ariel.Hendel
EMS: INTERNET / MCI ID: 376-5414
MBX: Ariel.Hendel@xxxxxxxxxxx
TO: stds-802-3-hssg
EMS: INTERNET / MCI ID: 376-5414
MBX: stds-802-3-hssg@xxxxxxxx
TO: * ROY BYNUM / MCI ID: 424-5935
Subject: Re: Data rate standards vs internal switching standards
Message-Id: 99080417120456/INTERNETGWDN1IG
Source-Msg-Id: <199908041712.KAA03822@xxxxxxxxxxxxxxxxx>
U-X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.2 SunOS 5.7 sun4u sparc
U-Content-MD5: NFmZkLW1UAJg7cpef41TRw==
> Date: Wed, 04 Aug 1999 10:19:28 -0400 (EDT)
> From: Roy Bynum <RBYNUM/0004245935@xxxxxxxxxxx>
> Subject: Re: Data rate standards vs internal switching standards
> To: Ariel Hendel <Ariel.Hendel@xxxxxxxxxxx>, stds-802-3-hssg
<stds-802-3-hssg@xxxxxxxx>
>
> Ariel,
>
> Actually, I am not in favor of a programmable IPG. I think that the IPG
> should be set to minimum for all frames in full duplex 10GbE. With 400
> bytes as the current average size of Internet 802.3 frames, I don't
> think that there will be enough "slop" to make up the difference
> between a 10.0 gb MAC and a 9.584 gb PHY. In the future, with more
> and more video based applications, the average size of the data frame
> will be increasing. This will only cause the MAC buffer discard rate
> to increase if the MAC and PHY are not data rate matched. I would much
> rather see the data rate be defined at the MAC, not the PHY.
>
My apologies for being dense on this thread, just one last hypothetical
question for Roy.
Would you accept a 10Gbps rate along with a variable IPG?
The IPG is just simple function of the length of the last packet sent
to guarantee that the payload rate does not exceed your OC-192 rate.
Open loop, interoperable, no pins, no thresholds, no nothing.
Would you settle for that or you still prefer the 9.xyz rate?
Thanks,
Ariel