Re: relative performance
On Wed, Aug 25, 2021 at 12:33 bch wrote: > > > On Wed, Aug 25, 2021 at 00:35 Daniel Stenberg via curl-library < > curl-library@cool.haxx.se> wrote: > >> On Tue, 24 Aug 2021, Ben Greear via curl-library wrote: >> >> > What is your network-under-test in this case? >> >> Not sure. >> >> I hope to come up with a way where the network and exact server aren't >> terribly important as long as they perform roughly the same on repeated >> runs. >> It would need some experimenting I think. > > > If the top of my head, it seems > *off the top visualizing this entirely and measuring > *virtualizing this entirely machine operations (perhaps w certain emphasis on things like memory > allocations) would be the way to go, rather than running this over some > unreliable environment and measuring wall-time… but I’m not entirely sure > what this virtualized env would be. > > -bch > > > >> >> If we run "sprinter" using say 10 different libcurl versions on the same >> host, >> network and test server (probably using localhost or a host that is on a >> network that cannot be saturated by a single CPU core) it might tell us >> something. >> >> I'll probably start out making the necessary scripts and those 10 runs on >> my >> own machine to see what I learn and then go from there. >> >> Maybe it could be interesting to point those 10 runs on a different >> server/network setup then to see if that changes anything. >> >> -- >> >> / daniel.haxx.se >> | Commercial curl support up to 24x7 is available! >> | Private help, bug fixes, support, ports, new features >> | https://curl.se/support.html >> --- >> Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library >> Etiquette: https://curl.se/mail/etiquette.html > > --- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.html
Re: relative performance
On Wed, Aug 25, 2021 at 00:35 Daniel Stenberg via curl-library < curl-library@cool.haxx.se> wrote: > On Tue, 24 Aug 2021, Ben Greear via curl-library wrote: > > > What is your network-under-test in this case? > > Not sure. > > I hope to come up with a way where the network and exact server aren't > terribly important as long as they perform roughly the same on repeated > runs. > It would need some experimenting I think. If the top of my head, it seems visualizing this entirely and measuring machine operations (perhaps w certain emphasis on things like memory allocations) would be the way to go, rather than running this over some unreliable environment and measuring wall-time… but I’m not entirely sure what this virtualized env would be. -bch > > If we run "sprinter" using say 10 different libcurl versions on the same > host, > network and test server (probably using localhost or a host that is on a > network that cannot be saturated by a single CPU core) it might tell us > something. > > I'll probably start out making the necessary scripts and those 10 runs on > my > own machine to see what I learn and then go from there. > > Maybe it could be interesting to point those 10 runs on a different > server/network setup then to see if that changes anything. > > -- > > / daniel.haxx.se > | Commercial curl support up to 24x7 is available! > | Private help, bug fixes, support, ports, new features > | https://curl.se/support.html > --- > Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library > Etiquette: https://curl.se/mail/etiquette.html --- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.html
Re: relative performance
Hello curl team,
Summary : IMHO the important thing is to test on a "slow enough"
machine, assuming the main measure you want is "elapsed".
A Raspberry Pi 4 is a good candidate, and quite cheap (you don't need
the 8GB RAM model to run curl!).
Alternatives are of course using a much faster network than the good old
Gigabit Ethernet -my test conditions-, or constraining the resource with
software.
Details of my own "benchmarks"
Fuse + libcurl might not be representative of anyday use of libcurl, but
I have some benchmark that I might publish if you think it helps to
illustrate the first sentence.
I have a test file of 19.3GB ("on the cloud", hosted by 1fichier.com). I
have 1Gb ethernet and fiber at 1Gb for the internet.
I experiment reading it through my fuse driver with 4 very different
algorithm:
- raw sockets (my own very basic code -blocking!-, http only, no libcurl)
- "curl sockets" (curl_easy_recv)
- "curl pause" (my PR on fcurl with some adaptations)
- threaded curl easy (the callback is stopped with semaphores when we
have enough data, method used in the stable "master" branch)
(Experimental -not at all production quality- code can be see
https://gitlab.com/BylonAkila/astreamfs/-/tree/new_read_engine)
Well, on my decent desktop (already 5 years and a half!) sporting a
sixth generation Core i7 (i7-6700), none of the algorithms make any
measurable difference. Kernel does not even step the cores to a higher
frequency than "minimum". In fact they all finish the test (repeated
twice) with an interval less than a second between 3:03.14 and 3:04.1
for http. https is about 0,5% slower but same between 3:03.98 and 3:04,75
This kind of difference, below one second on a 19.3GB file over the
internet (not "local network"!), is inside the "margin of error", or the
"noise", or what you want to call it statistically!
This corresponds to a throughput around 109MB/s, which is very close to
the maximum you get with 1GB ethernet+fiber due to each network's layer
overhead.
So with this kind of machine, you will probably see no noticeable
difference at all, unless, indeed, you have really huge and major
regression... which might be precisely the point!
On the other hand, on my much older laptop (Core i7 first generation)
and on my very recent Raspberry Pi 4 (that's a good test machine, since
it can't do 1Gb/s in TLSv1.3, you might start seeing impact on
"elapsed") results are not at all the same!
They range from 7:02 to 11:24 for https (~60% difference!), and are
closer but still show measurable differences (~10%) in http.
Not all the difference is due to the algorithms or libcurl of course,
some settings of the kernel and "userland" matter... too long to post here.
Cheers
Alain
---
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.se/mail/etiquette.html
Re: relative performance
On Tue, 24 Aug 2021, Ben Greear via curl-library wrote: What is your network-under-test in this case? Not sure. I hope to come up with a way where the network and exact server aren't terribly important as long as they perform roughly the same on repeated runs. It would need some experimenting I think. If we run "sprinter" using say 10 different libcurl versions on the same host, network and test server (probably using localhost or a host that is on a network that cannot be saturated by a single CPU core) it might tell us something. I'll probably start out making the necessary scripts and those 10 runs on my own machine to see what I learn and then go from there. Maybe it could be interesting to point those 10 runs on a different server/network setup then to see if that changes anything. -- / daniel.haxx.se | Commercial curl support up to 24x7 is available! | Private help, bug fixes, support, ports, new features | https://curl.se/support.html --- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.html
RE: Connection to file server disconnected while file transfer is in progress
On Wed, 25 Aug 2021, vaibhav.taksale--- via curl-library wrote: [Vaibhav] Libcurl version 7.58 Used on Embedded Linux platform on ar758x board. This should come as no surprise but of course my first recommendation will be to upgrade your libcurl to a recent release as whatever problem you experience it is most likely addressed (or different) then. e.g. In this function callback "writeCallback", error return was expected. I don't understand. The callback is your code. You make it return error! -- / daniel.haxx.se | Commercial curl support up to 24x7 is available! | Private help, bug fixes, support, ports, new features | https://curl.se/support.html --- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.html
