Is Your Internet Connection Free From Bufferbloat? (blogspot.com)

Bufferbloat is that "undesirable latency that comes from a router or other network equipment buffering too much data," according to the site for an ongoing project trying to address it. Now long-time Slashdot reader mtaht writes:Inside the lede-project, two core new bufferbloat-fighting techniques are poised to enter the linux mainline kernel and thousands of routers -- the first being a fq-codel'd and airtime fair scheduler for wifi, and the second, the new "cake" qdisc, which outperforms fq_codel across the board for shaping inbound and outbound connections.
His submission ends with a question for Slashdot readers. "It's been nearly six years since the start of the bufferbloat project. Have you or has your ISP fixed your bufferbloat yet?"

Comments

Can hosts files help?

[Anonymous Coward]

Can hosts files help with this bufferbloat problem? Anyone here that can enlighten us?

Re:Can hosts files help?

[Anonymous Coward]

No.

Re:Can hosts files help?

[Anonymous Coward]

but hosts file on your router and endpoint clients (either on windows or linux) can help you on your datacaps.

Nagle algorithm?

[ckatko]

Disable Nagle's Algorithm?

https://en.wikipedia.org/wiki/...

Re:Nagle algorithm?

[ShanghaiBill]

And how would that improve things?

It wouldn't. Nagle's algorithm doesn't cause congestion, it reduces it.

"Solving" a problem by going back to a probably worse one isn't really "solving it"

The first step in "solving" a problem is verifying that it is actually a problem. I am not convinced that "bufferbloat" (whatever that means) is a problem. Buffering can reduce latency, especially under heavy load, by better bandwidth utilization, and allowing faster retransmission of dropped packets. If it is slowing things down, then you should fix the buffering rather than eliminating it.

... and yes, I read TFA. It is a bunch of poorly labeled graphics that didn't make any sense to me, and seem to be designed to obfuscate rather than enlighten, although that may just be a result of Hanlon's Razor.

Re:Nagle algorithm?

[mtaht]

It is entirely probable we've been inside our own filter bubble so long (6 years) we cannot properly communicate with first time readers! some folk explaining the problem... the ietf video shows the benefit from fixing it. https://www.bufferbloat.net/pr... showing the extent: http://www.dslreports.com/spee... you have this entirely backwards: "Buffering can reduce latency, especially under heavy load, by better bandwidth utilization, and allowing faster retransmission of dropped packets. If it is slowing things down, then you should fix the buffering rather than eliminating it." You want enough buffering to absorb bursts, but any more just adds latency. Van Jacobson and kathie nichols calls this distinction good queue and bad queue: https://tools.ietf.org/html/dr... Less buffering (and fair queuing) allows for faster retransmission in particular.

Re:Nagle algorithm?

[Anonymous Coward]

I think it could be easier solved by simply applying the ARC (Adaptive Replacement Cache) algorithm, adapted to this scenario.

But what do I know, I've only been doing this for 3 decades.

Re:Nagle algorithm?

[Anonymous Coward]

"adapted to this scenario"

Re:Nagle algorithm?

[Anonymous Coward]

I can shed some light, hopefully.

At one point, and possibly currently, the upload buffer and the download buffer were the same. Since you could fill the upload buffer quite quickly and easily, the result was that your download latency went through the roof. The fix to this is to slow your upload (shape the traffic) to keep it just under the actual speed of your link, so that no upload buffering occurs.

The article talks about shaping download, which isn't possible at the endpoint. The traffic is already there and you have to deal with it. Dropping it will create retransmits for TCP and make the problem worse.

Re: Nagle algorithm?

[Anonymous Coward]

It doesn't matter how big or small the buffer is, what matters is why it's filling up to start with.
If you're buffering because of a transient traffic spike or network load, then the buffer helps. If it's constantly filling up and evicting then there's a deeper problem that won't be solved either by using, eliminating, or changing the buffering strategy.

Re:Nagle algorithm?

[Bengie]

Buffering can reduce latency, especially under heavy load, by better bandwidth utilization

You have no idea what you're talking about. Buffering is one of the main causes of latency. Ever see a 1,000ms ping? That's not because the speed of light is too slow, that's because there is a backlog of packets in the buffer. With the speed of light through fiber, no one should ever see a ping above 300ms to anywhere in the world. The highest ping I see from Midwest USA to Australia, India, or China is about 220ms.

Buffers are not inherently bad, but "bufferbloat" is because buffers are too large. Too large of buffers actually reduce throughput because TCP takes longer to respond to changes in congestion. Even worse is when bufferbloat starts to get up into the 3second range, yes seconds not milliseconds, TCP treats it as a lost packet and resends the data. I regularly see bloated Linux ISO seeders with 2k-4kms pings resending nearly 50% of their packets, most of which were not actually lost but only highly delayed.

Good anti-bufferbloat AQMs like fq_Codel and Cake increase effective bandwidth, while isolating light traffic from heavy traffic and keeping latency almost idle-link low. Want 10ms pings while paying games and downloading/uploading torrents, I have that already.

Re:Nagle algorithm?

[Bengie]

My response to this, it's not even wrong.

Re:Nagle algorithm?

[Bengie]

The article talks about shaping download, which isn't possible at the endpoint. The traffic is already there and you have to deal with it. Dropping it will create retransmits for TCP and make the problem worse.

Wrong. Dropped packets signal congestion. If you don't signal congestion, the congestion will only get worse. You eventually have to drop a packet. The sooner you drop the packet after congestion has started, the less the congestion will be. The flip side is if you signal too early, you lose effective bandwidth. I shape my download and it has caused my average to go up because it stabilizes the flows.

With normal fifo buffers, once the buffer is full, you get a burst of lost packets. This is much worst than dropping a single packet earlier.

Re: Nagle algorithm?

[Bengie]

If it's constantly filling up and evicting

This is actually normal for any congestion control algorithm that uses only packetloss to signal congestion. TCP? It keeps sending data until the buffer fill and drops "a packet", but we really know FIFO taildrop buffers drop bunches of packets. Then TCP backs off. But wait, there's more! You have many TCP flows going over the connection, so they are all fluctuation, keeping the buffer either in a state of steady full, which causes high latency and lots of dropped packets, or wildly swinging between empty an full because of global synchronization.

Re:Nagle algorithm?

[Anonymous Coward]

You can't shape download - you are confusing concepts.

Cisco: "Shaping implies the existence of a queue and of sufficient memory to buffer delayed packets, while policing does not. Queueing is an outbound concept; packets going out an interface get queued and can be shaped. Only policing can be applied to inbound traffic on an interface."

Re:Nagle algorithm?

[Bengie]

That is not the definition of "shaping", that is Cisco's definition for their own internal terminology. Regardless of what you want to call it, I can control the amount of bandwidth a flow or group of flows can use regardless of direction (ingress/egress), assuming they respond to normal loss, marked, or delayed packet. Most people calling this "shaping bandwidth", but you can call it whatever you want.

