Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

MIT CSAIL network design principles

tig.csail.mit.edu

Post reply on HN
Print view View original

21–30 of 30 posts

Re: MIT CSAIL network design principles

#21

Post by lucb1e »

dsr_ wrote: post #19
lucb1e wrote: post #16

> Ensure that at least one signal in every neighborhood is on a U-NII-1 or U-NII-3 channel. This ensures that, even in the case of a radar hit that takes out multiple U-NII-2 channels, at least one channel is available that is not subject to the Dynamic Frequency Selection rules and will not have to change channels. I don't understand this, can someone explain this in layman terms? Are they near some military base si…

"The Boston Logan Airport Terminal Doppler Weather Radar (TDWR) operates on 5.610 GHz, which is wireless channel 120."

Aha I read over that one! Thanks

Re: MIT CSAIL network design principles

#22

Post by kkylin »

dreamcompiler wrote: post #10

So in summary here's what we know: 1. The building's weirdly-shaped vertical spaces cause signal interference that cannot be mitigated by the 802.11 automatic mechanisms. 2. The building was not originally wired (or at least not wired properly) for ethernet. 3. The building is a Faraday cage, but not a useful one because it interferes with wifi penetration while exterior radar signals can still get in and block some…

And ventilation, apparently. I was told [0] that it had been designed with open spaces in mind. And when research groups decided they didn't like people walking through spaces where people are working (esp working on hardware) and put up partitions and doors, that messed up the air circulation. Also, and somewhat ironically, I was told that despite the open design, people were runnning into each other less often than in the old Tech Sq building (with its much smaller lobby), missing out on serendipitous interactions.

[0] Private communication

Re: MIT CSAIL network design principles

#23

Post by wolverine876 »

punnerud wrote: post #5

A key tool mentioned in the article is Ekahau Pro. What are good alternatives for Ekahau? As I understand this require special hardware. Most Macs support WiFi Monitor mode that should be possible to give the same functionality without extra hardware. And is only 5Ghz working on M1? So I would expect that there is some Mac software with capability of doing the same.

A challenge with evaluating such software is assessing its accuracy. Lots of software could draw you a map of signal strength, but how do you know it is accurate?

It's like a lot of fitness devices: At least for early devices, they would display the number of steps you took, etc., but a few sources actually tried to verify the results and found they could be wildly inaccurate. (Most people didn't seem to care, of course.)

Re: MIT CSAIL network design principles

#24

Post by Jugurtha »

gaze wrote: post #11
dreamcompiler wrote: post #10

So in summary here's what we know: 1. The building's weirdly-shaped vertical spaces cause signal interference that cannot be mitigated by the 802.11 automatic mechanisms. 2. The building was not originally wired (or at least not wired properly) for ethernet. 3. The building is a Faraday cage, but not a useful one because it interferes with wifi penetration while exterior radar signals can still get in and block some…

the building is also full of pests lol. All of MIT is like this and held together with duct tape and dental floss. Still the most fun place to do science I've encountered.

>with duct tape and dental floss

Here (Algiers, Algeria), one equivalent to this is "with newspaper and spit" or "held together with cum".

I'd love to see that phrase's equivalent in other languages.

Re: MIT CSAIL network design principles

#25

Post by wolverine876 »

I hate wifi. It's useful to users so they like it (it's useful to me too, I admit), but it's a serious PITA to manage and to diagnose problems. Perhaps people here - especially network professionals - have tips on these age-old issues:

* What statistic(s) actually correlate best with network performance? Signal strength is what everyone assumes; is that it? Signal strength variability (i.e., availability)? Ratio of endpoint to base station active radios?, etc.

* How do you efficiently diagnose user reports of intermittent network failures? How do you distinguish interference issues from base station hardware issues from user hardware issues from good old user confusion and imagination?

* How do you efficiently and cost-effectively track down sources of interference, especially intermittent interference? They could come from anywhere, inside and outside your facility. They could be caused by a million different things, active and passive.

