Hi. I have found the solution to your problem.

Longer wires. Put the box where the high-pressure water jet isn't.

You're welcome.

Indeed.

To further muddy the waters, DropBox supports (under Windows, at least) what it calls "LAN sync," with the goal of having data traverse LAN-WAN only once, no matter how many LAN clients want that data.

I do not know if it is default behavior. But I've seen it work just fine.

When the price differential between 2Mbps and 75Mbps is large, some people elect the cheaper option.

I write this from a 2Mbps connection. It works well, even with Steam, blizzard, and who knows what, all at the same time, while running BitTorrent to get the newest Linux ISOs, and remote backing up my computer.

Sure, it's slow. Downloading those ISOs requires patience.

But it's responsive. Interactive things happen quickly, and that's what matters most for the user experience. Games work fine. Netflix works. Pandora works. Youtube works. Skype works. Throw random workloads at it, and it works.

How? Using the perhaps-poorly-named QoS adjustments in Shibby's build of Tomato-USB on an old WRT54G.

Light and interactive and latency-sensitive things get the first dibs at bandwidth (both headed out, which is easy -- and coming in, which is much less straight-forward). Progressively more-intensive things get pushed to the back of the bus.

My Linux ISO torrents get whatever is left after these other more-important tasks (as defined by me) get their share.

So, either $20/month with an old freebie router, or $100+ per month for enough bandwidth to do what I describe without perceived lag.