Re: Nagle algorithm?

[Anonymous Coward]

You only have 10ms pings to servers closer than about 500 miles.

Re: Nagle algorithm?

[Anonymous Coward]

Wow. Not only did you not understand the technical explanation - you did not understand the airport analogy.

I'm not going to explain why you are wrong and an idiot - you're too dumb to understand that, and while it serves no purpose for me to educate you, it does serve a purpose for me to laugh at nerds who aren't really smart but think they are, just because they are very ugly. It's that juicy overlap, where they're not actually smart, but because they are ugly they were rejected by people and spent more time studying, so we get these mediocre people doing nerd stuff, just because they are very ugly, not because they actually have any brains. The real nerds of course, not the ones who are nerds due to lack of looks but ones who are nerds because they have a high iq - those people are actually pretty fucking popular, since in the adult world smart and decent looking is a bonus. You work 8 hours, they work 3. they enjoy life and are popular. you get excited about some computer game. you are a loser, and people laugh at you. they are the ones doing the laughing.

You wipe front to back moron. It's so you don't get shit in your pussy. You should talk on this topic now. Your uneducated comments about the topic on the thread are just spam, and not funny.

How can I tell?

[Snotnose]

Not like I'm writing router or server code, I'm just a clueless dude surfing the web. Bad stuff happens, "the network" is hosed.

Re: How can I tell?

[mspohr]

Why is bufferbloat bad?

Re:How can I tell?

[Anonymous Coward]

Try this no-bullshit speed test with bufferbloat analyzer: https://www.dslreports.com/speedtest

Re: How can I tell?

[pem]

Because it was there.

Well, your sig was, anyway.

Re:How can I tell?

[PopeRatzo]

I took the test and got an A in buffer bloat. Is that good or bad?

Re:How can I tell?

[crashumbc]

bad you should immediately turn off you internet fo for 30 days to "reset" it....

Re:How can I tell?

[PopeRatzo]

bad you should immediately turn off you internet fo for 30 days to "reset" it....

Say, I wasn't born yesterday. I know very well that if I just disconnect the cables and put the router in the microwave for 45 seconds at 50% power it'll do the same thing.

Re: How can I tell?

[Anonymous Coward]

Because it increases latency and causes backpressure on all other routers in the infrastructure. If latency gets really bad then stacks start missing windows and blocking upstreams sends, then clients back up and everyone gets mad and sad and slow.

Re:How can I tell?

[crashumbc]

OMG man, disconnect the cables!!!! NEVER, Skynet will detect that and launch! Joshua already had 8 of the launch codes! you need to make him play tic tac toe, enter zero players!

Re: How can I tell?

[Anonymous Coward]

It's a bloated buffer, it's not an optimally balanced buffer for the environment.

Re: How can I tell?

[mtaht]

do you ever use skype, play games, surf the web, while someone or something else is more heavily using you connection?

Re:How can I tell?

[mtaht]

It has nothing to do with writing code, but normal uses actually using the internet when contending for bandwidth.

Re: How can I tell?

[fbobraga]

Why is bufferbloat bad?

causes high latencies (very bad for gaming)

Let's find out.

[Anonymous Coward]

First bufferbloat test.

Cute name, no tangible problem

[Anonymous Coward]

You've given it a cute name but I don't see any tangible problems....?

Re:Cute name, no tangible problem

[Fly Swatter]

The tangible problem is if you need low latency, or want to maintain the latency you have, when your upstream connection is saturated. At least I think that is what it means.

Re:Cute name, no tangible problem

[NilesDonegan]

DSL is unfortuantely the best internet connection in the small town I live in. The upload rate of these connections is really slow, and for large uploads, can saturate the connection. What this translates to in the real world is constant complaints from people about how their internet connection has just died for no good reason. What's happening in 99% of these cases is that some iPad in their house is backing up to iCloud, and bufferbloat from this upload is temporarily wiping out download speeds.

What I did was install the OpenWRT firmware on my TP-Link router, and install the SQM (Smart Queue Management) QoS application on it. This shapes uploads so that bufferbloat is greatly reduced. I tested all of this on DSLReport's Bufferbloat page, and it works great.

Re:Cute name, no tangible problem

[mtaht]

which sqm mode are you using?

Re: Cute name, no tangible problem

[Anonymous Coward]

Buffers are not a problem for latency, the growing internet is. Back in the early 2000s from a particular place in Europe to the west coast in US we averaged over 220ms RTT because it was going up to a satellite, landing in Newark and then traveling over 4 hops to the west coast. Around 2003 when we switched to fiber we got down to about 110ms, with the fiber going via two landing stations on the north shore of Africa, then via France via the Atlantic Ocean to Maine (or dalaware) then over land to the west coast. That was something like 12 to 14 hops.
As the years passed newer and faster fibers were put in place, but also more routers were added to branch the backbone more. Now the same geographic location in Europe to the west coast of US is again at 220ms RTT, because the hop count is around 36. Almost 3 times more routers today than 14 years ago. This is where the latency problem comes from - packet switching in the multitude of hops and MPLS tunnels that you don't even see, not from some imaginative buffers.

Re:Cute name, no tangible problem

[Anonymous Coward]

Too much buffering means that packets don't get dropped when there is congestion.
The congestion avoidance algorithms in TCP work by detecting packet drop.

Buffer bloat causes congestion, which causes buffers to fill up even further, which causes more congestion.

The only real way to solve this is to timestamp packets as they enter a buffer and drop the ones that are too old. They have tried modifying the congestion algorithm, but the only reliable way of detecting congestion is still packet drop.

Re: Cute name, no tangible problem

[Dagger2]

Badly managed buffers are a massive problem for latency. Just look at this graph from the article. You see the four ping time measurements on the right? You see how one of them is 100-250ms and the rest are more like 20ms? That's exactly the same link in all cases, but the first measurement has a giant pile of latency introduced purely by poor buffer management.

I'm not going to dismiss the problem you described, because I agree it's a problem. But it makes no sense to worry about 100ms on cross-Atlantic links and yet completely dismiss 200ms right on the first hop.

Re:Cute name, no tangible problem

[Bengie]

The only real way to solve this is to timestamp packets as they enter a buffer and drop the ones that are too old.

You don't have to timestamp them to get the same effect. Codel and RED both effectively use time without timestamping. But yes, the "tracking time" is pretty much the only way.

Re: Cute name, no tangible problem

[Anonymous Coward]

