Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: [STDS-802-3-EPOC] EPoC PHY Statistics



Marek,

That document is like reading ancient Egyptian script.  Wow.  What I can determine is that we only have statistics defined for MPCP related items.  I hate to say it but I have always been puzzled by these statistics.  We support them but as far as I can tell, most of them are useless.  That is a side topic and not important.  See below for the table.

I'm still not clear on the answer to the basic question that I asked you and Duane.  If we have a statistic in the PHY, can we access it without mapping it to the MDIO?

Thanks
Ed...

Dot3MpcpStatEntry ::=
    SEQUENCE {
            dot3MpcpMACCtrlFramesTransmitted       Counter64,
            dot3MpcpMACCtrlFramesReceived          Counter64,
            dot3MpcpDiscoveryWindowsSent           Counter32,
            dot3MpcpDiscoveryTimeout               Counter32,
            dot3MpcpTxRegRequest                   Counter64,
            dot3MpcpRxRegRequest                   Counter64,
            dot3MpcpTxRegAck                       Counter64,
            dot3MpcpRxRegAck                       Counter64,
            dot3MpcpTxReport                       Counter64,
            dot3MpcpRxReport                       Counter64,
            dot3MpcpTxGate                         Counter64,
            dot3MpcpRxGate                         Counter64,
            dot3MpcpTxRegister                     Counter64,
            dot3MpcpRxRegister                     Counter64
    }



From: Marek Hajduczenia [mailto:marek.hajduczenia@xxxxxx]
Sent: Thursday, February 14, 2013 9:09 AM
To: Ed (Edward) Boyd; STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx
Subject: RE: [STDS-802-3-EPOC] EPoC PHY Statistics

Ed,

In terms of the MDIO registers for EPON, please take a look at 802.3av-2009 as published, changes to Clause 45. These are all registers that have been defined for 10G-EPON. There are some PMA/PMD registers (45.2.1) and some PCS registers (45.2.3). Everything else is defined in MIB (see http://www.ieee802.org/3/1/public/mib_modules/20121206/802dot3dot1C9mib.txt for the latest available EPON MIB from 802.3.1a).

That said, I think this should be a well understood topic and quick to examine. I do not think I can really contribute a lot going through this on the call.

"MDIO operation" was included in your email two levels down ... for some reason, I changed the name to "MDIO action" - sorry about that

Marek

From: Ed (Edward) Boyd [mailto:ed.boyd@xxxxxxxxxxxx]<mailto:[mailto:ed.boyd@xxxxxxxxxxxx]>
Sent: Thursday, 14 February, 2013 4:50 PM
To: Marek Hajduczenia; STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx<mailto:STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx>
Subject: RE: [STDS-802-3-EPOC] EPoC PHY Statistics

Marek,

Good point.  EPON does have standalone SERDES chips but I have never seen an MDIO definition or maybe I have ignored it.  I agree that we should look at what is available and use it as a starting reference but it is probably far from what is needed for a coax PHY.  I have been focusing on the Ethernet Copper PHYs as reference since they are much closer. Can you bring the MDIO register definition from EPON into the PHY Link Ad Hoc so it can be quickly reviewed?

I'm not clear on your reference to "MDIO action" below.

Thanks,
Ed...



From: Marek Hajduczenia [mailto:marek.hajduczenia@xxxxxx]
Sent: Thursday, February 14, 2013 12:59 AM
To: Ed (Edward) Boyd; STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx<mailto:STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx>
Subject: RE: [STDS-802-3-EPOC] EPoC PHY Statistics

Ed,

Well, I am sorry to say but EPON has a concept of stand-alone PHY - that is why PHY is defined in a separate subclause. Furthermore, initial implementations (of 1G-EPON) did have separate PHY and separate MAC. Over time, they became all integrated into a SoC. It is further expected that any 802.3 PHY can be implemented with a separated PHY - that is the reason we use xMII in the first place - to be able to pair devices from different vendors across an interoperability interface. Furthermore, some PHYs are prepared to support what is called PHY extender interface (XAUI) that allows you to further separate MAC and PHY across, e.g., different line cards or line card elements. So I do not think it is a correct statement to say that EPON always assumes PHY integrated with MAC. That is an implementation choice, with obvious advantages.

I would also like to ask for clarification of what "MDIO action" is. EPON does provide a set of registers in Clause 45, it does support MDIO as such (you have to be able to read these registers somehow) but I never came across the term "MDIO action". I learn something everyday :)

Marek

From: Ed (Edward) Boyd [mailto:ed.boyd@xxxxxxxxxxxx]<mailto:[mailto:ed.boyd@xxxxxxxxxxxx]>
Sent: Thursday, 14 February, 2013 2:26 AM
To: Marek Hajduczenia; STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx<mailto:STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx>
Subject: RE: [STDS-802-3-EPOC] EPoC PHY Statistics

Marek,

I don't think that EPON has the concept of an external/standalone PHY.  Did we even define MDIO operation for it in EPON?

Ed..

