Hacker Newsnew | past | comments | ask | show | jobs | submit | riobard's commentslogin

I hate the original Mac Pro case so much!!! The metal box is so heavy and the edges of the aluminum top handle is so sharp that you definitely need a pair of heavy-duty gloves to move it around.

OK, can we have 7GHz and 8GHz for Wi-Fi please?


China has already reserved the entire 6GHz for cellular and vehicles.


> What do these devices do that can't be accomplished by an OpenWrt One + an external AP for less money and fully FOSS?

Nice UI (as the company is best known for https://ui.com)


The assumed mentality of “being flexible” is the very reason WireGuard was created to fight against in the first place, otherwise why bother? IPSec is already standardized and with wide-spread hardware implementation (both FPGA and ASIC) and flexible.


Those pesky WD bridges usually support USB Bulk Storage only but not UASP, resulting in worse performance and higher CPU usage.

Also HDD power management is often complicated by the bridge chip sometimes intervening.

Not recommended for long-term use.


What ARM64 machines are you using and what are they used for? Last year you were announcing Gen 12 servers on AMD EPYC (https://blog.cloudflare.com/gen-12-servers/), but IIRC there weren’t any mentions of ARM64. But now it seems you’re running ARM64 in full production.


I'm not Cloudflare, I just read their blog too much. As they hint in the article when mentioning secure boot, they've been deploying Ampere in parallel to AMD for several years now. Purpose wise it seems to be Edge related for efficiency reasons, but maybe they use them for other things too. You can read some more here https://blog.cloudflare.com/designing-edge-servers-with-arm-... and here https://blog.cloudflare.com/arms-race-ampere-altra-takes-on-... along with the original evaluation of Qualcomm here https://blog.cloudflare.com/arm-takes-wing/


Yeah but those are pretty dated. I was under the impression those old Ampere servers are not efficient compared to modern EPYC anymore. So I’m wondering what their current generation of arm64 servers look like :p


I seem to recall Cloudflare hosts their some of their non-edge compute on public clouds? Like control plane stuff. Could be that.


What mail clients do you recommend that make mailing list UI/UX tolerable?


I use Gmail, but you have to turn on filters for that automatically label topics for it to work.


Can someone explain how UDP GSO/GRO works in detail? Since UDP packets can arrive out-or-order, how does a single large QUIC packet be split into multiple smaller UDP packets without any header sequence number, and how does the receiving side know the order of the UDP packets to merge?


Author here.

QUIC does not depend on UDP datagrams to be delivered in order. Re-ordering happens on the QUIC layer. Thus, when receiving, the kernel passes a batch (i.e. segmented super datagram) of potentially out-of-order datagrams to the QUIC layer. QUIC reorders them.

Maybe https://blog.cloudflare.com/accelerating-udp-packet-transmis... brings some clarity.


Thanks! The Cloudflare blog article explained GSO pretty well: application must send a contiguous data buffer with a fixed segment size (except for the tail of the buffer) for GSO to split into smaller packets. But how does GRO work on the receiving side?

For example GSO might split a 3.5KB data buffer into 4 UDP datagrams: U1, U2, U3, and U4, with U1/U2/U3 being 1KB and U4 being 512B. When U1~4 arrives on the receiving host, how does GRO deal with the different permutations of orderingof the four packets (assuming no loss) and pass them to the QUIC layer? Like if U1/U2/U3/U4 come in the original sending order GRO can batch nicely. But what if they come in the order U1/U4/U3/U2? How does GRO deal with the fact that U4 is shorter?


It will deliver two separate batches. One of U1 & U4 and a 2nd one of U3 & U2. `quinn-udp` in particular also uses recvmmsg and is thus able to receive up to 32 different permutations of src, dst and segment length with a single syscall (assuming the application provides enough buffers).


Thank you very much for the clarification! :)


I think as an application, when receiving packets you never really see a coalesced UDP datagrams when GRO is active.

It’s more like the kernel puts multiple datagrams into a single structure and passes that around between layers, maintaining the boundaries between them in that structure (sk_buff data fragments?)

Not an expert, but I tried looking at how this works and stumbled upon [0].

[0]: https://lwn.net/Articles/768995/


You definitely see the coalesced datagram as an application. That is kind of the whole point: Passing a big buffer to the syscall and segment it in user-space to minimize the syscall overhead per packet.


Unfortunately ads and tracking go hand in hand: without tracking, targeted ads are much less effective. If everything else stays the same, you'll just get more, bigger, and flashing ads to compensate for the inefficiency, like what you see today on smaller sites without sophisticated user data.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: