[Flent-users] [tohojo/flent] https_getter would be nice (#231)

[Dave Täht]

measuring time to connect, time to ssl, time to first b yte

-- 
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/231___
Flent-users mailing list -- flent-users@flent.org
To unsubscribe send an email to flent-users-le...@flent.org

[Flent-users] [tohojo/flent] udp_rtt in more tests (#230)

[Dave Täht]

Since ping is being spoofed by starlink, a udp ping test in combination with 
tcp_nup/tcp_ndown or appears needed.

also I am loving sampling things at a 3ms interval in irtt general.

I think a new generation of tests is needed. rrulv2 ?

I am thinking nup and ndown would be good names for something that leveraged 
irtt, but I am not sure how using a much smaller interval than socket-stats for 
irtt could work.

-- 
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/230___
Flent-users mailing list -- flent-users@flent.org
To unsubscribe send an email to flent-users-le...@flent.org

[Flent-users] Re: [tohojo/flent] udp_rtt in more tests (#230)

[Dave Täht]

and/or call it udp-owd so as to plot both directions

-- 
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/230#issuecomment-869200383___
Flent-users mailing list -- flent-users@flent.org
To unsubscribe send an email to flent-users-le...@flent.org

[Flent-users] Re: [tohojo/flent] Plots are broken somehow (#227)

[Dave Täht]

can you email me, I have something in the works you are going to *love* (davet 
AT teklibre.net)

-- 
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/227#issuecomment-867783987___
Flent-users mailing list -- flent-users@flent.org
To unsubscribe send an email to flent-users-le...@flent.org

[Flent-users] Re: [tohojo/flent] Plots are broken somehow (#227)

[Dave Täht]

It looks like we lost the g+ thread but basically we suppressed channel scans 
if the existing rssi was < 80 or so.

-- 
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/227#issuecomment-867651681___
Flent-users mailing list -- flent-users@flent.org
To unsubscribe send an email to flent-users-le...@flent.org

[Flent-users] Re: [tohojo/flent] Plots are broken somehow (#227)

[Dave Täht]

also try adding net.ipv4.tcp_ecn=1 to sysctl

-- 
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/227#issuecomment-867650898___
Flent-users mailing list -- flent-users@flent.org
To unsubscribe send an email to flent-users-le...@flent.org

[Flent-users] Re: [tohojo/flent] Plots are broken somehow (#227)

[Dave Täht]

thx very much for absorbing my (our) work.

what's the wifi chipset in this device? (can I get one?) did you implement 
https://www.usenix.org/conference/atc17/technical-sessions/presentation/hoilan-jorgesen

yes, I had written about the impact of channel scans before over here: 
http://blog.cerowrt.org/post/disabling_channel_scans/

-- 
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/227#issuecomment-867648924___
Flent-users mailing list -- flent-users@flent.org
To unsubscribe send an email to flent-users-le...@flent.org

[Flent-users] Re: [tohojo/flent] Plots are broken somehow (#227)

[Dave Täht]

What is causing the 3000ms spikes in your test???

-- 
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/227#issuecomment-865436922___
Flent-users mailing list -- flent-users@flent.org
To unsubscribe send an email to flent-users-le...@flent.org

[Flent-users] Re: [tohojo/flent] seeing the max, rather than the average, on rrul is less distracting (#225)

[Dave Täht]

yes

-- 
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/225#issuecomment-863491515___
Flent-users mailing list -- flent-users@flent.org
To unsubscribe send an email to flent-users-le...@flent.org

[Flent-users] Re: [tohojo/flent] seeing the max, rather than the average, on rrul is less distracting (#225)

[Dave Täht]

In other talks about voip, I've talked about this as "riding the sawtooth"

-- 
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/225#issuecomment-855291055___
Flent-users mailing list -- flent-users@flent.org
To unsubscribe send an email to flent-users-le...@flent.org

[Flent-users] Re: [tohojo/flent] seeing the max, rather than the average, on rrul is less distracting (#225)

[Dave Täht]

![rrul_-_evenroute_v3_server_fq_codel](https://user-images.githubusercontent.com/108682/120904374-e0474980-c600-11eb-9660-88cc566a15b9.png)
![rrul_-_evenroute_v3_server_fq](https://user-images.githubusercontent.com/108682/120904376-e2110d00-c600-11eb-8492-a2c9852bf138.png)


-- 
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/225#issuecomment-855290856___
Flent-users mailing list -- flent-users@flent.org
To unsubscribe send an email to flent-users-le...@flent.org

[Flent-users] [tohojo/flent] seeing the max, rather than the average, on rrul is less distracting (#225)

[Dave Täht]

Naive readers of a rrul plot tend to look at the average, when, especially when 
you are trying to describe the difference between a good plot of latency and 
jitter 

[a good sch_fq plot of latency and 
jitter](http://dallas.starlink.taht.net/virtio_nobql/rrul_-_evenroute_v3_server_fq.png)

and

[The Terrifying FQ_CODEL BQL 
BUG](http://dallas.starlink.taht.net/virtio_nobql/rrul_-_evenroute_v3_server_fq_codel.png)

To a manager type that wants to pull you off onto doing some irrelevant study 
of something of far less import to the correct behavior of 10s of millions of 
machines and of the internet itself and threatens to fire you if you are not 
going to comply... would help. rrul_max perhaps?


-- 
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/225___
Flent-users mailing list -- flent-users@flent.org
To unsubscribe send an email to flent-users-le...@flent.org

Re: [Flent-users] [tohojo/flent] ss_iterate.sh yields corrupted output (#204)

[Dave Täht]

I'd also really like this to work on osx.
/me hides

-- 
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/204#issuecomment-619612239___
Flent-users mailing list
Flent-users@flent.org
http://flent.org/mailman/listinfo/flent-users_flent.org

Re: [Flent-users] [tohojo/flent] ss_iterate.sh yields corrupted output (#204)

[Dave Täht]

I note if you are running into heisenbugs, patches exist for both tc and ss to 
let it poll on an interval. Much better than a script, not accepted upstream

-- 
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/204#issuecomment-619610436___
Flent-users mailing list
Flent-users@flent.org
http://flent.org/mailman/listinfo/flent-users_flent.org

Re: [Flent-users] [tohojo/flent] feature: positional data/plots and handling disconnects. (#199)

[Dave Täht]

Jumziey  writes:

> Jumziey notificati...@github.com writes:
> I would like to get some good data on how tcp uploads/downloads
> works from a boat in certain areas while moving around with
> different solutions. I did a naive test with flent running the
> tcp_download tcp_1up_noping tests but had a problem with the test
> just completely shutting down if i lost connection due to getting
> into a blind spot. Is this a configuration issue or is there some
> extra coding required to fix this?
>
> Well, TCP will tend to do that - depending on what you
> mean by "lost connection". What would you like to have happen
> instead?
>
> Good point! I brainfarted there. My first thought was to try and
> reestablish the connection while the test time hadn't run out. But
> yeah, i will try and run it with just UDP instead, seems more fitting
> for application.
>
> Would be great if there was some native support for presenting gps
> data as well on a seachart ala openseamap or similar.

gpsd can output data via udp.

>
> It should already be possible to embed a starting location
> in the metadata (just add it as a test parameter and it'll be
> saved). But I assume you mean you want periodic location data
> collected while the test is running, right?
>
> Correct!
>
> I could certainly look into implementing these features, but would
> like some feedback on my thoughts before just forking and trying
> it on my own.
>
> The location data collection should be straight-forward
> enough, given a suitable source of location data; no idea what
> it would take to integrate a map service into the GUI,
> though... But happy to take patches if you do give it a shot :
> )
>
> I wont make any promises, but it seems like something i will spend
> some time on in the future :)
>
> —
> You are receiving this because you are subscribed to this thread.
> Reply to this email directly, view it on GitHub, or unsubscribe.


-- 
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/tohojo/flent/issues/199#issuecomment-597499599___
Flent-users mailing list
Flent-users@flent.org
http://flent.org/mailman/listinfo/flent-users_flent.org

Re: [Flent-users] [tohojo/flent] CS5 does not appear to be emitted by the rrul test with irtt (#190)

[Dave Täht]

Closed #190.

-- 
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/190#event-2805039388___
Flent-users mailing list
Flent-users@flent.org
http://flent.org/mailman/listinfo/flent-users_flent.org

[Flent-users] [tohojo/flent] CS5 does not appear to be emitted by the rrul test with irtt (#190)

[Dave Täht]

Attached is a packet capture showing that cs1, cs0, and ef are being 
successfully set on the rrul test for irtt. cs5 (the vi queue in wifi), isn't.

(it also shows that comcast remarks ef to cs0)
[rrul-2019-11-16T101614.379448.flent.gz](https://github.com/tohojo/flent/files/3854545/rrul-2019-11-16T101614.379448.flent.gz)

[no-cs5.pcap.gz](https://github.com/tohojo/flent/files/3854548/no-cs5.pcap.gz)

@heistp @tohojo 

for the record this is a server (flent-singapore.taht.net) running a stock 
nanode instance with ubuntu 19.10 and kernel 5.3.x, no other mods.

irtt alone does appear to be able to successfully set cs5 --dscp=a0

-- 
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/190___
Flent-users mailing list
Flent-users@flent.org
http://flent.org/mailman/listinfo/flent-users_flent.org

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

[Dave Täht]

Pete Heist  writes:

> 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" % (argset, rep))
> )
> return clean_path(filename)
>
> On one hand, this ensures that output filenames are unique, but on the
> other hand, one can't create stable links to the output filenames that
> don't change between runs, for example in a static HTML or markdown
> file.
>
> What I could do is add a filename_no_time or similar parameter that if
> set to anything "truthy" (maybe if s in [ '1', 'true', 'yes' ]),
> excludes the time from the filename, then it's up to people to
> properly set filename_extra.
>
> Would you be ok if I do that, or do you have any other suggestions for
> this?

--no-time

>
> —
> You are receiving this because you are subscribed to this thread.
> Reply to this email directly, view it on GitHub, or mute the thread.


-- 
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-528885668___
Flent-users mailing list
Flent-users@flent.org
http://flent.org/mailman/listinfo/flent-users_flent.org

Re: [Flent-users] [tohojo/flent] `ss: command not found` on macOS (#177)

[Dave Täht]

Well, I'd LOVE it if we suppotedOSX for thuis

-- 
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/tohojo/flent/issues/177#issuecomment-528664922___
Flent-users mailing list
Flent-users@flent.org
http://flent.org/mailman/listinfo/flent-users_flent.org

[Flent-users] [tohojo/flent] it would be cool if we had a staggered rrul (#156)

[Dave Täht]

We really hit BBR where it hurts with starting it all up at the same time. 

https://forum.netgate.com/topic/112527/playing-with-fq_codel-in-2-4/788

-- 
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/156___
Flent-users mailing list
Flent-users@flent.org
http://flent.org/mailman/listinfo/flent-users_flent.org

[Flent-users] [tohojo/flent] falling back to another ipv6 address even with --local-bind (#155)

[Dave Täht]

I learned something today. There are times when netperf will fall back to not 
using the address you specified, or --local-bind is not working right for 
netperf. I have multiple ipv6 addresses... and in this case, I wanted to go 
back and forth between testing an ipv6 tunnel and ipv6 native. 

flent -6 --local-bind 2600:3c01:e001:9301::2 -H flent-fremont.bufferbloat.net 
-t wireguard_really_v6 rrul

netperf -L 2600:3c01:e001:9301::2 -H wherever

does the same thing. Negotiates the control connection over the first, but 
falls back to the native one. I was initially jumping for joy at wireguard 
"getting it right"... but

d 3242  0.0  0.0  24556  2500 pts/27   S+   09:23   0:00 
/usr/local/bin/netperf -P 0 -v 0 -D -0.20 -6 -Y CS5 CS5 -H 
flent-fremont.bufferbloat.net -p 12865 -t TCP_STREAM -l 60 -F /dev/urandom -f m 
-L 2600:3c01:e001:9301::1 -- -L 2600:3c01:e001:9301::1 -H 
flent-fremont.bufferbloat.net -k 
THROUGHPUT,LOCAL_CONG_CONTROL,REMOTE_CONG_CONTROL,TRANSPORT_MSS,LOCAL_TRANSPORT_RETRANS,REMOTE_TRANSPORT_RETRANS,LOCAL_SOCKET_TOS,REMOTE_SOCKET_TOS,DIRECTION,ELAPSED_TIME,PROTOCOL,LOCAL_SEND_SIZE,LOCAL_RECV_SIZE,REMOTE_SEND_SIZE,REMOTE_RECV_SIZE,LOCAL_BYTES_SENT,LOCAL_BYTES_RECVD,REMOTE_BYTES_SENT,REMOTE_BYTES_RECVD

I guess a sanity check would be nice that checked that the address you used was 
the one that was used short of a packet cap and 


-- 
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/155___
Flent-users mailing list
Flent-users@flent.org
http://flent.org/mailman/listinfo/flent-users_flent.org

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

[Dave Täht]

Another rrul_v2 issue would be to correctly end up in all the queues on wifi.

-- 
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/tohojo/flent/issues/148#issuecomment-418152116___
Flent-users mailing list
Flent-users@flent.org
http://flent.org/mailman/listinfo/flent-users_flent.org

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

[Dave Täht]

this convo is (purposefully) all over the place, but I'm leaning towards a 
rrul_v2 test with 10ms irtt intervals. Not clear to me if flent could deal with 
two different sample rates

-- 
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/tohojo/flent/issues/148#issuecomment-416615907___
Flent-users mailing list
Flent-users@flent.org
http://flent.org/mailman/listinfo/flent-users_flent.org

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

[Dave Täht]

actually - and I can see pete running screaming from the room - we could add 
tcp-like behavior to irtt and obsolete netperf entirely except for referencing 
the main stack. The main reason we use netperf was because core linux devs 
trusted it, and the reason why we sample only is because timestamping each 
packet and extracting stats from it is hard in light of mss and the complexity 
of the netperf codebase. 

Implementing tcp-like behavior and tcp-like congestion controllers on top of 
irtt seems simpler in comparison, and we already have better timestamp 
facilities than tcp in irtt.

Who here likes playing the Zerg as much as I do?

-- 
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/tohojo/flent/issues/148#issuecomment-416450498___
Flent-users mailing list
Flent-users@flent.org
http://flent.org/mailman/listinfo/flent-users_flent.org

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

[Dave Täht]

on plotting stuff I could see adding a 4th graph much like TSDE's for loss and 
reorder.

-- 
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/tohojo/flent/issues/148#issuecomment-416328501___
Flent-users mailing list
Flent-users@flent.org
http://flent.org/mailman/listinfo/flent-users_flent.org

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

[Dave Täht]

I really do care about measuring packet loss and re-orders accurately.

I've also been fiddling with setting the tos field, to do ect(0,1) and CE. 
Doing that at a higher level would be good and noting the result. --ecn 1,2,3 ?

summary line of "Forward/backward path stripping dscp", "CE marks"
reorders and loss



-- 
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/tohojo/flent/issues/148#issuecomment-416317840___
Flent-users mailing list
Flent-users@flent.org
http://flent.org/mailman/listinfo/flent-users_flent.org

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

[Dave Täht]

@chromi @heistp @jg  @richb-hanover 

Our tests with typical sampling rates in the 200ms range are misleading. We 
(until the development of irtt) are basically pitting request/response traffic 
against heavy tcp traffic and I think it's been leading us to draw some 
conclusions that are untrue for many other kinds of traffic, particularly with 
ecn enabled and the collateral damage it might cause.

The keruffle over: https://github.com/systemd/systemd/issues/9748 and 
https://github.com/systemd/systemd/issues/9725 is a symptom of my uneasyness.

I'm probably the only one that runs flent against a 20ms sampling interval 
regularly. Queues do build in this case, finally, for voip like traffic, and we 
end up in the "slow" queue, even the "fast" queue gets more than one packet to 
deliver.

Having to prioritize arp slightly as cake does in diffserv mode  is one 
symptom, having to (as I've done for years now) ecn mark babel packets  on a 
congested router is another. Other routing protocols that don't use IP will 
also always end up in a fixed queue. 

I've long thought a "special" "1025th" queue for things like arp were possibly 
needed. Right now that maps to the "0th" queue and can collide. There are other 
protocols not handled by the flow dissector. 

* tracking packet loss better for the measurement flows would comfort me  A LOT 
(having a graph mixin that could pull that data out?)

* a rrul_v2 test that did the 20ms irtt thing always would be good

* a test that tested ecn'd flows vs non-ecn'd flows would be good.

* a fixed rate, non-ecned, but queue building flow mixin (sort of like what 
babel does to me now). Toke picks on me for using babel on workloads like this, 
I view it as a subtle reminder real networks are not like a lab.

* syn repeats?

* RTO tracking?

* A heavy flows going and squarewave tests

I was also regularly able in the latest string of extreme tests get some, out 
of the hundred flows started simultaneously - at 100mbit - to wind up in ecn 
fallback mode for some.

Using "flows 32" for fq_codel & ecn was often "not good" from the perspective 
of my (non-ecned) monitoring flow, things like "top" would have their output 
pause half screened.





-- 
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/148___
Flent-users mailing list
Flent-users@flent.org
http://flent.org/mailman/listinfo/flent-users_flent.org

[Flent-users] [tohojo/flent] tc_iterate.c is borken for newer tcs (#146)

[Dave Täht]

It hangs. run at the command line the equivalent batch line works, so I am 
thinking that somewhere along on the jsonification stage they stopped line 
buffering or are not doing a flush somewhere needed.

Not specifically a flent issue, obviously, just noting this as a reminder to 
self to go fix it.

-- 
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/146___
Flent-users mailing list
Flent-users@flent.org
http://flent.org/mailman/listinfo/flent-users_flent.org

Re: [Flent-users] [tohojo/flent] Combine plots to actual timestamp-series (#144)

[Dave Täht]

thx! the network behavior I'm looking at itself doesn't make any sense, but at 
least I can plot it now.

-- 
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/tohojo/flent/issues/144#issuecomment-406391577___
Flent-users mailing list
Flent-users@flent.org
http://flent.org/mailman/listinfo/flent-users_flent.org

Re: [Flent-users] [tohojo/flent] Combine plots to actual timestamp-series (#144)

[Dave Täht]

the *weird* thing I'm actually trying to look at is that it takes 10sec for the 
impact of the 10 new flows to truly hit, then all the other flows come back 
hard, then 10 sec later, we achieve balance. I've been lying down on the job by 
not thoroughly auditing the last 6 months worth of AQM changes...

-- 
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/tohojo/flent/issues/144#issuecomment-406389940___
Flent-users mailing list
Flent-users@flent.org
http://flent.org/mailman/listinfo/flent-users_flent.org

Re: [Flent-users] [tohojo/flent] Combine plots to actual timestamp-series (#144)

[Dave Täht]

and ok, I got around to installing pyqt5 and it does the same thing. Older 
matplotlib?

-- 
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/tohojo/flent/issues/144#issuecomment-406387756___
Flent-users mailing list
Flent-users@flent.org
http://flent.org/mailman/listinfo/flent-users_flent.org

Re: [Flent-users] [tohojo/flent] Combine plots to actual timestamp-series (#144)

[Dave Täht]

d@dancer:~/ne
![fortoke](https://user-images.githubusercontent.com/108682/42965417-c9dfa524-8b4e-11e8-8cc3-ffea1c1cd26e.png)
m$ flent-gui --absolute-time *500*.gz
Started Flent 1.2.2-git-09e66b3 using Python 3.5.2.
WARNING: Falling back to Qt4 for the GUI. Please consider installing PyQt5.

Initialised matplotlib v1.5.1 on numpy v1.11.0.
GUI loaded. Running on PyQt v4.11.4.


-- 
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/tohojo/flent/issues/144#issuecomment-406387376___
Flent-users mailing list
Flent-users@flent.org
http://flent.org/mailman/listinfo/flent-users_flent.org

Re: [Flent-users] [tohojo/flent] Combine plots to actual timestamp-series (#144)

[Dave Täht]

(I have no idea how you are holding cake, iproute2, and flent all in your head)

-- 
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/tohojo/flent/issues/144#issuecomment-406384877___
Flent-users mailing list
Flent-users@flent.org
http://flent.org/mailman/listinfo/flent-users_flent.org

Re: [Flent-users] [tohojo/flent] Combine plots to actual timestamp-series (#144)

[Dave Täht]

Reopened #144.

-- 
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/tohojo/flent/issues/144#event-1743330633___
Flent-users mailing list
Flent-users@flent.org
http://flent.org/mailman/listinfo/flent-users_flent.org

Re: [Flent-users] [tohojo/flent] Combine plots to actual timestamp-series (#144)

[Dave Täht]

i pulled. that fix breaks those plots completely in the general case.

-- 
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/tohojo/flent/issues/144#issuecomment-406384387___
Flent-users mailing list
Flent-users@flent.org
http://flent.org/mailman/listinfo/flent-users_flent.org

Re: [Flent-users] [tohojo/flent] Combine plots to actual timestamp-series (#144)

[Dave Täht]

[tcp_nup-2018-07-19T114126.321412.500mbit-spaceheater-dancer-offset-20sec-ethernet.flent.gz](https://github.com/tohojo/flent/files/2211294/tcp_nup-2018-07-19T114126.321412.500mbit-spaceheater-dancer-offset-20sec-ethernet.flent.gz)
[tcp_nup-2018-07-19T114145.590670.500mbit-dancer-spaceheater-offset-20sec-ethernet.flent.gz](https://github.com/tohojo/flent/files/2211295/tcp_nup-2018-07-19T114145.590670.500mbit-dancer-spaceheater-offset-20sec-ethernet.flent.gz)


-- 
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/tohojo/flent/issues/144#issuecomment-406378417___
Flent-users mailing list
Flent-users@flent.org
http://flent.org/mailman/listinfo/flent-users_flent.org

Re: [Flent-users] [tohojo/flent] Combine plots to actual timestamp-series (#144)

[Dave Täht]

yes.


-- 
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/144#issuecomment-406375455___
Flent-users mailing list
Flent-users@flent.org
http://flent.org/mailman/listinfo/flent-users_flent.org

[Flent-users] [tohojo/flent] hmac support for irtt (#145)

[Dave Täht]

irtt supports hmac for authentication. I am glad to see the three way 
handshake, but hmac might be useful.

-- 
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/145___
Flent-users mailing list
Flent-users@flent.org
http://flent.org/mailman/listinfo/flent-users_flent.org

Re: [Flent-users] [tohojo/flent] Measure overhead of latency measurement flows (#78)

[Dave Täht]

I didn't realize irtt had grown so feature complete! --hmac! lovely! 

-- 
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/78#issuecomment-40608___
Flent-users mailing list
Flent-users@flent.org
http://flent.org/mailman/listinfo/flent-users_flent.org

Re: [Flent-users] [tohojo/flent] Measure overhead of latency measurement flows (#78)

[Dave Täht]

Closed #78.

-- 
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/78#event-1741016680___
Flent-users mailing list
Flent-users@flent.org
http://flent.org/mailman/listinfo/flent-users_flent.org

[Flent-users] [tohojo/flent] correct use of udp_flood_var_up? (#121)

[Dave Täht]

flent -H 172.22.148.9 -H 172.22.148.9 -H 172.22.148.9 -H 172.22.148.9 -t 
cake-simul udp_flood_var_up

?
[udp_flood_var_up-2017-11-23T154421.462961.cake-simul.flent.gz](https://github.com/tohojo/flent/files/1500331/udp_flood_var_up-2017-11-23T154421.462961.cake-simul.flent.gz)


-- 
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/121___
Flent-users mailing list
Flent-users@flent.org
http://flent.org/mailman/listinfo/flent-users_flent.org

[Flent-users] [tohojo/flent] UDP averages seem off in batch output (#120)

[Dave Täht]

I would prefer to think it was flent that was busted here rather than cake.

Summary of rrul_be test run '100-10Mbit:nat:ack_filter' (at 2017-11-22 
22:17:58.800917):
  avg   median  # data pts
 Ping (ms) ICMP: 0.86 0.88 ms  351
 Ping (ms) UDP BE1 :  1006.76 1.85 ms  350 ?
 Ping (ms) UDP BE2 :  1003.68 1.85 ms  350 ?
 Ping (ms) UDP BE3 :  1099.73 1.74 ms  350 ?
 Ping (ms) avg :  1036.72 1.56 ms  351
 TCP download BE   : 1.96 1.96 Mbits/s 301
 TCP download BE2  : 1.96 1.96 Mbits/s 300
 TCP download BE3  : 1.96 1.96 Mbits/s 301
 TCP download BE4  : 1.96 1.96 Mbits/s 301
 TCP download avg  : 1.96 1.97 Mbits/s 301
 TCP download sum  : 7.84 7.86 Mbits/s 301
 TCP totals:64.3264.28 Mbits/s 301
 TCP upload BE :14.1214.09 Mbits/s 301
 TCP upload BE2:14.1214.09 Mbits/s 300
 TCP upload BE3:14.1214.16 Mbits/s 301
 TCP upload BE4:14.1214.13 Mbits/s 301
 TCP upload avg:14.1214.12 Mbits/s 301
 TCP upload sum:56.4856.48 Mbits/s 301


-- 
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/120___
Flent-users mailing list
Flent-users@flent.org
http://flent.org/mailman/listinfo/flent-users_flent.org

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

[Dave Täht]

Toke Høiland-Jørgensen  writes:

> Oh, and many thanks for your work on irtt, @peteheist! We really needed such a
> tool :)

Thx very much also. I'd really like to get some owd plots out of
flent

>
> —
> You are receiving this because you commented.
> Reply to this email directly, view it on GitHub, or mute the thread.


-- 
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/tohojo/flent/issues/106#issuecomment-346478522___
Flent-users mailing list
Flent-users@flent.org
http://flent.org/mailman/listinfo/flent-users_flent.org

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

[Dave Täht]

Pete Heist  writes:

>> On Nov 20, 2017, at 10:44 PM, flent-users  wrote:
>> 
>> A goal for me has been to be able to run Opus at 24 bit, 96Khz, with 2.7ms
>> sampling latency.
>> Actually getting 8 channels of that through a loaded box would be marvelous.
>
> Sounds like a musician. :) If it were CBR, I don’t know if this is a way to
> estimate it:
>
> 2.7ms ~= 370 packets/sec

Well, it might be 8 of those with different tuples.

> @128kbps, 56 bytes / packet (44 data + 12 RTP)
> @256kbps, 99 bytes / packet (87 data + 12 RTP)
>
> Just for fun, a ~256 kbps test between two sites, 50km apart, both using p2p
> WiFi to the Internet. For realtime audio, I guess it’s the maximums that could
> be the biggest issue.

Hah. I didn't say over wifi. That's impossible.


>
> ```
> % ./irtt client -i 2.7ms -l 99 -q -d 10s a.b.c.d
> [Connecting] connecting to a.b.c.d
> [Connected] connected to a.b.c.d:2112
>
> Min Mean Median Max Stddev
> ---  -- --- --
> RTT 10.16ms 15.57ms 14.14ms 71.37ms 4.89ms
> send delay 4.5ms 8.01ms 6.85ms 33.1ms 3.6ms
> receive delay 4.99ms 7.56ms 6.93ms 64.86ms 3.05ms
>
> IPDV (jitter) 1.06µs 2.52ms 2.56ms 56.16ms 2.55ms
> send IPDV 50ns 2.1ms 1.93ms 25.94ms 2.18ms
> receive IPDV 49ns 1.14ms 663µs 58.63ms 1.9ms
>
> send call time 38.2µs 83.2µs 13.46ms 310µs
> timer error 2ns 44.7µs 18.23ms 620µs
> server proc. time 33.6µs 47.4µs 242µs 18.1µs
>
> duration: 10.2s (wait 214.1ms)
> packets sent/received: 3647/3644 (0.08% loss)
> server packets received: 3644/3647 (0.08%/0.00% loss up/down)
> bytes sent/received: 361053/360756
> send/receive rate: 288.9 Kbps / 288.7 Kbps
> packet length: 99 bytes
> timer stats: 57/3704 (1.54%) missed, 1.65% error
> ``` 
>
> —
> You are receiving this because you commented.
> Reply to this email directly, view it on GitHub, or mute the thread.


-- 
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/tohojo/flent/issues/106#issuecomment-346130517___
Flent-users mailing list
Flent-users@flent.org
http://flent.org/mailman/listinfo/flent-users_flent.org

Re: [Flent-users] [tohojo/flent] Using network namespaces (#117)

[Dave Täht]

Closed #117.

-- 
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/tohojo/flent/issues/117#event-1350923264___
Flent-users mailing list
Flent-users@flent.org
http://flent.org/mailman/listinfo/flent-users_flent.org

[Flent-users] [tohojo/flent] Using network namespaces (#117)

[Dave Täht]

For simulation it would be helpful to be able to monitor qdiscs and other stats 
within a container.


ip netns exec delay tc_iterate -i delay.l 
ip netns exec delay tc_iterate -i delay.r 
ip netns exec mbox tc_iterate -i middlebox.l
ip netns exec mbox tc_iterate -i middlebox.r 




-- 
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/117___
Flent-users mailing list
Flent-users@flent.org
http://flent.org/mailman/listinfo/flent-users_flent.org

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

[Dave Täht]

Pete Heist  writes:

> I really like these PCEngines APU2 boards, and PTP HW timestamps. Now Peter,
> back to work... :)

What kernel is this, btw? A *lot* of useful stuff just landed in
net-next for network namespaces, which may mean I can try to validate
your results in emulation, also. My primitive (eyeballing the packet
captures of some tcp traces) jitter result in a 4 virtualized network
namespace, was 2-6us, but that's hardly trustable.

Knowing that basic measurement noise in your setup is < 107us is quite
helpful, I wonder what the sources are

>
> sysadmin@apu2a:~$ ./irtt client -i 1ms -d 10s -q 10.9.0.2
> [Connecting] connecting to 10.9.0.2
> [Connected] connected to 10.9.0.2:2112
>
> MinMean  Median Max  Stddev
> ---  -- ---  --
> RTT   237µs   270µs   268µs   366µs10µs
>  send delay   119µs   135µs   134µs   226µs  7.34µs
>   receive delay   113µs   135µs   134µs   227µs  6.25µs
>
>   IPDV (jitter) 1ns  9.47µs  6.32µs   107µs  9.86µs
>   send IPDV  0s  6.96µs  4.71µs  90.1µs  7.43µs
>receive IPDV  0s  4.92µs  2.61µs  92.5µs  6.84µs
> ...
>
> —
> You are receiving this because you commented.
> Reply to this email directly, view it on GitHub, or mute the thread.


-- 
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/106#issuecomment-343582828___
Flent-users mailing list
Flent-users@flent.org
http://flent.org/mailman/listinfo/flent-users_flent.org

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

[Dave Täht]

I tried rust out at about the same time esr did (in fact, sped up his go code 
by threading it better). Didn't like it, either.

( http://esr.ibiblio.org/?p=7294 )

Honestly, I don't know what to do about having better R/T capable code in a 
better language. All I can do is point out things like temporarily disabling 
garbage collection as means of getting closer, promoting cpus that could 
context switch better, and buying old cars that don't have bluetooth support.

-- 
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/106#issuecomment-337291571___
Flent-users mailing list
Flent-users@flent.org
http://flent.org/mailman/listinfo/flent-users_flent.org

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

[Dave Täht]

Pete Heist  writes:

> Thanks! I made most of your changes (-o was particularly broken, so this is a
> better solution), except:
>
> * I'm still thinking about whether to default durations to seconds or not. I'm
>   using Go's default duration flag parsing, and I like the explicitness of
>   seeing the units.

I also like explicitness, and rejecting the arg without it is ok by me.

> * I like that the JSON is written even after ctrl-C, so that interrupting a 
> long
>   test doesn't mean you lose all your results. But maybe if you're sending
>   output to stdout, it's not a good idea (or even breaks some convention?) 
>
> I changed it to ping-like behavior (although there is now -q for no per-packet
> results and -qq for no output at all). But just to explain the thought 
> process,
> I felt that the default of five round trips in one second, which produces a
> reasonable approximation of all relevant stats in a short period of time, was
> better than waiting in anticipation for the next one second ping. In one 
> second
> you could already be reviewing stats. :) Also, since I think IRTT will be
> typically used for lower intervals than ping, not defaulting to per-packet
> output made sense to me. I don't need to do things just because of tradition.
> However, I took your advice because we're all so accustomed to ping for so 
> many
> years now, that what I like as a default might be uncomfortable or annoying to
> others, and I don't wish for people to get that feeling.
>
> If you do get some time, I'll try to turn around any changes ASAP even while 
> my
> visitor is here. I'm looking forward to using Flent with IRTT to redo my 
> second
> round of point-to-point WiFi tests. Open Mesh has also just released their 
> first
> public beta with airtime fairness, so I'd like to give that a try.

Groovy.

> Also, If there's a reason I should do my tests with iperf2 instead, I'm all
> ears, as I'm a "scientist," not attached to my own work. :) I read that 
> they're

Cross checking is always good.

> setting the thread priority to realtime, which likely reduces scheduling 
> delays,
> but there's probably a cost to that. I experimented with Go's

So long as you can complete your work within a bound, realtime
scheduling is a win. I also tended to like timer_fds as those let you
know easily when you'd overrun a bound.

> runtime.LockOSThread() (it's there as the -thread option for both client and
> server) but since during one round of testing I saw 10ms outliers with that
> enabled, it's not the default. It does seem to reduce mean RTT somewhat 
> though.

The *very* first thing I learned about GO was how to turn the garbage
collector off. I'm weird that way. I'd still suggest turning the garbage
collector off until after the end of a run.

> —
> You are receiving this because you commented.
> Reply to this email directly, view it on GitHub, or mute the thread.


-- 
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/106#issuecomment-337025131___
Flent-users mailing list
Flent-users@flent.org
http://flent.org/mailman/listinfo/flent-users_flent.org

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

[Dave Täht]

Pete Heist  writes:

> An update:
>
> *   JSON is working, sample attached in case there are comments / wishes.
>
> *   Median (where possible) and stddev are working.

While I'm obsessive, so many seem to think networks behave with gaussian
(where the concept of stdev comes from) distributions.

Pareto distributions are closer but still inadaquate... Poisson is poison:

http://www.pollere.net/Pdfdocs/QrantJul06.pdf

but by all means, throw stdev in there. It's sometimes useful.

I am usually most interested in the outliers above the 98th percentile,
and fine some use in seven number summaries also.


>
> *   pflag adds 160K to executable, passing for now.
>
> *   Interval restriction on non-root users works. "No can do" in Windows so 
> far
>   (uid always -1). Tried looking at well-known Windows admin SIDs but it's
>   unclear I can really get that to work right on different Windows
>   versions/configs so...punt for now and no restriction in Windows.
>
> *   Spent more time than I should have making different combinations of
>   timestamp (none, receive, send, both, midpoint) and clock (wall, monotonic,
>   both) modes working, but at least now packets can be reduced in size by
>   sacrificing timestamps or clock modes for simulating VoIP codecs that have
>   smaller payloads, which was one of my goals.
>
> *   Read the OWAMP RFC, mostly. Good lord. At least it gave me an idea that 
> the
>   server can (later) return received packet count and/or a bitmap of recently
>   received packets for a flow so we can distinguish between upstream and
>   downstream packet loss, which is not possible right now.

Don't let that RFC freeze you up! (talk about overenginering!)

> *   Last thing to do is the handshake (saved the best for last!) Did some more
>   thinking on this to make it more robust than my previous design. Maybe 
> about a
>   week to complete, we'll see, as this mixes with life stuff too...

> *   Stats output now in columns for easier reading:
>
> sysadmin@luke:~ $ ./irtt -i 10ms -d 30s -l 160 a.b.c.d
> IRTT to a.b.c.d (a.b.c.d:2112)
>
>  Min Mean   Median  Max  Stddev
>  ---    --  ---  --
> RTT  11.59ms  15.73ms  14.39ms  49.34ms  3.64ms
>  send delay5.9ms   9.23ms6.8ms  43.16ms  3.48ms
>   receive delay   5.42ms6.5ms   7.59ms  17.88ms   937µs
>
>   IPDV (jitter)   1.25µs   2.52ms   4.15ms  29.16ms  2.75ms
>   send IPDV 36ns   2.41ms595µs  28.84ms  2.69ms
>receive IPDV 60ns734µs   3.55ms   9.57ms   914µs
>
>  send call time   56.3µs   70.6µs 236µs  22.7µs
> timer error  4ns   11.3µs9.59ms   187µs
>   server proc. time   6.93µs   7.62µs68.1µs  2.23µs
>
>  duration: 30.2s (wait 148ms)
> packets received/sent: 2996/2996 (0.00% loss)
>   bytes received/sent: 479360/479360
> receive/send rate: 127.9 Kbps / 127.9 Kbps
>   timer stats: 4/3000 (0.13%) missed, 0.11% error
>
> g711.json.gz
>
> —
> You are receiving this because you commented.
> Reply to this email directly, view it on GitHub, or mute the thread.


-- 
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/106#issuecomment-332043470___
Flent-users mailing list
Flent-users@flent.org
http://flent.org/mailman/listinfo/flent-users_flent.org