Re: CVS commit: src/sys
At Sat, 28 Mar 2020 10:40:26 +0100, Martin Husemann wrote: > It would be good to have a file somewhere in the audio code where the > default is selected based on some ifdefs - if we don't have anything > better something like: > > #if defined(__m68k__) || defined(__vax__) || \ > (defined(__sparc__) && !defined(_LP64) > > #else > ... 4ms > #endif > > Or create (if we don't have yet) a and define it there. I try it. Thanks, --- Tetsuya Isaki
Re: CVS commit: src/sys
At Sat, 28 Mar 2020 09:34:11 +, nia wrote: > > - 4msec is (probably no problem for most modern real hardware but) > > too aggressive to be default. > > - 10msec is too severe for antique machines but it's hard to draw a line. > > <5ms blk_ms is required by real world applications; see emulators/mednafen. If you found such problem, you should have reported it, rather than changing amd64/conf/GENERIC. I look emulators/mednafen later. By the way, blk_ms is fixed at 50msec in netbsd-7 or prior, and is 50msec default (but uncertain) in netbsd-8. How was it able to run in those days? > I would prefer if blk_ms were kept below 5ms on amd64 and aarch64. > We don't have to worry about the CPU load of playing audio on these platforms. CPU load or performance is not subject. I know that my implementation will work on the most modern real hardware. But I feel that at least 4msec is too rush to be default. A default should not be for one game application. > We also released 9 with blk_ms=4 on these platforms and nobody complained. If you want to say so, you should have discussed before commit. 9.0-RELEASE/amd64 (blk_ms=4) on VirtualBox6 on OSX plays too bad sound. With blk_ms=8, it's almost good but a bit strange. With blk_ms=10, it's fine. At least in my environment. In result, there are two problems. - You claimed that emulators/mednafen requires blk_ms <= 5msec - I reported that VirtualBox6 on OSX requires blk_ms >= 10msec > > - It's not good idea to set such parameter in individual GENERICs. > > It's not a good idea to punish the majority of NetBSD users because m68k > is incredibly slow. As martin pointed out, you seem to misunderstand. I just dropped m68k from majority. Thanks, --- Tetsuya Isaki
Re: CVS commit: src/external/gpl3
On 28.03.2020 05:39, matthew green wrote: >> Date:Sat, 28 Mar 2020 11:46:29 +1100 >> From:matthew green >> Message-ID: <15233.1585356...@splode.eterna.com.au> >> >> | can we just leave this as-is and let netbsd GCC people care? >> >> Only if the GCC people do care, and understand the issue, and >> implement what we want > note i said "netbsd GCC people". i mean me, specifically. The problem is that libiberty is a generic gnu library wrapping software. I landed onto it from GDB. I can see now that P_tmpdir was changed last year to /tmp. OK. So the issue is understood. The problem will solve itself with some time. Meanwhile we could backport it to older branches and report to Darwin people. commit 69f10cfa0cf51ad935e9513474315231717749b0 Author: mrg Date: Fri Dec 13 20:25:16 2019 + move P_tmpdir from "/var/tmp/" to "/tmp/". the main effect of this is to make GCC and other libiberty using tools use /tmp instead of /var/tmp for compiler temp files, which can be a bottleneck on larger systems. a survey of other platforms shows only OSX also uses /var/tmp, everyone else has switched to /tmp long ago. cons: some smaller systems may have a smaller /tmp than /var/tmp, and this may cause builds to fail with out of space earlier. point the build to /var/tmp using TMPDIR in this case. one can argue that setting TMPDIR would work around this, but we want to have the effect for all users without having special setup.
Re: CVS commit: src/external/gpl3
On Sat, Mar 28, 2020 at 03:39:34PM +1100, matthew green wrote: > we want both changes (libiberty, and my stdio.h/P_tmpdir > change.) we want to support old netbsd, non-netbsd, .. > whatever build hosts. Can we have them in 8.2 please? Martin
Re: CVS commit: src/sys
On Sat, Mar 28, 2020 at 09:34:11AM +, nia wrote: > > - It's not good idea to set such parameter in individual GENERICs. > > It's not a good idea to punish the majority of NetBSD users because m68k > is incredibly slow. Both statements are true, and the latter is based on a misunderstanding. It would be good to have a file somewhere in the audio code where the default is selected based on some ifdefs - if we don't have anything better something like: #if defined(__m68k__) || defined(__vax__) || \ (defined(__sparc__) && !defined(_LP64) #else ... 4ms #endif Or create (if we don't have yet) a and define it there. You can make it overridabel in individual kernel config files - but the default should be sane. Martin
Re: CVS commit: src/sys
On Sat, Mar 28, 2020 at 08:35:37AM +, Tetsuya Isaki wrote: > - 4msec is (probably no problem for most modern real hardware but) > too aggressive to be default. > - 10msec is too severe for antique machines but it's hard to draw a line. <5ms blk_ms is required by real world applications; see emulators/mednafen. I would prefer if blk_ms were kept below 5ms on amd64 and aarch64. We don't have to worry about the CPU load of playing audio on these platforms. We also released 9 with blk_ms=4 on these platforms and nobody complained. On Sat, Mar 28, 2020 at 08:35:37AM +, Tetsuya Isaki wrote: > - It's not good idea to set such parameter in individual GENERICs. It's not a good idea to punish the majority of NetBSD users because m68k is incredibly slow.
