Mm. I’m an older millennial, so solidly in the Web 1.0 generation, but never had the chance to use the internet before the web took off. I missed BBSs too, which were big where I’m from (probably bigger than the pre-Web internet, outside universities at least). I was fourteen when Postel died in 1998. My earliest memories of internet use are probably from ’96 or so, using library or school computers after classes.
The lie is that hyper thread "cores" are equal to real "cores". Maybe this is what happens when an over 20-year old technology (hack) becomes ubiquitous and gets forgotten about? (We have to rediscover why our performance measurements don't seem to make sense?)
The other thing I think we have a hard time visualizing is that processor is only either executing (100%) or its waiting to execute (0%) and that happens over varying timescales... so trying to assign a % in between inherently means you're averaging over some arbitrary timescale...
Yeah. I learned programming in high school in the mid-80's and was hooked. I liked electronics too, and got a BSEE. But took a summer job writing code and never looked back... still coding now, professionally.
My analogy is that the 80's and 90's were like the "Golden years" of software jobs... maybe like being in the aircraft industry was in the 30's. Lot's of learning and discovery and fun to be had. Working in software now is probably like I imagine being an aeronautical engineer at Boeing now... you'd better be prepared for being satisfied working on some small part of a much larger and complex system and moving at a glacial pace (compared to the Golden years).
(And yeah, the workplace now is flooded with people who seem to be here because they heard it paid well.)
That's just one bottleneck. The other issue is head-of-line blocking. When there is packet loss on a TCP connection, nothing sent after that is delivered until the loss is repaired.
… from 0% (a wired home LAN with nothing screwy going on) to 100% (e.g., cell reception at the San Antonio Caltrain station), depending on conditions…?
Well, yes, that's the idea behind TCP itself, but a "normal" rate of packet loss is something along the lines of 5/100k packets dropped on any given long-haul link. Let's say a random packet passes about 8 such links, so a "normal" rate of packet loss is 0.025% or so.
TCP windowing fixes the issue you are describing. Make the window big and TCP will keep sending when there is a packet loss. It will also retry and usually recover before the end of the window is reached.
The statement in the comment you're replying to is still true. While waiting for those missed packets, the later packets will not be dropped if you have a large window size. But they won't be delivered either. They'll be cached in the kennel, even though it may be that the application could make use of them before the earlier blocked packet.
They are unrelated. Larger windows help achieve higher throughput over paths with high delay. You allude to selective acknowledgements as a way to repair loss before the window completely drains which is true, but my point is that no data can be delivered to the application until the loss is repaired (and that repair takes at least a round-trip time). (Then the follow-on effects from noticed loss on the congestion controller can limit subsequent in-flight data for a time, etc, etc.)
The application will hang waiting for the stack, but the stack keeps working and once the drop is remedied, the application will get a flood of data at a higher rate than the max network rate. So the application may pause sometimes, but the average rate of throughput is not much affected by drops.
The queuing discipline used by default (pfifo_fast) is barely more than 3 FIFO queues bundled together. The 3 queues allow for a barest minimum semblance of prioritisation of traffic, where Queue 0 > 1 > 2, and you can tweak some tcp parameters to have your traffic land in certain queues.
If there's something in queue 0 it must be processed first before anything in queue 1 gets touched etc.
Those queues operate purely head-of-queue basis. If what is at the top of the queue 0 is blocked in any way, the whole queue behind it gets stuck, regardless of if it is talking to the same destination, or a completely different one.
I've seen situations where a glitching network card caused some serious knock on impacts across a whole cluster, because the card would hang or packets would drop, and that would end up blocking the qdisc on a completely healthy host that was in the middle of talking to it, which would have impacts on any other host that happened to be talking to that healthy host. A tiny glitch caused much wider impacts than you'd expect.
The same kind of effect would happen from a VM that went through live migration. The tiny, brief pause would cause a spike of latency all over the place.
There are classful alternatives like fq_codel that can be used, that can mitigate some fo this, but you do have to pay a small amount of processing overhead on every packet, because now you have a queuing discipline that actually needs to track some semblance of state.
Certainly. Except their mistake had beyond-reasonable consequences, since account termination would result them losing access to: their phone, their laptops, their TV smart pucks, their tablets, their smart speakers, their photos, any accounts on websites if they logged in using Sign in with Apple, any accounts on websites if they were using Hide My Mail...
Once you are in Apple jail, it's on Apple to have a good process to follow to try to go back to good standing. OP was met with a black box that may or may not read their internal Apple mail. They may or may not reply either.
The moral to draw from this blogpost is to be careful of putting too many eggs on the same corporate basket. Though in theory you are good as long as you pay your bills, there is no banhammer with an accuracy stat of 100%!
I've been on the receiving end of a false-positive fraud flag on my Amazon account (literally undeserved), it ended with my account being terminated and me being banned from the store. The blast radius was bigger than expected:
- It forced a factory reset on all my Amazon Echos at 03:00AM (fun to be woken up to a house-wide symphony of smart speakers OOBE-ing at the same time).
- It immediately negated my ability to exercise warranty consumer rights on most of my tech devices, as they were purchased on Amazon.
- It also blocked from cancelling my Amazon recurring subscriptions, so I spent two more weeks receiving things like soap and cat food despite the account termination supposedly cancelling all outstanding orders. Support was unresponsive the whole time.
- It immediately terminated my (luckily personal!) AWS resources, as these are also umbrella'd under the same account.
No amount of email reading could have saved me since I did nothing wrong (still have all the receipts, but I'm a stranger on the Internet so caveat emptor). All I ever got back from the different tiers of customer support were different ways of saying you are bad and we don't need to listen nor explain, we are done bye bye.
Have you never been on a 3 week vacation? Or even just a 2 week one with a day before/after where you didn't sit down to read your email? Apple apparently started their freakout after 15 days
The arrogance of MIT is staggering? I would say the arrogance of paper's author is 10x as staggering that if what Robert Palgrave has suggested is true.
I think MIT is trying to protect its reputation as a would-be place of fraud-free research, unlike Harvard.
This really resonated with me. After reading, I thought "This person is likely from the same generation I am". I started programming in 1987. According to their About page, they've been programming since 2018. I wonder how they can feel that burned out after such a (relatively) short time?!
