ra1n85

[edit] Retracting my unnecessary jab around the moderator's comments being modified several times and their moderation leaving a lot to be desired. The latter was rude and uncalled for.

It's clearly tongue in cheek, how can you not see that? I mean there are joke tags!

Twitch and Reddit enacted bans simultaneously:

https://www.politico.com/news/2020/06/29/reddit-bans-pro-tru...

https://www.engadget.com/twitch-suspends-donald-trump-accoun...

Seems odd for multiple independent companies to act in concert like this.

That shouldn't be significant unless: 1. There is a significant serialization/deserialization delay, which I don't think will be the based on my naive understanding of the tech 2. Buffering in time periods even relevant to discussion should really only occur under specific circumstances (like during overutilization)

What did you experience the last time significant inflation occurred? Did you observe any early indicators then on that you're looking out for now?

Two things:

1. The consequences of having millions of unemployed people with bills to pay and no income are too much for a nation, let alone politicians in an election year. My bet is that the payments will be extended or replaced with something as the alternative is not viable.

2. WFH has already started normalizing, and will shortly become a differentiating perk offered by companies. I don't suspect that may of the people living in tech hubs would choose to continue doing so if they had the opportunity to live anywhere they wanted (of course while considering COL adjustment).

Yes, I would imagine so. HK seemed to be the only conduit through which trade with the west could flow smoothly. It will be interesting to see how this plays out.

It's wreak.

And you're probably right. Hong Kong's status made it home to a lot of the financial engineering of commerce between China and the west. With it losing its status, I think a lot of the financial machinery in HK is about to come undone. Singapore will likely benefit, to some degree, from this move. The world and China may need to find new markets and suppliers in the short term.

This is an amazingly ignorant viewpoint, and I'd bet the farmers in Vietnam of the 1960's and Afghanistan of the 2000's would likely care to differ. Insurgencies undermine the advantages of expensive weaponry.

And if we're talking about a civil war or insurgency within US borders: An army fighting on its own soil and against its own citizens is surrounded on all sides and can't maintain secure supply lines.

This, sadly, is so accurate. That, or the fact that as difficulty levels increase, the game just gives the AI opponents crude modifiers - they don't get smarter, they just get cheat codes.

>It's entirely possible to say "we need to work harder, or take a risk, or be bold" while understanding where your colleagues are at in terms of what they need to do that, or what has or hasn't been communicated to them about how that will happen, or how things have been done in the past to change them.

Great leaders, in my experience, haven't asked these questions or pushed performance in this way - they led their reports through soft management to come to the conclusion that it was necessary to increase performance. They framed questions that led people to the conclusions they had already made. Of course, this also requires that the reports are capable enough of being led in the right direction.

Yep, though it’s not commercially available quite yet. Likely only shipping samples to switch manufacturers at this time.

Yeah, it's an interesting approach. They're basically allowing you to define packet processing with P4 on their Tofino family of chipsets: https://p4.org/

That said, there's only so much you can do in a chip before considerable tradeoffs are going to be made. They're not going to offer the same level of flexibility you get out of a general purpose CPU, but may not have same the restrictions of most fixed pipeline chips - their product sits somewhere in the middle. Also, P4 seems to sit in a space complex enough to make it unreasonable for most network shops - it's not for your average enterprise or service provider network.

Sorry, what's not accurate here?

For many years, the most popular routing platforms (i.e., boxes built by Cisco) performed IP packet forwarding and management functions on the same processor (often a RISC architecture). In cases where packet rate was high, it was possible for devices to become unresponsive or lose critical protocols responsible for sharing routing information.

In the last 15 years there has been a hard move away from these architectures. Almost no packets are forwarded by the same processors running management and control plane functions anymore. This is mainly because the required traffic rates today need dedicated silicon purpose built for the task (the Broadcom Tomahawk3 can do 12.8 Terabits/sec above a relatively small packet size).

I don't know how things will shake out for the Linux world and x86 packet forwarding given the trend and lack of real performance in the kernel. Right now, your best bet when it comes to Linux and high network throughput/packet processing requirements is to just bypass the kernel entirely with DPDK, a "smart" NIC, or XDP.

Yes, correct, or through an open sauce repository

Can confirm - only native restaurant sauces are supported. Special sauces must be sourced from your own internal sources.

>Our national propaganda is so strong, that rather than workers asking "why do I have to go to work every day just to pay rent to the bank?"

This is not fair to people that have spent their lifetimes building businesses and are watching them go bust, or people that derive satisfaction from their employment.

Worse, for those that would rather not go back to work and are suffering, your comment comes across as "shame on them for not asking for more". This crisis is hurting so many people, and its impact will be felt for a long time. We don't need comments like this.

"Google is trying retail now?" was my first thought.

"For how long?" was my second thought.

Most don't have "multiple offers from FAANGS" and they are operating from an extremely poor bargaining position.

And how did you read that comment and come away with immigrants are to blame?

It's a DNS resolver that runs on the hypervisor hosting every instance.

Your link gives access denied.

1500 bytes is the MTU of IP, in most cases. It often excludes the Ethernet header, which is 14 bytes excluding the FCS, preamble, IFG, and any VLANs.

If have a 1500 byte MTU for IP, then we need at least a 1514 byte MTU for IP + Ethernet. We often call the > 1514B MTU the "interface MTU". It's unnecessarily confusing.

>Vision, goals, key results, what we are allowed to do and not do, are clear. Likely written down, understood, repeated frequently, taught to new members of a team.

On the nose.

Amazed by how many leaders that I've worked under that can't seem to set direction. That's all - communicate what's important, what's going to make the company differentiate itself, and then allow the smart folks you have hired to set their priorities accordingly, execute, and then adjust where needed (but sparingly).

Nope, I'm sorry you're not quite getting it here. Minimum Ethernet frame is 84B on the wire - it's simple enough from there.

Yes.

The point of discussion here is that the Linux kernel struggles to do line rate 10Gbps. This was misinterpreted as "the Linux kernel struggles to do 10Gbps".

It implies it. Ethernet at 84B per frame is the smallest you can go, thus the line rate - some examples:

https://events19.linuxfoundation.org/wp-content/uploads/2017...

https://www.redhat.com/en/blog/pushing-limits-kernel-network...

https://kernel-recipes.org/en/2014/ndiv-a-low-overhead-netwo...

16 iperf threads...sending at what packet size? Do you understand the notion of line rate? 85Gbps at 1500B is only 7MPPS, which is half of 10Gbps at line rate.

You're saying you can forward 100Gbps at line rate (148MPPS) through a stock kernel?

What if you have no application and you're purely forwarding traffic? That's what I'm measuring here (and that's actually typically faster than passing packets up to user space apps to consume through syscalls).

25G line rate is 37MPPS - are you saying you have zero problem forwarding at that line rate? I'd be very surprised if that's being done in the kernel. I'd be more surprised if you said that you're consuming bytes from the network at that speed with user space apps and no kernel bypass.

XDP (the forwarding approach built on top of eBPF) is limited to ~20MPPS, as well: https://www.netronome.com/blog/bpf-ebpf-xdp-and-bpfilter-wha...