It is not physically possible to have a rtt via geosynchronous satellite that is less than 484ms. The satellite is about 22500 miles high (even farther if you're not directly below it). Thats 121ms at the speed of light. You have to do that trip 4 times. Plus router delays. Plus the fiber delays on each end.

Re:Does the Tin Man have a sheet metal cock?

[Anonymous Coward]

Why the fuck would Tin Man have a woody?

Re: Does the Tin Man have a sheet metal cock?

[Anonymous Coward]

Idiot. It would be sheet metal, not wood. So it is called a steel hard stiffy. He is not equipped with one. Fluids are drained from a 1/2" NPT threaded plug in his abdomen. Recommended oil changes are every 5000 hours of operation.

Bufferbloat? Yes. But...

[Anonymous Coward]

While bufferbloat was patched out, my router is still under the control of a cargo ship, which claims to actually be an aircraft carrier. What is to be done about blufferboat?

Go measure

[mtaht]

Judging from the first 25 replies, the slashdot readership is suffering from an overdose of eggnog. Here's a link (which has links to results from every ISP), which shows latency under load often measured in seconds. http://www.dslreports.com/spee... The problem with this survey is that there are now plenty of folk that get sub-30ms latencies on their internet - which is what those using bufferbloat fixes get, and the question was if you or your isp was driving improved hardware to get those results. Problem seems to be 99% of the results are worse than that, still, 4+ years after the code to fix first arrived in Linux.

Re:Go measure

[Anonymous Coward]

First bufferbloat test.

Re:Go measure

[waveclaw]

With dislreports and other aggregation tests, the bloat for download and upload may not be symmetric. So the resulting score might not be as good as it looks.

Paying for a commercial connection? Test for this kind of performance daily and scream as soon as it drops. Otherwise why bother to pay so much?

In the United States and other jurisdictions a home 'customer' user is not expected to run a "server" on their paid for Internet connection. Downloads may be finely tuned to low bloat. But upload may have significant bufferbloat, caps and gradual dropout. For financial reasons, of course.

This upload problem may get to be much worse in the future. More and more services push data from "client" devices in the home or office. Camera phone videos, twitch streams, shared google docs and your home automation spyware upend the upload/download assumptions of last-hop telcos. P2P is impacted now. The highly asymmetric buffering of uploads is detectable using protocols like bittorrent that don't have client-server separation.

Re:Go measure

[mtaht]

I am not huge on basic web tests, preferring the finer grained results we get from flent. (https://flent.org).
And I totally agree that the trendline is to ever more devices doing ever more stuff randomly when you least desire it. We need to have edge routers AND ISPs ready for this change in traffic patterns.
The article you cited was quite good, although it missed completely the outputs of the ietf aqm working group, of which both I and fred baker are members.
https://tools.ietf.org/wg/aqm/

Re:Go measure

[wbr1]

Dave, I think most of the /. readership is on the eggnog all the time. However, this is the type of thing a few of us still come to this site for. Thanks for your work on this, one can only hope more ISPs and equipment manufacturers implement it.

I see the effects of bufferbloat everyday. As a manager at a small MSP, we have many clients who have large scheduled 'cloud' backups that can saturate the upstream connection. Especially on DSL. Significant reduction of bufferbloat would mean that we could use more upstream bandwitch, even during peak hours with minimal detriment to the customer.

Keep up the work!

Re:Go measure

[wbr1]

Cloud PC backups affect this as well. We offer this to business and home user clients, and those that are on smaller, non business, connections suffer from upstream bloat far more. Of course our primary DSL provider is Centurylink who is pretty terrible. Comcast seems to have been doing a bit better job, but not by much, and that may just be an artifact of a larger pipe.

Re:Go measure

[unixisc]

Why is bufferbloat something that's done at the routers, rather than in our browsers, w/ a variable buffer that we/the browser itself have an option of deleting? Why is it the job of a router to store all that garbage, rather than get that from the browsers themselves and do it?

Re:Go measure

[ipb]

"Dave, I think most of the /. readership is on the eggnog all the time. However, this is the type of thing a few of us still come to this site for. Thanks for your work on this"

I second this.
After the first couple of pages I almost gave up reading because of the eggnog comments.
For the record, queue management in OpenWrt has done a lot to lower bufferbloat on the systems I use.

Re: Go measure

[Anonymous Coward]

Because the buffer is a link level mechanism, and the browser is an application which only has indirect knowledge (if any) of pathing and link saturation.

Re:Go measure

[richb-hanover]

The router needs to manage the bottleneck link, since that's the place all the data gets queued up (in those buffers that are the topic of interest). The router is the only device that has visibility into the amount of data that's in transit "to the internet". Your browser doesn't know that your spouse's/kid's iPhone just decided to upload all new images to the cloud. Nor can your gaming system. Browsers are designed to send the data as fast as possible. Gaming systems are designed to send immediately after you click. It's the responsibility of good networking equipment to regulate all the flows of data so that *everyone* gets good performance. (And while you *could* spend your life optimizing qos rules, the beauty of fq_codel/cake is that they take one parameter (link speed) and they automate all the rest.)

Re:Go measure

[Bengie]

+1 this up. Nailed it, and not the meme type. Most people, including network admins with years of working with QoS, are incapable of setting up QoS correctly, and only think they've set it up correctly not because of theoretical correctness but because they cannot even think of the edge cases to get empirical tests..

Re:Let's find out.

[Anonymous Coward]

i notice that none of the pages that are linked to in this article have anyone's name on them. Is this the same crackpot who was complaining about this non-existant problem a few years ago?

Forget BB, the plethora of ad-serving sites...

[GerryGilmore]

...is what slows my connection speed down. Fuck, I could have a gigabit connection and would spend 80% of my time waiting for the next version of ad.doubleclick.net, etc. Really? Bufferbloat? I wish!

Re:Forget BB, the plethora of ad-serving sites...

[mtaht]

Oh, I strongly recommend ublock, too! I go around installing that on friends and family's computers every christmas. :) But this christmas, I reflashed a ton of routers, too.

Re:Forget BB, the plethora of ad-serving sites...

[tlhIngan]

...is what slows my connection speed down. Fuck, I could have a gigabit connection and would spend 80% of my time waiting for the next version of ad.doubleclick.net, etc. Really? Bufferbloat? I wish!

Yeah, you'd think the folks at Alphabet (DoubleClick's parent company) would know a thing or two about how to optimize for the Internet.

On the other hand, now DoubleClick knows everything you did on other Alphabet sites, like Google, YouTube, etc.

Re:Forget BB, the plethora of ad-serving sites...

[dinfinity]

I highly recommend DNS based blocking in your router. All smartphones and tablets using your network will also be rid of 99% of all that crap.

There's a package in OpenWRT (not in the main repository, though) that updates blocklists on a schedule (the scripts are very straightforward and DIYable, but it's nice to have a click and go solution):
https://github.com/openwrt/pac...

The only downside is that making (temporary) exceptions is not really an option.

Re:Forget BB, the plethora of ad-serving sites...

[Anonymous Coward]

One gets me 400 hp + 50 mpg (hosts) vs. 90 hp + 5 mpg (ublock)?

Re: Forget BB, the plethora of ad-serving sites...

[Anonymous Coward]

My phone has 15,000 hitpoints and I drive a Prius so there isn't any gallons, how do the hosts files help? Are they made of plastic, aluminum, or steel, and will they void my car's warranty if I install them?

