Re: Recommendations for USB Barcode Scanner and Thermal Receipt Printer
+1 for Symbol here. Have used them in factory environments and I can’t recall one ever failing. If buying used, be sure you can get the documentation for it, as these are often configurable (eg. continuous vs. triggered scanning) via scanning special barcodes. John On Sun, Jul 26, 2020 at 07:20 Erling Westenvik wrote: > On Sat, Jul 25, 2020 at 08:47:48PM +0200, Rubén Llorente wrote: > > Anybody in the list has good (or bad) experiences with USB Barcode > > Scanners? Which models with? > > I have a working barcode scanner, Symbol Technologies LS2208, that > shows up in dmesg as: > > uhidev4 at uhub3 port 6 configuration 1 interface 0 "?Symbol > Technologies, Inc, 2002 Symbol Bar Code Scanner" rev 2.00/2.01 addr 4 > uhidev4: iclass 3/1 > ukbd1 at uhidev4: 8 variable keys, 6 key codes, country code 33 > wskbd2 at ukbd1 mux 1 > wskbd2: connecting to wsdisplay0 > > It's an old model, manufactured in 2005, and I can't say that I've used > it extensively, but it seems to work well with at least "normal" > barcodes typically found on groceries, books (ISBN), receipts and so on. > There are barcodes that it cannot read but I have not investigated the > matter. The manufacturer still exists. > > Good luck! > > Erling > >
Build Problem in Unbound
What happened previously: Installed 6.7 Installed firmware Fetched source from 6.7 stable Built everything in syspatch 001-013 Installed everything in syspatch 001-013 Rebooted Built kernel Rebooted In trying to build userland, I encountered the following: ... ===> usr.sbin/trpt ===> usr.sbin/unbound make make: don't know how to make config.h (prerequisite of: dns.lo) Stop in usr.sbin/unbound/obj *** Error 2 in usr.sbin/unbound (Makefile.bsd-wrapper:49 'gnu') *** Error 2 in usr.sbin (:48 'all': @for entry in ac accton acme-client acpidump adduser amd apm apmd arp authpf bgpctl bgpd...) *** Error 2 in /usr/src (:48 'all': @for entry in lib include bin libexec sbin usr.bin usr.sbin share games gnu sys; do set ...) How do I get past this? What did I do wrong? Thanks, Ken
Re: CPU usage of httpd+slowcgi
On 2020-07-24 03:16, Kihaguru Gathura wrote: Hi, Which of the following legacy CPU types is best suited for very busy web server httpd+slowcgi Niagara CPU Such as T2 - More parallel Threads and Low power per single thread Sparc64 CPU such as VI, VII - Fewer threads but more computing power per thread. How is multithreading utilization of httpd+slowcgi like? Kind regards, Kihaguru. Hi Kihaguru, As with any computer, newer tends to be better with Moore's Law and all that. On sparc64 most of the logical cores that are shown are really just SMT pretending to be a bunch of cores. I have one machine that claims 128 cores, but in reality, its just 16 cores with 8-way SMT. sparc64 isn't renowned for its single core execution speed, so the faster the better in that regard. In my experience with running OpenBSD on sparc64, the kernel biglock or crypto became a bottleneck before other things did. (I've used T3 and T4 machines fairly extensively with OpenBSD). I've found that disk activity, networking and/or TLS would bottleneck before httpd became a bottleneck when I was running sparc64 web servers in production. If you are running very heavy scripts/programs with slowcgi, then you're results may be different. Things have likely improved dramatically in the past year or two with all the work done on removing the biglock, but the moral of the story remains, fewer, faster cores are likely to produce superior performance to numerous low power cores. Regards, Jordan
Re: CPU usage of httpd+slowcgi
> Better to look for an M3000 or M4000 or as suggested for a T4-1 M3000 don't work. The firmware locks up very badly.
Re: CPU usage of httpd+slowcgi
On Mon, Jul 27, 2020 at 02:54:25PM +0100, Stuart Henderson wrote: > Replying back on-list, I don't do support-type mails off-list, and other > people know more about sparc64 hardware than me. > > On 2020/07/26 22:38, Kihaguru Gathura wrote: > > Hi Stuart, > > > > For legacy, single-core CPU's such as Sparc64 V. > > Would OpenBSD cope well with more number of CPU's or less as in previous > > case? > > > > Example. > > > > 2 CPU's (primepower 250) -> 4 CPU's (PrimePower 450) -> 8 CPU's(PrimePower > > 650) -> 16 CPU's > > (PrimePower 850) -> 32 CPU's (Primepower 1500) > > It depends on the workload. I'd have thought for most things the max > really usable at the moment is probably somewhere in the region of 4-8 > cpu cores before kernel locking gets in the way too much. > > FWIW sparc64 ports builds are now done on T4 and they're really fast. > I think (but am not 100% sure) that this is carved into ldoms so the > number of cores visible to each OpenBSD instance is limited (so > contention between cores in the kernel is also limited). The primepower 250 are decent and IIRC you can get dual core SPARC64-VI CPUs for those. They use a fair amount of power. The bigger irons are fun but honestly the weight and power consumption is just not worth it. A primepower 250 is compareable with a fast v215. At least that is my experience. Better to look for an M3000 or M4000 or as suggested for a T4-1. Also make sure you get good CPUs in them (esp. the M4000 comes with a few options). -- :wq Claudio
Re: CPU usage of httpd+slowcgi
Replying back on-list, I don't do support-type mails off-list, and other people know more about sparc64 hardware than me. On 2020/07/26 22:38, Kihaguru Gathura wrote: > Hi Stuart, > > For legacy, single-core CPU's such as Sparc64 V. > Would OpenBSD cope well with more number of CPU's or less as in previous case? > > Example. > > 2 CPU's (primepower 250) -> 4 CPU's (PrimePower 450) -> 8 CPU's(PrimePower > 650) -> 16 CPU's > (PrimePower 850) -> 32 CPU's (Primepower 1500) It depends on the workload. I'd have thought for most things the max really usable at the moment is probably somewhere in the region of 4-8 cpu cores before kernel locking gets in the way too much. FWIW sparc64 ports builds are now done on T4 and they're really fast. I think (but am not 100% sure) that this is carved into ldoms so the number of cores visible to each OpenBSD instance is limited (so contention between cores in the kernel is also limited).
