freebsd-update and speed

[Ferdinand Goldmann]

Hello,

I've noticed that ever since update3.freebsd.org is gone (which was in Czech
republic I think), FreeBSD updates are often quite slow for me (= 
Austria/Europe)
Especially so for major release upgrades. In fact so slow that I have time
to type this mail while waiting for '8778 patches'.

The other day, freebsd-update even suffered a timeout.

What are other European users experiences and is there anything to do about it?

Regards
Ferdinand

smime.p7s
Description: S/MIME Cryptographic Signature

Re: freebsd-update and speed

[Ferdinand Goldmann]

Following up on my own mail:


to type this mail while waiting for '8778 patches'.


Which has ended in:

71107120 done.
Applying patches... done.
Fetching 1965 files... failed.

and after restarting it:

Fetching 1750 patches
[...]
Applying patches... done.
Fetching 326 files...

This does not seem very reassuring to me. :(



The other day, freebsd-update even suffered a timeout.

What are other European users experiences and is there anything to do about 
it?


Regards
Ferdinand


--
Ferdinand Goldmann
System Administrator
Information Management

JOHANNES KEPLER
UNIVERSITY LINZ
Altenberger Straße 69
Hochschulfond Building, HF9902
4040 Linz, Austria
P +43 732 2468 3925
ferdinand.goldm...@jku.at
www.jku.at/im

smime.p7s
Description: S/MIME Cryptographic Signature

Re: freebsd-update and speed

[Matthias Gamsjager]

Yeah it took some time. One machine (Netherlands) took 4 hours to download
the patches, failed multiple times but it finished after all.
today another box was faster but failed one time.

Far from perfect
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: freebsd-update and speed

[Rainer Duffner]

> Am 15.04.2021 um 14:20 schrieb Ferdinand Goldmann :
> 
> Hello,
> 
> I've noticed that ever since update3.freebsd.org is gone (which was in Czech
> republic I think), FreeBSD updates are often quite slow for me (= 
> Austria/Europe)
> Especially so for major release upgrades. In fact so slow that I have time
> to type this mail while waiting for '8778 patches'.
> 
> The other day, freebsd-update even suffered a timeout.
> 
> What are other European users experiences and is there anything to do about 
> it?
> 
> Regards
> Ferdinand


It’s OK-ish most of the time here (CH).

It does *NOT* work through a proxy, due to the use of pipelined http-requests.

What’s your internet-connection?


___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: freebsd-update and speed

[Karl Denninger]

On 4/15/2021 08:28, Ferdinand Goldmann wrote:

Following up on my own mail:


to type this mail while waiting for '8778 patches'.


Which has ended in:

71107120 done.
Applying patches... done.
Fetching 1965 files... failed.

and after restarting it:

Fetching 1750 patches
[...]
Applying patches... done.
Fetching 326 files...

This does not seem very reassuring to me. :(


It already got the others, so it now only has to fetch 326 more.

--
Karl Denninger
k...@denninger.net 
/The Market Ticker/
/[S/MIME encrypted email preferred]/


smime.p7s
Description: S/MIME Cryptographic Signature

Re: Frequent disk I/O stalls while building (poudriere), processes in "zfs tear" state

[Felix Palmen]

After more experimentation, I finally found what's causing these
problems for me on 13:

* Felix Palmen  [20210412 11:44]:
> * Poudriere running on idprio 22 with 8 parallel build jobs

Running poudriere with normal priority works perfectly fine. Now, I've
had poudriere running on idprio because there are several other services
on that machine that shouldn't be slowed down by running a heavy build
and I still want to use all the CPU resources available for building.

Right now, I'm running a test with idprio 0 instead, which still seems
to have the desired effect, and so far, I didn't have any of these
stalls. If this persists, the problem is solved for me!

I'd still be curious about what might be the cause, and, what this state
"zfs tear" actually means. But that's kind of an "academic interest"
now.

-- 
 Dipl.-Inform. Felix Palmen ,.//..
 {web}  http://palmen-it.de  {jabber} [see email]   ,//palmen-it.de
 {pgp public key} http://palmen-it.de/pub.txt   //   """
 {pgp fingerprint} A891 3D55 5F2E 3A74 3965 B997 3EF2 8B0A BC02 DA2A


signature.asc
Description: PGP signature

Re: Frequent disk I/O stalls while building (poudriere), processes in "zfs tear" state

[Dewayne Geraghty]

On 16/04/2021 2:29 am, Felix Palmen wrote:
> After more experimentation, I finally found what's causing these
> problems for me on 13:
> 
> * Felix Palmen  [20210412 11:44]:
>> * Poudriere running on idprio 22 with 8 parallel build jobs
> 
> Running poudriere with normal priority works perfectly fine. Now, I've
> had poudriere running on idprio because there are several other services
> on that machine that shouldn't be slowed down by running a heavy build
> and I still want to use all the CPU resources available for building.
> 
> Right now, I'm running a test with idprio 0 instead, which still seems
> to have the desired effect, and so far, I didn't have any of these
> stalls. If this persists, the problem is solved for me!
> 
> I'd still be curious about what might be the cause, and, what this state
> "zfs tear" actually means. But that's kind of an "academic interest"
> now.
> 

Most likely your other processes are pre-empting your build, which is
what you want :).

Use /usr/bin/top to see the priority of the processes (ie under the  PRI
column).  Using an idprio 22, means (on my 12.2Stable) a PRI of 146.  If
your kern.sched.preempt_thresh is using the default (of 80) then
processes with a PRI of <80 will preempt (for IO).

Even with an idprio 0, the PRI is 124. So I suspect that was more a
matter of timing (ie good luck).

You could increase your pre-emption threshold for the duration of the
build, to include your nice value. But... (not really a good idea).
Better if you run your build using nice (PRI of 76) which should avoid
the stalls, but should also influence your more important services.

Re zfs - sorry, I'm peculiar and don't use it ;)
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Deprecating base system ftpd?

[Chris]

On 2021-04-14 19:28, Andy Farkas wrote:

I think this is an excellent start. My shopping list includes:

- remove ftp(1)
- remove ftpd(8)
- remove telnet(1)
- remove telnetd(8)
- remove ftp:// and http:// from libfetch. This is 2021 and we should all
use https://.
- replace DNS lookups with DoH and/or DoT. Why let your ISP see your DNS
traffic?



I wonder how many people use YP/NIS (man 8 yp)?
It's a nifty concept; I played around with it last century...
I believe there is still an open PR in bugzilla I created (can't find it
right now, used a diffent email address back then, although same
username).

LOL I did the same a year or so ago. I felt much the same as you describe.
But I've since discovered it can be leveraged in ways that it did not
originally intend to do. So I've since decided that given in whole
it's small footprint, along with a proven track record. It has value
enough that it ought to remain.


Removing it from base (if it should be done at all) looks very complicated
and therefore creating a port equally so.

I know this topic (removing ftpd) is closed, so perhaps this should be
a new one (removing YP/NIS)?  ie. no development on yp has been
done for over a decade.

My view: remove neither

I concur. :-)



-andyf

--Chris



___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"