Glen,
I’m assuming that you take off the 8b/10b encoding. Remember that the CPRI rates are the wireline data rates with 8b/10b encoding. Strip the 8b/10b encoding off a 9.8304
Gbps CPRI stream, and you end up with a 7.8643 Gbps actual data stream. For 10GbE, the 10 Gbps of actual data is 6b/66b encoded to 10.3125 Gbps on the wire.
If (hypothetically) you have 40 bytes of total overhead (including inter-frame gap), a 9.8304 Gbps CPRI stream would have the following effective data rates, not counting
the 64b/66b encoding:
・
100 byte packets: 11,796,480,000
・
150 byte packets: 10,485,760,000
・
200 byte packets: 9,830,400,000
・
250 byte packets: 9,437,184,000
・
300 byte packets: 9,175,040,000
・
350 byte packets: 8,987,794,286
・
400 byte packets: 8,847,360,000
・
450 byte packets: 8,738,133,333
・
500 byte packets: 8,650,752,000
[At 100 byte CPRI samples, you will need 12,288,000 packets per second to handle the 800 bits per CPRI sample. In the list above, a 100 byte packet of CPRI data is 800 bits
of CPRI’s 8b/10b-encoded information; this would become 80 bytes after the 8b/10b encoding is removed. With 40 bytes overhead, the 80 bytes of cooked data becomes 120 bytes or 960 bits of wire time. Send 12,288,000 of those packets, and you get 11,796,480,000
bits of throughput required, something you can’t do on a single 10GbE line.]
As you can see, somewhere between the 150 and 200 byte range is where you barely get under 10 Gbps.
Does that make sense?
--kb
From: Glen Kramer [mailto:gkramer@xxxxxxxxxxxx]
Sent: Friday, May 08, 2015 11:59 AM
To: Bross, Kevin; STDS-1904-3-TF@xxxxxxxxxxxxxxxxx
Subject: RE: structure agnostic transport and a start of a frame
Kevin,
I don’t see how you can carry uncompressed 9.8304 Gbps over the 10G Ethernet link.
Let’s take the max packet size of 1518 bytes (1500 payload + 18 bytes for the header and FCS). In addition to the frame size, you have a minimum IPG (12 bytes) and preamble
(8 bytes). To, the total size of the frame with the overhead is 1538 bytes.
The total rate you need to carry 9.8304 Gbps would be
9.8304 Gbps * (1538/1500) =
10.07944Gbps, which exceed the maximum data rate of the 10G Ethernet link.
Going to smaller frame sizes will only increase relative overhead, or course.
Here is your max payload carrying capacities for different packet sizes (ignoring all other overheads, like control frames, etc.)
Glen
From: Bross, Kevin [mailto:kevin.bross@xxxxxxxxx]
Sent: Wednesday, May 06, 2015 7:10 PM
To: STDS-1904-3-TF@xxxxxxxxxxxxxxxxx
Subject: Re: [1904.3 TF] structure agnostic transport and a start of a frame
Liquan,
I concur.
Our worst-case scenario will be streaming traffic without any compression, right?
To encapsulate 9.8304 Gbps traffic within a 10 Gbps link (including Ethernet overhead), you’ll probably need to be somewhere in the 1500-2000 bits of CPRI data put into an
Ethernet frame at a minimum. Having some extra bytes in the header for packets this large will have negligible impact on the throughput. I’m not suggesting we waste bytes, but the header impact for Ethernet frames >150 bytes is not as significant as one
might think. If going with larger packets (such as 500 bytes), the impact is even less.
--kb
===================================================================
From:
stds-1904-3-tf@xxxxxxxx [mailto:stds-1904-3-tf@xxxxxxxx]
On Behalf Of yuan.liquan@xxxxxxxxxx
Sent: Wednesday, May 06, 2015 6:08 PM
To: Jouni Korhonen
Cc: stds-1904-3-tf@xxxxxxxx;
STDS-1904-3-TF@xxxxxxxxxxxxxxxxx
Subject: 答复: structure agnostic transport and a start of a frame
Jouni,
There may be some varied types of upper layer data carried over RoE frame, so the size is also varied, which RoE frame is the first part of upper layer data package and which RoE frame is the end
of upper layer data package should be indicated, then 1 more bit may be needed.
BR.
Liquan
ZTE CORP.
发件人:
Jouni Korhonen <jouni.korhonen@xxxxxxxxxxxx>
收件人:
"STDS-1904-3-TF@xxxxxxxxxxxxxxxxx" <STDS-1904-3-TF@xxxxxxxxxxxxxxxxx>,
日期:
2015/05/07 00:41
主题: structure agnostic transport and a
start of a frame
发件人: stds-1904-3-tf@xxxxxxxx
Folks,
Kevin brought up an interesting point a while back. If we want a truly structure agnostic transport mode be supported that would imply just a stream of bits. For example, in a case of CPRI we would not even touch 8B/10B or 64B/66B coding to preserve
e.g. K-characters etc. I am fine with this (with some pain). However, it could be beneficial to indicate the start of a frame in the RoE header (1 bit flag). The assumption I have is that all data streams to be carried over RoE in structure agnostic mode still
have some kind of framing. As an example we could indicate the start of each hyper frame in a case of CPRI.
The same flag would also serve structure aware modes & native RoE flows. Just to indicate when some packet is a start of a radio frame or other framing..
This is a small optimization that may or may not be worth it.. Comments/thoughts?
- Jouni
--
Jouni Korhonen, CTO Office, Networking, Broadcom Corporation
O: +1-408-922-8135, M: +1-408-391-7160