Re: MIT CSAIL network design principles

#26

Post by jbay808 »

twoodfin wrote: post #18
toast0 wrote: post #15

Earlier quoted context omitted.

I'm going to give everyone a pass on 1 and 3, because wifi's importance and characterstics weren't necessarily known enough to design around for a 2004 building. Especially the desire to reject external radar. 2 is not really the architect's fault. The client should have speced wired ethernet, and the architect should have included it in the design, and the construction manager should have verified it as installed du…

Navigation could be client or architect driven; I don't know about MIT, but I've been in Facebook's MPK 20 and 21 designed by Gehry, and they're also hard to navigate, but that's true of most of Facebook's buildings, and Gehry clearly adopted the client's style of ignoring the navigational needs of a building's users. Simple things like walking paths that are visually and texturally distinct from the sea of desks are…

The strange thing is that they built the exact opposite of building 20: an expensive, delicate, complicated building where the grad students wouldn't dare pick up a sledgehammer to run some ethernet cables through a wall in a hurry. How could they expect the new building to fill the same role as the old one?

If they wanted to reproduce the environment of Building 20, they should have built the whole structure out of T-slot aluminum extrusions and LEGO.

Re: MIT CSAIL network design principles

#27

Post by azinman2 »

Jugurtha wrote: post #24
gaze wrote: post #11

Earlier quoted context omitted.

the building is also full of pests lol. All of MIT is like this and held together with duct tape and dental floss. Still the most fun place to do science I've encountered.

> with duct tape and dental floss Here (Algiers, Algeria), one equivalent to this is "with newspaper and spit" or "held together with cum". I'd love to see that phrase's equivalent in other languages.

Why cum? Seems like an odd thing to apply to a random structure… is there some other cultural reference I’m missing to understand it other than being sticky?

Re: MIT CSAIL network design principles

#28

Post by gaze »

azinman2 wrote: post #27
Jugurtha wrote: post #24

Earlier quoted context omitted.

> with duct tape and dental floss Here (Algiers, Algeria), one equivalent to this is "with newspaper and spit" or "held together with cum". I'd love to see that phrase's equivalent in other languages.

Why cum? Seems like an odd thing to apply to a random structure… is there some other cultural reference I’m missing to understand it other than being sticky?

It's hard to argue that cum isn't funny.

Re: MIT CSAIL network design principles

#29

Post by gaze »

gsteinb88 wrote: post #20
dreamcompiler wrote: post #10

So in summary here's what we know: 1. The building's weirdly-shaped vertical spaces cause signal interference that cannot be mitigated by the 802.11 automatic mechanisms. 2. The building was not originally wired (or at least not wired properly) for ethernet. 3. The building is a Faraday cage, but not a useful one because it interferes with wifi penetration while exterior radar signals can still get in and block some…

Context for point 5: - MIT sued Gehry's firm: https://thetech.com/2007/11/09/lawsuit-v127-n53 - Eventual settlement: https://thetech.com/2010/03/19/statasuit-v130-n14

> He added that “value engineering,” trimming design elements to cut costs, was the primary cause of the problems

It sounds like Gehry really made a mess of the place but also, MIT can be very weirdly cheap about some things so this also sounds unsurprising.

Re: MIT CSAIL network design principles

#30

Post by Jugurtha »

azinman2 wrote: post #27
Jugurtha wrote: post #24

Earlier quoted context omitted.

> with duct tape and dental floss Here (Algiers, Algeria), one equivalent to this is "with newspaper and spit" or "held together with cum". I'd love to see that phrase's equivalent in other languages.

Why cum? Seems like an odd thing to apply to a random structure… is there some other cultural reference I’m missing to understand it other than being sticky?

Cum is sticky regardless of culture, and can be used to hold things together, and make things stick. Furthermore, it is more often at arm's reach than duct tape.
Post reply on HN