Re: rpki-client disk utilization / noting mfs in man?
On Sun, Jul 31, 2022 at 8:35 AM Tobias Fiebig < tob...@reads-this-mailinglist.com> wrote: > > You could periodically rsync it to permanent storage and use mount_mfs' > > -P option to populate at boot. > Really good point; I will give setting that up a try later today and add > that to the > blogpost. > In addition to a scheduled rsync job, don't forget to also put that same rsync command into /etc/rc.shutdown, so that a controlled reboot or shutdown will update persistent storage with the most up-to-date data. The scheduled rsync commands will then just be there to ensure you don't lose too much in case of system lockup or other uncontrolled reboot/powerfail/etc. -ken
Re: Trouble with lpr and Brother wireless printer
Seriously, get a printer that speaks PostScript and PDF. These exist, and are not too expensive. The just say lp::lp=:rm=aa.bb.cc.dd:rp=lp:sd=/var/spool/output/lpd:lf=/var/log/lpd-errs:sh: On Jul 31 13:34:18, grobe...@gmail.com wrote: > I use an HL-L2370DW which only accepts PCL on BINARY_P1. > I think it likely that yours acts the same. You'll have to tell lp to send > the output through a filter, using (iirc) the vf= option in printcap. > This is what i used for a filter: > > #!/bin/sh > gs -sPAPERSIZE=letter -sDEVICE=pxlmono -sOutputFile=- -dBATCH -dNOPAUSE - > > Hope this helps. >
Trouble with lpr and Brother wireless printer
I use an HL-L2370DW which only accepts PCL on BINARY_P1. I think it likely that yours acts the same. You'll have to tell lp to send the output through a filter, using (iirc) the vf= option in printcap. This is what i used for a filter: #!/bin/sh gs -sPAPERSIZE=letter -sDEVICE=pxlmono -sOutputFile=- -dBATCH -dNOPAUSE - Hope this helps.
Re: Trouble with lpr and Brother wireless printer
On Sun, 31 Jul 2022 19:10:08 +0900 John Mettraux wrote: > Brother MFC-L3770CDW wireless here. > > My /etc/printcap goes: > > lp:\ > sd=/var/spool/lpd:lp=:rm=192.168.xxx.xxx:rp=BINARY_P1 > > Maybe it will help. Thanks very much John. I wasn't aware of the BINARY_P1 service option, which I found documented in a Brother Network Users Manual[1] after reading your mail, so thank you for suggesting that. However, trying this was unsuccessful for me, so I'm afraid I'm still stuck. - Ben [1] https://www.brother-usa.com/virdata/content/en-us/printers/consumer/networkusersmanual/num_hl_1270n_en_1310.pdf
Re: xfreerdp and stuttering sound
On Wed, 27 Jul 2022 16:32:59 -0500 Ed Ahlsen-Girard wrote: > I am remoting to a Windows machine to view Widevine encrypted videos, > and need to forward the sound. My xfreerdp line is: > > xfreerdp /h:2560 /w:3712 /d:[hostname] /u:[username] /sound:sys:sndio > \ /v:[hostname] > > I see the video, but the sound stutters badly. Closing other > applications does not improve this, and choosing a different browser > on the remote Windows machine does not improve it. > > dmesg below signature. > Closing out the loop, it appears that FreeRDP only supports multi-media forwarding of Windows Media Player. The rdesktop port is not an alternative: upstream has been un-maintained since November 2019, and its latest version cannot connect to Windows 10 21H2 if fully patched. -- Edward Ahlsen-Girard Ft Walton Beach, FL
Re: rpki-client disk utilization / noting mfs in man?
Heho, > fwiw using a VM for a border router seems a strange choice. Agree. It is called 'doing-stupid-things' for a reason. :-| ;-) 0:-) > Also, having many routers in many networks fetch [...] Yes, and for my own systems I do just that with some added python code around it to make sure what I fetch from the cache makes sense ([1] in case anyone is Interested... still have to fix string handling -.-'); Yet, I cannot really tell people what to do on their own VMs. (Well, I can, but...) ;-) > You could periodically rsync it to permanent storage and use mount_mfs' > -P option to populate at boot. Really good point; I will give setting that up a try later today and add that to the blogpost. > BTW rpki-client is one of the (relatively few) cases where softdep is likely > to give > a significant improvement in performance. Also a good point. I think I will just bench through all the options (softdep, noatime, mfs, [...]) and write that down to have some comparison points. With best regards, Tobias [1] https://git.aperture-labs.org/AS59645/monitoring-tools/src/branch/master/other/update_rpki
Re: rpki-client disk utilization / noting mfs in man?
On 2022-07-31, Tobias Fiebig wrote: > I am running a small setup, where recently the boarder router VMs of a user > caused prolonged and consistent low bandwidth (2-3mb/s) yet high utilization > (many IOPS) disk utilization on the virtualization nodes (more writeup at > [1]). fwiw using a VM for a border router seems a strange choice. Also, having many routers in many networks fetch and validate all these certs, from many origin networks across the world, results in much duplicated work and bandwidth. The RPKI design is that fetch/validation is done by route servers or caches rather than on every individual router. The intention is to use RTR to feed routers but until that is fully handled you could e.g. run a central rpki-client box to generate the prefix list for bgpd and make it available to your own routers over sftp/http/rsync rather than fetching from origins on each router. > I ultimately resorted to giving an mfs on /var/cache/rpki-client a try. This > worked surprisingly well, (naturally) removed all disk i/o usage, and > improved the rpki-client runtime from ~30min to ~16min (CPUs aren't the > freshest, so this is fine, I guess). Of course the trade-off here is a full > sync after every reboot. You could periodically rsync it to permanent storage and use mount_mfs' -P option to populate at boot. BTW rpki-client is one of the (relatively few) cases where softdep is likely to give a significant improvement in performance. -- Please keep replies on the mailing list.
rpki-client disk utilization / noting mfs in man?
Heho, I am running a small setup, where recently the boarder router VMs of a user caused prolonged and consistent low bandwidth (2-3mb/s) yet high utilization (many IOPS) disk utilization on the virtualization nodes (more writeup at [1]). With a bit of digging, we figured out that this was caused by rpki-client, mostly due to the nature of /var/cache/rpki-client being 'lots of small files (~230k), subsequently opened and closed (during validation), with atime probably doing the rest of the hurt. This lead to rpki-client running for ~30-60minutes, sometimes dying due to exceeding 3600 seconds runtime. The problem becoming so pronounced may also relate to the RPKI blow-up due to some recent experiments (currently not finding a fitting link, though; Recall cloudflare suffered with some DB bloat because of that in their validators.). I ultimately resorted to giving an mfs on /var/cache/rpki-client a try. This worked surprisingly well, (naturally) removed all disk i/o usage, and improved the rpki-client runtime from ~30min to ~16min (CPUs aren't the freshest, so this is fine, I guess). Of course the trade-off here is a full sync after every reboot. I recon that this is mostly a fragment of spinning disks being used for storage in the virt environment, but it makes me wonder whether it would not make sense to note that in the man page? Would like to hear some opinions, though, before actually suggesting the change/typing up a fitting section. With best regards, Tobias [1] https://doing-stupid-things.as59645.net/networking/bgp/nsfp/2022/07/31/making-it-ping-part-5.html
Re: Trouble with lpr and Brother wireless printer
On Sat, Jul 30, 2022 at 08:40:59PM -0700, Ben Hancock wrote: > > Here's my /etc/printcap: > > lp|brother:\ > :rm=192.168.xxx.xxx:\ > :rp=brother:\ > :sd=/var/spool/output/lpd:\ > :lf=/var/log/lpd-errs: Hello, Brother MFC-L3770CDW wireless here. My /etc/printcap goes: lp:\ sd=/var/spool/lpd:lp=:rm=192.168.xxx.xxx:rp=BINARY_P1 Maybe it will help. Best regards, John
Re: Firefox and stuttering USB audio
On Sat, Jul 30, 2022 at 02:39:08PM -0700, Courtney wrote: > I hope it isn't in bad etiquette to resurrect an old piece of mail. > OK for me, your mail is attached to the thread. > Since May I mitigated the stuttering audio issue with Firefox running > by using Firefox ESR 91. Clearly something beyond 91 added something > that doesn't jive well with OpenBSD. Now that 91 ESR is gone and it is 102 > the issue has returned. > > I have been playing around with a different issue, but in the process > of messing with that issue I came across something. I ran sndiod in > debug mode with these flags: > > sndiod -dd -f rsnd/0 -F rsnd/1 > > I then went to try out opening tabs in firefox which then triggered > a whole bunch of this getting spat out > > snd1: rec hw xrun, rused = 1440/7680 > snd1: play hw xrun, pused = 6240/7680 > snd1: rec hw xrun, rused = 960/7680 > snd1: play hw xrun, pused = 6720/7680 > snd1: rec hw xrun, rused = 480/7680 > snd1: play hw xrun, pused = 7200/7680 > snd1: rec hw xrun, rused = 960/7680 > snd1: play hw xrun, pused = 6720/7680 > snd1: rec hw xrun, rused = 480/7680 > snd1: play hw xrun, pused = 7200/7680 > snd1: rec hw xrun, rused = 1440/7680 > snd1: play hw xrun, pused = 6240/7680 > snd1: rec hw xrun, rused = 960/7680 > snd1: play hw xrun, pused = 6720/7680 > snd1: rec hw xrun, rused = 480/7680 > snd1: play hw xrun, pused = 7200/7680 > snd1: rec hw xrun, rused = 960/7680 > snd1: play hw xrun, pused = 6720/7680 > snd1: rec hw xrun, rused = 480/7680 > snd1: play hw xrun, pused = 7200/7680 > snd1: rec hw xrun, rused = 1440/7680 > snd1: play hw xrun, pused = 6240/7680 > snd1: rec hw xrun, rused = 960/7680 > snd1: play hw xrun, pused = 6720/7680 > snd1: rec hw xrun, rused = 480/7680 > snd1: play hw xrun, pused = 7200/7680 > snd1: rec hw xrun, rused = 960/7680 > snd1: play hw xrun, pused = 6720/7680 > snd1: rec hw xrun, rused = 480/7680 > snd1: play hw xrun, pused = 7200/7680 > > I'm wondering if someone has more of a clue as to what all > this means. This confirms that sndiod woke up too late, probably because another process is using the CPU. The fraction is the portion of the buffer containing samples. For the play direction, we see that the buffer is not entierly full, but there are enough samples to continue playing smoothly. So these are just warnings, there are no underruns at sndiod level. I'd suggest you quickly check if there are underruns at firefox level: Use "-ddd" sndiod options. Whenever firefox underruns, sndiod will log: firefox0 vol=127,pst=run: xrun, pause cycle Is there a new message every time you hear a glitch? (note that certain programs just stop providing data to sndiod in order to pause, which will flood you with above messages, but it is not a problem)
