On 03/05/17 04:24 PM, Alex Pilon wrote: > On Wed, May 03, 2017 at 01:02:15PM -0400, Peter Sjöberg wrote: >> I'm currently in cottage country and internet here is limited. >> the people and I'm now wondering how it could be fixed. >> Setup is basically >> bell vdsl modem, wireless router -> unmanaged switch. >> From the switch it is a copper to fibre adapter and then fibre to each >> cottage. >> In each cottage it then goes to the phone (voip phone is connected to >> the switch) and on to a wireless router for each cottage. >> Issue is that out here the incoming speed is very low and any cottage >> doing any load kills everything. > > So you have a fairness problem, and you probably also have to deep a > buffer, hence the delay even were it fair. Probably so. They said the bell modem is a "commercial grade" one apparently intended for small businesses but I don't bet anything on that it's done anything to it besides having a higher price. > >> I have limited network knowledge but I'm thinking of removing the first >> wireless router (which I suspect is from when the pppoe info was >> required outside the modem), > > What do you mean? Was the modem in bridge or routing mode? Was the modem > itself configured with the PPPoE credentials or not? This was setup long time ago, and at that time the adsl modem might not been able to do pppoe it self = bridge only mode. The vdsl modem they have there now also have wifi that they can connect on so I guess it has the pppoe credentials configured. That means to me the little 4 port dlink router is now just masquerading the network once more and work as another single point of failure. > >> then put a managed switch in and then a rpi > > Uuunh, even though your cottage bandwidth is probably less than any of > the generations of RPis, the Ethernet NIC over the USB bus on a slow ARM > piece of Broadcom junk might introduce *just a little bit* of latency. Not in the path - on the side > >> to collect the info so they at least can see what port (=cottage) that >> use most bandwidth. > > So you just want to bridge traffic? no, hope I don't have to be in the path, at least not for a start, and if so I know I need something with better networking than USB "dongle" that (I assume) can't do true full duplex (since USB < v3 isn't true full duplex). It will just be a WUI that talk to the switch over snmp and collect info for something like mrtg. Possible also with other features like disable a port of an offender or so :) > >> My question is - what things should I look at? I'm guessing it exist >> apps/appliances for this purpose, does anyone know? > > Not *necessarily* needed. If the router runs Linux, or all the endpoints > run Linux. Linux QoS traffic control stack is all there is to it really. We talking off the shelf stuff so router/switch you can buy at computer stores. While they might run linux under the hood it's not like you have easy access to change anything not on the WUI. > All the rest is just a poor Netfilter substitute, or layers of UI and > wrappers. Just use a combination of tbf and fq_codel, or whatever fancy > combination you like if you want to give particular traffic strict > priority, particular weights, etc. Dunno what tbf or fq_codel is(yet, once I have decant internet I bet google can teach me that) but given that I suspect most traffic is https I imagine it's hard to segregate different types of traffic. > > If not running Linux, then whatever your OS is should similarly rate > limit the traffic to just a bit below what upstream *reliably* (not > nominally) provides. *reliable* is one of the problems, depending on what's done upstream it seems like the speed changes all the time. I suggested that they have bell to come over after it been raining hard for a week to check the copper cable but it sounds like it's very hard to get them to come at all (something like 1.5h drive from Kingston). They trying to get fibre direct to the rack, the junction is maybe 2km away but so far no luck in that area. > > It also helps if all your endpoints' network stacks do fair queueing, so > that applications on the same machine also fairly send traffic to > congestion-susceptible Wi-Fi. Endpoints would be in each cottage and they already have problems with things like people resetting the wireless router to factory default despite notes to not do that. Putting anything else than a standard router like a small computer would be another point of failure and possible drive the over all cost up. > > A full analysis of all possible sources of congestion is beyond the > scope of a single email. And beyond the scope of this project - at least for now. I'm just trying to help them a little as the summer comes, with monitoring capability and -if not that hard - possible some way to limit the traffic for offenders, not implement a final solution to all problems. My take on it is that if they can see what cottage that streaming videos it's a huge improvement that may help them over the summer. I'm also going tell them to check if they can get more connections that can then double the bandwidth (at worst half cottages on one and other half on the other). /ps