Date: Fri, 11 Aug 2023 12:25:17 -0400 From: Joe Schaefer <joesuf4@gmail.com> To: freebsd-hackers@freebsd.org Subject: Re: can sftp be made multi-threaded? Message-ID: <CAOzHqcK5DUj0-b%2BP_sqPyC7NknHKaS1_fNcnTWKjde-SYn9QSA@mail.gmail.com> In-Reply-To: <ZNZBVf1CuI35PyBf@int21h> References: <ZNOJUfIHGtY9lLpg@int21h> <202308111121.37BBLX0J064263@donotpassgo.dyslexicfish.net> <ZNZBVf1CuI35PyBf@int21h>
next in thread | previous in thread | raw e-mail | index | archive | help
--00000000000026ea2f0602a829c9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Why don=E2=80=99t you just use xargs -P until you=E2=80=99ve exhausted your= CPU capacity? On Fri, Aug 11, 2023 at 10:10 AM void <void@f-m.fm> wrote: > On Fri, Aug 11, 2023 at 12:21:33PM +0100, Jamie Landeg-Jones wrote: > > >rsync just spawns an ssh command, so would probably behave similarly. > > I'm hoping that rsync will spawn many ssh. Need to look at max sessions > on both ends of the connection. > > Since encountering the described problem, the person at the other > end is away for the week so have not been able to test thoroughly. > What I have been able to test shows that there is spiky latency > in the connection, as well as slow speed, single-threaded. > > >Another thing, scp transfers from my test Rpi2 are much slower than the > network > >can handle due to the CPU use, which hits 100% on one cpu whilst it's > running. > >So, check that CPU isn't the bottleneck too. > > Yup. That won't be happening here. Dual xenon with 56 cores at remote > end and same (but with 32 cores) at this end > > >As for the speed, I just tested sftp to transfer a file of random data, = 2 > GB in > >size from one FreeBSD box in London to another in France: > > > >The final result was: > > > > 100% 2000MB 43.5MB/s 00:46 (Note, that's MegaBYTES/s) > > I ran a similar test. > Sending system is on synchronous gigabit fibre on US east coast, > receiving system is near London on 110/21 fibre (so, gigabit in the sendi= ng > direction): > > 100% 2000MB 7.2MB/s 04:36 > > using rsync -azP : 2,097,152,000 100% 6.81MB/s 0:04:53 (xfr#1, > to-chk=3D0/1) > > the speed fluctulates a lot. Both systems are quiet in a network and OS > sense > for the duration of the test. > > >The London box is pretty old, and is a virtual host scheduled to be > decomissioned. > >It is running an old openssl 1.X, openssh 8.8 and is a single core 2.4Gh= z > amd64 box. > > > >The France box is a 4 core bare metal 3.1Ghz and64 running openssh 9.2 > and openssl 1.1.1 > > both ends here are running very recent -current, so ssl/ssh is > OpenSSH_9.3p1, OpenSSL 3.0.9 30 May 2023 > > >Anything more I can tell you that may help? > > Thanks very much for your input. I'm certain it's not a freebsd problem. > > -- > > --00000000000026ea2f0602a829c9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"auto">Why don=E2=80=99t you just use xargs -P until you=E2=80= =99ve exhausted your CPU capacity?</div><div dir=3D"auto"><br></div><div><d= iv class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Fri, Aug = 11, 2023 at 10:10 AM void <<a href=3D"mailto:void@f-m.fm">void@f-m.fm</a= >> wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0= 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Fri, Aug 11, 2023 a= t 12:21:33PM +0100, Jamie Landeg-Jones wrote:<br> <br> >rsync just spawns an ssh command, so would probably behave similarly.<b= r> <br> I'm hoping that rsync will spawn many ssh. Need to look at max sessions= <br> on both ends of the connection.<br> <br> Since encountering the described problem, the person at the other<br> end is away for the week so have not been able to test thoroughly.<br> What I have been able to test shows that there is spiky latency<br> in the connection, as well as slow speed, single-threaded.<br> <br> >Another thing, scp transfers from my test Rpi2 are much slower than the= network<br> >can handle due to the CPU use, which hits 100% on one cpu whilst it'= ;s running.<br> >So, check that CPU isn't the bottleneck too.<br> <br> Yup. That won't be happening here. Dual xenon with 56 cores at remote<b= r> end and same (but with 32 cores) at this end<br> <br> >As for the speed, I just tested sftp to transfer a file of random data,= 2 GB in<br> >size from one FreeBSD box in London to another in France:<br> ><br> >The final result was:<br> ><br> > 100% 2000MB=C2=A0 43.5MB/s=C2=A0 =C2=A000:46=C2=A0 (Note, that's M= egaBYTES/s)<br> <br> I ran a similar test.<br> Sending system is on synchronous gigabit fibre on US east coast,<br> receiving system is near London on 110/21 fibre (so, gigabit in the sending= <br> direction):<br> <br> 100% 2000MB=C2=A0 =C2=A07.2MB/s=C2=A0 =C2=A004:36<br> <br> using rsync -azP : 2,097,152,000 100%=C2=A0 =C2=A0 6.81MB/s=C2=A0 =C2=A0 0:= 04:53 (xfr#1, to-chk=3D0/1)<br> <br> the speed fluctulates a lot. Both systems are quiet in a network and OS sen= se<br> for the duration of the test.<br> <br> >The London box is pretty old, and is a virtual host scheduled to be dec= omissioned.<br> >It is running an old openssl 1.X, openssh 8.8 and is a single core 2.4G= hz amd64 box.<br> ><br> >The France box is a 4 core bare metal 3.1Ghz and64 running openssh 9.2 = and openssl 1.1.1<br> <br> both ends here are running very recent -current, so ssl/ssh is <br> OpenSSH_9.3p1, OpenSSL 3.0.9 30 May 2023<br> <br> >Anything more I can tell you that may help?<br> <br> Thanks very much for your input. I'm certain it's not a freebsd pro= blem.<br> <br> -- <br> <br> </blockquote></div></div> --00000000000026ea2f0602a829c9--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAOzHqcK5DUj0-b%2BP_sqPyC7NknHKaS1_fNcnTWKjde-SYn9QSA>