[Rpm] fremont.nq.taht.net is ready for rpm testing

[Rpm] fremont.nq.taht.net is ready for rpm testing

[Dave Taht]

Example of use:

I don't have an osx box to test with...

davetaht@penguin:~/goresponsiveness$ ./goresponsiveness --config
fremont.nq.taht.net --port 443 --path config
04-19-2022 15:13:12 UTC Go Responsiveness to fremont.nq.taht.net:443...
Download:  39.447 Mbps (  4.931 MBps), using 12 parallel connections.
Upload:     1.000 Mbps (  0.125 MBps), using 24 parallel connections.
(really crazy to open that many as I've mentioned)

Total RTTs measured: 5
RPM:    30

...

I built a worldwide apache2 cluster.... not fully deployed yet: one
trick is you need to use a full chain on a letsencrypt cert on the
server, I don't know if that's the case on other cert types

Apache config

#SSLCertificateFile "/etc/letsencrypt/live/fremont.nq.taht.net/cert.pem"
SSLCertificateFile "/etc/letsencrypt/live/fremont.nq.taht.net/fullchain.pem"
SSLCertificateKeyFile "/etc/letsencrypt/live/fremont.nq.taht.net/privkey.pem"

# kvetches
* the large file is REALLY large. Ran me out of disk. It doesn't need
to be that stinking large.
* seq -f "x" doesn't work on my linux, results in a 1 character file.
Is that meant to be just one 'x" elsewhere or
a string of numbers? xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx compresses too well.
*

My cluster is ALSO flent capable, so as to calibrate flent or irtt
based tests against it.

I'm using a CNAME for it, which is kind of a clever trick I think
in measuring DNS latency....
-- 
I tried to build a better future, a few times:
https://wayforward.archive.org/?site=https%3A%2F%2Fwww.icei.org

Dave Täht CEO, TekLibre, LLC

Re: [Rpm] fremont.nq.taht.net is ready for rpm testing

[Sebastian Moeller]

Mmmh:

user@work-horse:~/CODE/goresponsiveness$ ./networkQuality --config fremont.nq.taht.net --port 443 --path config
04-19-2022 15:33:36 UTC Go Responsiveness to fremont.nq.taht.net:443...
Error: Saturation could not be completed in time and no provisional rates could be accessed. Test failed.

Might be too far away from Fremont?

Regards
	Sebastian



> On Apr 19, 2022, at 17:20, Dave Taht via Rpm <rpm@lists.bufferbloat.net> wrote:
> 
> Example of use:
> 
> I don't have an osx box to test with...
> 
> davetaht@penguin:~/goresponsiveness$ ./goresponsiveness --config
> fremont.nq.taht.net --port 443 --path config
> 04-19-2022 15:13:12 UTC Go Responsiveness to fremont.nq.taht.net:443...
> Download:  39.447 Mbps (  4.931 MBps), using 12 parallel connections.
> Upload:     1.000 Mbps (  0.125 MBps), using 24 parallel connections.
> (really crazy to open that many as I've mentioned)
> 
> Total RTTs measured: 5
> RPM:    30
> 
> ...
> 
> I built a worldwide apache2 cluster.... not fully deployed yet: one
> trick is you need to use a full chain on a letsencrypt cert on the
> server, I don't know if that's the case on other cert types
> 
> Apache config
> 
> #SSLCertificateFile "/etc/letsencrypt/live/fremont.nq.taht.net/cert.pem"
> SSLCertificateFile "/etc/letsencrypt/live/fremont.nq.taht.net/fullchain.pem"
> SSLCertificateKeyFile "/etc/letsencrypt/live/fremont.nq.taht.net/privkey.pem"
> 
> # kvetches
> * the large file is REALLY large. Ran me out of disk. It doesn't need
> to be that stinking large.
> * seq -f "x" doesn't work on my linux, results in a 1 character file.
> Is that meant to be just one 'x" elsewhere or
> a string of numbers? xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx compresses too well.
> *
> 
> My cluster is ALSO flent capable, so as to calibrate flent or irtt
> based tests against it.
> 
> I'm using a CNAME for it, which is kind of a clever trick I think
> in measuring DNS latency....
> -- 
> I tried to build a better future, a few times:
> https://wayforward.archive.org/?site=https%3A%2F%2Fwww.icei.org
> 
> Dave Täht CEO, TekLibre, LLC
> _______________________________________________
> Rpm mailing list
> Rpm@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/rpm

Re: [Rpm] fremont.nq.taht.net is ready for rpm testing

[Dave Taht]

On Tue, Apr 19, 2022 at 8:36 AM Sebastian Moeller <moeller0@gmx.de> wrote:
>
> Mmmh:
>
> user@work-horse:~/CODE/goresponsiveness$ ./networkQuality --config fremont.nq.taht.net --port 443 --path config
> 04-19-2022 15:33:36 UTC Go Responsiveness to fremont.nq.taht.net:443...
> Error: Saturation could not be completed in time and no provisional rates could be accessed. Test failed.
>
> Might be too far away from Fremont?

 I did see it complete on my lte box.

I get the same non-answer within the cluster, even if I enable sqm to
be 100/100Mbit... I'm obviously saturating the link here...

                 Tin 0
  thresh        100Mbit
  target            5ms
  interval        100ms
  pk_delay       2.92ms
  av_delay       2.32ms
  sp_delay          1us
  backlog            0b
  pkts           192049
  bytes       286514221
  way_inds           13
  way_miss          113
  way_cols            0
  drops            6073
  marks               0
  ack_drop            0
  sp_flows            0
  bk_flows            1
  un_flows            0
  max_len         12112
  quantum          1514


I should probably version the config file also.
> Regards
>         Sebastian
>
>
>
> > On Apr 19, 2022, at 17:20, Dave Taht via Rpm <rpm@lists.bufferbloat.net> wrote:
> >
> > Example of use:
> >
> > I don't have an osx box to test with...
> >
> > davetaht@penguin:~/goresponsiveness$ ./goresponsiveness --config
> > fremont.nq.taht.net --port 443 --path config
> > 04-19-2022 15:13:12 UTC Go Responsiveness to fremont.nq.taht.net:443...
> > Download:  39.447 Mbps (  4.931 MBps), using 12 parallel connections.
> > Upload:     1.000 Mbps (  0.125 MBps), using 24 parallel connections.
> > (really crazy to open that many as I've mentioned)
> >
> > Total RTTs measured: 5
> > RPM:    30
> >
> > ...
> >
> > I built a worldwide apache2 cluster.... not fully deployed yet: one
> > trick is you need to use a full chain on a letsencrypt cert on the
> > server, I don't know if that's the case on other cert types
> >
> > Apache config
> >
> > #SSLCertificateFile "/etc/letsencrypt/live/fremont.nq.taht.net/cert.pem"
> > SSLCertificateFile "/etc/letsencrypt/live/fremont.nq.taht.net/fullchain.pem"
> > SSLCertificateKeyFile "/etc/letsencrypt/live/fremont.nq.taht.net/privkey.pem"
> >
> > # kvetches
> > * the large file is REALLY large. Ran me out of disk. It doesn't need
> > to be that stinking large.
> > * seq -f "x" doesn't work on my linux, results in a 1 character file.
> > Is that meant to be just one 'x" elsewhere or
> > a string of numbers? xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx compresses too well.
> > *
> >
> > My cluster is ALSO flent capable, so as to calibrate flent or irtt
> > based tests against it.
> >
> > I'm using a CNAME for it, which is kind of a clever trick I think
> > in measuring DNS latency....
> > --
> > I tried to build a better future, a few times:
> > https://wayforward.archive.org/?site=https%3A%2F%2Fwww.icei.org
> >
> > Dave Täht CEO, TekLibre, LLC
> > _______________________________________________
> > Rpm mailing list
> > Rpm@lists.bufferbloat.net
> > https://lists.bufferbloat.net/listinfo/rpm
>


-- 
I tried to build a better future, a few times:
https://wayforward.archive.org/?site=https%3A%2F%2Fwww.icei.org

Dave Täht CEO, TekLibre, LLC

Re: [Rpm] fremont.nq.taht.net is ready for rpm testing

[Sebastian Moeller]

Mmmh, now directly from home it seems to work (most of the time):

Macos:
bash-3.2$ ./networkQuality --config fremont.nq.taht.net --port 443 --path config
04-19-2022 20:21:03 UTC Go Responsiveness to fremont.nq.taht.net:443...
Download:  74.422 Mbps (  9.303 MBps), using 16 parallel connections.
Upload:    22.844 Mbps (  2.855 MBps), using 20 parallel connections.
Total RTTs measured: 5
RPM:   110

Linux:
user@work-horse:~/CODE/goresponsiveness$ ./networkQuality --config fremont.nq.taht.net --port 443 --path config
04-19-2022 20:22:03 UTC Go Responsiveness to fremont.nq.taht.net:443...
Download:  80.406 Mbps ( 10.051 MBps), using 24 parallel connections.
Upload:    26.000 Mbps (  3.250 MBps), using 20 parallel connections.
Total RTTs measured: 5
RPM:   105

With an RTT of 180 ms (over IPv6) I would expect at best:
RPM: 60*1/0.180 = 333.333333333 = 333/minute



Interstingly without cake I still get
Macos:
bash-3.2$ ./networkQuality --config fremont.nq.taht.net --port 443 --path config
04-19-2022 20:30:38 UTC Go Responsiveness to fremont.nq.taht.net:443...
Download:  75.668 Mbps (  9.459 MBps), using 12 parallel connections.
Upload:    16.500 Mbps (  2.062 MBps), using 36 parallel connections.
Total RTTs measured: 5
RPM:   109

Linux:
moeller@work-horse:~/CODE/goresponsiveness$ ./networkQuality --config fremont.nq.taht.net --port 443 --path config
04-19-2022 20:34:13 UTC Go Responsiveness to fremont.nq.taht.net:443...
Download:  96.155 Mbps ( 12.019 MBps), using 24 parallel connections.
Upload:    23.188 Mbps (  2.898 MBps), using 28 parallel connections.
Total RTTs measured: 5
RPM:   109

Linux versus apple (RTT ~18.8ms -> 60*1/0.018 = 3333 RPM)
moeller@work-horse:~/CODE/goresponsiveness$ ./networkQuality --config mensura.cdn-apple.com --port 443 --path /api/v1/gm/config 
04-19-2022 20:38:10 UTC Go Responsiveness to mensura.cdn-apple.com:443...
Download:  89.718 Mbps ( 11.215 MBps), using 12 parallel connections.
Upload:    26.938 Mbps (  3.367 MBps), using 12 parallel connections.
Total RTTs measured: 5
RPM:   811

I guess progress yeah, measurements return something, now let's see when the go timing bug will get zapped.

Regards
	Sebastian


> On Apr 19, 2022, at 17:53, Dave Taht <dave.taht@gmail.com> wrote:
> 
> On Tue, Apr 19, 2022 at 8:36 AM Sebastian Moeller <moeller0@gmx.de> wrote:
>> 
>> Mmmh:
>> 
>> user@work-horse:~/CODE/goresponsiveness$ ./networkQuality --config fremont.nq.taht.net --port 443 --path config
>> 04-19-2022 15:33:36 UTC Go Responsiveness to fremont.nq.taht.net:443...
>> Error: Saturation could not be completed in time and no provisional rates could be accessed. Test failed.
>> 
>> Might be too far away from Fremont?
> 
> I did see it complete on my lte box.
> 
> I get the same non-answer within the cluster, even if I enable sqm to
> be 100/100Mbit... I'm obviously saturating the link here...
> 
>                 Tin 0
>  thresh        100Mbit
>  target            5ms
>  interval        100ms
>  pk_delay       2.92ms
>  av_delay       2.32ms
>  sp_delay          1us
>  backlog            0b
>  pkts           192049
>  bytes       286514221
>  way_inds           13
>  way_miss          113
>  way_cols            0
>  drops            6073
>  marks               0
>  ack_drop            0
>  sp_flows            0
>  bk_flows            1
>  un_flows            0
>  max_len         12112
>  quantum          1514
> 
> 
> I should probably version the config file also.
>> Regards
>>        Sebastian
>> 
>> 
>> 
>>> On Apr 19, 2022, at 17:20, Dave Taht via Rpm <rpm@lists.bufferbloat.net> wrote:
>>> 
>>> Example of use:
>>> 
>>> I don't have an osx box to test with...
>>> 
>>> davetaht@penguin:~/goresponsiveness$ ./goresponsiveness --config
>>> fremont.nq.taht.net --port 443 --path config
>>> 04-19-2022 15:13:12 UTC Go Responsiveness to fremont.nq.taht.net:443...
>>> Download:  39.447 Mbps (  4.931 MBps), using 12 parallel connections.
>>> Upload:     1.000 Mbps (  0.125 MBps), using 24 parallel connections.
>>> (really crazy to open that many as I've mentioned)
>>> 
>>> Total RTTs measured: 5
>>> RPM:    30
>>> 
>>> ...
>>> 
>>> I built a worldwide apache2 cluster.... not fully deployed yet: one
>>> trick is you need to use a full chain on a letsencrypt cert on the
>>> server, I don't know if that's the case on other cert types
>>> 
>>> Apache config
>>> 
>>> #SSLCertificateFile "/etc/letsencrypt/live/fremont.nq.taht.net/cert.pem"
>>> SSLCertificateFile "/etc/letsencrypt/live/fremont.nq.taht.net/fullchain.pem"
>>> SSLCertificateKeyFile "/etc/letsencrypt/live/fremont.nq.taht.net/privkey.pem"
>>> 
>>> # kvetches
>>> * the large file is REALLY large. Ran me out of disk. It doesn't need
>>> to be that stinking large.
>>> * seq -f "x" doesn't work on my linux, results in a 1 character file.
>>> Is that meant to be just one 'x" elsewhere or
>>> a string of numbers? xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx compresses too well.
>>> *
>>> 
>>> My cluster is ALSO flent capable, so as to calibrate flent or irtt
>>> based tests against it.
>>> 
>>> I'm using a CNAME for it, which is kind of a clever trick I think
>>> in measuring DNS latency....
>>> --
>>> I tried to build a better future, a few times:
>>> https://wayforward.archive.org/?site=https%3A%2F%2Fwww.icei.org
>>> 
>>> Dave Täht CEO, TekLibre, LLC
>>> _______________________________________________
>>> Rpm mailing list
>>> Rpm@lists.bufferbloat.net
>>> https://lists.bufferbloat.net/listinfo/rpm
>> 
> 
> 
> -- 
> I tried to build a better future, a few times:
> https://wayforward.archive.org/?site=https%3A%2F%2Fwww.icei.org
> 
> Dave Täht CEO, TekLibre, LLC

Re: [Rpm] fremont.nq.taht.net is ready for rpm testing

[Will Hawkins]

Thanks for doing the testing. I will keep you all posted on the
progress with the upstream work!

As always, I apologize for the delays!
Will

On Tue, Apr 19, 2022 at 4:41 PM Sebastian Moeller via Rpm
<rpm@lists.bufferbloat.net> wrote:
>
> Mmmh, now directly from home it seems to work (most of the time):
>
> Macos:
> bash-3.2$ ./networkQuality --config fremont.nq.taht.net --port 443 --path config
> 04-19-2022 20:21:03 UTC Go Responsiveness to fremont.nq.taht.net:443...
> Download:  74.422 Mbps (  9.303 MBps), using 16 parallel connections.
> Upload:    22.844 Mbps (  2.855 MBps), using 20 parallel connections.
> Total RTTs measured: 5
> RPM:   110
>
> Linux:
> user@work-horse:~/CODE/goresponsiveness$ ./networkQuality --config fremont.nq.taht.net --port 443 --path config
> 04-19-2022 20:22:03 UTC Go Responsiveness to fremont.nq.taht.net:443...
> Download:  80.406 Mbps ( 10.051 MBps), using 24 parallel connections.
> Upload:    26.000 Mbps (  3.250 MBps), using 20 parallel connections.
> Total RTTs measured: 5
> RPM:   105
>
> With an RTT of 180 ms (over IPv6) I would expect at best:
> RPM: 60*1/0.180 = 333.333333333 = 333/minute
>
>
>
> Interstingly without cake I still get
> Macos:
> bash-3.2$ ./networkQuality --config fremont.nq.taht.net --port 443 --path config
> 04-19-2022 20:30:38 UTC Go Responsiveness to fremont.nq.taht.net:443...
> Download:  75.668 Mbps (  9.459 MBps), using 12 parallel connections.
> Upload:    16.500 Mbps (  2.062 MBps), using 36 parallel connections.
> Total RTTs measured: 5
> RPM:   109
>
> Linux:
> moeller@work-horse:~/CODE/goresponsiveness$ ./networkQuality --config fremont.nq.taht.net --port 443 --path config
> 04-19-2022 20:34:13 UTC Go Responsiveness to fremont.nq.taht.net:443...
> Download:  96.155 Mbps ( 12.019 MBps), using 24 parallel connections.
> Upload:    23.188 Mbps (  2.898 MBps), using 28 parallel connections.
> Total RTTs measured: 5
> RPM:   109
>
> Linux versus apple (RTT ~18.8ms -> 60*1/0.018 = 3333 RPM)
> moeller@work-horse:~/CODE/goresponsiveness$ ./networkQuality --config mensura.cdn-apple.com --port 443 --path /api/v1/gm/config
> 04-19-2022 20:38:10 UTC Go Responsiveness to mensura.cdn-apple.com:443...
> Download:  89.718 Mbps ( 11.215 MBps), using 12 parallel connections.
> Upload:    26.938 Mbps (  3.367 MBps), using 12 parallel connections.
> Total RTTs measured: 5
> RPM:   811
>
> I guess progress yeah, measurements return something, now let's see when the go timing bug will get zapped.
>
> Regards
>         Sebastian
>
>
> > On Apr 19, 2022, at 17:53, Dave Taht <dave.taht@gmail.com> wrote:
> >
> > On Tue, Apr 19, 2022 at 8:36 AM Sebastian Moeller <moeller0@gmx.de> wrote:
> >>
> >> Mmmh:
> >>
> >> user@work-horse:~/CODE/goresponsiveness$ ./networkQuality --config fremont.nq.taht.net --port 443 --path config
> >> 04-19-2022 15:33:36 UTC Go Responsiveness to fremont.nq.taht.net:443...
> >> Error: Saturation could not be completed in time and no provisional rates could be accessed. Test failed.
> >>
> >> Might be too far away from Fremont?
> >
> > I did see it complete on my lte box.
> >
> > I get the same non-answer within the cluster, even if I enable sqm to
> > be 100/100Mbit... I'm obviously saturating the link here...
> >
> >                 Tin 0
> >  thresh        100Mbit
> >  target            5ms
> >  interval        100ms
> >  pk_delay       2.92ms
> >  av_delay       2.32ms
> >  sp_delay          1us
> >  backlog            0b
> >  pkts           192049
> >  bytes       286514221
> >  way_inds           13
> >  way_miss          113
> >  way_cols            0
> >  drops            6073
> >  marks               0
> >  ack_drop            0
> >  sp_flows            0
> >  bk_flows            1
> >  un_flows            0
> >  max_len         12112
> >  quantum          1514
> >
> >
> > I should probably version the config file also.
> >> Regards
> >>        Sebastian
> >>
> >>
> >>
> >>> On Apr 19, 2022, at 17:20, Dave Taht via Rpm <rpm@lists.bufferbloat.net> wrote:
> >>>
> >>> Example of use:
> >>>
> >>> I don't have an osx box to test with...
> >>>
> >>> davetaht@penguin:~/goresponsiveness$ ./goresponsiveness --config
> >>> fremont.nq.taht.net --port 443 --path config
> >>> 04-19-2022 15:13:12 UTC Go Responsiveness to fremont.nq.taht.net:443...
> >>> Download:  39.447 Mbps (  4.931 MBps), using 12 parallel connections.
> >>> Upload:     1.000 Mbps (  0.125 MBps), using 24 parallel connections.
> >>> (really crazy to open that many as I've mentioned)
> >>>
> >>> Total RTTs measured: 5
> >>> RPM:    30
> >>>
> >>> ...
> >>>
> >>> I built a worldwide apache2 cluster.... not fully deployed yet: one
> >>> trick is you need to use a full chain on a letsencrypt cert on the
> >>> server, I don't know if that's the case on other cert types
> >>>
> >>> Apache config
> >>>
> >>> #SSLCertificateFile "/etc/letsencrypt/live/fremont.nq.taht.net/cert.pem"
> >>> SSLCertificateFile "/etc/letsencrypt/live/fremont.nq.taht.net/fullchain.pem"
> >>> SSLCertificateKeyFile "/etc/letsencrypt/live/fremont.nq.taht.net/privkey.pem"
> >>>
> >>> # kvetches
> >>> * the large file is REALLY large. Ran me out of disk. It doesn't need
> >>> to be that stinking large.
> >>> * seq -f "x" doesn't work on my linux, results in a 1 character file.
> >>> Is that meant to be just one 'x" elsewhere or
> >>> a string of numbers? xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx compresses too well.
> >>> *
> >>>
> >>> My cluster is ALSO flent capable, so as to calibrate flent or irtt
> >>> based tests against it.
> >>>
> >>> I'm using a CNAME for it, which is kind of a clever trick I think
> >>> in measuring DNS latency....
> >>> --
> >>> I tried to build a better future, a few times:
> >>> https://wayforward.archive.org/?site=https%3A%2F%2Fwww.icei.org
> >>>
> >>> Dave Täht CEO, TekLibre, LLC
> >>> _______________________________________________
> >>> Rpm mailing list
> >>> Rpm@lists.bufferbloat.net
> >>> https://lists.bufferbloat.net/listinfo/rpm
> >>
> >
> >
> > --
> > I tried to build a better future, a few times:
> > https://wayforward.archive.org/?site=https%3A%2F%2Fwww.icei.org
> >
> > Dave Täht CEO, TekLibre, LLC
>
> _______________________________________________
> Rpm mailing list
> Rpm@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/rpm