From: Marek Hajduczenia [mailto:marek.hajduczenia@xxxxxx]
Sent: Wednesday, February 13, 2013 2:54 PM
To: Ed (Edward) Boyd; STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx<mailto:STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx>
Subject: RE: [STDS-802-3-EPOC] EPoC PHY Statistics

Ed,

Without lengthy emails: I think we should emulate the approach to division between registers / MIBs as done in EPON, unless for some (currently unclear) reason such an approach would not work for EPoC. I am in favour of using tried-and-tested approaches.

Marek

From: Ed (Edward) Boyd [mailto:ed.boyd@xxxxxxxxxxxx]<mailto:[mailto:ed.boyd@xxxxxxxxxxxx]>
Sent: Wednesday, 13 February, 2013 10:43 PM
To: STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx<mailto:STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx>
Subject: Re: [STDS-802-3-EPOC] EPoC PHY Statistics

Duane, Marek, and Nicola,

First, a few logistic issues.  I changed the "subject" on the email chain to avoid confusion with another topic.  I also added Duane's comment below to get back to a single thread.


Ø  Duane: In general statistic's gathering is more of a mib function than something to be stored and retrieved from a PHY via MDIO.


Yes, I agree that statistics need to be in MIBs.  It is my understanding that we need to use the MDIO to get the statistics that are gathered from the PHY for the MIBs.  If that is the case, we will need a definition for them in the MDIO space.  I would be happy to be wrong and we can just define MIBs. Of course, there would be no IOP with standalone PHYs.  I might be dated in my understanding since my last Ethernet PHY design was many years ago.  In the past, a standalone PHY only had an MDIO for management/config and an MII for the data port.


Ø  Duane: I think we may need to develop a "snap shot" mechanism for those instances where we are talking about a large number of registers for each CNU

I'm open to a "snap shot" approach on some of the per-carrier statistics.  You could select a particular CNU for detailed monitoring and debug.


Ø  Nicola: Just a quick thought from my side: do we really need to store detailed statistics for all CNUs in the CLT PHY ?

I think that they need to be gathered in the PHY.  Ideally, they are separated per CNU for analysis.  It is also ideal if the statistic width in the PHY is large enough for the SME (station management entity) to read out the information without losing counts.


Ø  Nicola: Of note, when using MMP, the CLT PHY may store the MCS associated with each CNU. But that would require much less memory space (single value for each CNU).


I don't see that as a help.  If an MMP has bad performance, you can't identify the CNU that has the issue.  In the case of MMP, you would want to the find the CNU with low performance and drop his modulation profile.


Ø  On the other hand, as you say we do need statistics on the PHY link quality for debugging and management purposes. My thought was that this kind of information could be conveyed from the CNU to the CLT via upper layer procedures (e.g., OAM). In this way, storage capabilities of the PHY layer should not be a concern.

While it can be transferred between the CLT and CNU via OAM, we still need a method to pull the information from the PHY.  Additionally, during the start-up process, we need to gather statistics and transfer them up to the CLT before the OAM link has been established.


In summary, I need to understand if we can have statistics in the PHY without MDIO access.  We need to define which statistics and status indicators in the CNU PHY need to be accessible via the PHY link channel before the link is established.

Thanks,
Ed....



-------------- From Duane -----------------------------

Ed,
I think I have to agree with Marek on this point. In general statistic's gathering is more of a mib function than something to be stored and retrieved from a PHY via MDIO. Certainly the CLT PHY will need to be able to report locally some receive statistic for each CNU but I think we may need to develop a "snap shot" mechanism for those instances where we are talking about a large number of registers for each CNU. I think you even alluded to some like this on the last PHY_Link call.
Best Regards,
Duane

FutureWei Technologies Inc.
duane.remein@xxxxxxxxxx<mailto:duane.remein@xxxxxxxxxx>
Director, Access R&D
919 418 4741
Raleigh, NC



From: Varanese, Nicola [mailto:nicolav@xxxxxxxxxxxxxxxx]
Sent: Wednesday, February 13, 2013 7:46 AM
To: STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx<mailto:STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx>
Subject: Re: [STDS-802-3-EPOC] Minutes

Marek,

I believe that we should clearly specify whether we are discussing about a PHY procedure (e.g., reporting link quality for MCS selection) or a management procedure (e.g., reporting link quality for monitoring, debugging, etc...). In yesterday's discussion we probably mixed up these two things that - at least in my view - could be analysed separately.

Thanks,
Nicola





From: Marek Hajduczenia [mailto:marek.hajduczenia@xxxxxxxxx]<mailto:[mailto:marek.hajduczenia@xxxxxxxxx]>
Sent: 13 February 2013 11:12
To: Varanese, Nicola; STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx<mailto:STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx>
Subject: RE: [STDS-802-3-EPOC] Minutes

Nicola,

That is the reason why I asked about this topic on the call. When I look at how statistics and link debug information for EPON is collected, it is stored in the MIB, that can be implemented in a vendor-specific manner. In EPON, only basic link related information is stored in registers and the rest is pushed out to MIBs. This means that link stats are collected over OAM after the MAC link is up and does not need any additional data links or exchange mechanisms.

A MIB for EPoC could be designed very easily by cooperating with 802.3.1 and we can get any level of detail there we want (and need)

