1,583 karma · joined August 17, 2009
> 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?
> But outside, we got sunshine. And it’s free. Nothing is cheaper than free!
Would simulated and/or pumped-in sunshine cost more than (or even a significan fraction of) the labor?
If not, that seems similar to the sunk-cost fallacy, substituting "free" for "already paid for".
Otherwise, a separation before the first anniversary (presumably a certainty for seasonal workers) results in losing none of the raise, at just shy of the second anniversary only one quarter of the raise.
Half the raise is an upper bound, and we'd have to know at least the average tenure of a warehouse employee to guess how much an average worker loses.
This statement strikes me as likely to be true, at least for database non-experts.
It was certainly true for me. I didn't have anything approaching a decent understanding of query performance until I discovered posgresql's EXPLAIN and, perhaps more importantly, EXPLAIN ANALYZE.
Even that question is too broadly posed. The question is, is learning it in addition to[1] the previously-standard tools useful?
[1] In the context of the article, this might be "instead of", which presents a much lower bar.
This doesn't strike me as dumb at all, unless the refrigerator's heat pump is more efficient [1] than the AC. Although it may be, it's not a foregone conclusion, and it stands to reason that a refrigerator would be designed to function better when pumping [2] heat into room temperatures than outdoor temperatures (as opposed to an AC).
Regardless, all heat pumps have to work harder (use more energy and/or run longer) when the temperature differential on either side is worse. You wouldn't be getting something for nothing by moving a fridge's hot side to a hotter outdoor location.
[1] Overall, including maintenance/replacement cost due to longer run-time
[2] or dumping, though "dump" suggest something more passive than what I believe is going on
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.
Bulk of discussion at the submission for the slides pdf https://news.ycombinator.com/item?id=18099304
Updated version https://news.ycombinator.com/item?id=18109098
https://news.ycombinator.com/item?id=18108980
And an updated one:
https://www.youtube.com/watch?v=__wn9zXFiy8
https://news.ycombinator.com/item?id=18109098
I'm not sure which version these slides correspond to.
Besides the usual arguments against public transit, such as schedule inflexibility, comfort, and cost[1], there's overall trip time.
Unless your other endpoint is similarly close to a Caltrain "bullet" stop (and one is taking such a "bullet" train), driving takes less time on a typical day (and always during any off-peak period).
[1] Primarily for ad-hoc trips, and especially acute for dual-occupancy cars. For two people, Lawrence Caltrain to the Creamery would cost $19 more by train than incremental cost of driving. (Ignoring parking costs.. which, if more than $24.50 near the Creamery would, indeed, wipe out the savings).
Considering that Blekko was, ultimately, shut down, users may be less inclined to contribute to something similar in the future, assuming they remember.
At this end of the spectrum, that means abandoning commodity hardware, with everything it implies, not just a change in binary architecture, as it might for ARM vs. x86 in end user devices.
Recently, I looked up the max memory on IBM's system z, and it was only 32TB, but it looks like their Power Systems E980 can take 64TB. It appears that, like with their mainframe line, going that route means significant vendor lock-in, including proprietary memory modules.
It's certainly interesting that the current generation of high-end x86 CPUs took a step backwards from the last generation, in that that their max is 12TB and just catching back up to 24TB isn't expected to happen until next year.
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.
The parent did ask about a mobo, specifically, but I think it's a stretch that the question was about the component on its own, at least in the context of the broader conversation of feasibility.
I took the "off the shelf" question to be synonymous with "commodity". That is, the opposite of (truly) custom. One doesn't have to be Google or Facebook and design a board layout to get 8 sockets. One can just order it from the same vendor as all the other commodity hardware.
> it probably makes more sense to just buy the system
I'm asserting that this is what every commercial purchaser does, anyway.
It may imply that but only outright requires 40Gb/s total, which is provided by the "4-port 10GBase-T Ethernet SIOM (Intel® X550 controller)" of a SuperServer 7089P-TR4T.
The EBS bandwidth can be elided entirely by using local storage instead. Local storage bandwidth can be much cheaper than ethernet, especially considering how many NVMe ports are already included.
As 10GE is maybe $200/port (including SFPs), at scale, network cost doesn't "move the needle" on a $400k server.
These systems (from SuperMicro or Lenovo, for example) still fit in a standard 19" rack, and still take standard CPUs, standard DIMMs, and standard PCIe cards.
The main limitation is that the complete "barebones" system is indivisible, unlike with most 1S-2S systems, where motherboards can be mixed and matched among a wider variety of chasses. This limitation also applies to high-density offerings like blades and SM's "Twin" line. I have yet to encounter a situation where such a limitation has ever even entered the conversation.
That's previous generation:
>Intel® Xeon® processor E7-8800 v4/v3 family
The articles states:
> All three sizes are powered by the latest generation Intel® Xeon® Platinum 8176M (Skylake) processors
You mention the 8176Ms in your original comment, too. The current SuperMicro product that supports those is https://www.supermicro.com/products/system/7U/7089/SYS-7089P... and that only has 96 DIMM slots.
> Intel® Xeon® Scalable Processors, 8S-3 UPI up to 10.4GT/s
> 96x 288-pin DDR4 DIMM slots
> Supports up to 12TB DDR4 ECC 3DS LRDIMM in 96 DIMM slots
I think you'll find that this is due to the limitations of the CPU itself:
> Max Memory Size (dependent on memory type) 1.5 TB
according to https://ark.intel.com/products/120505/Intel-Xeon-Platinum-81...
Anyone paying more than a negligible amount (per server) for any of these is needlessly over-paying. For a server this expensive, it had better be way below 1%. (Tech support is arguable, but it costs a pretty penny from AWS, too).
> RAM 64GB: $866.23 x 192 = $166,316.16
These CPUs can't support 192 DIMMs, only 96, so they're limited to the much more expensive 128GB modules. That means you're looking at closer to $250k for the RAM alone.
NB that this was calculated based on the "All Up Front" pricing, so, for that situation, it's safer to say that their profit for the first year is $300k+ [1] and merely non-existent or negative for the second and third years.
[1] Assuming $400k purchase cost as per https://news.ycombinator.com/item?id=18090058
Sadly, it just used 6TB as a fixed cutoff, so keeping it up-to-date would be a manual task.
Today, only a few years later, that number is 24TB. (Even more sadly, that's for the last generation of Intel CPU, whereas the current 8S generation tops out at 12TB and isn't even scheduled to have models that would get to 24TB until next year).
This was discussed a couple days ago in a different thread [1], when 4TB was the EC2 limit.
$400k for the current-gen (224 cores) or, as a sibling comment [2] notes, $250k for the previous CPU generation (which can use twice as many DIMMs of half the density and only 192 cores of that).
> obviously, there's operational costs to consider as well
We can estimate an upper bound on this, given that the current-gen system has N+2 5x1600W 96% efficient PSUs, so 5kW max. If you're paying a colo $.50/kWh, that's another $66k over 3 years worst case.
Realistically, though, CPUs with a max TDP of 1640W, DIMMs (generously) 700W, leaves plenty of room for fans, SSDs and other overhead before getting to 3kW or $40k, and that's still assuming running full-bore the whole time.
There are obviously also ancillary costs to AWS, such as data transfer and EBS.
If you're already running your own hardware, it sure does look more attractive to pay $400k now and $40k over 3 years than to pay AWS $800k All Up Front (now). If not, perhaps it's more attractive to hand-wave away that $360k as saving the "hassle" of hiring someone who knows how to run equipment in a datacenter.
I'm not suggesting that there's necessarily value in "managed", but your parent comment was about the Ubiquiti product being overkill, which is a much broader statement.
The GP certainly advocates for management, but that's neither the primary value delivered by the overall product, nor the majority cost (even with a single AP). IIRC, this may not hold for competitors, such as Ruckus, where even the lowest-end "controller" is quite pricey.
> wifi should function without the need to phone home.
AFAIK, Ubiquiti's products can be run standalone, only requiring management software for initial configuration.
Presumably it's only less of an issue because the cost of the part has come down from $1k or more (in '92 dollars, no less).
Even something like PG with the Citus extension to compare parallelism would have been relevant.
EDIT: Although another comment suggests that the data for the paper could have been gathered as long ago as 2016, which could mean Citus was not yet open source.