Re:Forget BB, the plethora of ad-serving sites...

[thegarbz]

...is what slows my connection speed down. Fuck, I could have a gigabit connection and would spend 80% of my time waiting for the next version of ad.doubleclick.net, etc. Really? Bufferbloat? I wish!

Two different problems. I don't randomly get ads in the middle of time sensitive UDP packets while video chatting or playing games.
There are two problems we can solve here.

Re:Forget BB, the plethora of ad-serving sites...

[Anonymous Coward]

I'd say a fuck of a lot less than 50mpg considering how much energy and time is wasted with your shitty deduplication algorithm. Hurr durr it's a built in Delphi feature, hurr durr, I'm too stupid to write my own which actually works.

Re:Forget BB, the plethora of ad-serving sites...

[Lennie]

You really think it's just ads ?

Here is the Bufferbloat demo from 2013:

https://www.youtube.com/watch?...

More data?

[wizden]

The latency measurements in the article are meaningless. Reducing seconds of latency to milliseconds! Where is point a and b? The driver layer adds ten seconds of latency? None of this makes sense.

Re:More data?

[mtaht]

If you are referring to the cake article, the baseline latency of the path is ~11ms. It grows to about 250ms under pressure from a tcp transfer with a "normal" cable modem, and to only 16ms or so with cake. See the bar graph... wifi could get much much worse. but we fixed it in the upcoming linux 3.10 release. Not that anybody seems to understand....

Re:More data?

[mtaht]

As for the wifi article, yes, we have seen 10+ seconds of excess latency in the wifi stack. 1-2 seconds is typical with normal traffic at lower rates, as most protocols time out in that range.

Re:More data?

[DamonHD]

You're coming across as rather rude and condescending in your various posts.

As it happens I do kinda understand the problem having run one of the first live commercial IP connections in the UK since it was possible, and for example had to have a word with a small startup called something weird like 'Google' that more connections doesn't equal lower latency either when you are bandwidth constrained (which everyone on the UK was by orders of magnitude more than the US to the bafflement of G's engineers).

So back off accusing people here of being stupid or drunk, and try being helpful, I suggest.

Rgds

Damon

Re:More data?

[amacide]

Thank you for such excellent contributions to Linux kernel :-)

Re:More data?

[wbr1]

Few here can understand anymore. Admittedly it is at the edge of my skill and knowledge level, but I understand enough to respect it. I think most of the real engineers have gone from here.....

Re: More data?

[wizden]

Thanks for sharing the baseline latency. I work for a rather prominent wireless manufacturer and I just don't see the latency you're talking about. Voice over wifi would be impossible with that level of latency and we see customers deploy that everyday. Is this limited to Linux?

Re: More data?

[mtaht]

These are "latency under load" measurements (using the dslreports and flent tools to stress out your link). If your network is otherwise idle voip is fine, but with people adding ever more devices to their network doing random things at random times, the bloat problem raises its ugly head.
(and yes, voip is frequently unusable when your ISP link is under stress from something else without out these queue management techniques in place there)
I tried to stress in the lwn article that first eliminating bloat from the ISP link will make your wifi a lot better, because wifi is usually not the bottleneck in many scenarios. But: the wifi work we just pushed upstream makes voip far more possible when wifi is contended.
Is it limited to linux? No - it seems to be deeply affecting the current crop of gateways supplied by ISPs, as well as nearly the entire 3rd party router market, except those who are deploying qos sanely (which is nearly everybody these days in third party firmware - "fq_codel" lies underneath many a rebranded qos system nowadays. "cake" is a possible successor.
The frustrating part is that wifi folk are often saying their stuff is fine, when it can be so deeply affected by the next hop up, and also tends to become poor anytime a second or third device is stressing the link (transferring files to a NAS, for example, screensharing for another). 802.11ac devices tend to have more latency than 802.11n, also, because they tend to use a fixed buffer size suitable for their highest rates, and not something that adjusts to the actual rate.
If you are interested in poking into these issues further, on your equipment, take a look at flent, and/or come on over for the discussions on the make-wifi-fast mailing list.

Re:More data?

[mtaht]

I was a bit put off by the first 25 posts being basically trollish. I have tried to be helpful, merely, since.

Re: More data?

[mtaht]

Many enterprise APs are pretty good, btw - and while I have not tested the current crop of stuff from eero, and google and so on, I'm pretty sure they've been paying attention to the work. (portions of the make-wifi-fast project were funded both by google and comcast research) So I hope you've been making your stuff great in the first place, and not having to deal with paying off all the technical debt we've been paying off here: https://docs.google.com/docume... But please go test for the things we are testing for and fixing!

Re:More data?

[DamonHD]

That's gracious of you.

I've gone and read a bunch of your work, including blogs, and it is very interesting and definitely a public good if you pull it off, thank you.

I like smart distributed algorithms.

I am still baffled from an afternoon's reading round the subject if to be effective your anti-BB magic has to happen at (nearly) every edge device, or (nearly) every lossy (or speed-mismatched) network gap, or if BB can be fixed by judicious ISP infrastructure deployment, or would cumulatively benefit if multiple of those happened.

Rgds

Damon

Re: More data?

[wizden]

I guess my assumptions are tainted from running enterprise APs in my house and at my customers. Of course our hardware is awesome. :)

Re:More data?

[Anonymous Coward]

Then make it an educational channel that explains why this is so important/cool/useful. I started reading Slashdot back in the day to learn from experts in various fields. Over the years, I've read or linked to tons of cool stuff that I would never have come across in my normal reading.

Re:More data?

[mtaht]

Dear Damon:
I'm sorry, I tuned out of slashdot after a day.
"I am still baffled from an afternoon's reading round the subject if to be effecitive your anti-BB magic has to happen at (nearly) every edge device, or (nearly) every lossy (or speed-mismatched) network gap, or if BB can be fixed by judicious ISP infrastructure deployment, or would cumulatively benefit if multiple of those happened."
Better queue management everywhere would be good. Your second thought is closest to correct:
"(nearly) every lossy (or speed-mismatched) network gap" needs better queue management. That's a LOT (billions) of devices. The thing is, the queue management problem was known well before 1992, it's just that RED did not deploy very well, and FQ techniques were often kept as secret sauce. Things got out of hand as speeds went up and the potential speed mismatch variance between links went to 6 orders of magnitude, since 1992.
I (we) fully realize that the scope (billions of machines/year) of sticking solutions everywhere is hard, but it is never too late to start, (b and replacing dumb overbuffered fifos everywere with a couple hundred lines of code - considering the millions elsewhere seems simple!) and we've pursued developing an easily deployable solution (fq_codel primarily), as well as standardization efforts (ietf aqm working group). Things like systemd default to fq_codel, so do most third party linux router firmwares.
About the only major thing left (since fixing wifi) is actually getting this stuff into hardware and "big iron" like cmtss and BRASes.
... On devices themselves, we've worked on ripping out excessive buffering throughout the stack (BQL, things like TCP_NOTSENT_LOWAT (now the default in OSX), most recently pacing via the sch_fq qdisc and "TCP BBR") so that the tcp's and applications (mostly linux, but increasingly BSD), are not storing crazy amounts of data internally. There's been a lot of other changes, all my talks include a slide on the higher levels of stack and application issues.
... IF you have enough capacity, you don't see BB (except for microbursts, which couldbe quite bad before we started moderating TSO/GSO/GRO bursts). Certainly the core and a well designed infrastructure that never saturates removes the issue (except when it does happen!)
... At some point I need to sit down and write something definitive, instead of this vapor trail of 6 years worth of work all over all the gear and all of the stack(s).
-- Dave TÃht Let's go make home routers and wifi faster! With better software! http://blog.cerowrt.org/

