Turn Off the WiFi

Yes, the STS mantra is to turn off the WiFi in order to insure the most available precious bandwidth for a streaming broadcast. For your terrifying entertainment, let me share what happened immediately after I turned off the WiFi for our stake conference broadcast yesterday.
__

At 45 minutes before broadcast, WiFi off at the meetinghouse farthest away in the stake.
Immediate text from them: The WiFi just went off.
Me: Yes, I turned it off so you will be able to receive the broadcast.
Them: My laptop doesn't have an Ethernet connection.
Me: The one you were going to use for the broadcast?
Them: Yes.
Me: Go find another one. You have 43 minutes.

A leader who lived near the building went home and got his laptop.
__

At 44 minutes before broadcast, WiFi off at stake center.
Immediate text from them: The WiFi just went off.
Me: Yes, I just turned it off for the broadcast.
Them: Turn it back on. I need the WiFi to set up the encoder for the broadcast.

I missed that last text. When I didn't respond, another STS, who had a laptop with a bad Ethernet card went to a clerk's office and turned the WiFi back on. They finished setting up the encoder and started the broadcast, after which the other STS again turned off the WiFi at the stake center. The person starting the broadcast had been using a tablet to load the encoder.
__

I came to the realization that many laptops today just use wireless connections. And although I have an Ethernet port on my own laptop, I got to thinking that I never use it, except for streaming Church broadcasts. At home, I just hit my wireless router from my favorite location at the moment. (Well, I do recall using it one other time to program the router.)

I visited with several members who I knew had recently obtained laptops. None of them had an Ethernet connection. I began seeing a future with USB to Ethernet adapters. One more item to lose on the way to the meetinghouse.

In the past, I have turned off the WiFi about 10 minutes before the broadcast. In the far away meetinghouse, 400 members would have missed the first part of conference if I had done that this time.

End of terrifying entertainment.

I experienced a similar thing at our conference, luckily I had a spare with me that could be wired. It seems the tablet type laptops are going the wireless way. I don't know if this is good or bad, but it is frustrating.

Thanks for this. I for one am glad that I decided to use the clerk computers as my receivers. They are hardwired to the network and the video and audio is sent to the distribution system via a CAT 5E cable. I used to use RCA until we got the new distribution amplifiers from the church and now we will be running VGA from the computer to the amplifiers. Then it will be connected into the church TV distribution system.

So I don't have to worry about WiFi in my stake.

Terry

While taking my turn at the temple's recommend desk, I like to examine the tablet/laptop used there to check recommends. I noticed that it has no Ethernet port, but rather used a USB-to-Ethernet adapter. That was the first computer I had seen for the past 20 years or so that did not have an Ethernet port, but I agree that such ports are becoming obsolete, as did serial ports, parallel ports, Firewire ports, and diskette drives. Even DVD drives are vanishing.

harddrive wrote:So I don't have to worry about WiFi in my stake.

Be careful. It depends on your Internet speed. In our stake, there are times when the clerks cannot do their work because the WiFi users are taking up so much of the bandwidth. Even using the administrative computers, we would never attempt a streaming broadcast, sending or receiving, without turning off the Wifi.

lajackson, any time I do a streaming broadcast, I do turn the WiFi off. What I was referring to was the fact that none of the receiving sites are using laptops that require WiFi to receive or set up the broadcast. I am using the clerk's computers and they are hardwired into the network. Personally I'm old school and prefer the hardwired connections over wireless.

I turn the wifi off at the receiving sites and verify the computers have ethernet connections the day before. I sometimes keep it on at the stake center that morning until the broadcast is started an hour before. I really do wish we had a private wifi network we could always leave on.

We do a complete test of all broadcast and receive site equipment 2 weeks before conference. On conference morning, broadcasting (Bible videos, MoTab Choir, etc) & receiving begins at 8:30am to allow time to handle any last minute problems that may occur. Sound checks are also done periodically during this time. We also plug an old AccessPoint into the LAN so we have our own private WiFi, which we share with leaders and speakers if necessary. A 2nd STS, watching the broadcast from home, is the clearinghouse for any phone calls from receive sites experiencing problems.

Would it be possible to stop messing around with turning off wifi and put some rules in the firewalls along the lines of:

