On Wed, 3 Aug 2022, Richard Miller wrote:
That was a typo, is almost five times slower (~80% slower). Just
to be clear, it is really worst!
Unless your "small arm linux machine" is a raspberry pi, you are changing
too many variables to make a meaningful comparison. Benchmarking i/o across
the internet will also introduce enough variation to suggest an experimental
sample size of more than one attempt.
An interesting set of experiments might be to run both linux and plan 9 on
the pi4, try the built-in ether adapter and the usb dongle, and try fetching
both from http:// and https:// (to see how much of the variation is due to
tls decode speed).
Reading my mail it seems like this was something I suddenly was
aware of. It is not, I've been trying to understand what is wrong
for some time now. The pi4 saturates my fiber in linux, there is
no problem with the hardware. But note that the linux machine is
sending and receiving packages through the plan9 machine. If there
was a hardware problem in the pi4 (or the usb adapter), the linux
machine's connection would be affected.
And yes, I have made tests with different sites. As I said before
the archlinux servers usually let me saturate my bandwidth, so they
have become a good target for me.
The thing this setting is telling me is that the usb and ethernet
drivers are working reasonably good (again, at least for my
bandwidth).
I don't know any reliable server with good bandwidth serving without
tls, I could set an http server on the linux machine and make tests,
but I modified the example at
https://golangdocs.com/golang-download-files
and there is no real difference between the native and go tls implementations:
; time ./gget -o /dev/null
https://arch.mirror.constant.com/images/v20220801.71902/Arch-Linux-x86_64-basic-20220801.71902.qcow2
Downloaded a file /dev/null with size 513671168
2.25u 1.45s 65.51r ./gget -o /dev/null
https://arch.mirror.constant.com/images/v20220801.71902/Arch-Linux-x86_64-basic-20220801.71902.qcow2
; time hget -o /dev/null
https://arch.mirror.constant.com/images/v20220801.71902/Arch-Linux-x86_64-basic-20220801.71902.qcow2
couldn't set mtime: permission denied
9.27u 35.02s 64.62r hget -o /dev/null
https://arch.mirror.constant.com/images/v20220801.71902/Arch-Linux-x86_64-basic-20220801.71902.qcow2
With linux (again, through the plan9 machine) I get:
$ time ./gget -o /dev/null
https://arch.mirror.constant.com/images/v20220801.71902/Arch-Linux-x86_64-basic-20220801.71902.qcow2
Downloaded a file /dev/null with size 513671168
real 0m48.624s
user 0m14.265s
sys 0m21.648s
So now It is only about 25% slower in plan9, so yes, the factors are variable.
I found this thread in the list's archives:
https://marc.info/?t=145579525000007&r=1&w=2
Maybe is related.
------------------------------------------
9fans: 9fans
Permalink:
https://9fans.topicbox.com/groups/9fans/T668643d11149fab4-Mf2898ed1a403f2159dda8d9a
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