Some people are more willing to put a little bit of effort into such things, some people are more willing to open up their billfold a little wider. (And some people manually micro-manage what they do, and when, to keep latency low, but that's the path of madness and a generally unfulfilling Internet experience.)

You cant trust a manufacturer to be truthful

Re: Fight Club. In most instances, they (manufacturers) are the ones instituting the recall, presumably based on numbers and figures.. NHTSA (I'm in the US) will document the recall if it is justified, and the manufacturer is always the one paying for for parts and work and documentation and mailings and phone calls and....

In some cases, it seems the NHTSA will suggest -- or in egregious cases, demand -- a recall, but in -all- cases it is a manufacturer recall.

If the NHTSA demands that Toyota or Hyundai recall a lot of cars for something, then of course the NHTSA should be public with that -- as well as Toyota or Hyundai.

If Toyota or Hyundai recall on their own, then of course they should notify the NHTSA and then all related parties should also publish that.

But I should still be able to go to toyota.com, and get proper, up-to-date, recall information for a Toyota that I'm looking at buying or already own. It should be the first place I look, because (again) if Toyota is involved in a recall of their stuff, nobody will know more about it than them.

It's really no different than changelogs, errata, and bugfix releases on important software: We don't rely on the government for that, nowdo we?

Nay. If I want to know if AES is secure or not, I look to the vendor and peer-reviewed studies -- not the government. If I want to know if Windows 8.1 or 10 or whatever is a good step, I look to third-party reviews or the vendor website, not the government.

I propose that people aren't as dumb as you suggest. If they're smart enough to look for recalls before buying, then they're also smart enough to find those recalls without government intervention and expense. And a manufacturer, in any published recall, will always have more up-to-date information about a particular vehicle than any other party aside from, perhaps, the original owner.

If recall information is not published clearly and accessibly on manufacturers' websites,. then that is a failure of legislation and capitalism, not of a lack of a central repository.

Because again, if I'm looking to buy a car and I want to know what that models list of official issues are, why would I ask the government? The companies that both made and recalled the broken thing should foot the entire bill, even if it requires new laws to promote this behavior.

Some people have found that government sites are relatively accurate, compared to the other sources, or at least more accountable.

There can be no source more accurate or accountable than the manufacturer, as they are the body charged with implementing the recall, and are also the ones with $billions at risk.

Which of the following is more accurate:

A. A group of people reading the same newspaper
B. An orator reading the same newspaper to the same group of people
C. A transcriptionist transcribing the orator's speech and posting that transcription to Facebook
D. ...ad absurdum

OP's question, stated differently:

Why should the government be the main source for recall information on the Internet ?

Your response:

Besides, if you're buying a used car, this is an easy way to see if it is on a recalled list since you wouldn't have been notified by the manufacturer.

My thoughts:
If I'm buying a used car, presumably I know who manufactured the car because the car will be littered in badges proudly proclaiming who, exactly, built and may have subsequently recalled some part of the car. Whether a Kia or a BMW or a Lincoln, I should be able to go to kia.com, bmw.com, or whatever, and find the recall information.

I should also be able to find if the car has been serviced for any of these recalls.

I don't need my government to save me the gross and unjust burden of typing "2010 toyota recalls" into Google (which, presumably, would quickly populate with accurate results, as Google tends to do, in the absence of government intervention).

(Disclaimer: I'm a bleeding-heart liberal with a strong like for social programs, and even I think that the government has no business in managing recalled cars.)

That's one issue that I hadn't heard of, but it makes sense: Of course the wifi chip, in an age of nearly-universally-smart NICs, should be able to filter broadcast traffic without waking up the rest of the system or even generating an interrupt...unless an application is actually using broadcast traffic.

The other issue is WMM, which is a function that requires support from the access point. It involves some packet scheduling, rather than shout-ASAP-into-the-collision-domain that Wifi was initially designed to do. This lets the RX portion of the radio to sleep when connected to an AP, whereas without WMM it cannot.

1. Can be taken further, in a manner not dissimilar to disabling the retarded pre-load-at-boot that such things as Open Office and Adobe Reader like to do on Windows:

Keeping seemingly-innocuous apps from doing non-productive things, triggered by system events that they have no business keeping track of, is something I've found to be very good for both performance and battery life.

As an example Pandora, the popular music streaming service, wakes up (runs) on all of the following universally-useless intents by default: After startup (why?), locale changed (eh?), application replaced (any app!), timezone changed (!), time changed (!!).

I don't want Pandora to run on boot, or any other time that any of those things -- booting is already slow enough as it is. And what business is it of Pandora's when I update an application? I want Pandora to run when I run Pandora.

I use Autostarts to do kill these hooks, and many other hooks for other apps. (Requires root and Xposed,)

2. Turning off radios helps, but not like you think it does. Modern Bluetooth sips so little battery in the idle state that it's silly to bother with adjusting it if you use it for anything, ever.

Manually GPS off is laughable: It's -always- off unless an app (navigation, etc) requests access. Some apps do use GPS when their needs are better suited using cell/Wifi geolocation (Weatherbug's first Android releases did default to GPS years ago), but I don't see it anymore because.... Rule #1: Look at permissions when installing...if an app doesn't need to know precisely where you're at and requests GPS access, just find another app.

One radio does make a difference: I found massive improvements in battery on VZW by having disabling LTE when the screen is off.

By default, both the LTE (data only) and CDMA radios are always on (this is how voice calling works), and I don't care if I have fast data if I'm not looking at the phone.

3. Yep. A good ROM will also disable LTE when connected to Wifi. Another big improvement: Turn on WMM in your access point if there are options for it. Without WMM, the client radio is always listening for a packet when connected, with WMM packets can scheduled and client is allowed to sleep for a short period. (This seems to be enabled by default on home routers lately, but it wasn't always the case. Hence the option in standard Android to turn off Wifi when the screen is off. WMM is what makes Wifi battery-friendly, and without it it can be very thirsty when connected, even if seemingly idle.)

4. I wish. (VZW.)

Also: 5. Greenify FTW.

Care to share the name of that mysterious ROM?

Sure thing!

Liquidsmooth. Running on a VZW Motorola Droid Bionic. Beautiful, simple. Fast. Easy.

Yeah, as if Cyanogenmod is ever going to release anything other than an Milestone release.

Srsly. They ditched 10.1 for 11, when 10.1 wasn't even yet stable? It's now most of a year later, and we still don't have a properly-stable, just-works release that doesn't change once a month?

And I say this as someone who actually likes Cyanogenmod, but found another AOSP 4.4.4 build that actually lets me use my multi-core >1GHz pocket computer with more than a thousand megabytes of RAM as it should be.

Nay, I have plenty of clue. But the private commercial networks I manage do not benefit from QoS, as all packets that transverse these networks are equally important and congestion is -- by design -- not an issue.

You really don't have a clue that it's even possible to solve this problem with a home gateway. Your perception clouds your vision.

Your loss, friend.

Now get off my lawn.

Again, you haven't used it. You're working with a theory, and really have no idea what you're going on about.

Latency increases somewhat under load (as it must), though not appreciably enough to affect any of the things we do with it. Jitter is very low as well. No matter how hard people or things hit the network, the user experience remains very responsive for interactive tasks...perceptibly the same as it is with an unladen connection.

This, as opposed to hundreds of torrent peers hammering away, one or more Netflix stream soaking up as much as it can get its hands on, and et cetera: Without QoS (and I didn't name it that, such terminology has been in place for quite a long time as relating to this sort of technique), this network was essentially unusable.

And now, it works reasonably. Individual TCP or UDP sessions are placed into groups with other similar sessions, and those groups have their own assigned priorities. This can be done by port, IP/MAC address, or deep packet inspection, or the amount of data the session has used, or even DiffServ flags.

It even has a fancy GUI that actually works.

You sound a lot like people used to sound back in the day, proclaiming that NAT (or ipmasq as it was more-commonly known at the time) could never successfully allow FTP, ping, or traceroute to seamlessly work. They'd list a lot of seemingly-logical reasons as to why it can't work and never will work, and then go on a long-winded rant about why either proxy servers or public IP assignments or at least one-to-one NAT is the only way.

Fast forward, and those people have STFU because -- gosh -- NAT works and does these things. They were ignorant of the possibilities of creative people making creative solutions.

I mean, sure: "Proper" QoS (ie: DiffServ and sensible routers with sensible queues and routes from end to end) might be nice. Maybe it even works on a private network. It doesn't work on the greater Internet, though, as you yourself say.

So rather than say "fuck it, I give up, there's nothing to do," I've simply solved the contention issues of my own grossly-overburdened last mile. And I've done it all from one side of the pipe.

If that seems impossible, then you're the ignorant one. There is a world of things that you did not learn in school, and some of them actually solve real problems that people experience. Nothing of this universe is so rigidly-defined that it cannot be adjusted in some useful way.

If you want to learn about it, though, download Tomato and spend an hour or two playing with it on a relatively-saturated network. Then read the source code if you still think it can't work that way.

Nothing I'm doing with QoS involves DiffServ -- at all.

That you proclaim otherwise shows that you haven't used the QoS features of Shibby's version of Tomato-USB.

And until you do, we don't really have much to talk about here.

The fact remains that I can rate-limit specific ingress UDP and TCP streams based on a number of parameters, leaving room in the otherwise-saturated pipe for other packets, using nothing more than an ancient freebie WRT54G and a small Shibby build.

How does this all work behind the scenes? I really don't care -- it's not my primary field of study. All I care is that it accomplishes everything that I said it does.

Apparently nobody here has used the QoS features in Shibby's version of Tomato-USB.

Torrenting and Netflix and gaming and multiple kids playing with Facebook and Youtube, all at once, all on 2Mbps of downstream while maintaining sufficient low-latency that interactive tasks and VoIP work fine?

Why not?

I did this just last night, as I have many nights before.

I'm perfectly capable of prioritizing my own bandwidth, thanks. I don't want my ISP prioritizing it on my behalf. Ever. At all. Not even a little bit. Not my wired ISP, and especially not my cellphone ISP where I pay by the gigabyte.

I'm not the person you're replying to, but: My (almost 20-year-old) car tells me when I have a brake light bulb out, and/or a failure in the brake light wiring and/or the mechanical switch that activates said lights.

When it tells me that something is wrong with the brake lights, I stop where it is safe to do so and fix the problem. I do this because I recognize the importance of showing the people behind me that I am, in fact, slowing down. (I also tend to have spare bulbs and a proper toolkit.)

I'm not suggesting that everyone would be so anal about their brake lights, but they should at least be informed.

With modern automobiles, where a network of microcontrollers is cheaper than a maze copper wires and multi-purpose LCD displays are standard fare, much of this functionality could probably be implemented in software alone.

And it should be. So people are at least informed that they're being jerks.