Re:Let's find out.

[Anonymous Coward]

You are a wien-er.

captcha = viewable

bufferbloat versus data throttling at data-cap

[Anonymous Coward]

I don't have problems with bufferbloat, i have problems with speed throttling of my ISP once my data-cap of 3GB is used. Before reaching the cap I get 120 kbps download and once the 3GB is reached (due to ads and css on third party sites) my connection is throttled to 35 kbps. Fun times.

Comment removed

[account_deleted]

Comment removed based on user account deletion

Re:Not magic

[Anonymous Coward]

Don't forget that dropped packets is the only reliable way for TCP to detect congestion, unless you want to use out-of-band signalling for congestion.

This is completely a non-issue with the ISPs

[mimino]

The simple answer why we don't hear an answer to "Have you or has your ISP fixed your bufferbloat yet?" is because the ISPs have been usin cut-through routing and forwarding that do not suffer from the buffer bloat. Modern internet does not suffer from this problem. Maybe your home lab with a Linux router does, but that is of no concern of the ISPs.

Re:This is completely a non-issue with the ISPs

[Dagger2]

Maybe in their core, but what happens when they try to fit that traffic down your 10 Mbit/s DSL link? There is going to be a buffer there.

Re:This is completely a non-issue with the ISPs

[mtaht]

cut through routing works when there is no congestion. http://www.dslreports.com/spee...

Re:This is completely a non-issue with the ISPs

[richb-hanover]

Well... I disagree that the "modern internet does not suffer from this problem." I have seen it at my house, and at measurements at many other places. (If you're only considering FTTH as "modern", I have still seen bufferbloat there...)

The ISP does have an opportunity to control buffering in two places: at both ends of the bottleneck (which is likely to be your cable/DSL/FTTH/etc.) link between your house and their facility.

a) Their "head end" gear might control queues for traffic going *to* you
b) Their Customer Premise Equipment (CPE) also would have the ability to control outgoing queues

If the ISP did both, then no one would have need to coin the term "bufferbloat". But the fact of the matter is that the vast majority of ISPs do *neither*.

Consequently, in late 2016, I believe it's prudent to provide my own solution and use one of the Smart Queue Management solutions (fq_codel, cake) that's available in LEDE/OpenWrt/DD-WRT so that I can get on with useful work.

Yes

[Bender Unit 22]

Now it is after I got my fiber connection it is all gone. My old *DSL connected at 50/10 mbit(errorfree) but I couldn't get anywhere near that(30mbit at most) and latency were way too high. Only place it caused me some problems was when I worked from home and the Citrix connection as I don't play online games.

Re:Yes

[ciro2016]

masa thatk you for this nice post

Re:Not magic

[adolf]

You're right, of course. The trouble is, the latency increases aren't reasonable for common consumer networks under load.

Two speedtests I just did on my lightly-loaded hardwired home network (30Mbsp cable from Time Warner):

With QoS

Without QoS

Throughput is less (rather surprisingly less -- I may want to check some things) with my QoS rules that group connections into individually-throttled categories, but bufferbloat is sane-ish (a brief peak at 250ms was observed, but otherwise under 100ms).

Without QoS, bufferbloat starts at around 1000ms (x10 increase!) and goes up from there.

I'm currently using Shibby's version of Tomato-USB on an overkill dual-core Asus router to accomplish this, though I have used other consumer-ish hardware with reasonable success (including the venerable WRT54G/L/GS) using similar software.

The trick, as I see it, is primarily to ensure that the cable modem (and whatever is directly upstream of it at the head-end) never see enough throughput for their buffers to begin filling by keeping all nearby bottlenecks under my own control.

The other benefit of QoS is that on heavily bandwidth-constrained networks, some tasks can be given higher priorities than other tasks, which is easy when we control the neck of the bottle.

I dated a girl for a bit who had the cheapest Internet she could get: 2Mbps down. Her kids hated it, and web browsing with tablets and phones and laptops was terrible for all of them if anyone was streaming a video (badly) or downloading (slowly). Loud banter over who was "hogging the Internet" and ruining gaming was common, and not unreasonable. It got worse when people would visit. It was really bad.

Best case: They were taking turns using the Internet. In 2014.

After observing this and suggesting she get faster Internet ("no, it's not important to me," she said) I gave her a router with Tomato, did some obvious QoS priorities that were tweaked for that particular situation, and voila: The games worked fine. Web browsing was always quite responsive. Youtube worked (worked meh, but worked), and downloads and BT didn't trash any of the above. Anyone could do whatever they wanted, and the inevitable slowdowns were graceful while responsiveness remained good. The gamer of the house didn't get upset anymore seemingly-randomly.

But that's just one success story. I've been doing tricks like this for over a decade on a myriad of non-enterprise networks, using cheap hardware and thoughtful software.

