I know of two buildings that have 10Mbit download but .4 - .5 upload and they bottlekneck at 60 - 70 users.russellhltn wrote:I have one building with DSL and 3 overlapping wards. I think it's 3Mbit. And the usage graphs do flat top at 3000kb/s. DHCP reports 80-90 users. I've not heard any complaints from that building.
I called to have a couple of questions answered about the process and they completed the creation of the SPZ within just a few seconds. Don't make the call until AFTER you have moved the FHC to port 2 or your FHC will be offline until you do.CleggGP wrote:This being said, STSs must remember to contact the Global Service Center to create a Special Purpose Zone if an "official" FHC exists in the meetinghouse. It may take a 2-3 days for the SP Zone to be created (due to GSC staffing levels), so take that into account when planning the firewall upgrade.
Interesting. Our DSL doesn't go that low. More like .768. But even then I wonder what's going on since that still seems sufficient unless someone is uploading photos, etc.rolandc wrote:I know of two buildings that have 10Mbit download but .4 - .5 upload and they bottlekneck at 60 - 70 users.
Prioritizing clients would be a mess since it would require some method of identifying the client.aclawson wrote:These firewalls can easily prioritize specific clients with QoS - it is baffling that they have not been programmed to do so.
Exactly. Since we know which clients are official devices (webcaster, clerk machines) then prioritize traffic going to/from those devices.russellhltn wrote:Most QoS I've heard of is based on traffic type or perhaps where it's going to/from. For example, prioritize lds.org and 10.x.x.x traffic.
Packet sniffer between the clients and the firewall on the meetinghouse side.russellhltn wrote:I'd like to find a way to monitor the traffic so I can learn what's going on.
Even something as simple as giving priority to wired over wireless clients would help in many meetinghouses.russellhltn wrote:Prioritizing clients would be a mess since it would require some method of identifying the client.
When you use Wireshark for your packet captures. You will discover that when MLS connects to the SLC it will use an Internet IP address and not a 10.x.x.x address. So QOS will not help unless you get the correct Internet IP address and then it will only work on the last mile because the Internet does not support QOS tagging.aclawson wrote:Exactly. Since we know which clients are official devices (webcaster, clerk machines) then prioritize traffic going to/from those devices.russellhltn wrote:Most QoS I've heard of is based on traffic type or perhaps where it's going to/from. For example, prioritize lds.org and 10.x.x.x traffic.
Packet sniffer between the clients and the firewall on the meetinghouse side.russellhltn wrote:I'd like to find a way to monitor the traffic so I can learn what's going on.
Good point. You can prioritize requests going out, but I don't know if there's any way to manage what comes back in from our end.harddrive wrote:So QOS will not help unless you get the correct Internet IP address and then it will only work on the last mile because the Internet does not support QOS tagging.