HN user

gmazza

205 karma
Posts0
Comments33
View on HN
No posts found.

Middle ground between dropping [1] and buffering is Active Queue Management as wtallis pointed out above. State of the art AQM on Linux nowadays is CoDel [2].

Big network gear vendors that ship to ISPs have adopted early forms of AQM (both RED [3] and proprietary algorithms) quite a while ago - they had to:

(a) backbone routers have much smaller buffer-to-bandwidth ratio (compared to a PC or even home router), so endless buffering is not an option;

(b) buffer tail drops (i.e. what drop keyword does when added to tc filters/disciplines) interact really poorly with TCP bandwidth control algorithms, and rather badly with RTP streams, too (so drop is not an option either - it ruins user's connections; and

(c) ISPs and carriers would typically run links (on average) much closer to saturation than your typical home router, so situation where router has to make buffer/drop decision is much, much more frequent.

[1] My point above was that you don't really want to drop packets on the receiver side, after that packet already traversed expensive part of the network.

[2] https://en.wikipedia.org/wiki/CoDel

[3] https://en.wikipedia.org/wiki/Random_early_detection

Wrong: you see 10KB/s download speed because you are not throttling the incoming packets but the outgoing packets!

Yep. TC's default is to policy outgoing traffic, which in OP's example is a bunch of TCP ACKs essentially. Instead, they should be using ingress keyword, something like described here:

http://blog.stevedoria.net/20050906/ingress-policing-with-li...

Caveat emptor: ingress rate-limiting is hard. Long story short, it all boils down to what you do with non-confirming packets: There are two alternatives, and both are rather sub-optimal. You can either buffer/delay packets in kernel space (default, which leads to bufferbload and memory waste), or drop (which author linked above opted for, which leads to excessive retransmits and bandwidth waste).

If you don't need hierarchical classes[1], just use tbf (token bucket filter) instead of htb (hierararchy token bucket) - it's more efficient, more compact, and gives you access to delay in the same discipline as well. Compare:

  # htb
  tc qdisc add dev eth0 handle 1: root htb default 11
  tc class add dev eth0 parent 1: classid 1:1 htb rate 1kbps
  tc class add dev eth0 parent 1:1 classid 1:11 htb rate 1kbps
vs.
  # tbf
  tc qdisc add dev eth0 root tbf rate 1kbit latency 42ms burst 2k
"man htb" and "man tbf" are quite usable too.

[1] i.e. stuff like "I would like to have tcp/80 limited to 10 mbit/s, tcp/443 limited to 15 mbit/s, while sum of above should never exceed 20mbit/s, and tcp/80 should get priority when competing for that shared 20mbit/s"

EDIT: changed to "burst 2k". Having burst lower than interface MTU will delay large packets essentially forever.

I wish there were an API to detect how much data still hasn't been acked.

From example code attached to the original article (Linux only):

  int outstanding;
  ioctl(fd, SIOCOUTQ, &outstanding);

Have a look lenovo forums [1] (also linked prominently from original article), where OP has following to say:

  I am attempting to install ubuntu 16.04 on my yoga 900.
  The bios can see the 512 gb samsung hard drive and so can Windows.

  The ubuntu installer can not see it at all. 
...and first person to reply adds:
  I have the same issue with the 900S model. 
 
  I have tried the newest kernel 4.6 but linux doesn't
  even list the pci express device in lspci.
So no, positively not the 3.2.x kernel to blame here.

[1] https://forums.lenovo.com/t5/Linux-Discussion/Yoga-900-13ISK...

And for an example of co-existence of competing languages, see javascript triggering flash/actionscript (e.g. for clipboard access) and vice-versa (e.g. for DOM access).

Both are somewhat dated examples, that is pre-HTML5.

This was mostly from a personal experience of running couple of dozens Raspberry Pies. To elaborate:

- Cheap cards would start corrupting right in the middle of first "apt-get update && apt-get upgrade";

- SanDisk Extreme Pro 16GB fared much better, but still we had several failures after half-a-year;

- Failure mode in both cases - corruption in superblocks and inodes, journal doesn't help much when recovering (we use ext4).

As a result, we settled on splitting each card into two root partitions - active and standby. To upgrade, overwrite standby one with dd, switch active/standby by editing /boot/cmdline.txt, and reboot.

Designed-for use-case for an SD card is a buffer where a photo/video camera will save footage sequentially, then you copy everything to your PC/laptop and reformat the card.

When used as a generic storage with a complex write/delete/overwrite pattern, most card would start corrupting data fairly quickly.

Atl-. will cycle through the n-th argument, which is not the same as repeating entire last command with all arguments as up-arrow or !! do:

  $ yum install bash-completion
  Error: This command has to be run under the root user.
  $ sudo <Alt-.>
  $ sudo bash-completion
  > The press release was issued, I think, sort of as if it
  > came from some sort of independent or cross-vendor project,
  > and there’s the snapcraft.io site to back up that impression,
  > but every Snappy committer is a Canonical employee
That's a pretty old trick. Google pulled exactly the same with Open Handset Alliance few years ago.

Why not? RedHat will let you run arbitrary binaries just fine on OpenShift - both long-running/worker/"PaaS" and on-demand/per-request/"FaaS".

Obviously this is tightly locked down with cgroups.

Serverless = new name for PaaS.

VPS (virtual private servers) were available (and largely ignored) for quite a while before 2006, when AWS came along with the catchy word "cloud". This single word changed everything. Same technology all of the sudden became cool, and everybody started using it.

Maybe now it is the turn of PaaS [1] - call it "serverless" and folks finally start seeing all the benefits (true scalability, efficient resource utilization, timely and painless software upgrades, et c.)?

[1] https://en.wikipedia.org/wiki/Platform_as_a_service

What you raise is a valid concern, but letting websites decide on enabling/disabling auto-complete is solving it entirely wrong way around.

If local admin is incapable of configuring user accounts, how are websites supposed to figure out who is who, and which browser is on shared computer?

After all, if managing user accounts is too hard for said admin (or we are talking about a shared PC in a library, which doesn't have user accounts as a matter of principle) - just make browser always start in private/incognito mode on shared computer. It is as easy as adding command-line argument "--private-window" for firefox or "--temp-profile" for chrome. That's it. Window closed - autocomplete gone. Problem solved.