Hacker News Reader

Comment by MBCook | Hacker News Reader

It’s only sort of passively mentioned in the article but I am AMAZED at the number of people who don’t hardwire everything they can.

Obviously phones are out, but why not hardwire every laptop when it’s at the desk? If someone’s using a actual desktop computer like an iMac then what’s the point of Wi-Fi? Clear up the signal space and get a 100% reliable and ultra fast connection.

View on HN

You could say the opposite I guess.

I'm AMAZED at the number of people that bother hardwiring everything they can for no reason when they have no interference issues.

Why go to all the effort of hardwiring every laptop at every desk?

If someone's using a laptop and moving around the office, why cable every desk when you can have gigabit wifi wherever you are?

Because gigabit wifi turns to 50mbps when the office gets big enough. There is only so much spectrum to use. Plus if you're already connecting monitors when you have your laptop at your desk the Ethernet adapter can be part of the dock.

When the office gets big enough, you reduce transmit power and add more access points so that there's enough spectrum to cover each desk.

Aruba Networks equipment was used at my alma mater, and is also used by $dayjob. I've also had good experiences with employers using Cisco Meraki.

Even a single AP, single client, 160 MHz AC wave 2 2x2 connection in clear airspace has less max theoretical throughput than a gigabit hardware (1.7 vs 2).

What makes a sane high density 5 GHz office design with 40 MHz channels (theoretical 400 mbit/s, real usually ~200-300) work is that office workers don't actually need that decent of a connection, just a guarantee voice jitter won't be >10 ms and that throughput will be "fast enough".

Wired:

PING 10.0.3.1 (10.0.3.1): 56 data bytes

64 bytes from 10.0.3.1: icmp_seq=0 ttl=64 time=0.737 ms

64 bytes from 10.0.3.1: icmp_seq=1 ttl=64 time=0.636 ms

64 bytes from 10.0.3.1: icmp_seq=2 ttl=64 time=0.701 ms

64 bytes from 10.0.3.1: icmp_seq=3 ttl=64 time=0.633 ms

...

--- 10.0.3.1 ping statistics ---

8 packets transmitted, 8 packets received, 0.0% packet loss

round-trip min/avg/max/stddev = 0.516/0.644/0.737/0.075 ms

Wifi:

PING 10.0.3.1 (10.0.3.1): 56 data bytes

64 bytes from 10.0.3.1: icmp_seq=0 ttl=64 time=6.713 ms

64 bytes from 10.0.3.1: icmp_seq=1 ttl=64 time=3.508 ms

64 bytes from 10.0.3.1: icmp_seq=2 ttl=64 time=2.425 ms

64 bytes from 10.0.3.1: icmp_seq=3 ttl=64 time=2.127 ms

64 bytes from 10.0.3.1: icmp_seq=4 ttl=64 time=4.057 ms

...

--- 10.0.3.1 ping statistics ---

22 packets transmitted, 22 packets received, 0.0% packet loss

round-trip min/avg/max/stddev = 1.429/3.769/16.722/4.054 ms

Depending on what you're doing, this can make a HUGE difference.

I'm interested in what situations 3ms difference (16ms max) makes a difference in an average office environment?

It makes a huge difference when copying lots of files over SMB, for example.

I've never heard that, but I also don't use SMB heavily (especially over Wifi) to begin with.

Is there a site you can point to that details the protocol's latency-sensitivity?

If something like bulk file transfer is at issue, a ping test with sizes closer to the MTU (e.g. 1480 bytes) would be a closer simulation of those latencies.

It's just what I've experienced myself when copying a lot of files. E.g. "add 50k photos from network drive to Photos" or "perform initial Time Machine backup". Over cable I'd say it's at least twice as fast, haven't done any measurements though.

That also raises the question of if it's implementation-dependent (especially if Apple optimizes AFP over everything else), rather than generally applicable to SMB, not that this would negate the validity of the example.

> Over cable I'd say it's at least twice as fast

That could be be because of the bandwidth difference, if wireless isn't 802.11ac (or if the cable isn't 100Mb/s).

Is it also the case that copying a single file of comparable size doesn't show the same speedup?