Marek

From: Varanese, Nicola [mailto:nicolav@xxxxxxxxxxxxxxxx]
Sent: Wednesday, 13 February, 2013 8:50 AM
To: STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx<mailto:STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx>
Subject: Re: [STDS-802-3-EPOC] Minutes

Hi Ed,

Just a quick thought from my side: do we really need to store detailed statistics for all CNUs in the CLT PHY ?

As far as link quality per-subcarrier(-group) is concerned, it seems to me that the CLT PHY may need to be aware of that only for the CNU that is trying to accomplish PHY acquisition/auto-negotiation. That information is needed for PHY layer procedures, e.g., determining supported MCS (per-plant or for this specific CNU, it does not matter). The US PHY Link could potentially be used also for periodic updates of this kind of information. I believe this could be a topic for the PHY Link ad-hoc.

Of note, when using MMP, the CLT PHY may store the MCS associated with each CNU. But that would require much less memory space (single value for each CNU).

On the other hand, as you say we do need statistics on the PHY link quality for debugging and management purposes. My thought was that this kind of information could be conveyed from the CNU to the CLT via upper layer procedures (e.g., OAM). In this way, storage capabilities of the PHY layer should not be a concern.

Hope this makes sense.

Thanks,
Nicola





From: Ed (Edward) Boyd [mailto:ed.boyd@xxxxxxxxxxxx]
Sent: 13 February 2013 00:52
To: STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx<mailto:STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx>
Subject: Re: [STDS-802-3-EPOC] Minutes

Hi Marek,

I found the same results as Duane in the specification.  The MDIO is a 16 bit address with half for vendor specific but 30K+ register addresses still available.  It seems that we have lots of address space if we need it.  We could easily add a layer of indirection to mux selected banks of statistics.  For example, on the CLT PHY, we could have a register to choose which CNU to monitor.  As I mentioned on the call, I don't think that the address space should be a reason for including or not including a statistic or monitoring function.   The question is whether the statistics are needed to properly monitor the link and enable algorithms to handle channel conditions.

As someone who spends a lot of time debugging systems, I'm a huge fan of monitoring statistics.  Large blocks of statistics are often implemented in RAM so the cost can be reasonable.  Based on the testing that we have done so far on EPoC, I would like to see many statistics included in the standard.  This system is much more complicated to debug than EPON and the statistic have been the only way to resolve issues and tune the system for higher performance.  We could decide to split the   statistics into a basic (required) set and an extended (optional) set.  Operators could specify a particular supported level of statistics in the PHY. I think that we have done this in the past on other managed devices.  Obviously, Broadcom, SIEPON, or CableLabs could use the vendor specific address area to specify the extended statistics but I'm not sure if that is the best solution.  Just a thought.

Thanks,
Ed....


From: Marek Hajduczenia [mailto:marek.hajduczenia@xxxxxxxxx]
Sent: Tuesday, February 12, 2013 2:14 PM
To: STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx<mailto:STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx>
Subject: Re: [STDS-802-3-EPOC] Minutes

Duane,

I believe you'd agree that creating a set of a few thousand registers for each CNU on the CLT would be at least "frivolous". The reason why I brought it up during the call today was that I did not really know what to expect and contrary to some opinions voiced on the call, register space is limited and does have associated cost, so the fewer registers we actually need, the better for us. We do have some register space left, but again, going and consuming a large share of that for just one project would not be a good way forward IMO.

Regards

Marek

From: Duane Remein [mailto:Duane.Remein@xxxxxxxxxx]<mailto:[mailto:Duane.Remein@xxxxxxxxxx]>
Sent: Tuesday, 12 February, 2013 9:53 PM
To: STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx<mailto:STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx>
Subject: Re: [STDS-802-3-EPOC] Minutes

Steve,
Sorry to have missed this call.
FYI I would have vote "Yes" on each of the straw polls.
I note from Table 45-3 that there are close to 31,000 registers still available and that some past projects have reserved large blocks of registers (see 1.340 through 1.699 & 1.740 through 1.1099 for example), apparently for some future function so it doesn't appear we are in jeopardy of breaking the bank on MDIO registers. That said I don't disagree that we should not be frivolous; defining sub-carrier groups could go a long way to conserving this limited resource.
Best Regards,
Duane

FutureWei Technologies Inc.
duane.remein@xxxxxxxxxx<mailto:duane.remein@xxxxxxxxxx>
Director, Access R&D
919 418 4741
Raleigh, NC

From: Shellhammer, Steve [mailto:sshellha@xxxxxxxxxxxxxxxx]
Sent: Tuesday, February 12, 2013 3:09 PM
To: STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx<mailto:STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx>
Subject: [STDS-802-3-EPOC] Minutes

All,

               Attached are the minutes of the RF Spectrum Ad Hoc call.  For those who were not on the call we held several straw polls which you can review.

Steve


________________________________

<="" p="">

________________________________

________________________________

<="" p="">

________________________________

<="" p="">

________________________________

________________________________

<="" p="">

________________________________

<="" p="">

________________________________________________________________________

To unsubscribe from the STDS-802-3-EPOC list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-EPOC&A=1