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]
Sent: Wednesday, 13 February, 2013 10:43 PM
To: 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
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
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]
Sent: 13 February 2013 11:12
To: Varanese, Nicola; 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
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
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
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]
Sent: Tuesday, 12 February, 2013 9:53 PM
To: 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
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
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