Wow, a NetApp employee who's actually heard of performance as a feature!

I'm saying this because every time I hear that a customer has a NetApp I get giddy as a school girl, because their filer products have a literal turbo button that I get to press.

Thanks to NetApp I've had some career highlights of boosting storage performance of entire enterprises by at least a factor of two, and occasionally as high as tenfold or more.

I'm not saying that I'm some sort of storage performance tuning wizard! There is literally a single parameter that can be changed to at least double the performance of every NetApp filer that has been shipped in about two decades: Just increase the TCP Window size from the original 1990s era default of 17KB to something sane like 256KB and then everything gets magically faster.

This is why it's so bizarre hearing you talking about performance and working at NetApp. It's like hearing that someone was on the Trabant F1 team.

The default for both CIFS and NFS is 64k since ONTAP 8.2.1, released in 2013.

https://library.netapp.com/ecmdocs/ECMP1401220/html/GUID-7FB...

That's still way too low. A window size of 64KB will be a bottleneck on any 10 Gbps Ethernet connection, except perhaps a point-to-point cable. Any real-world network with switches, routers, and firewalls will require on the order of 256-512KB window sizes for decent performance. You need megabytes for any link that leaves the building!

For reference, 64KB was the default in Windows 2000-XP, and is dynamically raised up to 2MB in Vista and later, and up to 16MB on recent Windows Server versions.

Perhaps to avoid support tickets for people with equipment that doesn't properly support window scaling. The 64k setting is as high as you can go and avoid that.

What planet are you from where there is still such as unique and special flower that talks to only NetApp and no other operating system made in the last twenty years?

The planet where cheap or old or buggy routers, VPN software, etc don't properly support tcp window scaling: https://en.wikipedia.org/wiki/TCP_window_scale_option

I didn't say anything like what you're describing. Also not a fan of your unnecessary cheap shot.

How would you get around speed-of-light delays? The speed of light is about 1 foot/nanosecond, so maintaining a 1-cycle access time @ 3 GHz gives you about 4 inches to play with. Current server designs have some headroom (100 cycles = 33 feet, while the actual physical distance is more like 1-2 feet), but as soon as you start going to another rack and want to maintain normal RAM access speeds you run up against physical limits pretty quickly.

I assume you mean the speed of light in copper, or silicon instead of a vacuum? If so, may i warp your assumptions by the suggestion of using silicon photonics, and

[1] https://en.wikipedia.org/wiki/Photonic-crystal_fiber

theryby gaining 30% more speed?

Some article from 2013:

[2] https://www.extremetech.com/extreme/161687-darpa-creates-hol...

Some company from now:

[3] https://www.nktphotonics.com/lasers-fibers/product-category/...

It's very sad that lack of a PhD would cause such a decision to be made rather than that it would get debated on its merits.

Or that the merits of a suggestion were inversely proportional to an employee number, but cultures such as those frequently emerge in engineering driven organizations with a lot of smart people. I speculate that it is an offshoot off the imposter syndrome effect, when someone is feeling like an imposter and they are being asked to make a big decision, they search for externally generated metrics that would increase their confidence in the decision.

Degrees, low employee numbers, industry awards, are all signals that "someone else" thought this person was "good". And not even super geniuses understand everything about everything and they still have to make decisions.

Sad or not, in my experience working around gifted engineering teams it is not uncommon.

> Sad or not, in my experience working around gifted engineering teams it is not uncommon.

OK, so I had hoped that this was a problem unique to Google but I guess its not.

I just don't get this kind of thinking. I understand that a PhD is a good marker for intelligence... but not for ingenuity (maybe a tiny bit). I've worked with both PhD's and non PhD's... while PhD's are amazing to talk through different ideas, what may or may not work, the people I was most productive with have universally been people who get excited about technology (not saying they're mutually exclusive). Mind, not excited about fads, but those who can't wait to code a prototype to see if it really works as expected. Those who will jump in the middle of an outage and are excited to learn about what might have gone wrong.

Those are the attributes that I now look for whenever I have to make a choice between teams, between companies, whatever. The people that get excited by new designs and architectures, who love to talk through them, are the best people to work with.

I guess I do understand why Google is that way... I just hope that this kind of thinking doesn't infect other workplaces.

Google is a big company and maybe this was true but it feels false (having worked there & other large tech companies) that the reason for failing to get that project going was the lack of a PhD. Now having top engineers on board probably is key, but again that isn't tied to any advanced degree but due to Google hiring & promo committees which are intended to reward merit.

The value of this is multi-faceted. It shows technical validation by trusted engineering talent. Those engineers are able to expend their own political capital on the project. Those engineers have demonstrated an ability to navigate corporate hierarchy and deliver large-scale projects. One of the key requirements of higher levels of promotion is that you are focusing on strategic goals for the companies rather than strictly complex/important technical products.

Having interesting & exciting conversations is nothing. Everyone is smart & happy to nerd out about complex and interesting abstract concepts/designs. Doesn't mean that they think those ideas are worth pursuing or that they're worth pursuing right now.

Same here. What I noticed PhD people are more good candidate for research but not coding/finishing product. They put all their career in research tackling completely different set of problems. Most of time they are not aware of industry tools and applications like VCS, coding-styles etc and lack attitude to know context and more focused on (re)inventing something.

On other side engineer guys good to finish product, learn many half-assd tools and tacking different set of problems every day. This builds good intuition. But most of time they lack concept and they berate academics (at least in their early career days)

Now this is not universally applicable to everyone and may be wrong. I have seen some good people who rock both worlds.

A PhD is generally seen as "proof" that you can take a vague concept and perform high quality research. Obviously a PhD doesn't necessitate this and research is a VERY different skill than class work, but a PhD is likely seen to be lower risk for an employer (where any research is generally considered high risk).

These types of multi-tier compute systems/MITM processors are now being implemented. Microsoft publicly discusses their efforts here:

https://www.microsoft.com/en-us/research/project/project-cat...

That looks like a lot of fun. I wonder if they would let me do a 1 year residency with that team. HP Enterprise was doing something as well with "the machine" (very large memory systems) which generated some interesting papers.

I feel like we do not yet have a calculus for analyzing the mix of "entanglement" of data across transactional expressions. It is a problem I've puzzled over since about 2001 when Steve Kleiman asked me to scale file systems without speeding up the processor.

As I recall the solution then was "buy Spinnaker". :) . Join us at HPE storage, we'll do it right this time!

If you want to get a PhD there's definitely a lot of research going into networks. Especially at the big computing labs (read DOE). So like LLNL, ORNL, Sandia, Argonne. I don't work in this area, but I do work on/with HPC stuff so there's a lot of talk about all this stuff. It definitely seems to be a big part of the ECP movement/funding. Data transport and memory storage are two of the biggest problems I hear being talked about in ECP.

This is kind of what nvswitch does, albeit in a proprietary architecture. All 16 GPUs in an NVSwitch can see the memory space of all others, and any reads/writes are transparently performed on the correct GPU. This effectively gives a 512GB address space of HBM2 memory.

Better: this works between/towards POWER 9 sockets, including knowing to execute atomics right at the destination.

That sort of node exists as KNL, for numbers of compute elements up to ~200 with threading on. Unfortunately the on-chip OPA (RDMA) interface didn't materialize as far as I know, and KNL is dead (unless you're Down Under Geosolutions?).