[Bloat] netperf server news

[Colin Dearborn]

1): This hits what I'd expect my connection to be (or close enough anyway):
./betterspeedtest.sh
2020-10-06 12:53:54 Testing against netperf.bufferbloat.net (ipv4) with 5 simultaneous sessions while pinging gstatic.com (60 seconds in each direction)
.............................................................
 Download: 926.27 Mbps
  Latency: (in msec, 61 pings, 0.00% packet loss)
      Min: 23.200
    10pct: 25.500
   Median: 31.100
      Avg: 30.503
    90pct: 34.100
      Max: 38.800
...............................................................
   Upload: 103.50 Mbps
  Latency: (in msec, 63 pings, 0.00% packet loss)
      Min: 22.700
    10pct: 23.900
   Median: 28.600
      Avg: 30.233
    90pct: 33.400
      Max: 112.000

2) That sounds like plenty to me.


-----Original Message-----
From: Bloat <bloat-bounces at lists.bufferbloat.net> On Behalf Of Rich Brown
Sent: October 6, 2020 4:53 AM
To: bloat <bloat at lists.bufferbloat.net>
Cc: Richard E. Brown <richb.hanover at gmail.com>
Subject: [Bloat] netperf server news

  CAUTION: This email is from an external source. Do not click links or open attachments unless you recognize the sender and know the content is safe.

To the Bloat list,

I had some time, so I looked into what it might take to keep the netperf.bufferbloat.net server on-line in the face of an unwitting "DDoS" attack - automated scripts that run tests every 5 minutes 24x7. The problem was that these tests would blow through my 4TB/month bandwidth allocation in a few days.

In the past, I had been irregularly running a set of scripts to count incoming netperf connections and blacklist (in iptables) those whose counts were too high. This wasn't good enough: it wasn't keeping up with the tidal wave of connections.

Last week, I revised those scripts to work as a cron job. The current parameters are: run the script every hour; process the last two days' of kern.log files; look for > 500 connections; drop those addresses in iptables.

There are currently 479 addresses blacklisted in iptables (that explains why the bandwidth was being consumed so quickly). There are only a few new addresses being added per day, so it seems that we have flushed out most of the abusers.

My questions for this august group:

1) The server at netperf.bufferbloat.net is up and running. I get full rate speed from my 7mbps DSL circuit, but that's not much of a test. I would be interested to hear your results.

2) The current threshold comes from this estimate: most speed tests use 10 connections: 5 connections up and 5 down. So 500 connections would permit about 50 tests over the course of two days. Is that enough for "real research"? (If you need more, I can add your address to my whitelist file...)

3) I would be pleased to get comments on the set of scripts. I'm a newbie at iptables, so it wouldn't hurt to have someone else check the rules I devised. See the README at https://github.com/richb-hanover/netperfclean

Thanks.

Rich

_______________________________________________
Bloat mailing list
Bloat at lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat