Re: [STDS-802-3-EPOC] Minutes
Hi Marek,
Thanks for the reply. I'm not sure that I understand the difference between the MDIO register and MIBs. If we want to get a statistic out of the PHY and into a MIB for SNMP, don't we need to define it in the MDIO interface? I would assume that we need to define both for PHY related items. Let me know if that isn't the case.
Thanks,
Ed...
From: Marek Hajduczenia [mailto:marek.hajduczenia@xxxxxxxxx]
Sent: Tuesday, February 12, 2013 5:10 PM
To: Ed (Edward) Boyd; STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx
Subject: RE: [STDS-802-3-EPOC] Minutes
Ed,
On the call, I confirmed the number of values that need to be recorded into registers to make sure we did not run aground too quickly. Storing all this data in the PMD registers will be a problem. 30k registers seems like an awful lot, but considering the number of parameters that would need to be stored and the fact that OLT might want to have track of these parameters on per CNU basis, I do not think that it is hard to imagine the 30k registers becoming quickly exhausted. Consider 128 CNUs connected to one CLT port, in which case "only" 232 registers per CNU. That is certainly much less than the number of subcarriers we envision. So yes, I do see a problem storing all this data in registers. I do not think it scales.
I think that if you want extensive statistics in the system, it is all fine, but we should not store these in registers. This is not what they were originally designed for. I am not arguing against the use of statistics in the system, but I am arguing about pushing all this data into hardware registers and then having to deal with the bloated memory requirements associated with that. If you want statistics for debugging, it is a MIB you need, and not a bunch of registers. Let's not mix these together because they have different purposes and are implemented in different fashions.
Marek
From: Ed (Edward) Boyd [mailto:ed.boyd@xxxxxxxxxxxx]<mailto:[mailto:ed.boyd@xxxxxxxxxxxx]>
Sent: Tuesday, 12 February, 2013 11:52 PM
To: Marek Hajduczenia; 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="">
________________________________________________________________________
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