Hi all,
I'm really confused about GT/s? vs Gbps?. The PCIe 2.0 Base Spec (rev 0.9)
on page 34, section 1.2 speaks of "Signaling rate - [...] For the first
generation of PCI Express technology, there is only one signaling rate
defined, which provides an effective 2.5 Gigabits/second/Lane/direction
of raw bandwidth." but later in the document it purely speaks of 2.5
GT/s.
If I understand this correctly it means the following:
PCIe has a raw bandwidth of 2.5 Gbps (or 5.0 Gbps, whatever) but because
of the "8b/10b" encoding the effective bit rate is only
2.5 Gbps * (8/10). So it's called 2.5 GT/s to explicitly say this is raw
bandwidth.
IMHO this is rather confusing, as most people don't know what GT/s means.
So I'd suggest the following change:
diff --git a/drivers/pci/hotplug/pci_hotplug_core.c b/drivers/pci/hotplug/pci_hotplug_core.c
index 0325d98..75ef3d7 100644
--- a/drivers/pci/hotplug/pci_hotplug_core.c
+++ b/drivers/pci/hotplug/pci_hotplug_core.c
@@ -86,8 +86,8 @@ static char *pci_bus_speed_strings[] = {
"66 MHz PCIX 533", /* 0x11 */
"100 MHz PCIX 533", /* 0x12 */
"133 MHz PCIX 533", /* 0x13 */
- "2.5 GT/s PCI-E", /* 0x14 */
- "5.0 GT/s PCI-E", /* 0x15 */
+ "2.5 Gbps PCI-E", /* 0x14 */
+ "5.0 Gbps PCI-E", /* 0x15 */
};
#ifdef CONFIG_HOTPLUG_PCI_CPCI
? Gigatransfers/second
? Gigabits/second
Stefan
--
Stefan Assmann | Red Hat GmbH
Software Engineer | Otto-Hahn-Strasse 20, 85609 Dornach
| HR: Amtsgericht Muenchen HRB 153243
| GF: Brendan Lane, Charlie Peters,
sassmann at redhat.com | Michael Cunningham, Charles Cachera
Stefan Assmann <[email protected]> writes:
> IMHO this is rather confusing, as most people don't know what GT/s means.
It's trivial to look it up, isn't it?
> So I'd suggest the following change:
>
> --- a/drivers/pci/hotplug/pci_hotplug_core.c
> +++ b/drivers/pci/hotplug/pci_hotplug_core.c
> @@ -86,8 +86,8 @@ static char *pci_bus_speed_strings[] = {
> "66 MHz PCIX 533", /* 0x11 */
> "100 MHz PCIX 533", /* 0x12 */
> "133 MHz PCIX 533", /* 0x13 */
> - "2.5 GT/s PCI-E", /* 0x14 */
> - "5.0 GT/s PCI-E", /* 0x15 */
> + "2.5 Gbps PCI-E", /* 0x14 */
> + "5.0 Gbps PCI-E", /* 0x15 */
Isn't it like calling 100BASE-TX a 125 Mb/s? _That_ would be confusing.
BTW PCI-E can be multi-lane so Mb/s (and even MB/s) don't make sense.
I guess many people don't know what a MHz is either but we don't say
133 MHz = 133 Mbps.
--
Krzysztof Halasa
Krzysztof Halasa wrote:
> Stefan Assmann <[email protected]> writes:
>
>> IMHO this is rather confusing, as most people don't know what GT/s means.
>
> It's trivial to look it up, isn't it?
>
>> So I'd suggest the following change:
>>
>> --- a/drivers/pci/hotplug/pci_hotplug_core.c
>> +++ b/drivers/pci/hotplug/pci_hotplug_core.c
>> @@ -86,8 +86,8 @@ static char *pci_bus_speed_strings[] = {
>> "66 MHz PCIX 533", /* 0x11 */
>> "100 MHz PCIX 533", /* 0x12 */
>> "133 MHz PCIX 533", /* 0x13 */
>> - "2.5 GT/s PCI-E", /* 0x14 */
>> - "5.0 GT/s PCI-E", /* 0x15 */
>> + "2.5 Gbps PCI-E", /* 0x14 */
>> + "5.0 Gbps PCI-E", /* 0x15 */
>
> Isn't it like calling 100BASE-TX a 125 Mb/s? _That_ would be confusing.
> BTW PCI-E can be multi-lane so Mb/s (and even MB/s) don't make sense.
> I guess many people don't know what a MHz is either but we don't say
> 133 MHz = 133 Mbps.
so, maybe the right terms are
2.5 GHz PCI-E
5.0 GHz PCI-E
No matter how many lanes, or how the data is sent (long or short bursts),
the frequency rate is a constant.
So, the data rate is not stated, just the cycle rate.
This would follow the PCIX syntax as well, which is
void of bandwidth illusions.
- Don
ps -- "GT/s" isn't even defined in the PCIe spec, just
blindly introduced, and unjustified in its use.
..... too much marketing-speak in PCI SIG ...
FWIW, I think using the same nomenclature as the PCI-SIG documents is
probably the least confusing option. Inventing our own terminology that
conflicts with the "upstream" PCI specs is just going to confuse things,
even if the Linux terminology is "better." With that said:
> "66 MHz PCIX 533", /* 0x11 */
> "100 MHz PCIX 533", /* 0x12 */
> "133 MHz PCIX 533", /* 0x13 */
> "2.5 GT/s PCI-E", /* 0x14 */
> "5.0 GT/s PCI-E", /* 0x15 */
it is the case that PCI-SIG uses "PCI-X" and "PCIe" rather than "PCIX"
and "PCI-E". That naming would make sense to me as something to clean up.
The table of names also seems to be missing entries for PCI-X mode 1
with ECC, although I don't know if there ever was a system with a
device that actually used that mode.
- R.
Don Dutile <[email protected]> writes:
> so, maybe the right terms are
> 2.5 GHz PCI-E
> 5.0 GHz PCI-E
I don't thinks so. It would be fine for PCI/PCI-X, as there is a clock
signal with a given frequency. PCI-E doesn't use a clock signal. Really,
the meaningful value is a cycle time (or number of cycles per second).
Of course one could calculate or measure a frequency (or spectrum) for
a given code sequence on PCI-E. For example, for something like
01010101010101 (raw code) the (base) frequency would be 1.25 or 2.5 GHz
for 2.0. For other patterns it would be lower.
> No matter how many lanes, or how the data is sent (long or short bursts),
> the frequency rate is a constant.
Actually, this is not the case.
> So, the data rate is not stated, just the cycle rate.
Cycle rate, sure. Frequency, no.
> This would follow the PCIX syntax as well, which is
> void of bandwidth illusions.
Bandwidth, actually it may make some sense. But it would have to take
#lanes into account, I'm not sure we want to do it. And it would create
another confusion - raw vs effective bandwidth (like 125 vs 100 Mbps
with Ethernet).
--
Krzysztof Halasa
Krzysztof Halasa wrote:
> Don Dutile <[email protected]> writes:
>
>> so, maybe the right terms are
>> 2.5 GHz PCI-E
>> 5.0 GHz PCI-E
>
Yeah, the std nomenclature is PCI-e not PCI-E.
> I don't thinks so. It would be fine for PCI/PCI-X, as there is a clock
> signal with a given frequency. PCI-E doesn't use a clock signal. Really,
> the meaningful value is a cycle time (or number of cycles per second).
>
number of cycles/second == frequency.
cycle time = 1/frequency
>From a run-time perspective, the status is trying to
tell the user/admin what (steady-state) frequency the
links are running at : 2.5GHz or 5.0GHz.
> Of course one could calculate or measure a frequency (or spectrum) for
> a given code sequence on PCI-E. For example, for something like
> 01010101010101 (raw code) the (base) frequency would be 1.25 or 2.5 GHz
> for 2.0. For other patterns it would be lower.
>
>> No matter how many lanes, or how the data is sent (long or short bursts),
>> the frequency rate is a constant.
>
> Actually, this is not the case.
>
Frequency changing would require link re-synch.
This code is dealing w/steady-state frequency.
>> So, the data rate is not stated, just the cycle rate.
>
> Cycle rate, sure. Frequency, no.
>
I think nomeclature is mixed up here.
>> This would follow the PCIX syntax as well, which is
>> void of bandwidth illusions.
>
> Bandwidth, actually it may make some sense. But it would have to take
> #lanes into account, I'm not sure we want to do it. And it would create
> another confusion - raw vs effective bandwidth (like 125 vs 100 Mbps
> with Ethernet).
Again, trying to generate output that relates
to what devices are spec to run at: 2.5GHz or 5.0GHz links.
Roland Dreier wrote:
> FWIW, I think using the same nomenclature as the PCI-SIG documents is
> probably the least confusing option. Inventing our own terminology that
> conflicts with the "upstream" PCI specs is just going to confuse things,
> even if the Linux terminology is "better."
I think so too.
And lspci output is "GT/s".
Thanks,
Kenji Kaneshige
> Yeah, the std nomenclature is PCI-e not PCI-E.
To be pedantic: "PCIe" without the hyphen is correct, cf
http://www.pcisig.com/specifications/pciexpress/ (the web page, not any
member-only specs) -- "PCIe" is used many times there.
> Again, trying to generate output that relates
> to what devices are spec to run at: 2.5GHz or 5.0GHz links.
But the spec does not talk about rates in GHz but rather GT/s (since
PCIe is not clocked but rather uses a recovered embedded clock).
Matching the terminology of the PCIe spec by using GT/s really seems
best in terms of clarity, and describes the situation most exactly,
since by using GT/s one also sidesteps the issue of having the data rate
depend on the link width.
- R.
Roland Dreier wrote:
> > Yeah, the std nomenclature is PCI-e not PCI-E.
>
> To be pedantic: "PCIe" without the hyphen is correct, cf
> http://www.pcisig.com/specifications/pciexpress/ (the web page, not any
> member-only specs) -- "PCIe" is used many times there.
>
agreed.
> > Again, trying to generate output that relates
> > to what devices are spec to run at: 2.5GHz or 5.0GHz links.
>
> But the spec does not talk about rates in GHz but rather GT/s (since
> PCIe is not clocked but rather uses a recovered embedded clock).
Yes, it does in section 2.1, page 38 of base spec:
Signaling rate – Once initialized, each Link must only operate at one of the supported signaling
levels. For the first generation of PCI Express technology, there is only one signaling rate
defined, which provides an effective 2.5 Gigabits/second/Lane/direction of raw bandwidth.
The second generation provides an effective 5.0 Gigabits/second/Lane/direction of raw
bandwidth. The data rate is expected to increase with technology advances in the future.
Additionally, the original specs listed the Link speeds in the Link Capabilities
register as Gb/s; this is also reflected in MindShare's PCI Express System Architecture
book (3rd edition; I'm curious to find out if the 4th edition updated this area
to the GT/s terminology).
> Matching the terminology of the PCIe spec by using GT/s really seems
> best in terms of clarity, and describes the situation most exactly,
> since by using GT/s one also sidesteps the issue of having the data rate
> depend on the link width.
>
> - R.
So, the original spec (and for those that worked on it originally), the
link speeds were stated in Gb/s.
If GT/s will be the nomenclature used by PCIe vendors
when they have varying speed devices, then I agree, use the GT/s terminology.
Doing a number of varying web searches, it appears the hw vendors
are avoiding which to use: T/s or b/s by using "2.5G" & "5.0G"
sometimes prefixing with "Gen1-" & "Gen2-" respectively.
Maybe we should take a hint from the hw folks and drop the use of "T/s" or "b/s"
and just output "2.5G", "5.0G".... and when it gets here "8.0G".
cheers... Don
Don Dutile <[email protected]> writes:
>>> No matter how many lanes, or how the data is sent (long or short bursts),
>>> the frequency rate is a constant.
I'm not sure there is such thing as "frequency rate" (but English isn't
my first language). Rate, yes - symbol rate, clock rate (not used here),
code rate. Frequency is a clearly defined but different thing.
> Frequency changing would require link re-synch.
> This code is dealing w/steady-state frequency.
Believe me or not, there is no single frequency on PCIe link.
Google shows for example:
http://www.home.agilent.com/upload/cmc_upload/All/PCIe_HighSpeedSymposiumDec2008.pdf
See page 30, it's frequency spectrum for PCIe 3.0 but the idea is the
same. Also note consistent use of "GT/s" to avoid confusion.
> Again, trying to generate output that relates
> to what devices are spec to run at: 2.5GHz or 5.0GHz links.
That seems like wifi rather than PCIe.
--
Krzysztof Halasa