Changing $SUBJECT, this was previously
Re: [blfs-support] Network problems with recent kernels (r8169)
but the network problems now appear to be resolved.
Based on what Bruce said, I thought it would be interesting to look
at the timings for untarring firefox-68.3.0 over nfs on my current
systems.
On Sun, Dec 22, 2019 at 01:28:50AM +0000, Ken Moffat via blfs-support wrote:
> On Sat, Dec 21, 2019 at 06:10:22PM -0600, Bruce Dubbs via blfs-support wrote:
> > On 12/21/19 3:29 PM, Ken Moffat via blfs-support wrote:
> > > Anybody else seeing periodic "stalls" in networking with 5.4 kernels
> > > and the r8169 driver ?
> >
> > I can't really say anything about the 5.2 or 5.4 kernels. I'm still on
> > lfs-9.0 on my development system. However, I've always had some speed
> > issues with nfs. If I try to do a tar -xf on the nfs mount, it is very
> > slow. If I try to do an rm -r on a moderate sized directory tree, it is
> > very slow.
> >
>
> I've seen slow untarring over nfs in the past, particularly on my
> haswell (which seems not to have problems with the network in 5.4),
> but it was a while ago and I think it eventually got resolved on one
> of the point releases.
>
[...]
> > What I do is extract the tarball from the nfs location to a local disk and
> > that is quite fast. Writing to a log file on the nfs directory or running a
> > script located there seems to run at an appropriate speed.
> >
> > My thought is that doing a lot of disk operations is slow, but
> > open-read/write-close on a few files like a script or log or tarball works
> > at relatively full speed.
> >
> > -- Bruce
>
> Seems reasonable. My scripts are on nfs, so when a stall happens
> after a fresh start, the 'driver' script gives some initial output
> (e.g. settings for -j in make, CFLAGS), mentions the client script
> it will invoke, then waits some (or many) seconds before reporting
> the directory name (it identifies the type of tarball - not strictly
> necessary nowadays - and then runs tar -tvf | head -n1 to find out
> the directory name). Normally, for most tarballs that only takes a
> second or so because my /sources is on SSD.
>
All my machines now have enough DRAM to untar this firefox version in
/tmp.
And all except the laptop are connected via cheap GB switches - the
laptop uses wifi, obviously that makes this much slower and I would
not use it for development.
I dropped caches on the server and then ran md5sum on this tarball
to preload the cache.
First, the timings for the server itself, it is a bit slow and
obviously the cp doesn't use nfs.
server: Athlon 200ge (Zen1)
---------------------------
DDR4 2400
cp 0.148
tar 22.154
For the nfs client machines, first timings are cp over nfs to /tmp
and then untar, second timings are plain tar -xf from nfs in /tmp.
laptop - Ryzen5 2500u (Raven Ridge, Zen1)
-----------------------------------------
DDR4 probably 2133, wifi
(therefore slow transfers over wifi)
cp 10.770 N/A
tar 1m21.614 59.997
total 1m32.384 59.997
I noted that the desktop was unresponsive during untar over nfs
(initially the mouse pointer was missing, then clicking on 'top'
did nothing until tar had finished).
Haswell i7
----------
DDR3 1600
cp 2.676 N/A
tar 16.909 17.159
total 19.585 17.159
Skylake i3
----------
DDR4 2133
cp 2.661 N/A
tar 18.401 19.277
total 21.062 19.277
Ryzen3 1300X (Zen1)
-------------------
DDR4 2400
cp 4.639 N/A
tar 18.836 20.455
total 23.475 20.455
Ryzen5 3400G (Picasso, Zen+)
----------------------------
DDR4 3000
cp 2.658 N/A
tar 16.901 17.660
total 19.559 17.660
Conclusion: on my hardware, using nfs v3, tar -xf over nfs is
beneficial although the differences are small.
These runs were all one-off, perhaps repeated runs might show
variation. But for a couple of seconds it isn't worth doing that on
the desktops, and the situation on the laptop using wifi looks
pretty conclusive although the lack of responsiveness is sad (I
had a couple of xfce terms, firefox and falkon all open - I suspect
it swapped - if I'm upgrading firefox or qtwebengine I have to close
things down, there is only 6+ GB DRAM because of the built-in
graphics).
ĸen
--
We've all got both light and dark inside of us.
What matters is the part we choose to act on.
-- Sirius Black
--
http://lists.linuxfromscratch.org/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