• Traffic going to the webcast servers (ie: portal.ldswebcast.org and mhw*.cloudapp.net gets Priority 1
  Traffic going to MLS servers (or other clerk related sites) gets Priority 2
  Traffic going to familysearch.org, etc gets Priority 3
  All other traffic gets Priority 4

That should take care of most of the slowdown issues and still let people use the internet during conferences.

Aaron Z

Aczlan wrote:and put some rules in the firewalls along the lines of:

I'm not up on network protocols, but I doubt if you can control the priority from the narrow end of the funnel (chapel side). You'd have to control it from the wide end (ISP side). Once the packet has arrived past the bottle neck, it's done it's damage.

You can do a fair amount on the firewall side. Its not perfect, but it helps.
I used to work with a bunch of libraries and throttling made it so that even libraries with a lot of kids online (playing games like Minecraft or watching videos) could still do core functionality (checking out books, placing holds, etc). Before we implemented filtering, their connection was swamped to the point where the firewall was not responding regularly to pings (ie: ping times went from 30-40ms to 300+ms and 1/3 of the pings were not responded to). We implemented filtering (no other changes) and things still got slow, but they could do their work,

Alternatively, how about a way to switch on a device whitelist for wifi or internet access?
Connect your devices, pick which ones are critical (automatically whitelist all static addresses, then have checkboxes from a list of DHCP leases). Once its turned on, only the devices on the whitelist can access the internet. That would also allow the speaker to connect and use a device on the wifi without letting everyone else swamp the internet.

Aaron Z

I don't think the church is going to roll out a management interface to customize access for every meetinghouse. That would be a management nightmare. Some buildings have barely enough bandwidth to run a conference as it is. Turning off the WiFi is the safest way.

Turning off wifi works until you run into issues (like have been discussed in this thread) where you don't have the option to use a wired network (ie: using a tablet or a laptop without an Ethernet port).
IMO, those issues will become more prevalent as time goes on.

As for a management interface being a nightmare, thats that the Technology Manager already does, it lets you enable/disable wifi, it lets you reboot firewalls, view logs, view stats, view debug info, etc.
If you view a firewall and click on the gear next to a Zone with DHCP turned on, you will see a list of DHCP reservations there.
If you go to the ISP tab, it shows the advertised bandwidth (which is needed to do throttling)
What would be needed (to do a connection whitelist) would be a page to select from those addresses, put them in an ACL Object Group and activate a ACL that only allows the devices in the Object Group to access the internet.
I would redirect all other connections to a page that says "Your internet has been disabled to preserve bandwidth for a broadcast in progress. Thanks for your understanding, your access should return after the meeting when it is turned on, or automatically at HH:MM on DD-MMM-YYYY" (the date being an auto timeout X hours after it was disabled).

Aaron Z

Acxlan,

The problem isn't at the firewall it is with the service providers. Once the packet leaves our router/firewall with a QOS bit set, the routers on the Internet will ignore that bit and everything on the Internet is best effort. So for inbound traffic to the firewall from the ISP would not be prioritized because the service provider won't honor the QOS bit. The Internet is just a free service and it is first come first serve and it will always be best effort.

The other issue is that no matter how much bandwidth you put in the old saying is true, you build it they will come. People will use bandwidth like its candy. So the best thing to do is turn off WIFI and that is easy with one click on the access point tab in TM.

Aczlan wrote:Turning off wifi works until you run into issues (like have been discussed in this thread) where you don't have the option to use a wired network (ie: using a tablet or a laptop without an Ethernet port).
IMO, those issues will become more prevalent as time goes on.

And we've already discussed the word arounds. If desperate, you can plug a home router into the hardwired jack and then just share the id/password with the very few that would need it.

Yes, I can (and have) used a "home AP" (although, it was running OpenWRT not the stock firmware). It would just be nice to be able to have the wifi on

On QOS, I have seen where adding QOS on a library network made a saturated network usable for staff functions (IIRC, it was a 5mbps x 384kbps network with 7 public computers and 3 staff computers).
In that case (which I suspect is the case here), the uplink was saturated (IIRC the cablemodem stats said that the downlink was at 50-60% and the uplink was at 100%).
As such, rate limiting by the firewall made a huge difference because it reduced the outgoing traffic a little and sent the high priority traffic first.

Aaron Z

Aczlan wrote:In that case (which I suspect is the case here), the uplink was saturated (IIRC the cablemodem stats said that the downlink was at 50-60% and the uplink was at 100%).
As such, rate limiting by the firewall made a huge difference because it reduced the outgoing traffic a little and sent the high priority traffic first.

If the uplink is saturating, I can see how that helps. But I'm more concerned about the downlink. I think when you start streaming a video that uses up much of the downlink, that changes the dynamic.

I'd also note that your library has a down to up ratio of 13. The worst in my stake is 7. (Others are 3 and 5). Given the high ratio at your library, I can see why your uplink might saturate first. But since my buildings have a lower ratio, that may not play out the same way for me.

Russellhtn is correct. When you are looking at download (receiving a webcast) then it is coming from the Internet first come first serve. Again, on the Internet there is no QOS honored. The only way you can control uplink is from your source building, but at the receiving building, all bets are off. You will be at the mercy of the Internet. That is why you turn off WIFI, so that you don't have users downloading their updated apps, or streaming a movie or anything like that.

In new buildings, there is a network drop at the podium. In older buildings, 85% of my buildings are old, so there is no network drops at the podium. So WIFI is the easiest, but I decided a while back to hard wire the clerks' offices and the bishops office just because I don't care for WIFI. It is good, but it can be too flaky and for streaming stake conference, I wanted to have a clean reliable connection.

If you want reliable webcasting, then time will need to be invested to bring old buildings up to snuff. I think we all have had to do that. I know that I have.

Terry

I think the newest building in my stake was built in the 70s. When the Internet was installed, my local FM group put in a jack for the podium (and the clerk's office) in each case. It may take a budget cycle (and right now would be a good idea for planning 2017), but I think you can get FM to install a jack.

Our FM Group was willing to hardwire the pulpit and each clerk's office with barely a mention that it would be a nice thing to have.