<rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Hacker News: atomt</title><link>https://news.ycombinator.com/user?id=atomt</link><description>Hacker News RSS</description><docs>https://hnrss.org/</docs><generator>hnrss v2.1.1</generator><lastBuildDate>Thu, 09 Apr 2026 12:35:24 +0000</lastBuildDate><atom:link href="https://hnrss.org/user?id=atomt" rel="self" type="application/rss+xml"></atom:link><item><title><![CDATA[New comment by atomt in "AI companies cause most of traffic on forums"]]></title><description><![CDATA[
<p>I've seen concurrency in excess of 500 from Metas crawlers to a single site. That site had just moved all their images so all the requests hit the "pretty url" rewrite into a slow dynamic request handler. It did not go very well.</p>
]]></description><pubDate>Mon, 30 Dec 2024 20:18:50 +0000</pubDate><link>https://news.ycombinator.com/item?id=42553042</link><dc:creator>atomt</dc:creator><comments>https://news.ycombinator.com/item?id=42553042</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=42553042</guid></item><item><title><![CDATA[New comment by atomt in "OpenSSL 1.1.1 End of Life Approaching"]]></title><description><![CDATA[
<p>I was hoping they would extend it for a bit longer, not because I want to be running old versions but because 3.0/3.1 have some massive performance regressions that are yet to be fixed.<p>Have a look at HAProxys latest release announcement for some openssl 3.x commentary.<p>With some luck they will get a handle on this before 1.1.1 expires.</p>
]]></description><pubDate>Fri, 16 Jun 2023 18:04:38 +0000</pubDate><link>https://news.ycombinator.com/item?id=36361012</link><dc:creator>atomt</dc:creator><comments>https://news.ycombinator.com/item?id=36361012</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=36361012</guid></item><item><title><![CDATA[New comment by atomt in "My network home setup – v4.0"]]></title><description><![CDATA[
<p>Direct hit to the heart *cries in BGP and big enterprise switches*</p>
]]></description><pubDate>Thu, 09 Feb 2023 16:33:35 +0000</pubDate><link>https://news.ycombinator.com/item?id=34726598</link><dc:creator>atomt</dc:creator><comments>https://news.ycombinator.com/item?id=34726598</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=34726598</guid></item><item><title><![CDATA[New comment by atomt in "The future is in symmetrical, high-speed internet speeds"]]></title><description><![CDATA[
<p>Norway. Most of the FTTH plans seems to be symmetrical, anything from 100Mbps to 1Gbps. Some GPON based networks will hold back upstream at 500Mbps max (but they are fairly rare. Most is active ethernet anyway, not GPON)<p>FTTH is quickly taking over with over 70% coverage in homes passed. Pretty sure I saw less dense areas (rural?) had hit 60% last year according to some goverment report.<p>DSL is practically dead and "Fiber to the Cabinet" never really happened here.  Coax is shrinking. Those still using these technologies are of course getting asymmetrical down/up. Some "Fiber to the Building" exists but mostly with copper ethernet to the housing unit, so its practically full FTTH.<p>Things that could be better is:
- pricing, it's not exactly great most places, although smart HoAs can usually get decent pricing if they actually try.
- the networks are very rarely open access, local monopolies are rife.<p>I've been on 1Gbps/1Gbps open access FTTH since ~2014, coming from 300/20 cable.</p>
]]></description><pubDate>Mon, 05 Jul 2021 03:45:56 +0000</pubDate><link>https://news.ycombinator.com/item?id=27734471</link><dc:creator>atomt</dc:creator><comments>https://news.ycombinator.com/item?id=27734471</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=27734471</guid></item><item><title><![CDATA[New comment by atomt in "ZFS on Linux still has annoying issues with ARC size"]]></title><description><![CDATA[
<p>If nginx decided to support ktls they could use sendfile for encrypted traffic as well. Unsure if it is worth it just to make sendfile work however.</p>
]]></description><pubDate>Sun, 21 Jul 2019 00:46:39 +0000</pubDate><link>https://news.ycombinator.com/item?id=20489252</link><dc:creator>atomt</dc:creator><comments>https://news.ycombinator.com/item?id=20489252</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=20489252</guid></item><item><title><![CDATA[New comment by atomt in "Network offloading in OpenWrt (2018) [pdf]"]]></title><description><![CDATA[
<p>I have no idea about the economics in this area, but it kind of baffles me that they add these propietary, closed source and buggy "accelerators" instead of improving the cores a bit. A bit more L1 cache would go a long way for networking.<p>Many switched from MIPS to ARM in the past 10? years, but the cores remain mostly just as anaemic as they were.</p>
]]></description><pubDate>Sun, 05 May 2019 22:17:37 +0000</pubDate><link>https://news.ycombinator.com/item?id=19835427</link><dc:creator>atomt</dc:creator><comments>https://news.ycombinator.com/item?id=19835427</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=19835427</guid></item><item><title><![CDATA[New comment by atomt in "Transparent Hugepages: measuring the performance impact (2017)"]]></title><description><![CDATA[
<p>The problem I have with THP is that while it initially looks great on our workload (yay! a core saved per server!), it often starts to degrade badly after several days or even many weeks depending on memory fragmentation and pressure.<p>It keeps getting better, maybe one day..</p>
]]></description><pubDate>Mon, 01 Apr 2019 00:25:09 +0000</pubDate><link>https://news.ycombinator.com/item?id=19539403</link><dc:creator>atomt</dc:creator><comments>https://news.ycombinator.com/item?id=19539403</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=19539403</guid></item><item><title><![CDATA[New comment by atomt in "Iptables Tutorial 1.2.2"]]></title><description><![CDATA[
<p>It was declared ready for "experimentation" about a year ago or so, so not very mature. If you are on current upstream versions it is not too bad, I'm using it here and there on not very important things.<p>It is a bit hit and miss with kernel/nftables versions on release distributions. I probably would not use it with any kernels older than 4.10 for example. So any current LTS kernel is out.</p>
]]></description><pubDate>Sat, 21 Oct 2017 04:27:03 +0000</pubDate><link>https://news.ycombinator.com/item?id=15520654</link><dc:creator>atomt</dc:creator><comments>https://news.ycombinator.com/item?id=15520654</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=15520654</guid></item><item><title><![CDATA[New comment by atomt in "Iptables Tutorial 1.2.2"]]></title><description><![CDATA[
<p>That example is made needlessly complicated to compress down to a one-liner and show off maps.<p>It does look nicer when properly formatted as part of a rule file, however.<p>The docs needs some work.</p>
]]></description><pubDate>Sat, 21 Oct 2017 04:06:21 +0000</pubDate><link>https://news.ycombinator.com/item?id=15520597</link><dc:creator>atomt</dc:creator><comments>https://news.ycombinator.com/item?id=15520597</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=15520597</guid></item><item><title><![CDATA[New comment by atomt in "TCP BBR congestion control comes to GCP"]]></title><description><![CDATA[
<p>That is good to know. I just deployed BBR on some pilot virtio backed VMs yesterday and I missed this.<p>As far as I can tell the Actual Hardware I'm running my other BBR pilots on are doing the right thing.<p>File under: BBR - still a gotcha or two ;-)</p>
]]></description><pubDate>Fri, 21 Jul 2017 00:15:12 +0000</pubDate><link>https://news.ycombinator.com/item?id=14817228</link><dc:creator>atomt</dc:creator><comments>https://news.ycombinator.com/item?id=14817228</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=14817228</guid></item><item><title><![CDATA[New comment by atomt in "TCP BBR congestion control comes to GCP"]]></title><description><![CDATA[
<p>Just loading the sysctl values will not switch the packet scheduler on already existing network interfaces, but it will start using BBR on new sockets.<p>Switching the scheduler at runtime using tc qdisc replace is possible, but then you need to take extra care if the device is multi queue or not. Instead of explaining it all here just rebooting is probably simpler.</p>
]]></description><pubDate>Thu, 20 Jul 2017 18:30:48 +0000</pubDate><link>https://news.ycombinator.com/item?id=14815109</link><dc:creator>atomt</dc:creator><comments>https://news.ycombinator.com/item?id=14815109</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=14815109</guid></item><item><title><![CDATA[New comment by atomt in "TCP BBR congestion control comes to GCP"]]></title><description><![CDATA[
<p>To try it out, make sure that your Linux kernel has:<p>CONFIG_TCP_CONG_BBR<p>CONFIG_NET_SCH_FQ (not to be confused with FQ_CODEL)<p>Put these into /etc/sysctl.conf:<p>net.core.default_qdisc=fq<p>net.ipv4.tcp_congestion_control=bbr<p>Reboot.</p>
]]></description><pubDate>Thu, 20 Jul 2017 17:43:52 +0000</pubDate><link>https://news.ycombinator.com/item?id=14814691</link><dc:creator>atomt</dc:creator><comments>https://news.ycombinator.com/item?id=14814691</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=14814691</guid></item><item><title><![CDATA[New comment by atomt in "TCP BBR congestion control comes to GCP"]]></title><description><![CDATA[
<p>A warning if you want to try out BBR yourself:<p>Due to how BBR relies on pacing in the network stack make sure you do not combine BBR with any other qdisc ("packet scheduler") than FQ. You will get very bad performance, lots of retransmits and in general not very neighbourly behaviour if you use it with any of the other schedulers.<p>This requirement is going away in Linux 4.13, but until then blindly selecting BBR can be quite damaging.<p>Easiest way to ensure fq is used: set the net.core.default_qdisc sysctl parameter to "fq" using /etc/sysctl.d/ or /etc/sysctl.conf, then reboot. Check by running "tc qdisc show"<p>Source: bottom note of <a href="https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0f8782ea14974ce992618b55f0c041ef43ed0b78" rel="nofollow">https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...</a></p>
]]></description><pubDate>Thu, 20 Jul 2017 17:26:38 +0000</pubDate><link>https://news.ycombinator.com/item?id=14814530</link><dc:creator>atomt</dc:creator><comments>https://news.ycombinator.com/item?id=14814530</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=14814530</guid></item><item><title><![CDATA[New comment by atomt in "WordPress Core up to 4.7.4 – Potential Unauthorized Password Reset"]]></title><description><![CDATA[
<p>Another way to trigger a bounce would be to have the evil domain purposefully having strict SPF and DMARC policy set.</p>
]]></description><pubDate>Thu, 04 May 2017 15:52:20 +0000</pubDate><link>https://news.ycombinator.com/item?id=14265789</link><dc:creator>atomt</dc:creator><comments>https://news.ycombinator.com/item?id=14265789</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=14265789</guid></item><item><title><![CDATA[New comment by atomt in "CoreFreq – CPU monitoring for 64-bit processors"]]></title><description><![CDATA[
<p>For Intel processors, on Linux, the "turbostat" utility provides much of the same information using the -d switch.</p>
]]></description><pubDate>Sat, 29 Apr 2017 16:39:10 +0000</pubDate><link>https://news.ycombinator.com/item?id=14227343</link><dc:creator>atomt</dc:creator><comments>https://news.ycombinator.com/item?id=14227343</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=14227343</guid></item><item><title><![CDATA[New comment by atomt in "5% of Google's traffic is now IPv6"]]></title><description><![CDATA[
<p>And AT&T with their huge 6rd deployment for DSL.</p>
]]></description><pubDate>Tue, 09 Dec 2014 15:13:04 +0000</pubDate><link>https://news.ycombinator.com/item?id=8723149</link><dc:creator>atomt</dc:creator><comments>https://news.ycombinator.com/item?id=8723149</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=8723149</guid></item><item><title><![CDATA[New comment by atomt in "IPv6 Adoption Statistics"]]></title><description><![CDATA[
<p>That is their usual excuse. But its just a bogus answer to shut people up - its not only THEIR customers you want to communicate with.</p>
]]></description><pubDate>Tue, 09 Dec 2014 14:57:23 +0000</pubDate><link>https://news.ycombinator.com/item?id=8723051</link><dc:creator>atomt</dc:creator><comments>https://news.ycombinator.com/item?id=8723051</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=8723051</guid></item><item><title><![CDATA[New comment by atomt in "5% of Google's traffic is now IPv6"]]></title><description><![CDATA[
<p>At work (a larger enterprise in Europe) we already see quite a bit of pain with IPv4. B2B connections are increasingly not using globally unique addressing anymore, so we often need to use prefix NAT and application level proxies to bridge clashing address space. This in turn is a support nightmare and is hurting reliability.<p>Our network guys seems to love the extra complexity, though.</p>
]]></description><pubDate>Tue, 09 Dec 2014 14:10:29 +0000</pubDate><link>https://news.ycombinator.com/item?id=8722735</link><dc:creator>atomt</dc:creator><comments>https://news.ycombinator.com/item?id=8722735</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=8722735</guid></item></channel></rss>