User talk:Nightwalker/IEEE 802.3
Appearance
Non-TP PHY table
[edit]So, where do we start here?
- FIXED I doesn't make too much sense to fix all errors and then merge the table with the present tables that don't have those errors. Basically, overhaul your table as replacement or migrate details to present table? I'd favor the latter.
- --> Will overhaul and extend my table as a suitable replacement, as it already unifies formatting and as I've gone through the content of the exisitng tables already when creating it. I'd prefer to have it completed and corrected where necessary.
- --> in general: I'd like to create a complete coverage first, before optimising the table in it's layout & size (e.g. grouping redundant info to save space).
- FIXED The FC column needs to be less fiber-specific.
- --> Separated the FC & connector columns.
- FIXED The fiber detail columns are a bit out of place with non-fiber PHYs. How about using a Reach column instead with the allowed cable specifications?
10BASE5 RG8X: 500 m 10GBASE-SR 160 MHz·km: 26 m
200 MHz·km: 33 m
...
- --> Yes, that would also save quite some space, nevertheless the related colouring for the respective fibre types should be preserved. --> sub-cells to be introduced...
- FIXED The Media count column should maybe indicate lanes and total media count as well. Currently it's a mix, see 10GBASE-CX4 actually using 2×4 lanes. How do we do that?
- --> Could be split into two columns if fibre columns are cocatenated into the range column.
- The Symbol coding column needs some refinement – it's either about the PCS only or all sublayers. Currently, it's a mix.
- FIXED IMHO, the table has to be split into the different speed classes – a single table is too long and precludes any class comments.
- --> Can be done at the end; this is useful to maintain the article structure.
- I don't think diving into the transceiver type topic is a very good idea – transceivers aren't covered by 802.3 and vary greatly, leading to more confusion than clearness. I think we should leave it to their respective articles except for SFP+, CFSP etc that are used as PHY substitutes. Additionally, transceivers are no media connectors, so possibly we should have a separate transceiver column?
- --> Partially agree; they are now in a separate column. Maybe it's more favourable to have uncovered transceivers in italic or with a subnote.
- FIXED Notes need to be revised/added to the new table format.
@Zac67: You may have another look at it now. Nightwalker-87 (talk) 20:56, 2 August 2018 (UTC)
--Zac67 (talk) 11:36, 30 July 2018 (UTC)
- Good job - I've just corrected a few minors, will continue tomorrow. --Zac67 (talk) 20:39, 2 August 2018 (UTC)
- Thx for your feedback and the assistance. I'm very happy with the result.
BTW: What is the actual line rate for 10/100/1000 MBit/s Ethernet? Unfortunately I could not find that out yet.
Will continue with 25GbE and more recent standards ... Nightwalker-87 (talk) 20:56, 2 August 2018 (UTC)
- Thx for your feedback and the assistance. I'm very happy with the result.
- @Zac67: Yet another update: 40GbE. Can you add/correct any missing info?. Thx. Nightwalker-87 (talk) 14:47, 5 August 2018 (UTC)
- @Zac67: Update: 50GbE. Can you add/correct/revise any missing info? Thx. Nightwalker-87 (talk) 19:45, 8 August 2018 (UTC)
- Sorry for keeping you waiting, I'll get to it shortly. Some thoughts:
- Why don't we include TP PHYs?
- FIXED where not useful We should only mention the minimum cable/fiber grade necessary for a PHY and include those that are mentioned in the standard (or in RS). There's little benefit in repeating OM2 reach for OM3, OM4, ...
- --Zac67 (talk) 21:28, 13 August 2018 (UTC)
- Sorry for keeping you waiting, I'll get to it shortly. Some thoughts:
- Hi Zac67: No Problem. Looking at the table I can already see quite some progress, but it will take a little more time to complete.
Can you give a representative example for TP PHYs as you could imagine your idea?
Regarding the cable fibre/grade: I'm with you here if these are simply "duplicates". Here one should keep an eye on which fibre types were common in the time of standardisation. Use of succeding fibre grades introduced after availablity of the respective standard should only be given if the reach is exactly definable (ideally verifiable by source). I believe this is also what you meant. Nightwalker-87 (talk) 13:04, 15 August 2018 (UTC)
- Re leaving out TP PHYs: we could theoretically group all PHYs by medium – coax, TP, twinax, MMF, SMF – which I don't think is a very good idea; grouping by speed makes more sense. Doing TP separately and all the rest together doesn't make too much sense to me – what are you aiming at? --Zac67 (talk) 18:16, 20 August 2018 (UTC)
- @Zac67. Hi there. I'd prefer not to group by medium in general, but though leave the copper TWP variants seperate as this is what most readers will look at. Also the specs for the latter are quite different to the other physical transport layers (TP-PHY), so bringing together both in one table just to have all standard flavours together does not seem to make much sense. Instead it might even turn out harmful in terms of readability and understanding. Looking at this the current state (apart of some necessary additions and correction seems quite reasonable to me.
I currently updating the specs for 50GbE, which is in preparation for standardisation this year. Maybe you can keep an eye on this as well. Beginning from (50GbE?) 100GbE toward newer standards specs like line code and line rate should be named separately for the different flavours as these parameters can either derive from the 10GbE or the 25GbE evolution path. Otherwise the table would remain too unspecific regarding this. In general it looks like I can see light at the end of the tunnel. There's not too much work left. Nightwalker-87 (talk) 16:59, 23 August 2018 (UTC)
- @Zac67. Hi there. I'd prefer not to group by medium in general, but though leave the copper TWP variants seperate as this is what most readers will look at. Also the specs for the latter are quite different to the other physical transport layers (TP-PHY), so bringing together both in one table just to have all standard flavours together does not seem to make much sense. Instead it might even turn out harmful in terms of readability and understanding. Looking at this the current state (apart of some necessary additions and correction seems quite reasonable to me.
- @Zac67. I've updated the info on symbol rates and line rates. It is desireable that these parameters are correct. Can you verify/correct these? Unfortunately I could not find all missing specs during my research on the web. :-/ Nightwalker-87 (talk) 14:55, 25 August 2018 (UTC)
- @Zac67. I think it's your turn again. The table seems to be mostly complete by now with a few open points left, especially for the newest standards. It might want some minor corrections here and there though. Please have your say and let me know when you feel that we are ready to transfer the work to the dedicated wiki articles. Nightwalker-87 (talk) 20:08, 29 August 2018 (UTC)