(Now it's time for someone to pop up and tell me that I've done it all wrong, and that my results are impossible. This always happens on /. when I write about using Tomato and QoS to solve real, practical problems. I'm ready.)

Re:Not magic

[Anonymous Coward]

Is your moustache real?

Re:Not magic

[wbr1]

You've done it all wrong! Those results are impossible!

Re:UBlock = inferior + inefficient vs. hosts

[IWantMoreSpamPlease]

I have 32GB of ram in my system, 64mb barely registers on the radar. Nice try, thank you for playing.

i dont get it.

[Anonymous Coward]

okay. so the internet provider is selling 100/100 Mbps to twenty people but the backbone uplink is only 1 Gbps.
so the solution to more snappy-ness is to limit YOUR CONNECTION (on your end) to fit into the REAL uplink capacity?
that is "move the buffer to something you control" which fits into the REAL uplink of 50 Mbps?

of course if the provider would upgrade the uplink to 2 Gbps there would be NO los of snappy-ness?

Re:i dont get it.

[Dagger2]

It's pretty much not that at all. It's closer to:

* The provider is selling 100/100 Mbit/s to 20 people with a 1 Gbit/s uplink.
* You hook a WiFi router up to the 100/100 connection.
* While trying to VoIP/Skype on one WiFi device, somebody else starts watching Netflix on another.
* The latency on your WiFi (and thus your VoIP call) jumps up to 50-100ms due to bad buffer management on the WiFi.
* A third device starts trying to sync photos to a backup service, introducing another 100-250ms* of latency by tying up your upstream and generating another badly managed queue on your router.

That's a ton of unnecessary latency being generated right in your own house, by your own gear, and none of it will be helped by the ISP putting in more upstream bandwidth.

...on the topic of which, it would be insanely unnecessary to have 2 Gbit/s of bandwidth for twenty 100 Mbit/s users. You don't need enough bandwidth for every user to max out their connection simultaneously, because that never happens; you only need enough to cover whatever your actual peak traffic is without dropping any packets. When averaging over thousands of customers, this actually works out to needing something around 100 Kbit/s(!) per customer today.

Of course 20 is much less than "thousands" and the traffic profile of 20 customers will be much more peaky than the one of 1000 customers, but I suspect even then that 1000 Mbit/s would be enough to cover twenty 100 Mbit/s connections without dropping any packets. It certainly wouldn't be anywhere near having a "real uplink of 50 Mbit/s".

(*: Probably it wouldn't be this bad with a symmetric 100/100 connection; the graph I linked is for a 140/12 connection, but those are probably more common than symmetric connections anyway.)

Re:i dont get it.

[DamonHD]

There are definite peak hours for customer traffic, eg work hours for businesses, and evenings and weekends for home users, so even the very generous 2:1 contention ratio that you seem to be suggesting probably would still result in a saturated backhaul from time to time.

Thus shifting as much discretionary stuff away from that peak as possible will help, just as for power grids, but that's a separate topic.

Rgds

Damon

Re:i dont get it.

[Dagger2]

It depends on the number of users involved. For this case of 20 users... yeah, you're probably right that you couldn't guarantee no packet loss all of the time, but you would probably get quite close. "It's a weekend" wouldn't be enough to saturate it; even when actively using the internet, most people's bandwidth use is short large spikes surrounded by lots of idle time. Torrents would be a better bet, but maxing out the link would require 10 users torrenting at their max line speed. There are people who will do that, sure, but your odds of having 10 of them at once in a building of 20 people are low.

At the main ISP level, where you're aggregating thousands of customers together, you can overprovision far more than 2:1 safely because customers average each other's traffic out and unusually high peaks become even rarer.

(I should point out that I have no operational experience running a network like this so a lot of this is educated guesswork, but the ~100 Kbit/s figure I gave in the last post comes from people who do have that experience.)

Doing less using more != better

[Anonymous Coward]

Comparison: Hosts gets 50mpg/400hp. Ublock gets 5mpg/30hp. What's better? Best hosts creator https://tech.slashdot.org/comments.pl?sid=10039961&cid=53555237/

APK

P.S.=> Hosts do far more for far less vs. UBlock (or any addons) & faster + more efficiently... apk

Re:Doing less using more != better

[Anonymous Coward]

If you're going to use a program to manage your hosts file, don't use one made by a forum spammer, troll, and stalker. There's tons better software for the purpose out there that work much better than this clown's "Host File Engine 9.0+++". I wouldn't trust any closed source freeware in which the author spends so much time spamming forums with online virus scan results trying to show it is "safe". Perhaps you malware just hasn't been discovered yet because you only have tens of people using your garbage app? There's plenty of host file management utilities out there that are open source and are much faster than APK's trash, all use the same damn sources for their lists. Don't support this idiot!

Re:Doing less using more != better

[Anonymous Coward]

And he considers Linux users his enemy!

Rogers isn't

[davecb]

At least in Tranna

Re:Rogers isn't

[davecb]

The sped test says and shows as a png

Re:Not magic

[adolf]

I'll need to see your CCNA before I can accept your retort.

Re:Does the Tin Man have a sheet metal cock?

[rotorbudd]

Steely Dan?

No problem here!

[DaMattster]

I built my own router because I don't want any of these mass-produced, consumer piece of shit routers with more holes in them than swiss cheese.

Re:No problem here!

[Lennie]

So what OS did you use ? Did you enable fq_codel or similar ?

Re:Not magic

[mtaht]

Nice success story and the exact circumstances we were trying to make easier to solve with cake. (and the dream is more ISPs would just be doing it for you on their default supplied boxes)
I would like to benchmark more stuff like tomato's qos against cake, the equivalent (single!) command line for outbound would be:
tc qdisc add dev your_device root cake bandwidth 2mbit nat
which automatically applies per host fairness, qos, and queue length management.
inbound requires a slightly more complex setup but not much.

Re: Let's find out.

[Anonymous Coward]

Pizza delivery for an I.C Weiner.....

oh crud.

Re: Not magic

[Anonymous Coward]

Buffering is more useful for UDP, and is primarily intended to smooth out transient congestion on a network link or interface.
On a Carrier network, it's used to help deal with bursty traffic... TCP is a rather "slow" response mechanism which works fine in general, but can't handle congestion which comes and goes on millisecond or sub millisecond time scales.

For example, if an ISP has ten 100gig links running in a bundle, and a 1ms duration traffic burst fills one link up, the buffer will soak it up and allow for the load balancing to recalculate traffic flows across the other links. Without the buffer, those packets would drop, and all the TCP clients would react and throttle back, even though the overall bundle is still under 50% capacity, and even though the congestion has long since cleared before the packet times out.

The other place buffers are useful is when enforcing QoS on a network. They allow the router to evict higher priority traffic ahead of other traffic, so that when congestion hits you can still guarantee some traffic types.

Re:Not magic

[richb-hanover]

Buffer bloat can't happen without congestion. Congestion is the real problem and talk of buffer bloat is a bit off-point. Sure, if you combat congestion with very large buffers (and hence significant queuing), you get increased latency due to the queuing. Reasonable increase in latency (say 20%) is not a huge hit on performance. Remember that you're trading that extra latency for lower probability of dropped packets.

You're correct that bufferbloat "only happens" when there's traffic. But I don't think you appreciate the current nature of internet traffic.

With web pages averaging 2 megabytes these days, you're "doing large file transfers" all the time. And if your iPhone kicks off an upload of its pictures, or your child starts watching videos, or your spouse starts their own web browsing/mail session, you're at the mercy of your router's queue management algorithm.

I don't think a "20% increase" in latency is reasonable, given that the Smart Queue Management (fq_codel, and soon cake) that's available in the Linux kernel (not to mention LEDE/OpenWrt/DD-WRT for your home routers) provide a "no-settings" way to limit lag/latency to an increase of only a few msec (or a couple dozen msec on a crummy DSL link).

Re:UBlock = inferior + inefficient vs. hosts

[fbobraga]

maintain a hosts file is a PITA

GEO is 0.24 s round trip

[tepples]

With the speed of light through fiber, no one should ever see a ping above 300ms to anywhere in the world.

Even to places where there's no fiber connection? In a lot of places, the only route to the Internet with a throughput greater than the 0.15 Mbps of IDSL is through a satellite in geostationary Earth orbit, 36,000 km up. An ICMP ECHO request from a subscriber to a satellite ISP, such as Exede, needs to go up to the satellite and down to the destination network, and its response needs to come out of the network and then go up to the satellite and back down to the subscriber. That's 0.12 light seconds for each of four legs, already nearly half a second, plus whatever latency is in the destination network.

Re:GEO is 0.24 s round trip

[Bengie]

In a lot of places

At some point in your life, you should realize that "no one" mean very very rarely. Absolutes are never absolute. I question if my last statement makes any sense.

A testimonial

[Anonymous Coward]

I've been using CeroWrt (https://www.bufferbloat.net/projects/cerowrt/wiki/ - the initial testbed for all of the bufferbloat work) for at least four years. For the majority of that time I had 1.5Mbps DSL service, but now I'm connected via a 12Mbps ADSL2+ link.

Prior to the installation of CeroWrt, it was painful for me to attempt to work remotely using an SSH tunnel if someone was watching a show via Netflix, but after setting up CeroWrt everyone was happy (me for not having to yell at my daughter and my daughter for being able to watch Netflix without me yelling).

With the 12Mbps link, it doesn't seem to be the ingress traffic that causes issues, but the egress traffic (at times, I upload large data sets). Without shaping the outbound traffic, I can see round-trip times in excess of 2 seconds which is just a bit excessive. ;-)

I recently installed LEDE (https://lede-project.org/) (an OpenWrt (https://openwrt.org/) fork) on a spare router (the same model as the CeroWrt router - WNDR3800) and it is obvious that the software continues to improve.

It appears that LEDE may be approaching its first stable release (https://forum.lede-project.org/t/criteria-for-first-lede-stable-release/552). If you have a spare router that is supported by LEDE, please consider installing a current build and report any issues found.

If you would like to learn more, here are a few random links to get you started:

• Explaining RRUL Charts (https://www.bufferbloat.net/projects/bloat/wiki/RRUL_Chart_Explanation/)
• The Cerowrt-devel Mailing List Archives (https://lists.bufferbloat.net/pipermail/cerowrt-devel/)
• The Lede-dev Mailing List Archives (http://lists.infradead.org/pipermail/lede-dev/)
• Does LEDE support my router? (https://lede-project.org/supported_devices)
• The Make Wi-Fi Fast Wiki (https://www.bufferbloat.net/projects/make-wifi-fast/wiki/)
• The Make-wifi-fast Mailing List Archives (https://lists.bufferbloat.net/pipermail/make-wifi-fast/)
• Possible OpenWrt and LEDE merge (https://www.google.com/search?q=OpenWrt+LEDE+merge)
• All of Dave's Patreon posts (https://www.patreon.com/dtaht/posts)

I feel that the work that Dave (and everyone else that is involved) is so important that I send a few coins his way every month via Patreon. Here's his most recent update: "Where your donations go" (https://www.patreon.com/posts/where-your-go-7564906).

Dave, a belated Merry Christmas to you and I'm looking forward to a New Year where all of the efforts to tame bufferbloat and make WiFi fast benefit everyone.

Re:Not magic

[Anonymous Coward]

Can you elaborate on some of the QoS settings you use? I'd like to mess around because speedtest.net gives me an F on bufferbloat, but I have no clue which knobs to tweak or what values are reasonable. HTB vs HFSC, service priorities, etc.

Re:Not magic

[Bengie]

Remember that you're trading that extra latency for lower probability of dropped packets.

Not once you've gotten into the "bloated" range of buffer sizes. Increased latency from large buffers also increases the latency to signal to the sender that the route is congested. The sender will spend more time sending packets that will ultimately just get dropped. If the latency was lower, the sender would have known sooner to reduce its rate. Latency and loss go hand-in-hand once you get into unnaturally large buffers. I'm not sure the exact recommend buffer size, but I think it's around 10ms of the bandwidth. Many people are seeing 1,000ms+, which is 2 orders magnitudes above optimal.

UBlock = inferior + inefficient vs. hosts

[Anonymous Coward]

UBlock can't do these as well as (or @ all) hosts do 4 speed, security, & reliability:

1.) Protect vs. bad sites (past ads)
2.) Protect vs. fastflux botnet C&C's
3.) Protect vs. dyndns botnet C&C's
4.) Protect vs. DGA botnet C&C's
5.) Protect vs. downed DNS (reliability)
6.) Protect vs. DNS poisoned dns
7.) Protect vs. trackers
8.) Protect vs. spam payloads
9.) Protect vs. phish payloads
10.) Protect vs. caps
11.) Get past dns blocks
12.) Keep off dns request logs
13.) Speed up 2 ways (adblocks/hardcodes)
14.) Work on anything webbound multiplatform.
15.) Ez data edit
16.) Block ads more efficiently in cpu/ram/I-O use
17.) UBlock now uses hosts (no DNS benefits vs. dns issues) - poor imitation = "sincerest form of flattery"

