Hi Jonas,

> On Jan 14, 2022, at 14:50, Jonas Mårtensson <martensson.jo...@gmail.com> 
> wrote:
> 
> >  Not all ISPs work with a single level of splitters, some do 1:4 and split 
> > each of the four up into more later, I would guess that 1:4 + 1:8 will have 
> > a bigger aggregate attenuation than going 1:32 directly, but I am guessing 
> > here, so thanks for the numbers.
> 
> It will be slightly higher, mainly due to the extra splices I think, but 
> other than that there is no fundamental difference between doing 1:32 and 
> doing 1:4 + 1:8. The fundamental loss is 3 dB per 1:2 split.
> 
> > In Germany the law is as it is and requires a passive handover point of an 
> > ISPs network to the home network and also the freedom to choose routers 
> > (and probably also ONTs/ONUs but that is still in flux), so plugs will be 
> > common as will be exchange of ONTs/ONUs by end-users.
> 
> That's interesting. I would think that exchanging ONUs is quite tricky (as 
> also indicated by the "hacking" threads discussed earlier) since OLTs and 
> ONUs from different suppliers may not even be compatible.

        Well the big incumbent has a process under test which might require one 
phone call to transmit one important number after which a compatible ONT (there 
is a compatibility list I think) can and will be provisioned, so this is 
possible. And given that GPON is an ITU standard I would assume that unless 
vendoe-specific extra features are used ONTs should be compatible.


> Can't the "passive handover point" be between the ONU and the home router?

        That is under discussion. The BEREC describes three hand-over points, 
one passive before the ONT, one at the ethernet port of an ONT (or maybe the 
cage-end of an SFP-module) and/or behind an ISP supplied router (see 
https://berec.europa.eu/eng/document_register/subject_matter/berec/regulatory_best_practices/guidelines/9033-berec-guidelines-on-common-approaches-to-the-identification-of-the-network-termination-point-in-different-network-topologies).
 The German law however is clear, the termination point needs to be passive 
(unless there is an explicit exemption granted by the national regulatory 
authority NRA) OR the ISP declares an device as part of its active network, but 
then the ISP needs to cover the electricity cost of that device. The NRA BNetzA 
has communicated that it expects ONT to be treated the same as routers (for 
which the law grants freedom of choice by end-users) and that it is 
unlikely/unwilling to grant exceptions unless there are excellent reasons to do 
so (so far ISPs did not bring forward convincing arguments for not offering a 
passive termination point, as far as the BNetzA is concerned).


> In Sweden (where FTTH is very common but PON is almost non-existing), the ISP 
> normally installs both an Ethernet "switch" terminating the fiber (typically 
> using an SFP) and a home router connected to the switch using copper Ethernet 
> cable. While it is common to exchange the home router (or selecting to not 
> install the ISP's router from the beginning), I don't think anyone exchanges 
> the switch with the fiber termination and doing so would probably not work 
> anyway since the switch needs to be "managed" by the ISP.

        German law allows for that, as long as the ISP covers the electricity 
bill of that switch (operating it as part of the ISPs own active network), the 
termination point then would be the CatN-socket in each flat. The goal in 
Germany is true FTTH where each dwelling unit/flat has its own fiber connection 
(and then AON becomes pricy, you need to run all those fibers to COs and then 
have enough room for the required patching/splicing, with fiber taking more 
room than coper).


Regards
        Sebastian


P.S.: While AON is the technically better solution (you can always easilyput a 
splitter in a CO and run X direct fibers as a PON, but try the same when the 
spillters are out in the field much closer to the end-users than the CO and 
there are not enough fibers between splitter and CO). Telcos especially 
incumbents however prefer PON for a number of reasons:
a) price, it simply is cheaper, fewer fibers to pull and terminate and OLTs 
appear smaller and cheaper that active switches that can supply a similar 
number of end-nodes.
b) control I: if a telco builds a PON plant every user of that PON will owe the 
incumbent some money
c) control II: no competitor will be able to offer more advanced technology 
over a PON than its owner.

