Re: time_t
On Mon, Oct 5, 2020 at 12:27 PM Roderick wrote: ... > Back to tar files: there is place for 11 octal digits, that is > only twice the time you can count with 32 bits, in years: > > 2^33/(60*60*24*365.25*2)=136.09930083403047126524 > > Also not too much. Is it not a better solution to begin a new epoch > every 68.05 years? We can do a big celebration at the beginning of > each new epoch. > The pax file format (which is supported by many 'tar' binaries) supports expressing the time as a decimal string with sub-integer part, bounded only by the block size, solving both the field size limit problem and the lack of subsecond resolution. Philip Guenther
Re: time_t
On Mon, 5 Oct 2020, Christian Weisgerber wrote: There's an #ifdef __LP64__ ... Yes. That is not to oversee, but I oversaw it, because I wanted to oversee it. For lazyness I use snprintf to fill the mtime field of a component of a v7 tar file I generate: snprintf([136],12,"%011lo", time(NULL)); This was not a problem in FreeBSD, where I wrote the program. But when I compiled it in OpenBSD, I got an error: time(NULL) is long long, lo is only long. I thought (without thinking too much) that this is because sizes are different, and I saw the included files (without seeing too much) and found a (false) explanation. Back to tar files: there is place for 11 octal digits, that is only twice the time you can count with 32 bits, in years: 2^33/(60*60*24*365.25*2)=136.09930083403047126524 Also not too much. Is it not a better solution to begin a new epoch every 68.05 years? We can do a big celebration at the beginning of each new epoch. Rod.
Re: sysupgrade with latest snapshot: The directory '/home/_sysupgrade/' does not exist.
> ... > > 2. Figure out how to tell sysupgrade the right answers in advance i.e. > > via the auto_upgrade.conf mechanism > > This is fairly easy: > > sysupgrade -s -n > vi /auto_upgrade.conf, edit "Pathname to the sets" > reboot > ... FYI, or for the record, I just tried the above and it worked perfectly. The sysupgrade ran automatically, found the sets, and here I am running: kern.version=OpenBSD 6.8 (GENERIC.MP) #98: Sun Oct 4 18:13:26 MDT 2020 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP There was just this one error towards the end, after the final reboot: > Path to firmware: http://firmware.openbsd.org/firmware/6.8/ > Updating: intel-firmware-20200616v0 vmm-firmware-1.11.0p3 > inteldrm-firmware-20200421 > Checking for available binary patches... > syspatch: Error retrieving > https://ftp.halifax.rwth-aachen.de/pub/OpenBSD/syspatch/6.8/amd64/SHA256.sig: > 404 Not Found And that is correct, there is no 6.8 directory under "syspatch". Did I pick a bad week to give up smoking (airplane :)) and just happen to hit the switch from Beta to Release? Or have I screwed up something else? A subsequent "pkg_add -vu" fails with a similar error: "pub/OpenBSD/6.8/packages/amd64/: no such dir" Night all & thanks again! Robb.
cmake does not use -O2 for Release builds
It looks like OpenBSD's cmake port patches cmake to remove the use of
-O2 in Release and RelWithDebInfo builds -
/usr/ports/devel/cmake/patches/patch-Modules_Compiler_GNU_cmake has:
- string(APPEND CMAKE_${lang}_FLAGS_MINSIZEREL_INIT " -Os -DNDEBUG")
- string(APPEND CMAKE_${lang}_FLAGS_RELEASE_INIT " -O3 -DNDEBUG")
- string(APPEND CMAKE_${lang}_FLAGS_RELWITHDEBINFO_INIT " -O2 -g -DNDEBUG")
+ string(APPEND CMAKE_${lang}_FLAGS_MINSIZEREL_INIT " -DNDEBUG")
+ string(APPEND CMAKE_${lang}_FLAGS_RELEASE_INIT " -DNDEBUG")
+ string(APPEND CMAKE_${lang}_FLAGS_RELWITHDEBINFO_INIT " -g -DNDEBUG")
Does anyone know why things are patched in this way?
[I think one can force optimisation with (for example):
cmake -DCMAKE_CXX_FLAGS_RELWITHDEBINFO="-O2 -g -DNDEBUG" ...
]
Thanks,
- Jules
--
http://op59.net
Re: time_t
On 2020-10-05, Roderick wrote: > The source of my confusion with FreeBSD: > /usr/include/x86/_types.h contains: >typedef __int32_t __time_t; >typedef int __int32_t; $ fgrep time_t /usr/include/x86/_types.h typedef __int64_t __time_t; /* time()... */ typedef __int32_t __time_t; There's an #ifdef __LP64__ ... -- Christian "naddy" Weisgerber na...@mips.inka.de
Re: time_t
On 2020-10-05, "Peter N. M. Hansteen" wrote: > I hadn't looked in a while, but it amazes me that FreeBSD still has > 32-bit time_t. Only on FreeBSD/i386. On all other architectures, time_t is int64_t. See src/sys/*/include/_types.h. -- Christian "naddy" Weisgerber na...@mips.inka.de
Re: time_t
The source of my confusion with FreeBSD:
/usr/include/time.h contains: typedef __time_t time_t; and includes
/usr/include/sys/types.h includes
/usr/include/machine/_types.h includes
/usr/include/x86/_types.h contains:
typedef __int32_t __time_t;
typedef int __int32_t;
Of course I am doing something wrong. Perhaps there is a definition
that makes the difference. I write only small programs I need,
no macros, and copy the necessary includes from the man pages, no
nested includes ad nauseam.
Rodrigo
On Mon, 5 Oct 2020, Roderick wrote:
Thanks anybody for the instructive answers!
On Mon, 5 Oct 2020, Todd C. Miller wrote:
> Are you sure about that? FreeBSD declares __time_t to be __int64_t
> on amd64. On FreeBSD/amd64 __int64_t is defined as a long.
You are right. My error. I just run:
#include
#include
int main() {printf("%ld\n",sizeof(time_t));}
And got: 8.
That is easier than navigating on the include files.
Rodrigo
Re: time_t
Thanks anybody for the instructive answers!
On Mon, 5 Oct 2020, Todd C. Miller wrote:
Are you sure about that? FreeBSD declares __time_t to be __int64_t
on amd64. On FreeBSD/amd64 __int64_t is defined as a long.
You are right. My error. I just run:
#include
#include
int main() {printf("%ld\n",sizeof(time_t));}
And got: 8.
That is easier than navigating on the include files.
Rodrigo
Re: time_t
Hi Peter, Peter J. Philipp wrote on Mon, Oct 05, 2020 at 05:47:59PM +0200: > When time_t was made, I think, positive integers meant time forwards, and > negative integers meant time backwards from epoch so that people born in > 1938 for example could be processed. https://man.openbsd.org/time.3#HISTORY A time() system call first appeared in Version 1 AT UNIX and used to return time in sixtieths of a second in 32 bits, which was to guarantee a crisis every 2.26 years. Since Version 6 AT UNIX, time() scale was changed to seconds, extending the pre-crisis stagnation period up to a total of 68 years. Yours, Ingo
Re: time_t
On Mon, Oct 05, 2020 at 03:16:24PM +, Roderick wrote: > > The result of time() has type time_t and we know what kind of number > goes there: seconds since 0 hours, 0 minutes, 0 seconds, January 1, > 1970, Coordinated Universal Time. > > In my FreeBSD running on a 64 bit processor this type is: int (__32_t). > It considers this size enough for above information. > > In my OpenBSD running on a 32 bit processor this type is: long long > (__64_t). > > None of both has an unsigned type, although time moves forward > (more or less fast!!!). > > Is there a reason for this discrepancy? Is there no standard for the > size of time_t? > > And what does mean the types with __? I find it so confusing. :) > > Rod. > Hi Rod, I don't know for sure but I believe in BSD most system internal variables start with __, they are not meant to be used by the programmer. When time_t was made, I think, positive integers meant time forwards, and negative integers meant time backwards from epoch so that people born in 1938 for example could be processed. There is a song on the openbsd site that "please don't let my time be time32_t" for a time machine because the singer also didn't want to end up in 1912 or so. Which is what 32 bit time_t rolls over to sometime in January 2038(?). On a 32 bit time_t one second past timestamp 2147483647 will wrap it into the negative because it is not unsigned and the 32nd bit in a 32 bit signed integer indicates negative afaik. kite$ dc 2o 2147483648 p 1000 2147483647 p 111 Regards, -peter
Re: time_t
The universe didn't start in 1970 On Monday, October 5, 2020, Roderick wrote: > > The result of time() has type time_t and we know what kind of number > goes there: seconds since 0 hours, 0 minutes, 0 seconds, January 1, > 1970, Coordinated Universal Time. > > In my FreeBSD running on a 64 bit processor this type is: int (__32_t). > It considers this size enough for above information. > > In my OpenBSD running on a 32 bit processor this type is: long long > (__64_t). > > None of both has an unsigned type, although time moves forward > (more or less fast!!!). > > Is there a reason for this discrepancy? Is there no standard for the > size of time_t? > > And what does mean the types with __? I find it so confusing. :) > > Rod. > > --
Re: time_t
Hi Rodrick, Roderick wrote on Mon, Oct 05, 2020 at 03:16:24PM +: > The result of time() has type time_t and we know what kind of number > goes there: seconds since 0 hours, 0 minutes, 0 seconds, January 1, > 1970, Coordinated Universal Time. > > In my FreeBSD running on a 64 bit processor this type is: int (__32_t). > It considers this size enough for above information. http://www.openbsd.org/lyrics.html#55 > In my OpenBSD running on a 32 bit processor this type is: long long > (__64_t). > > None of both has an unsigned type, although time moves forward > (more or less fast!!!). https://man.openbsd.org/mktime.3#RETURN_VALUES https://man.openbsd.org/time.3#RETURN_VALUES > Is there a reason for this discrepancy? Is there no standard for the > size of time_t? https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/sys_types.h.html only says: time_t shall be an integer type. > And what does mean the types with __? I find it so confusing. :) Names starting with double underscores are reserved by the C standard, for example paragraphs 3.8.8 and 4.1.2 in C89, so an implementation of the C language can use them internally without risking conflicts with identifiers defined by conforming application programs. Yours, Ingo
Re: time_t
On Mon, 05 Oct 2020 15:16:24 -, Roderick wrote: > The result of time() has type time_t and we know what kind of number > goes there: seconds since 0 hours, 0 minutes, 0 seconds, January 1, > 1970, Coordinated Universal Time. 32-bit time_t rolls over at 03:14:07 on Tuesday, 19 January 2038. > In my FreeBSD running on a 64 bit processor this type is: int (__32_t). > It considers this size enough for above information. Are you sure about that? FreeBSD declares __time_t to be __int64_t on amd64. On FreeBSD/amd64 __int64_t is defined as a long. > In my OpenBSD running on a 32 bit processor this type is: long long > (__64_t). Correct. OpenBSD uses long long for int64_t on all architectures for consistency. Other OSes use long for int64_t on 64-bit systems. > None of both has an unsigned type, although time moves forward > (more or less fast!!!). time_t must be signed in order to represent times in the past. > Is there a reason for this discrepancy? Is there no standard for the > size of time_t? The POSIX standard does not really specify the size of time_t. Most (all?) 64-bit system use a 64-bit time_t. Some 32-bit systems use a 64-bit time_t too, in order to support times after 2038. OpenBSD is one of them. > And what does mean the types with __? I find it so confusing. :) It is to avoid namespace pollution. The underlying types need to be visible to other header files but unless you pull in the specific header file they are not visible in the main namespace. You can't really print a time_t via printf(3) without a cast. On OpenBSD we generally print it with %lld and cast the argument to long long. - todd
Re: time_t
On Mon, Oct 05, 2020 at 03:16:24PM +, Roderick wrote: > > The result of time() has type time_t and we know what kind of number > goes there: seconds since 0 hours, 0 minutes, 0 seconds, January 1, > 1970, Coordinated Universal Time. > > In my FreeBSD running on a 64 bit processor this type is: int (__32_t). > It considers this size enough for above information. > > In my OpenBSD running on a 32 bit processor this type is: long long > (__64_t). I hadn't looked in a while, but it amazes me that FreeBSD still has 32-bit time_t. > None of both has an unsigned type, although time moves forward > (more or less fast!!!). for precisely that reason, OpenBSD had completed the switch to 64-bit time_t by OpenSBD 5.5. Slides for Theo's 2013 keynote about that can be found here: http://www.openbsd.org/papers/eurobsdcon_2013_time_t/ (and I would not be terribly surprised to find that video exists out there somewhere too) - P -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/ "Remember to set the evil bit on all malicious network traffic" delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.
Re: time_t
On Mon, Oct 05, 2020 at 03:16:24PM +, Roderick wrote:
>
> The result of time() has type time_t and we know what kind of number
> goes there: seconds since 0 hours, 0 minutes, 0 seconds, January 1,
> 1970, Coordinated Universal Time.
>
> In my FreeBSD running on a 64 bit processor this type is: int (__32_t).
> It considers this size enough for above information.
>
> In my OpenBSD running on a 32 bit processor this type is: long long
> (__64_t).
>
> None of both has an unsigned type, although time moves forward
> (more or less fast!!!).
I don't know if these are the real reasons, but I can think of two ways
having a signed type helps:
(a) Sometimes, you might want to represent times before 1970. Not in the
return value of time(), of course, but maybe in other places your
program is reasoning about times.
(a) Working with unsigned types can be error-prone. For example,
consider:
if (deadline - time() < TIME_NEEDED) {
printf("There's not enough time left.\n");
}
You probably want the condition to be triggered even when
time() > deadline, but that's not what the above code would do if
they were unsigned. There are probably more compelling examples
where it's even more obvious unsigned ints will not do what you
probably wanted, but that's what came to me on the spot. In any
case, my previous employer's (C++) style guide strongly discouraged
use of unsigned integer types for this reason.
--
James
time_t
The result of time() has type time_t and we know what kind of number goes there: seconds since 0 hours, 0 minutes, 0 seconds, January 1, 1970, Coordinated Universal Time. In my FreeBSD running on a 64 bit processor this type is: int (__32_t). It considers this size enough for above information. In my OpenBSD running on a 32 bit processor this type is: long long (__64_t). None of both has an unsigned type, although time moves forward (more or less fast!!!). Is there a reason for this discrepancy? Is there no standard for the size of time_t? And what does mean the types with __? I find it so confusing. :) Rod.
Re: Understanding download speed reduction by introducing an inline Ubiquity ERL device
On Mon, Oct 5, 2020 at 1:08 AM Stuart Henderson wrote: > > On 2020-10-04, Amarendra Godbole wrote: > > 1. config #1: MacBook - Linksys WRT1200AC - xfinity cable modem > > (speed: ~210 Mbits/s down, 6 Mbits/s up) > > 2. config #2: MacBook - Linksys WRT1200AC - Ubiquiti ERL - xfinity > > cable modem (speed: ~90 MBits down, 6 Mbits/s up) > > 3. config #3 (Line speed): MacBook wired to cable modem (~230 Mbits/s > > down, ~8 Mbits/s up). > > > cnmac0 1600a8:28:dc:cc:2e:6f 56088774 0 22283491 2688 > > 0 > > cnmac1 160078:8a:20:46:a8:c1 23646497 4 5656985348 > > 0 > > cnmac2 160078:8a:20:46:a8:c214823 0 226198 226198 > >0 > > bridge0 1500 23187238 0 57022219 0 > > 0 > > Since "netlivelocks" is increasing, network performance will be impacted. [...] Based on several misc@ threads that's what I thought. > Is it any better if you don't use bridge/vether, just use the cnmac interface > directly? I will try, and if you are referring to the MTU difference - that was me messing around with stuff without understanding it. It did not help, so I have reset everything back to 1500, and there is no change in downlolad speed. NameMtu Network Address Ipkts IfailOpkts Ofail Colls lo0 32768 224 0 224 0 0 lo0 32768 localhost/1 localhost 224 0 224 0 0 lo0 32768 fe80::%lo0/ fe80::1%lo0224 0 224 0 0 lo0 32768 127/8 localhost 224 0 224 0 0 cnmac0 1500a8:28:dc:cc:2e:6f 63352305 0 24938774 2688 0 cnmac0 1500 73.231.60/2 c-73-231-60-128.h 63352305 0 24938774 2688 0 cnmac1 150078:8a:20:46:a8:c1 26482574 4 6383709548 0 cnmac2 150078:8a:20:46:a8:c218483 0 273496 273496 0 enc0* 00 00 0 0 bridge0 1500 25929477 0 64384056 0 0 vether0 1500fe:e1:ba:d0:c8:a9 25770496 0 64110529 0 0 vether0 1500 192.168.10/ 192.168.10.1 25770496 0 64110529 0 0 pflog0 331360 031965 0 0 > Is it any better with a snapshot? (at present these haven't gone past > 6.8 yet so you can still upgrade easily from there to release - just check > to make sure it says "6.8" not "6.8-current" in the version number) [...] Will try with snapshot as well and report back later this week. Thanks for your help. -Amarendra
Re: Nextcloud large file downloads fail (httpd, postgresql, php7.3)
I don't know if it can be related to https://marc.info/?l=openbsd-bugs=158755394912063=2 In my case I had to (sadly) switch to nginx, as a fix for httpd is required and I am not familiar with its code to start working on it.
Re: Understanding download speed reduction by introducing an inline Ubiquity ERL device
On 2020-10-04, Amarendra Godbole wrote: > 1. config #1: MacBook - Linksys WRT1200AC - xfinity cable modem > (speed: ~210 Mbits/s down, 6 Mbits/s up) > 2. config #2: MacBook - Linksys WRT1200AC - Ubiquiti ERL - xfinity > cable modem (speed: ~90 MBits down, 6 Mbits/s up) > 3. config #3 (Line speed): MacBook wired to cable modem (~230 Mbits/s > down, ~8 Mbits/s up). > cnmac0 1600a8:28:dc:cc:2e:6f 56088774 0 22283491 2688 > 0 > cnmac1 160078:8a:20:46:a8:c1 23646497 4 5656985348 > 0 > cnmac2 160078:8a:20:46:a8:c214823 0 226198 226198 > 0 > bridge0 1500 23187238 0 57022219 0 > 0 Since "netlivelocks" is increasing, network performance will be impacted. Is it any better if you don't use bridge/vether, just use the cnmac interface directly? Is it any better with a snapshot? (at present these haven't gone past 6.8 yet so you can still upgrade easily from there to release - just check to make sure it says "6.8" not "6.8-current" in the version number)
Re: Understanding download speed reduction by introducing an inline Ubiquity ERL device
Hello, Scott Seekamp : > I had a similar speed drop on an Edge Router 4. I don?t know if it?s the same > situation on the Lite, but I believe it?s expected due to hardware > acceleration support (or lack of) and single core performance on the pf side. The last time I logged on an ubiquiti switch (not a router) on SSH, I was wondering why there was no bridge/switch interface showing up on the interface list. It looks like there is an userland process controlling the switching, probably communicating to a dedicated chip, maybe a dedicated ASIC. As far as I remember, an strace on it did show some ioctl() to some custom /dev/... device. So it looks like a comparison between hardware accelerated routing vs in-kernel routing off the CPU. -- Josuah