Hosts = native vs. illogically "Bolting on 'MoAr'" & not ClarityRay blockable like addons.

APK

P.S.=> Hosts (1st resolver) do MORE w/ less in fast kernelmode & before slow usermode addons

Hosts ~3mb vs. UBlock = 64MB -> http://cdn.ghacks.net/wp-conte...

Best ad & threat blocker bar-none

[Anonymous Coward]

APK Hosts File Engine 9.0++ SR-4 32/64-bit https://www.google.com/search?...

Ads rob speed, security (malvertising) & privacy (tracking).

Hosts add speed (hardcodes/adblocks), security (bad sites/poisoned dns), reliability (dns down), & anonymity (dns requestlogs/trackers) natively.

Works vs. caps & PUSH ads.

Avg. page = big as Doom http://www.theregister.co.uk/2... & ads = 40% of it.

Hosts != ClarityRay blockable (vs. souled-out to admen inferior wasteful redundant slow usermode addons)

Less power/cpu/ram + IO use vs. DNS/routers/addons/antivirus (slows you) + less security issues/complexity.

Compliments firewalls (blocking less used IP addys vs. hosts blocking more used domains) & DNS (lightens dns load).

Gets data via 10 security sites.

APK

P.S. - Safe https://www.virustotal.com/en/... (Verified by Malwarebytes' S. Burn "seen the code & it's safe" http://forum.hosts-file.net/vi... )

This makes it easy

[Anonymous Coward]

See subject & this link https://tech.slashdot.org/comments.pl?sid=10039961&cid=53557503/

APK

P.S.=> Hosts do FAR more (vs. far more threats) for FAR less using what you already natively have... apk

Re: This makes it easy

[Anonymous Coward]

And I can easily disable temporally disable/enable a domain (for like, a test)?

Re: Not magic

[adolf]

I have a spare Asus RT-N16.

Where do I get started with Cake?

Re:Best ad & threat blocker bar-none

[Anonymous Coward]

Your "seen the code & it's safe" link says "You are not allowed to access this resource" even with an account for hpHosts support forums.

