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

Pete Heist notifications at github.com
Sun Nov 12 22:08:11 EET 2017


Cool, so far your namespaces scripts seem to work fine for me on 4.9.0 on the APU2. I tried an irtt run once with namespaces and once straight to the local adapter. There doesn't seem to be anything disqualifying in these results. In fact they look remarkably similar (took both results from the second run).

Things will probably be different with tests under load, so I added to my list to try some Flent runs. Maybe I could compare rrul_be on Gbit LAN vs simulated Gbit LAN?

#### Local adapter

```
sysadmin at apu2a:~$ ./irtt client -i 1ms -d 10s -q localhost
[Connecting] connecting to localhost
[Connected] connected to 127.0.0.1:2112

                        Min    Mean  Median     Max  Stddev
                        ---    ----  ------     ---  ------
                RTT   136µs   194µs   189µs  1.23ms    19µs
         send delay  67.3µs   104µs  99.8µs   316µs  11.5µs
      receive delay  57.7µs  89.7µs  89.6µs  1.12ms  13.5µs
                                                           
      IPDV (jitter)      0s  12.5µs  8.95µs  1.03ms  17.8µs
          send IPDV     4ns  8.12µs  5.15µs   205µs  8.69µs
       receive IPDV     2ns  8.82µs  6.02µs  1.06ms  16.6µs
                                                           
     send call time  35.4µs  50.4µs           240µs  3.57µs
        timer error     2ns  4.49µs          99.9µs  5.15µs
  server proc. time  12.1µs  18.8µs           132µs  3.65µs

                duration: 10s (wait 3.7ms)
   packets sent/received: 10000/10000 (0.00% loss)
 server packets received: 10000/10000 (0.00%/0.00% upstream/downstream loss)
     bytes sent/received: 600000/600000
       send/receive rate: 480.0 Kbps / 480.1 Kbps
           packet length: 60 bytes
             timer stats: 0/10000 (0.00%) missed, 0.45% error
```

#### Namespaces

```
root at apu2a:/home/sysadmin/src/veth# ip netns exec client /home/sysadmin/irtt client -i 1ms -d 10s -q 10.10.2.2
[Connecting] connecting to 10.10.2.2
[Connected] connected to 10.10.2.2:2112

                        Min    Mean  Median     Max  Stddev
                        ---    ----  ------     ---  ------
                RTT   135µs   193µs   189µs   290µs  15.3µs
         send delay  68.3µs   104µs  99.7µs   216µs  10.9µs
      receive delay  55.7µs  89.2µs  89.8µs   185µs  9.33µs
                                                           
      IPDV (jitter)     1ns  11.2µs  7.81µs   118µs  11.5µs
          send IPDV     2ns  7.43µs  4.54µs   115µs  8.63µs
       receive IPDV      0s  8.29µs   5.5µs   120µs  8.08µs
                                                           
     send call time  35.9µs  51.3µs           210µs  3.79µs
        timer error      0s  8.52µs           110µs  10.2µs
  server proc. time  11.7µs  18.2µs          66.5µs  4.11µs

                duration: 10s (wait 869µs)
   packets sent/received: 10000/10000 (0.00% loss)
 server packets received: 10000/10000 (0.00%/0.00% upstream/downstream loss)
     bytes sent/received: 600000/600000
       send/receive rate: 480.0 Kbps / 480.1 Kbps
           packet length: 60 bytes
             timer stats: 0/10000 (0.00%) missed, 0.85% error
```

#### Local Adapter, SCHED_RR

```
sysadmin at apu2a:~$ sudo chrt -r 99 ./irtt client -i 1ms -d 10s -q localhost
[Connecting] connecting to localhost
[Connected] connected to 127.0.0.1:2112

                        Min    Mean  Median     Max  Stddev
                        ---    ----  ------     ---  ------
                RTT   133µs   181µs   177µs   286µs  12.2µs
         send delay  63.4µs  93.6µs  90.1µs   189µs  10.1µs
      receive delay  62.1µs  87.3µs  86.3µs   145µs  5.01µs
                                                           
      IPDV (jitter)     2ns  7.82µs  5.08µs   111µs  8.38µs
          send IPDV      0s  6.62µs  3.86µs   102µs  7.71µs
       receive IPDV      0s  3.94µs  2.77µs  69.3µs  4.47µs
                                                           
     send call time  34.4µs  47.7µs          78.6µs  2.85µs
        timer error     1ns   3.1µs           112µs  3.71µs
  server proc. time  12.5µs    18µs          53.2µs  3.58µs

                duration: 10s (wait 858µs)
   packets sent/received: 10000/10000 (0.00% loss)
 server packets received: 10000/10000 (0.00%/0.00% upstream/downstream loss)
     bytes sent/received: 600000/600000
       send/receive rate: 480.0 Kbps / 480.0 Kbps
           packet length: 60 bytes
             timer stats: 0/10000 (0.00%) missed, 0.31% error
```