> 
> /Jonas
> 
> On Fri, Jan 14, 2022 at 2:23 PM Sebastian Moeller <moell...@gmx.de> wrote:
> Hi Jonas,
> 
> 
> 
> > On Jan 14, 2022, at 14:12, Jonas Mårtensson <martensson.jo...@gmail.com> 
> > wrote:
> > 
> > >  Sure, but given that you probably need a few splices along the way and 
> > > preferably pluggable connectors at both ends the loss budget is not that 
> > > large (assuming an ISP does not want to push its luck and allows for 
> > > stuff like end-users not cleaning the plug diligently before each 
> > > plugging).
> > 
> > GPON loss budget is 28 dB and typical insertion losses for 1:32 and 1:64 
> > splitters are 17 dB and 21 dB. This leaves 11 dB or 7 dB for splices, 
> > connectors and fiber losses. I don't think it's common to have end-users 
> > cleaning and plugging in the fiber, this is done by the ISP technician at 
> > installation.
> 
>         Not all ISPs work with a single level of splitters, some do 1:4 and 
> split each of the four up into more later, I would guess that 1:4 + 1:8 will 
> have a bigger aggregate attenuation than going 1:32 directly, but I am 
> guessing here, so thanks for the numbers. In Germany the law is as it is and 
> requires a passive handover point of an ISPs network to the home network and 
> also the freedom to choose routers (and probably also ONTs/ONUs but that is 
> still in flux), so plugs will be common as will be exchange of ONTs/ONUs by 
> end-users. Whether that is a good or a bad thins is open for discussion, but 
> as an ISP I would try to plan my PON plant such that there would be more loss 
> reserve for these final connections than would be if these would be performed 
> and documented by trained technicians. (I think that might be one of the 
> consequences of deploying FTTH in the mass market, solutions need to be a bit 
> more error tolerant than for networks mainly handled by experts only.)
> 
> > 
> > > Dslreports has no cue what a link is actually using, all it reports wich 
> > > test profile a user selected, and some users like me ignore the names and 
> > > simply use/recommend the profile with the desired number of flows. Plus 
> > > quite a number of dedidedly metallic access technology are marketed with 
> > > fiber somewhere in the name, potentially confusing users into selecting 
> > > the "wrong" profile (think Fiber to the Cabinet for copper DSL or even 
> > > Hybrid-Fiber-Coax for docsis cable)... in short the abels are nice, but I 
> > > would not read too much inside those.
> > 
> > I agree with all these points. It may be better to look at ISPs that are 
> > known to only use PON, such as Google Fiber. Here are some recent tests 
> > that all show similar and interesting bufferbloat behaviour on the uplink:
> > 
> > https://www.dslreports.com/speedtest/70320015
> > https://www.dslreports.com/speedtest/70346586
> > https://www.dslreports.com/speedtest/70346578
> 
> Thanks!
> 
> Best Regards
>         Sebastian
> 
> 
> 
> > 
> > /Jonas
> > 
> > On Fri, Jan 14, 2022 at 12:55 PM Sebastian Moeller <moell...@gmx.de> wrote:
> > Hi Jonas,
> > 
> > 
> > > On Jan 14, 2022, at 11:44, Jonas Mårtensson <martensson.jo...@gmail.com> 
> > > wrote:
> > > 
> > > Hi,
> > > 
> > > >  getting gpon more right has increasingly been on my mind
> > > 
> > > I think more right is to not turn the fiber into a shared medium in the 
> > > first place but since gpon is so popular, improving it seems like a nice 
> > > goal.
> > > 
> > > > Nobody in their right mind is going to hook up 128 terminalt to one OLT 
> > > > port, I hope...
> > > 
> > > Well, sharing one OLT port between many terminals is kind of the (only) 
> > > advantage of PON, although split ratios of 32 or 64 are more typical. But 
> > > often it's the loss budget that limits the ratio.
> > 
> >         Sure, but given that you probably need a few splices along the way 
> > and preferably pluggable connectors at both ends the loss budget is not 
> > that large (assuming an ISP does not want to push its luck and allows for 
> > stuff like end-users not cleaning the plug diligently before each plugging).
> > 
> > 
> > > 
> > > >  Fist question might to be "how broken is GPON/XGPON" to start with, no?
> > > 
> > > Looking at dslreports bufferbloat results for fiber, there are many 
> > > samples with >250ms latency on the uplink. Unfortunately, this graph 
> > > doesn't show results for 500Mbit/s or 1Gbit/s services but it's still 
> > > interesting to look at:
> > > 
> > > https://www.dslreports.com/speedtest/results/bufferbloat?up=1
> > 
> >         Dslreports has no cue what a link is actually using, all it reports 
> > wich test profile a user selected, and some users like me ignore the names 
> > and simply use/recommend the profile with the desired number of flows. Plus 
> > quite a number of dedidedly metallic access technology are marketed with 
> > fiber somewhere in the name, potentially confusing users into selecting the 
> > "wrong" profile (think Fiber to the Cabinet for copper DSL or even 
> > Hybrid-Fiber-Coax for docsis cable)... in short the abels are nice, but I 
> > would not read too much inside those.
> > 
> > 
> > > 
> > > >  this thread 
> > > > https://www.computerbase.de/forum/threads/eigenes-modem-an-ftth-anschluss-via-sfp-gpon-modul.2061989/
> > > >  (in German) has some instructions how to get root on one type of SFP 
> > > > ONU...
> > > 
> > > Thanks, that's an interesting thread. "Hacking" SFP ONUs seems like a 
> > > popular hobby. Here are some other resources I found:
> > > 
> > > https://github.com/zry98/SFP-GPON-ONU
> > > https://github.com/hwti/G-010S-A
> > > https://forum.mikrotik.com/viewtopic.php?t=116364&start=300#p771961
> > 
> > Thanks for the links!
> > 
> > Regards
> >         Sebastian
> > 
> > 
> > 
> > 
> > 
> > > 
> > > > so pulling  a testbed together of some sort would be cool, and for that 
> > > > matter, having a SFP that could go right into a SFP enabled home router 
> > > > rather than a separate unit seems like a good idea, also
> > > 
> > > Yes, but ideally I guess you would also need some control of the OLT 
> > > side. You may want to look into the VOLTHA project run by ONF:
> > > 
> > > https://wiki.opennetworking.org/display/COM/VOLTHA
> > > 
> > > /Jonas
> > > 
> > > On Thu, Jan 13, 2022 at 5:29 PM Sebastian Moeller <moell...@gmx.de> wrote:
> > > Hi Dave,
> > > 
> > > 
> > > 
> > > > On Jan 13, 2022, at 16:59, Dave Taht <dave.t...@gmail.com> wrote:
> > > > 
> > > > On Thu, Jan 13, 2022 at 7:57 AM Sebastian Moeller <moell...@gmx.de> 
> > > > wrote:
> > > >> 
> > > >> Hi Dave,
> > > >> 
> > > >> 
> > > >> this thread 
> > > >> https://www.computerbase.de/forum/threads/eigenes-modem-an-ftth-anschluss-via-sfp-gpon-modul.2061989/
> > > >>  (in German) has some instructions how to get root on one type of SFP 
> > > >> ONU... (I was monitoring that thread for general interest, turns out 
> > > >> the intel falcon plattform seems somehow based on an ancient OpenWrt)
> > > >> 
> > > >> Regards
> > > >>        Sebastian
> > > > 
> > > > It's really remarkable how many places are running an ancient openwrt.
> > > > Starlink's use was not an abomination, but a persistent reality. Given
> > > > how much
> > > > chaos calmer I've found, I sometimes wish we'd somehow started the
> > > > cerowrt project 2 years earlier.
> > > 
> > >         Yes and no.
> > > 
> > > > Then we'd be done by now.
> > > 
> > >         Hopefully, but then I would not have noticed the whole thing and 
> > > would probably not have participated... ;)
> > > 
> > > Regards
> > >         Sebastian 
> > > 
> > > 
> > > 
> > > > 
> > > >> 
> > > >>> On Jan 13, 2022, at 15:38, Dave Taht <dave.t...@gmail.com> wrote:
> > > >>> 
> > > >>> And a gpon onu
> > > >>> 
> > > >>> https://www.fs.com/products/133619.html
> > > >>> 
> > > >>> On Thu, Jan 13, 2022 at 6:23 AM Sebastian Moeller <moell...@gmx.de> 
> > > >>> wrote:
> > > >>>> 
> > > >>>> That is similar to what happens in some GPON-ONT SFPs, some run a 
> > > >>>> full small Linux distribution like OpenWrt inside.... though for 
> > > >>>> ethernet that is unexpected.
> > > >>>> This is also similar to SFP VDSL "modems" which likely run their own 
> > > >>>> embedded OS as well inside the SFP package (at a time there was even 
> > > >>>> a PCI VDSL2 "modem" that was actually running its own embedded 
> > > >>>> system on the PCI board, IIRC, it pretended to the main computer to 
> > > >>>> be an ethernet NIC).
> > > >>>> 
> > > >>>> Regards
> > > >>>>       Sebastian
> > > >>>> 
> > > >>>> 
> > > >>>> 
> > > >>>>> On Jan 13, 2022, at 15:18, Dave Taht <dave.t...@gmail.com> wrote:
> > > >>>>> 
> > > >>>>> running linux, of course.
> > > >>>>> 
> > > >>>>> https://blog.benjojo.co.uk/post/smart-sfp-linux-inside
> > > >>>>> 
> > > >>>>> --
> > > >>>>> I tried to build a better future, a few times:
> > > >>>>> https://wayforward.archive.org/?site=https%3A%2F%2Fwww.icei.org
> > > >>>>> 
> > > >>>>> Dave Täht CEO, TekLibre, LLC
> > > >>>>> _______________________________________________
> > > >>>>> Cerowrt-devel mailing list
> > > >>>>> Cerowrt-devel@lists.bufferbloat.net
> > > >>>>> https://lists.bufferbloat.net/listinfo/cerowrt-devel
> > > >>>> 
> > > >>> 
> > > >>> 
> > > >>> --
> > > >>> I tried to build a better future, a few times:
> > > >>> https://wayforward.archive.org/?site=https%3A%2F%2Fwww.icei.org
> > > >>> 
> > > >>> Dave Täht CEO, TekLibre, LLC
> > > >> 
> > > > 
> > > > 
> > > > -- 
> > > > I tried to build a better future, a few times:
> > > > https://wayforward.archive.org/?site=https%3A%2F%2Fwww.icei.org
> > > > 
> > > > Dave Täht CEO, TekLibre, LLC
> > > 
> > > _______________________________________________
> > > Cerowrt-devel mailing list
> > > Cerowrt-devel@lists.bufferbloat.net
> > > https://lists.bufferbloat.net/listinfo/cerowrt-devel
> > 
> 

_______________________________________________
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

Reply via email to