HFSC to the rescue

[HighBit]

bufferbloat is definitely still a thing.

I've been using this script for years to drop packets early to improve latency. it uses HFSC (built into linux since forever) and works great:

https://gist.github.com/eqhmco...

from that:

Congestion avoidance algorithms (such as those found in TCP) do a great job of allowing network endpoints to negotiate transfer rates that maximize a link's bandwidth usage without unduly penalizing any particular stream. This allows bulk transfer streams to use the maximum available bandwidth without affecting the latency of non-bulk (e.g. interactive) streams.

In other words, TCP lets you have your cake and eat it too -- both fast downloads and low latency all at the same time.

However, this only works if TCP's afore-mentioned congestion avoidance algorithms actually kick in. The most reliable method of signaling congestion is to drop packets. (There are other ways, such as ECN, but unfortunately they're still not in wide use.)

Dropping packets to make the network work better is kinda counter-intuitive. But, that's how TCP works. And if you take advantage of that, you can make TCP work great.

Yes easily 1 of 2 ways... apk

[Anonymous Coward]

See subject: My program's tooltray icon rightclick popup menu lets you disable (or enable) hosts temporarily (or edit in/out entries in hosts).

APK

P.S.=> Nitpick away as an unidentifiable ac all you like - I've thought of your "objections" long ago & built them into the program... apk

Where's yours that's better? It's not

[Anonymous Coward]

See subject: That's all I have to say to "the trolling unidentifiable likes of you" as truth you're an unskilled "ne'er-do-well" that can't produce a better program for the same purpose yourself in GUI form, lol!

APK

P.S.=> I wonder HOW MANY TIMES I've handed you your ass beneath your "registered 'luser'" account on /. that you're trolling me by unidentifiable anonymous posts? apk

Untrue: I'm waiting on Delphi... apk

[Anonymous Coward]

See subject & this link (Linux 64-bit executables are coming in it VERY soon & it does all major others already) https://community.embarcadero.com/article/news/16418-product-roadmap-august-2016/ & it already does MacOS X + Android & "IoT" also.

* I could port it to Lazarus/FreePascal though - but I want the codebase to stay "EXACTLY" the same done in the same compiler (less risk that way) & ports to *NIX for this program are easy enough - some WinSock2 vs. *NIX sockets diffs (easy), drive letters vs. mounted devices (easy), & finding *NIX API analogs to some Win32/64 API calls (should be easy enough).

APK

P.S.=> I'm not in the habit of helping an inferior competitor though & yes, Linux is inferior in many levels (mainly availability of applications vs. Windows)... apk

Not my fault you can't figure it out

[Anonymous Coward]

See subject: Mr. Burn of Malwarebytes' hpHosts probably has proxies you're using to hide your true IP filtered off OR you are too dumb to figure out how to use a forums!

APK

P.S.=> It's already obvious you're too unskilled & stupid to create a better hosts managing program than mine in GUI form - all you know how to do is stalk/troll by unindentifiable anonymous posts (that I shoot down w/ facts easily)... apk

You're the one stalking/trolling by ac

[Anonymous Coward]

See subject: E.G. - hostsman - it doesn't do hardcoded favorites @ top of hosts for fastest local memory resolution & protection vs. DNS redirect poisoning + dns being down. It also doesn't have a native 64-bit model (mine does). It also has a dependency on OTHERS' work (SQLite) so if bugs turn up in those libs/dlls, he has a problem & has to wait out a fix - I don't. My codebase is self-contained in a single multithreaded GUI executable.

57++ antivirus programs haven't found a bugs - there isn't any!.

Malwarebytes' own verfied it's code as safe too.

Dozens use it here speaking highly of my program & many 1,000's use it worldwide.

BOTTOM-LINE: You don't have a leg to stand on (which is why you post unidentifiably STALKING MY POSTS imo).

Seems like you're SCARED of the fact I'm doing well here! I love it...

APK

P.S.=> Keep "nitpicking" as an unindentifiable anonymous - I'll keep shooting down your "so-called 'points'" easily as always, lol... apk

Re:You're the one stalking/trolling by ac

[IWantMoreSpamPlease]

You know, I'd love to use your program and do a comparison between it and a few other ones I use, but I do have a few questions.
Rather than clutter up this forum, drop me a line, let's talk, geek to geek

Ask here (I overcome objections directly)

[Anonymous Coward]

See subject: Says all - *NIX folks'll like Delphi for Linux64 (does other major platforms already) https://community.embarcadero.com/article/news/16418-product-roadmap-august-2016/

* I was "holding off" (could port it to FreePascal via Lazarus IDE - both almost exact 'clones' of Delphi) due to not admittedly helping 'the competition' & waiting for Delphi to become complete for ALL platforms (most all if NOT all amongst the "major" ones...) + wanting it to be from the SAME EXACT COMPILER (less risk of bugs etc.) - that's coming VERY soon & I just MAY build ports to MacOS X (already possible) + Linux (or, possibly, open source it).

QUESTION: How would I 'drop you a line' when you left no point of contact in your message (e.g. email)?

APK

P.S.=> I'd "OpenSORES" it but after seeing what happened to GOOGLE's Chrome w/ EFast? No thanks & NO WAY - that's NOT going to happen to me or my work... apk

Re:Ask here (I overcome objections directly)

[IWantMoreSpamPlease]

Link to my homepage has my e.mail address there.

Routers have 100's of security issues

[Anonymous Coward]

See subject & proof thereof here (only very partial, I can literally list MANY 100's more) https://it.slashdot.org/comments.pl?sid=9995967&cid=53488785/

APK

P.S.=> This populating hosts = best possible overall solution that's multiplatform & multidevice (hosts are everywhere & do FAR more for FAR less vs. more threats than ANY single other "so-called 'solution'") https://tech.slashdot.org/comments.pl?sid=10039961&cid=53557503/ via the BEST tool for hosts creation featured in the 2nd link I just posted... apk

No

[allquixotic]

I have an LTE Verizon Jetpack as my primary Internet connection, and the firmware is proprietary and not user-modifiable, and of course they refuse to implement bufferbloat mitigations on their own. So, no, it's not free from bufferbloat.

Just dedup'd 500++k records ~ 30 seconds

[Anonymous Coward]

See subject: That's pretty short & it uses a quicksort (best overall sort for large & small datasets).

APK

P.S.=> My character mode version does it under 17 seconds but folks don't use tools like that for decades now (most want GUI & gui has overheads that slow it but ACCURACY is perfect & more important vs. speed only)... apk

As I said, here (not in your private playpen)

[Anonymous Coward]

See subject & in the meantime? I'm "Turning Japanese" https://www.youtube.com/watch?v=IWWwM2wwMww/

* LOL!

(It's my life...)

APK

P.S.=> Merry X-mas & happy new year (my email's in my program - I get ~ 2 mails a month, makes sense - I documented the hell out of it & how to use it)... apk