[Flent-users] Re: [tohojo/flent] -6 Option ignored for hosts with IPv4 and IPv6 address (#241)

I never noticed this, actually. The standard net.Dial(), for "historical reasons", just prefers IPv4 instead of relying on the local resolver. This prompted a "Wow, okay" from B. Fitzpatrick. (https://github.com/golang/go/issues/20911). It looks like one can get around that by using the

[Flent-users] Re: [tohojo/flent] -6 Option ignored for hosts with IPv4 and IPv6 address (#241)

Fwiw I tried irtt with a similar setup, using hosts defined in /etc/hosts with both IPv4 and IPv6 addresses: 10.72.0.230 apu2a_6 a::601 apu2a_6 10.72.0.233 apu2c_6 a::603 apu2c_6 All of the following worked as expected: ``` sysadmin@apu2a:~$ irtt client -n apu2c_6

[Flent-users] Re: [tohojo/flent] runners: Bracket IPv6 addresses before passing to irtt (#239)

> LGTM, but could you please squash the changes into a single commit? :) Squashed and force pushed, so hopefully that's fine. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub:

[Flent-users] Re: [tohojo/flent] runners: Bracket IPv6 addresses before passing to irtt (#239)

@heistp commented on this pull request. > @@ -1682,7 +1683,13 @@ def check(self): if self.ip_version is not None: args.append("-{}".format(self.ip_version)) -args.append(self.host) +try: +ipaddress.IPv6Address(self.host) +

[Flent-users] Re: [tohojo/flent] runners: Bracket IPv6 addresses before passing to irtt (#239)

@heistp commented on this pull request. > @@ -1682,7 +1683,13 @@ def check(self): if self.ip_version is not None: args.append("-{}".format(self.ip_version)) -args.append(self.host) +try: +ipaddress.IPv6Address(self.host) +

[Flent-users] Re: [tohojo/flent] runners: Bracket IPv6 addresses before passing to irtt (#239)

@heistp pushed 1 commit. 7d7a6ac0c5aeef4206d6d43afe735d92adeb18bc util: Add optional bracket_v6 parameter to normalise_host -- You are receiving this because you are subscribed to this thread. View it on GitHub:

[Flent-users] Re: [tohojo/flent] irtt fails with IPv6 (wrong format) (#238)

The proposed fix is in pull request #239. I tested an rrul test briefly and successfully passed in a link local IPv6 address containing a scope (%dev), so that should work at least as far as irtt is concerned. -- You are receiving this because you are subscribed to this thread. Reply to this

[Flent-users] Re: [tohojo/flent] irtt fails with IPv6 (wrong format) (#238)

Hi, I guess that creates a bit of a hassle on the flent side as it needs to know the address type in order to surround it with brackets. It comes from Go's requirement for brackets around IPv6 address literals in net.Dial(). I added an issue for irtt, but I don't know if/when that will ever get

Re: [Flent-users] [tohojo/flent] specifying bounds for subplots (#206)

That makes sense to me, and should be supported in the gui with no changes? So far this isn't urgent for me now so I probably won't get to it soon, so either you can do it if you have time and it's easy, or else I'll come back to it when needed later. :) -- You are receiving this because you

Re: [Flent-users] [tohojo/flent] Add TCP delivery rate plots to rrul_be (#205)

Ok, let's see if I finally got it right. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/tohojo/flent/pull/205#issuecomment-626746340___ Flent-users mailing list

Re: [Flent-users] [tohojo/flent] Add TCP delivery rate plots to rrul_be (#205)

So that's there. Might have just needed an rrul_be test with socket stats, not sure. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub:

Re: [Flent-users] [tohojo/flent] Add TCP delivery rate plots to rrul_be (#205)

@heistp pushed 1 commit. 637b14c0bea66d7e3c9e3a326f2b166c7738ad33 Add all_scaled_delivery to PLOTS_MAY_FAIL and a sample data file. -- You are receiving this because you are subscribed to this thread. View it on GitHub:

[Flent-users] [tohojo/flent] specifying bounds for subplots (#206)

In a plot that has subplots, like all_scaled, it appears that --bounds-y can only be specified once, and it applies to all of the subplots for the plot. Is there a way to specify bounds separately for each subplot? -- You are receiving this because you are subscribed to this thread. Reply to

Re: [Flent-users] [tohojo/flent] Add TCP delivery rate plots to rrul_be (#205)

@heistp pushed 1 commit. ebf8aa72bc1edd8e69663afebee96e98f3462878 Update delivery rate title for all_scaled_delivery. -- You are receiving this because you are subscribed to this thread. View it on GitHub:

[Flent-users] [tohojo/flent] Add TCP delivery rate plots to rrul_be (#205)

Hi, just adding a few plots were using with rrul_be... Signed-off-by: Pete Heist p...@heistp.net You can view, comment on, or merge this pull request online at: https://github.com/tohojo/flent/pull/205 -- Commit Summary -- * Add TCP delivery rate plots (tcp_delivery_rate

Re: [Flent-users] [tohojo/flent] marking parameter not working for tcp_1up test (#201)

Thanks! Works for me, only I got a little confused because 'tcp_cong_control' stopped working and is replaced by 'cc_algo'. It's no problem for me as I can adjust and it's more consistent now, just that people's existing batches may behave differently... -- You are receiving this because you

[Flent-users] [tohojo/flent] marking parameter not working for tcp_1up test (#201)

I can set 'markings' for tcp_nup, but it seems that setting 'marking' on a tcp_1up test is not working. Any chance you could take a look or point me where to fix this? -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub:

Re: [Flent-users] [tohojo/flent] tests: Add tcp_delivery_with_rtt and upload_box plots. (#200)

Should be fixed. I admit that I haven't actually tested with a cutoff, but the plot works... -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub:

Re: [Flent-users] [tohojo/flent] tests: Add tcp_delivery_with_rtt and upload_box plots. (#200)

@heistp pushed 1 commit. f736e627d6a6019aca6253d83221d6fb5d0b0d0e tests: Add cutoff for upload_box plot. -- You are receiving this because you are subscribed to this thread. View it on GitHub:

[Flent-users] [tohojo/flent] tests: Add tcp_delivery_with_rtt and upload_box plots. (#200)

Signed-off-by: Pete Heist p...@heistp.net You can view, comment on, or merge this pull request online at: https://github.com/tohojo/flent/pull/200 -- Commit Summary -- * tests: Add tcp_delivery_with_rtt and upload_box plots. -- File Changes -- M flent/tests/tcp_1up.conf (15) M

Re: [Flent-users] [tohojo/flent] box plots missing boxes (#198)

So as it turns out, it would still be useful in this case to be able to plot the box plots for each flow in a tcp_nup test. Is there a way to do that? -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub:

Re: [Flent-users] [tohojo/flent] box plots missing boxes (#198)

Closed #198. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/tohojo/flent/issues/198#event-3042804193___ Flent-users mailing list Flent-users@flent.org

Re: [Flent-users] [tohojo/flent] box plots missing boxes (#198)

Ah, I understand now that that the boxes would appear when there are multiple repetitions in the batch run. I thought they might show the variances in data for each flow. While that could be useful, it looks like I can get what I actually need at the moment by adding other open data files in

[Flent-users] [tohojo/flent] box plots missing boxes (#198)

In flent from head (1.9.9-git-3d663cf) I seem to be missing the boxes on box plots, like the attached image. I'm mostly doing tcp_nup and tcp_1up. It's the same on Linux and MacOS. I'll send a .flent.gz in case that helps. ![Screen Shot 2020-02-16 at 11 27 22

Re: [Flent-users] [tohojo/flent] Adding netperf send size params (-m/-M) (#195)

Sent a pull request but only for setting it globally for TCP so far, as setting it per-flow and for the UDP packet size was more than I bargained for. :) The reason I'm probably seeing this more than most people is because I have non-default settings for `net.ipv4.tcp_wmem` for doing tests on

[Flent-users] [tohojo/flent] runners: Add --send-size flag for netperf send size (-m/-M) (#196)

This is only a start on what we discussed, as its over my head at the moment how to make this setting per-flow and have it affect the UDP packet size. Sorry if short on time at the moment to dig into it further. :) Signed-off-by: Pete Heist p...@heistp.net You can view, comment on, or merge

Re: [Flent-users] [tohojo/flent] Adding netperf send size params (-m/-M) (#195)

Ah ok, so we could combine them for now and there can always be separate flags later if needed, plus that's good if the UDP one can be overridden with the test param. Will see if I can make this change... -- You are receiving this because you are subscribed to this thread. Reply to this email

Re: [Flent-users] [tohojo/flent] Adding netperf send size params (-m/-M) (#195)

Ok, it sounds good allowing the comma separated values for setting it per-flow, but I'm not sure about sharing it with the UDP setting. People usually specify a UDP packet size that's something below the MTU right? That would cause pretty high CPU on the stream test. I expect when people are

[Flent-users] [tohojo/flent] Adding netperf send size params (-m/-M) (#195)

Sometimes it can happen that you see periodic dips in throughput plots, like this:  The period of the dips can be short, depending on test conditions / parameters:

Re: [Flent-users] [tohojo/flent] Stable output filenames for batch runs (#179)

Closed #179. -- You are receiving this because you commented. Reply to this email directly or view it on GitHub: https://github.com/tohojo/flent/issues/179#event-2617445990___ Flent-users mailing list Flent-users@flent.org

Re: [Flent-users] [tohojo/flent] Stable output filenames for batch runs (#179)

Added in 2d0d8fbd844b2f2153f098e157294983e3432dc7, thanks for accepting. -- You are receiving this because you commented. Reply to this email directly or view it on GitHub: https://github.com/tohojo/flent/issues/179#issuecomment-529311035___

[Flent-users] [tohojo/flent] batch: Add --batch-no-timestamp command line argument (#180)

Re-arranged gen_filename a bit now that some parts of the filename are optional. Signed-off-by: Pete Heist p...@heistp.net You can view, comment on, or merge this pull request online at: https://github.com/tohojo/flent/pull/180 -- Commit Summary -- * batch: Add --batch-no-timestamp command

[Flent-users] [tohojo/flent] Stable output filenames for batch runs (#179)

Currently, the output filenames for batches always include `batch_time`: ``` def gen_filename(self, settings, batch, argset, rep): filename = "batch-%s-%s-%s" % ( settings.BATCH_NAME, batch['batch_time'], batch.get('filename_extra', "%s-%s" %

[Flent-users] [tohojo/flent] Add totals_with_tcp_rtt and upload_with_ping_and_tcp_rtt plots. (#176)

Adding two plots that Im frequently using. Signed-off-by: Pete Heist p...@heistp.net You can view, comment on, or merge this pull request online at: https://github.com/tohojo/flent/pull/176 -- Commit Summary -- * Add totals_with_tcp_rtt and upload_with_ping_and_tcp_rtt plots. -- File

Re: [Flent-users] [tohojo/flent] Add multiple inheritance support for batch files. (#175)

No other reason for the order except it felt natural to me that what comes later overrides what comes earlier. It's about like which way do you like your mouse wheel to scroll ("finger on the paper" is correct, obviously :). I'm totally fine with taking out the `reversed` call for priority

[Flent-users] [tohojo/flent] Add multiple inheritance support for batch files. (#175)

. :) Signed-off-by: Pete Heist p...@heistp.net You can view, comment on, or merge this pull request online at: https://github.com/tohojo/flent/pull/175 -- Commit Summary -- * Add multiple inheritance support for batch files. -- File Changes -- M flent/batch.py (11) -- Patch Links -- https

[Flent-users] [tohojo/flent] metadata: Add pacing sysctls (ca_ratio and ss_ratio) (#174)

You can view, comment on, or merge this pull request online at: https://github.com/tohojo/flent/pull/174 -- Commit Summary -- * metadata: Add pacing sysctls (ca_ratio and ss_ratio) -- File Changes -- M flent/metadata.py (2) -- Patch Links --

[Flent-users] [tohojo/flent] Fix pacing and delivery rate calculations and add plot for tcp_nup (#168)

Jon and I noticed this with pacing and delivery rate, and this plot might be useful for others as well. :) You can view, comment on, or merge this pull request online at: https://github.com/tohojo/flent/pull/168 -- Commit Summary -- * Fix calculation of pacing and delivery rate. * Add

Re: [Flent-users] [tohojo/flent] Unable to use flent-gui from 83d14d68 (#167)

``` export QT_API=pyside2 ``` A space had crept in my previous post after the equals. :) -- You are receiving this because you commented. Reply to this email directly or view it on GitHub:

Re: [Flent-users] [tohojo/flent] Unable to use flent-gui from 83d14d68 (#167)

It looks like it was still using PyQt5 in your case, so make sure to first do: ``` export QT_API= pyside2 ``` If this is a long-term fix for Mac, maybe that var could be set on MacOS when sys.platform is darwin, assuming we have a chance to do so before those libs are initialized. Probably

Re: [Flent-users] [tohojo/flent] Unable to use flent-gui from 83d14d68 (#167)

Ah, ok, well it looks like PySide2 has a more permissive license anyway, although I guess that shouldn't affect flent. I haven't noticed any other problems using it, although my testing has hardly been extensive. -- You are receiving this because you commented. Reply to this email directly or

Re: [Flent-users] [tohojo/flent] Unable to use flent-gui from 83d14d68 (#167)

Ok, the problem doesn't happen with PySide2. It's likely with recent versions of PyQt5, although I'm not exactly sure of the first version where it started. It's also possible the bug doesn't happen on MacOS 10.14 (Mojave), but my 2011 hardware is pinned to 10.13 so I can't test that. So far

Re: [Flent-users] [tohojo/flent] Unable to use flent-gui from 83d14d68 (#167)

Yes, it does, then the symptom after the error (same with one or more files) is that Python is unresponsive and there's 100% CPU usage. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub:

Re: [Flent-users] [tohojo/flent] Unable to use flent-gui from 83d14d68 (#167)

Against better judgment I upgraded PyQt5 to 5.13.0 on both the Mac and Linux and still see the problem on Mac but not on Linux, so that suggests it's not directly related to the PyQt 5 version. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or

Re: [Flent-users] [tohojo/flent] Unable to use flent-gui from 83d14d68 (#167)

Hmm, that made me realize it's working in Linux but not on my Mac, with slightly different versions of Python and PyQt5: Not working (on MacOS 10.13.6): ``` % flent --version Flent v1.9.9-git-83d14d6. Running on Python 3.7.4 (default, Jul 9 2019, 18:15:00) [Clang 10.0.0 (clang-1000.11.45.5)].

[Flent-users] [tohojo/flent] Unable to use flent-gui from 83d14d68 (#167)

I compiled on some new test boxes from head (83d14d68) and ran a test. flent -i for the text output worked but when I use flent -gui I see the following errors before it freezes: ``` ERROR: Error while loading data file: ' returned a result with an error set'. Skipping. ERROR: Error while

[Flent-users] [tohojo/flent] flent -i summary text not working (#166)

On flent from head I'm not able to generate summary text for a tcp_2up test: ``` % flent -i *.flent.gz Started Flent 1.2.2-git-325dad7 using Python 3.7.3. Summary of tcp_2up test run from 2019-07-08 19:53:28.768995 Title: 'sce cc:reno,reno-sce q:triple-isolate bw:50Mbit rtt:80ms crtt:100ms'

Re: [Flent-users] [tohojo/flent] unable to start flent-gui (#165)

Super, works for me.  -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/tohojo/flent/issues/165#issuecomment-508557242___ Flent-users mailing list

Re: [Flent-users] [tohojo/flent] tcp_rtt plots not working? (#163)

Yes, that's the case, so it's working now with the kernel compiled with CONFIG_INET_DIAG and as root. Closing this, unless you want me to test anything else... -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub:

Re: [Flent-users] [tohojo/flent] tcp_rtt plots not working? (#163)

Ok, there is a difference there (below, sudo version contains pid at end of ESTAB line). Running flent with sudo works even though I didn't used to need to do that on older Ubuntus. It's a fine workaround for now, only in addition, ss with my custom kernel doesn't show TCP RTT or a lot of

[Flent-users] [tohojo/flent] tcp_rtt plots not working? (#163)

I have ss installed and am using --socket-stats, but for some reason tcp_rtt plots don't seem to be working (using rrul_be but I need it ultimately for tcp_1up_noping). I'm using flent from HEAD and python 3.7.3 on Ubuntu 19.04. Do the attached .flent.gz files and output from --verbose show

Re: [Flent-users] irtt on flent-london

> On Jan 11, 2019, at 5:31 PM, Pete Heist wrote: > >> On Jan 11, 2019, at 5:00 PM, Dave Taht wrote: >> >> I just turned it on again (I think it had crashed). I actually never noticed that it went on, and it isn’t on now. Is it really

[Flent-users] [tohojo/flent] tcp_rtt_bar_combine plot with rrul_be wrong number of columns (#158)

When I make a tcp_rtt_box_combine plot of ten data sets, it looks like this:  but what I make a tcp_rtt_bar_combine, it looks like this:

Re: [Flent-users] [tohojo/flent] testing the behavior of small queue building non-ecn'd flows (#148)

Ah, I see TSDE is Pollere's work. I need to go through the talks referenced on pollere.net asap to get smarter on that. Will be on some roofs today though, p2p connection for the neighbors... -- You are receiving this because you commented. Reply to this email directly or view it on GitHub:

Re: [Flent-users] [tohojo/flent] testing the behavior of small queue building non-ecn'd flows (#148)

As for packet loss and reorders, there's the `lost` property on each `round_trip` that could be plotted, but for re-orders there's so far just a global `late_packets`, which is the number of packets who sequence number is lower than the previous one received. It would be possible to add a

Re: [Flent-users] [tohojo/flent] testing the behavior of small queue building non-ecn'd flows (#148)

Ok, well if we do go for it, so far in irtt's JSON there's just an average `send_rate` and `receive_rate` under stats, both of which contain an integer `bps` and a `string` text representation. `send_rate` ignores lost packets and `receive_rate` takes them into account. Let me know if anything

Re: [Flent-users] [tohojo/flent] testing the behavior of small queue building non-ecn'd flows (#148)

> On Aug 27, 2018, at 1:40 PM, flent-users wrote: > > Hi Pete, > > > On Aug 25, 2018, at 19:53, Pete Heist wrote: > > > > 50ms wouldn't be too disruptive in most cases. At 1 Mbit, the 5% of > > bandwidth threshold is crossed. > > Would it be possi

Re: [Flent-users] [tohojo/flent] testing the behavior of small queue building non-ecn'd flows (#148)

Yeah, I haven't thought about what it would mean to change the semantics of the existing tests by changing the default interval. Although, as it is, there's still a fallback to UDP_RR for current tests, so results can change if irtt isn't installed or the server isn't reachable for some reason.

Re: [Flent-users] a nice endorsement

> On Aug 25, 2018, at 5:43 PM, Dave Taht wrote: > > " Flent has been an invaluable network analysis tool while performing > these experiments and has become my goto application for testing > networking performance after making changes/optimizations/tweaks etc. > > from -

Re: [Flent-users] [tohojo/flent] testing the behavior of small queue building non-ecn'd flows (#148)

Is there an argument for lowering the default interval for when flent calls irtt? The default irtt packet length with no payload is 60 bytes, so here are bitrates at various intervals for IPv4+Ethernet (106 byte frames, and tripled for RRUL's three UDP flows): ``` 200ms => 4.2 Kbit * 3 = 12.7

Re: [Flent-users] total throughput for rrul test on WiFi

> On Jun 26, 2018, at 12:43 PM, Toke Høiland-Jørgensen wrote: > > There's a limit to the maximum aggregation size on VO and VI (for VO it > is '1 packet' as Sebastian noted). Minstrel will take this into account > when building the aggregate, but IIRC only for the first entry in the > retry

Re: [Flent-users] total throughput for rrul test on WiFi

> On Jun 26, 2018, at 10:40 AM, Sebastian Moeller wrote: > > Hi Pete, > >> On Jun 26, 2018, at 00:40, Pete Heist wrote: >> >> The rrul test over a point-to-point WiFi link cuts the total TCP throughput >> considerably below that of rrul_be. For example,

[Flent-users] total throughput for rrul test on WiFi

The rrul test over a point-to-point WiFi link cuts the total TCP throughput considerably below that of rrul_be. For example, on an 802.11n 20MHz MCS 15 link: rrul_be: ~90mbit rrul: ~30-45mbit I think this came up before, but could the standard rrul test be exceeding the 802.11e spec in terms

[Flent-users] VoIP rrul/be test

Currently the voip-rrul test is actually an rrul_be + voip test, but it could be useful to sometimes do a voip-rrul test that’s rrul (not best-effort only) + voip. Would it make sense to make the current voip-rrul use the rrul test instead, and to add a voip-rrulbe test for the best-effort

Re: [Flent-users] Mailing lists delisted from mailman overview

> On Jun 10, 2018, at 5:32 PM, Toke Høiland-Jørgensen wrote: > >> I had good luck with reCAPTCHA solving spam for one simple form. Every >> time I click “I am not a robot" I fear it’s somehow snapshotting my >> soul, but that’s another thing… :) > > Well as someone that runs uMatrix and

Re: [Flent-users] Mailing lists delisted from mailman overview

> On Jun 10, 2018, at 4:37 PM, Toke Høiland-Jørgensen wrote: > >> Anyway…I don’t know mailman from the admin side, but what about trying >> to configure reCAPTCHA support? It looks like they added it to mailman >> 2.1.26 (setup instructions in release notes): > > Ah, that might be an option;

Re: [Flent-users] Mailing lists delisted from mailman overview

> On Jun 10, 2018, at 3:42 PM, Toke Høiland-Jørgensen wrote: > > Just a note that I have been forced to delist the Flent mailing lists > from the public mailman listing page. Apparently spammers have started > using unsolicited mailman confirmation requests as a way to spam people; > so I had

Re: [Flent-users] irtt packet-cluster mode for estimating queueing delay

> On May 6, 2018, at 9:17 PM, Sebastian Moeller wrote: > > you could also try different packet sizes for you probes. The size ratio > should give you an idea about the RTT difference explained by simple transit > times and anything on top of that might be related to queueing.

Re: [Flent-users] irtt packet-cluster mode for estimating queueing delay

> On May 6, 2018, at 10:51 PM, Pete Heist <p...@eventide.io> wrote: >> >> Ah, so this is a wired connection? And you are only targeting a >> particular setup? > > The backhaul is a mixture of wired and wireless links, each with an ALIX or > APU router.

Re: [Flent-users] irtt packet-cluster mode for estimating queueing delay

> On May 6, 2018, at 9:27 PM, Toke Høiland-Jørgensen wrote: >> >> The backhaul I’d like to test it on uses mostly NSM5s as the wireless >> devices and APUs for routing, QoS, etc. The QoS scripts use the htb, >> sfq and prio qdiscs. I’m hoping I can just add a prio qdisc / tc >>

Re: [Flent-users] irtt packet-cluster mode for estimating queueing delay

> On May 6, 2018, at 5:54 PM, Toke Høiland-Jørgensen <t...@toke.dk> wrote: > > Pete Heist <p...@eventide.io> writes: > >> Channel contention delay may be estimated by the difference between >> the round-trip times for the strict priority VO and BE packets (0

Re: [Flent-users] DSCP / ToS

> On Feb 19, 2018, at 11:36 AM, Toke Høiland-Jørgensen <t...@toke.dk> wrote: > > Pete Heist <petehe...@gmail.com> writes: > >> I liked the simplicity of RFC 795 (https://tools.ietf.org/html/rfc795) from >> 1981 :) so, mostly in jest, I’ll propose a new syste

Re: [Flent-users] DSCP / ToS

> On Feb 18, 2018, at 9:03 PM, Sebastian Moeller wrote: > > Really, I am always confused by this especially since I aways forget > whether network order is big or little endian (looked it up again it is > big-endian). Here I got nailed by assuming that ECN being in

Re: [Flent-users] SmokePing probe

> On Feb 18, 2018, at 7:11 PM, Toke Høiland-Jørgensen <t...@toke.dk> wrote: > > Pete Heist <petehe...@gmail.com> writes: > >> The author pulled the probe in pretty quickly, so it’s already upstream. >> Some samples: >> >> https://www.drh

Re: [Flent-users] SmokePing probe

<https://www.drhleny.cz/bufferbloat/smokeping/irtt_smokeping2.png> Maybe I’ll post another image after a while if something more exciting happens… :) > On Feb 18, 2018, at 12:29 AM, Pete Heist <petehe...@gmail.com> wrote: > > I wrote a SmokePing (https://oss.oetiker.ch/smokeping/

Re: [Flent-users] weir error message after update of macosx and flent

> On Feb 18, 2018, at 10:55 AM, Sebastian Moeller wrote: > > Not that I have looked at the actual parameter names, but how about having > --dscp mask out the upper two bits (if they are set) and --tos allowing to > set the full legacy 8 bit? I think that’s the right thing to

Re: [Flent-users] weir error message after update of macosx and flent

> On Feb 18, 2018, at 10:38 AM, Toke Høiland-Jørgensen wrote: > > Yes, that would probably be a good idea; and also agreement on the values > would be a good idea ;) the current mapping I put in is taken from netperf, > which in turn cites an RFC. But it's different from the

Re: [Flent-users] weir error message after update of macosx and flent

> On Feb 17, 2018, at 11:21 PM, Toke Høiland-Jørgensen wrote: > > Sebastian Moeller writes: > >> Hi Toke, >> >> I made the mistake of updating both my os (from macos 10.12.6 to >> 10.13.3) and flent (to 1.2 I believe) at the same time. Now when I try >> to

[Flent-users] SmokePing probe

I wrote a SmokePing (https://oss.oetiker.ch/smokeping/) probe for IRTT: Code: https://github.com/peteheist/SmokePing/blob/master/lib/Smokeping/probes/IRTT.pm Pull request: https://github.com/oetiker/SmokePing/pull/110 I hope to use this in my ISP, which uses SmokePing for about 70 access

Re: [Flent-users] IRTT question

> On Feb 9, 2018, at 11:36 AM, Toke Høiland-Jørgensen wrote: > > Sebastian Moeller writes: > >> Hi Toke, >> >> Ah, great, this got me a bit further: >> >> UDP RTT test: Cannot use irtt runner (Irtt connection check failed: >> [InvalidServerRestriction] server

Re: [Flent-users] IRTT question

> > On Feb 8, 2018, at 8:53 PM, Sebastian Moeller <moell...@gmx.de> wrote: > > Hi Pete, >> On Feb 8, 2018, at 20:49, Pete Heist <petehe...@gmail.com> wrote: >> >> It should work, but the irtt server needs to be running. On your box where >> n

Re: [Flent-users] IRTT question

It should work, but the irtt server needs to be running. On your box where netserver is running (sounds like the Mac for you if you’re testing locally), run “irtt server”. On Linux you can use the irtt.service file in the repo with systemd to run it at startup. I’m working on a Debian package

Re: [Flent-users] anyone for quic?

> On Jan 30, 2018, at 9:17 AM, Dave Taht wrote: > > https://github.com/lucas-clemente/quic-go Cool, in case it ends up in flent one day I’d like to add that to the “flenter” tests. Two things I noticed: - It’s possible to use BBR with QUIC (not implemented in quic-go

Re: [Flent-users] [tohojo/flent] Use = with all long form flags with values. (#125)

Cool, hope that works... -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/tohojo/flent/pull/125#issuecomment-351200608___ Flent-users mailing list

[Flent-users] [tohojo/flent] Use = with all long form flags with values. (#125)

For some reason, the Go pflag packages (both of them) require long form flags with values to have equals signs. This works for me, but I'm not sure of and didn't test the local_bind stuff in particular, so by all means fix or replace any of it if there's a better way. :) You can view, comment

[Flent-users] irtt test

If anyone would like to try a semi-public irtt server for testing, I’ll leave it up for a bit: irtt client -hmac flentusers irtt.eventide.io irtt can be had here, where you can also report any problems: https://github.com/peteheist/irtt The server is configured with the hmac key above, and

Re: [Flent-users] [tohojo/flent] occasional WARNING: Unable to get packet timestamp and seqno (#124)

Yep, that fixed it (three runs an no warning), thanks! -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/tohojo/flent/issues/124#issuecomment-346933882___

Re: [Flent-users] [tohojo/flent] occasional WARNING: Unable to get packet timestamp and seqno (#124)

By the way, in case you'd want undocumented flags for both client and server for dropping or duplicating some percentage of packets I can add that. I currently have compiled in constants for those. -- You are receiving this because you are subscribed to this thread. Reply to this email

[Flent-users] [tohojo/flent] occasional WARNING: Unable to get packet timestamp and seqno (#124)

I'm filing this here for the moment but we can move it to irtt if it turns out to be something for me. The warning says: Unable to get packet timestamp and seqno: u'wall' The seqno does some to be there though. It seems to happen when `lost` is `true_down`, which would mean there aren't any

Re: [Flent-users] [tohojo/flent] irtt not used for rrul_be_nflows (#123)

Closed #123. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/tohojo/flent/issues/123#event-1357443251___ Flent-users mailing list Flent-users@flent.org

Re: [Flent-users] [tohojo/flent] irtt not used for rrul_be_nflows (#123)

Duh, I didn't have an up to date irtt in my test bed. `-v` was helpful, thanks. Maybe I need to set up my test bed to update irtt on commit. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub:

[Flent-users] [tohojo/flent] irtt not used for rrul_be_nflows (#123)

Actually not sure if this should work yet or not, but rrul_be_nflows is one of the more common tests I do and it still uses UDP_RR... -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub:

Re: [Flent-users] [tohojo/flent] packet loss stats (#106)

Oh yeah, probably time for this issue thread to retire. :) So I'm glad! Looking forward to playing with this more soon. Thanks for all that refactoring too, looks like it was some real walking through walls... -- You are receiving this because you commented. Reply to this email directly or

Re: [Flent-users] [tohojo/flent] packet loss stats (#106)

> On Nov 22, 2017, at 8:49 AM, Toke Høiland-Jørgensen > <notificati...@github.com> wrote: > > Pete Heist <notificati...@github.com> writes: > > >> > And this likely takes the mean value of all transactions and > >> > summarizes it at t

Re: [Flent-users] [tohojo/flent] packet loss stats (#106)

> On Nov 21, 2017, at 10:56 PM, Toke Høiland-Jørgensen > <notificati...@github.com> wrote: > > Pete Heist <notificati...@github.com> writes: > > > Trying to confirm how latency was being calculated before with the > > UDP_RR test. Looking at its

Re: [Flent-users] [tohojo/flent] packet loss stats (#106)

Trying to confirm how latency was being calculated before with the UDP_RR test. Looking at its raw output, I see that transactions per second is probably used to calculate RTT, with interim results like: ``` NETPERF_INTERIM_RESULT[0]=3033.41 NETPERF_UNITS[0]=Trans/s NETPERF_INTERVAL[0]=0.200

Re: [Flent-users] [tohojo/flent] packet loss stats (#106)

> On Nov 21, 2017, at 3:53 PM, Toke Høiland-Jørgensen > wrote: > > > Next thing I noticed as for current tests, for rrul_be_nflows, the > > test completed but only one irtt instance ran (also just saw one > > connection to the server). > > > > % flent rrul_be_nflows

Re: [Flent-users] [tohojo/flent] packet loss stats (#106)

> On Nov 21, 2017, at 11:36 AM, Toke Høiland-Jørgensen > wrote: > > Ha! Epic fail! :D > > Well, I only just managed to finish writing the code and unbreaking the > CI tests; didn't actually get around to running any tests. I've fixed > those two errors, and am

Re: [Flent-users] [tohojo/flent] packet loss stats (#106)

> On Nov 20, 2017, at 10:14 PM, flent-users wrote: > > Winstein plot of latency variance? It doesn't get denser, it gets darker. > > Packet loss vs throughput? Not sure what that is exactly. Something like from July 2014 on this page?

Re: [Flent-users] [tohojo/flent] packet loss stats (#106)

> On Nov 20, 2017, at 9:58 PM, Toke Høiland-Jørgensen > wrote: > Okay, testable code in the runner-refactor branch. > > Ended up doing a fairly involved refactoring of how runners work with > data; which is good, as the new way to structure things makes a lot more >

  1   2   >