> I am running with CONFIG_HZ_1000 in the kernel.

On the APU2s, I'm currently using the default of CONFIG_HZ_250.

> An strace might be revealing as to the syscalls you are making and could
> try to optimize out. sar can show the context switches...
>
> (I am away from desk, and can do these things, too, when I get back to
> it, but enjoy teaching folk to fish and then eating the results. :))

Ok, put on my list to try...

> OSX may well make available a harder timer system than what go uses,
> since it is so often used for realtime work.

What's notable to me about the OS/X vs Linux `irtt clock` results is that on Linux the "drift", which is the per-second difference in time between the wall and monotonic clocks, starts high but then tends towards zero over time as the process runs. On OS/X is stays pretty fixed at around -15us to -20us. The first drift result should be discarded.

> I suddenly have way too much stuff to do this month. I'd like the other
> cake folk to review that patch first, but it seemed pretty awsome to me.

Ok, added to my list to test it too. Won't be right away.

> I note that I am aging fast. I don't easily understand either your or
> toke's coding style. I predate the concept of factories and crazy arse
> callbacks.

Rage, rage! I'm not nearly as inspired by young people running on the street as I am by old folks (maybe the ones from Czech's first Republic, who were around for a ripping Democracy before Communism came) walking to the tram carrying full grocery bags. I sense you've done / are doing some really important work, and when there are also people like John Goodenough around cranking it into their 90s, we've all got few excuses...

> And I had no idea you were at:
> 
> dave at nemesis:~/git/irtt$ loccount -c *.go
> all             4577 (100.00%) in 43 files
> go              4577 (100.00%) in 43 files
> Total Physical Source Lines of Code (SLOC)                = 4577
> Development Effort Estimate, Person-Years (Person-Months) = 0.99 (11.85)
 (Basic COCOMO model, Person-Months = 2.40 * (KSLOC**1.05))
> Schedule Estimate, Years (Months)                         = 0.53 (6.40)
 (Basic COCOMO model, Months = 2.50 * (person-months**0.38))
> Estimated Average Number of Developers (Effort/Schedule)  = 1.85
> Total Estimated Cost to Develop                           = $143143
 (average salary = $60384/year, overhead = 2.40).

Go's design is supposed to make it more readable, so I wish the code were shorter and easier to understand. When it's easy to understand, it also tends to be nearly bug-free. I spent some years as a developer-manager releasing commercial API software, which is where my lean towards exposing an API comes from. But for this project it may not have been worth it, and maybe just added more LOCs. Who's really going to implement `irtt.Waiter` except for me anyway? Come on now. :)

I'm also trying to shed some of my formal education. I'm a student of the "design pattern" days and spent years trying to be clever with Java. I'm tired of those things, and now more appreciate brevity and readability, since we tend to spend more time reading code (even our own) than writing it. So bear with me as I "unlearn what I have learned".

Anyway, I still want to try to handle your "videoconferencing" use case, which is what keeps invading my daily walks. Thanks for that little seed of creative destruction. :)

> Out of curiousity, how does go handle infinities and nans?
>
> // Average gets the cumulative average.
> func (ca *CumulativeAverager) Average() float64 {
>         if ca.n == 0 {
>                 return 0
>         }
>         return ca.sum / ca.n
> }

Division by zero always panics in Go, even for floats. I don't know how they got from Russ Cox's position in 2010, which makes more sense to me, to where they are today:

https://groups.google.com/forum/#!topic/golang-dev/k_RhkisDXcY

I found some illustrative code on NaN (for me too) and put it up in the Playground:

https://play.golang.org/p/MMc8mLNP36


-- 
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-343763437
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://flent.org/pipermail/flent-users_flent.org/attachments/20171112/c6c7768a/attachment-0002.html>


More information about the Flent-users mailing list