Although I'm skeptical (though see below), as the sibling comment is, that this small an increase in best case latency would make a difference in a typical office environment, I'm curious if it was (as close to) apples-to-apples as possible. That is, was it comparing 802.11ac to gigabit ethernet (or 54/108 Mb/s Wifi to 100Mb ethernet), and were the interfaces connected the same way (e.g. both via USB or both via PCIe/Thunderbolt)?

Despite my skepticism, I've seen that, in the typical office setting, wireless latencies can vary much higher. It stands to reason that, no matter how well-engineered, it's still a shared medium, which means that congestion or interference caused by a neighbor can ruin someone's VoiP call during the time it's happening.

Both computers are connected the same Unifi network. One was a Macbook Pro using the builtin wireless (ac; listed as 144 Mbps in the Unifi controller iirc) and the other a Mac Mini connected via cable (1Gbps). They both pinged the router, so all traffic was local. There are no other wifi networks nearby (single family house area, 50+ meters between houses), and basically no other traffic on the network.

We're about to move ~800 people into a new office and we're going Wi-Fi only when we do. Several reasons:

- Cost avoidance. Hard wiring a new fitout is expensive, and in our case costs $200k for the structured cabling alone (ignoring the switch port cost, and the fact that we'd be deploying Wi-Fi anyway for roaming)

- Better roaming experience. USB3 docking made the desk experience better for staff but USBC has made it worse again, to the point that we get all kinds of random crap happening when roving from wired to wireless. This could (and will eventually be) fixed with some attention, but when we were considering Wi-Fi only for the office, mitigating this issue was a nice bonus.

- Reduced end-user network requirements. With most end-user applications being moved behind a web interface, the trend is for far lower fat-client throughput requirements. I don't see that changing any time soon despite the additional bloat being introduced to a lot of web front-ends. There are still special cases that do have high throughput requirements (raw media work, mostly) but it's a fraction of the user base.

- ROI on existing wireless infrastructure. We have significant investment in a proven enterprise wireless infrastructure (Aruba) that we can extract far more value out of by bumping up access point density and attaching all clients onto.

- Competing nonsense avoidance. In my sector, fibre to the desk is the current load of bollocks that we're being railroaded into adopting. I've side-stepped that whole debacle by shifting us entirely across to something we had to deploy anyway - Wireless.

- It fits a theme. We're doing wireless stuff in a ton of other places at the same time: Wireless bluetooth headsets for telephony. Wireless screen casting (Miracast, Airplay and Chromecast) for meeting presentation. Wireless bluetooth conference phones for audio conferencing. If I could nail some kind of bluetooth webcam for vid conferencing, I probably would push for that that too.

- We have the underlying capabilities to effectively support wireless-only, such as dedicated network staff with appropriate skills (Wi-Fi is it's own specialist subject aside from conventional networking) and the right investigative/monitoring tools (in our case, Spectrum analysis, heatmapping, air monitoring and such all come out of the Aruba mobility controller/Airwave systems we already operate.

There are risks to doing this, and you want to run a solid proof-of-concept ahead of committing your organisation to it. But that's achievable, and there's no reasons a sufficiently mature organisation that's trying to work more flexibly can't treat wireless as a first-class connectivity option.

As a fellow large Aruba user I'd recommend extreme caution with how much you're pushing the BT stuff for telecommunications in a high density wireless environment. We've had that bite us in the ass a few times already. A lot of stuff doesn't mind running slower but telecommunication/video hates jitter, loss, and delay far more than anything else and you're putting it on the lowest end wireless infrastructure you have.

Yeah all of this coincides with moving people across to soft phones and headsets. Most users are heading to wired headsets which will keep a lot of Bluetooth out of the airspace, but a few will have BT headsets (and many have just obtained their own).

The other big gotcha with wireless is catering adequately for guest devices. In more permissive environments (such as ours), catering for 3 devices per staff member is a good starting point.

You also have to decide how/if you want to prioritize corporate over guest traffic, and that's not as straightforward as it first looks.

We're fortunate that our user base (800) is spread over a significant floor area, and four separate large floors. We're also pretty much alone in our space, so less outside interference to handle. It was far worse at my last organisation (also Aruba), where not only were we surrounded by very noisy neighbours but we also had far higher floor density, coupled with the navy docking right next to the building which would regularly wipe out our wireless, site-wide, for random amounts of time.

You got a wifi problem? I'll bring the cable.

Don't forget the dongle too.

Reply on news.ycombinator.com