I have Red Hat Enterprise Linux 4.
I was just reading up about UTC and leap seconds.
Is it true on my system that the Unix time may skip up or down by one second
at midnight when there is a leap second?
By "Unix time" I mean the integer returned by time() and similar functions.
I'm concerned about the "down" case. Some of the software I've written
assumes monotonically-increasing time.
Thanks.
--
David T. Ashley (dt*@e3ft.com) http://www.e3ft.com (Consulting Home Page) http://www.dtashley.com (Personal Home Page) http://gpl.e3ft.com (GPL Publications and Projects) 37  4633 
On Sat, 23 Jun 2007 01:04:46 -0400 David T. Ashley said
Is it true on my system that the Unix time may skip up or down by one second
at midnight when there is a leap second?
By "Unix time" I mean the integer returned by time() and similar functions.
I'm concerned about the "down" case. Some of the software I've written
assumes monotonically-increasing time.
I don't think you have to worry.
(1) NIST says "Based on what we know about the earth's rotation, it seems
unlikely that we will ever have a negative leap second."
<http://tf.nist.gov/general/leaps.htm#Anchor-52904>
(2) If it did happen, the time would repeat, not go backwards.
Sig
-- http://koiclubsandiego.org/comment/?r=8
9b9a436ac9285567ef58d7d6a4dbb750
David T. Ashley wrote:
I have Red Hat Enterprise Linux 4.
I was just reading up about UTC and leap seconds.
Is it true on my system that the Unix time may skip up or down by one second
at midnight when there is a leap second?
By "Unix time" I mean the integer returned by time() and similar functions.
I'm concerned about the "down" case. Some of the software I've written
assumes monotonically-increasing time.
Daylight saving (though how calling one time another saves daylight - there
will be exactly the same amount of daylight in the day regardless of what
you call the hours - I'm still trying to work out) are specified in a config
file (mefinx) and rarely change. Leap seconds I'm not so sure about - they
seem to be added semi-randomly (as and when the extremely constant and
accurate (for some definition of accurate) atomic clocks' day gets behind of
the slowing down earth rotation day).
Leap seconds will then mean that your clock is 1 second fast.
Personally I think you've probably got more concern from using a time server
to sync your computer's clock - the clock in this PC, for example, gains
quite a bit and so resyncing it adjusts it downward every time.
If you've got software that assumes monotonically increasing time, I'd
recommend you get a PC with a clock that loses time (ie it ticks at 1.00001
secs, as opposed to the 0.99999 secs of this PC) so that when re-syncing
your clock it will always adjust upwards. Besides, on a GHz processor,
seconds are rather a coarse measure anyway.
David T. Ashley wrote:
I have Red Hat Enterprise Linux 4.
I was just reading up about UTC and leap seconds.
Is it true on my system that the Unix time may skip up or down by one second
at midnight when there is a leap second?
By "Unix time" I mean the integer returned by time() and similar functions.
I'm concerned about the "down" case. Some of the software I've written
assumes monotonically-increasing time.
Thanks.
Bad programming. What happens, for instance, if the clock on your
server is "corrected" back five seconds (possibly because it's running
fast)?
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp. js*******@attglobal.net
==================
On Sat, 23 Jun 2007 07:28:18 -0400, Jerry Stuckle <js*******@attglobal.net>
wrote:
>Bad programming. What happens, for instance, if the clock on your
server is "corrected" back five seconds (possibly because it's running
fast)?
Well, that in turn would be bad server administration, since NTP tries to do
this by slowing the clock to maintain monotonic time - you have to be off by
minutes before it resorts to going backwards (and even then there's an option
to prevent it).
--
Andy Hassall :: an**@andyh.co.uk :: http://www.andyh.co.uk http://www.andyhsoftware.co.uk/space :: disk and FTP usage analysis tool
"Sig" <iv*****@example.comwrote in message
news:MPG.20e65d5b8466b279989681@islay...
On Sat, 23 Jun 2007 01:04:46 -0400 David T. Ashley said
>Is it true on my system that the Unix time may skip up or down by one
second
at midnight when there is a leap second?
By "Unix time" I mean the integer returned by time() and similar
functions.
I'm concerned about the "down" case. Some of the software I've written
assumes monotonically-increasing time.
I don't think you have to worry.
(1) NIST says "Based on what we know about the earth's rotation, it seems
unlikely that we will ever have a negative leap second."
<http://tf.nist.gov/general/leaps.htm#Anchor-52904>
(2) If it did happen, the time would repeat, not go backwards.
If I'm understanding your comment correctly, and if I'm not mixed up myself,
I believe you have the sign wrong in the way you're thinking about leap
seconds. An ordinary (positive) leap second is where you insert an extra
second and "time stands still" for a second (this is akin to February 29).
I believe these will get more frequent as the earth's rotation is slowing
down.
An ordinary leap second ("time stands still") actually in effect gives the
earth's rotation time to "catch up" to the kept time.
A negative leap second would result in the Unix time skipping a second
(jumping forward).
Of course, "time standing still" can't happen on a computer system, so you
have to re-use a Unix time value (i.e. Unix time goes backwards).
So, I believe but am not sure that due to a sign mixup, the case that you
have presented as impossible is actually the normal and expected case.
According to the entry on Wikipedia, http://en.wikipedia.org/wiki/Unix_time
Unix time will re-use certain integers when a leap second occurs. That
surprised me, but it may very well be true.
My application is generating unique identifiers in PHP (as part of web
database scripts). The current scheme I use is:
a)Concatenate the integer seconds time, the microtime, and the process PID,
and then
b)Spin lock or micro_sleep() until the microtime changes.
The identifiers generated should be unique because no two processes can have
the same PID at the same time.
I think the workaround I'll use (because leap seconds are handled at
midnight UTC) is that if I get an integer seconds time that is too close to
a midnight (i.e. mod 86400 is <=1 or >=86398), then I'll just sleep until it
gets out of that range. That leaves approximately 4 seconds near midnight
UTC where a web page load may hang for up to 4 seconds. That seems very
tolerable, because the window is so narrow and because the web page will
eventually load.
Anyone want to throw rocks at me and tell me I'm crazy?
Thanks for all input.
Dave.
--
David T. Ashley (dt*@e3ft.com) http://www.e3ft.com (Consulting Home Page) http://www.dtashley.com (Personal Home Page) http://gpl.e3ft.com (GPL Publications and Projects)
Robert Newson wrote:
though how calling one time another saves daylight -
there will be exactly the same amount of daylight in the day regardless
of what you call the hours - I'm still trying to work out
.... tedious rhetoric ...
David T. Ashley wrote:
I'm concerned about the "down" case. Some of the software I've written
assumes monotonically-increasing time.
If you're concerned then bullet proof your code in case it does happen.
On Sat, 23 Jun 2007, in the Usenet newsgroup comp.os.linux, in article
<09******************************@giganews.com>, David T. Ashley wrote:
>I have Red Hat Enterprise Linux 4.
I was just reading up about UTC and leap seconds.
You'll want to look at
-rw-rw-r-- 1 gferg ldp 43295 Nov 18 2005 TimePrecision-HOWTO
TimePrecision-HOWTO, Managing Accurate Date and Time HOWTO
Updated: Nov 2005. Explains the time mechanisms on Linux, what are
time zones, and precision with NTP.
>Is it true on my system that the Unix time may skip up or down by one
second at midnight when there is a leap second?
No. Your system time will wander along as usual. If you have installed
and configured an NTP _client_ application, your time will _SLEW_ to
make up for the one second error. See the several RFCs that relate to
Network Time, such as
1305 Network Time Protocol (Version 3) Specification, Implementation
and Analysis. D. Mills. March 1992. (Format: TXT=307085, PDF=442493
bytes) (Obsoletes RFC0958, RFC1059, RFC1119) (Status: DRAFT STANDARD)
4330 Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and
OSI. D. Mills. January 2006. (Format: TXT=67930 bytes) (Obsoletes
RFC2030, RFC1769) (Status: INFORMATIONAL)
as well as the documentation for your NTP client.
>By "Unix time" I mean the integer returned by time() and similar functions.
time(2) returns seconds since the UNIX epoch. Note that NTP time is
using a different epoch (1/1/1900), but an NTP timestamp really a
truncated NTP date expressed as an unsigned 64-bit integer including the
low order 32 bits of the seconds field concatenated with the high-order
32 bits of the fraction field. This format can represent the 136 years
from 1900 to 2036 with a precision of 232 picoseconds. Ranges beyond
these years require an era number which is the high order 32 bits of the
seconds field of the associated date. Your NTP client corrects for the
difference in epochs when tweaking the time. See http://www.cis.udel.edu/~mills/y2k.html for more details.
>I'm concerned about the "down" case. Some of the software I've written
assumes monotonically-increasing time.
So does Professor Mills, who has been in this racket for a "few" years.
If you are interested, you may wish to review recent posts in the Usenet
newgroup 'comp.protocols.time.ntp' which is carried on this news server.
Obviously you aren't concerned with Daylight Saving Time, which has
nothing to do with time(2), or the timestep that occurs when your
system is booting (before client applications start).
Old guy
On Sat, 23 Jun 2007, in the Usenet newsgroup comp.os.linux, in article
<46**************@bullet3.fsnet.oc.ku>, Robert Newson wrote:
>David T. Ashley wrote:
>I was just reading up about UTC and leap seconds.
>By "Unix time" I mean the integer returned by time() and similar
functions.
[compton ~]$ whatis time
time (2) - get time in seconds
[compton ~]$
>Daylight saving (though how calling one time another saves daylight -
there will be exactly the same amount of daylight in the day regardless
of what you call the hours - I'm still trying to work out) are
specified in a configfile (mefinx) and rarely change.
Neither UTC or 'time(2)' know anything about Daylight Saving Time
>Leap seconds I'm not so sure about - they seem to be added semi-randomly
(as and when the extremely constant and accurate (for some definition of
accurate) atomic clocks' day gets behind of the slowing down earth
rotation day).
From the 'leapsecond' file in the timezone source file tzdata2007f.tar.gz
available from ftp://elsie.nci.nih.gov/pub/
# YEAR MONTH DAY HH:MM:SS CORR YEAR MONTH DAY HH:MM:SS CORR
1972 Jun 30 23:59:60 + 1972 Dec 31 23:59:60 +
1973 Dec 31 23:59:60 + 1974 Dec 31 23:59:60 +
1975 Dec 31 23:59:60 + 1976 Dec 31 23:59:60 +
1977 Dec 31 23:59:60 + 1978 Dec 31 23:59:60 +
1979 Dec 31 23:59:60 + 1981 Jun 30 23:59:60 +
1982 Jun 30 23:59:60 + 1983 Jun 30 23:59:60 +
1985 Jun 30 23:59:60 + 1987 Dec 31 23:59:60 +
1989 Dec 31 23:59:60 + 1990 Dec 31 23:59:60 +
1992 Jun 30 23:59:60 + 1993 Jun 30 23:59:60 +
1994 Jun 30 23:59:60 + 1995 Dec 31 23:59:60 +
1997 Jun 30 23:59:60 + 1998 Dec 31 23:59:60 +
2005 Dec 31 23:59:60 +
Relatively random, no?
>Personally I think you've probably got more concern from using a time server
to sync your computer's clock - the clock in this PC, for example, gains
quite a bit and so resyncing it adjusts it downward every time.
You seem to be posting from a Linux box - see the TimePrecision-HOWTO
which should be on your system (or get it from the LDP).
>If you've got software that assumes monotonically increasing time, I'd
recommend you get a PC with a clock that loses time (ie it ticks at 1.00001
secs, as opposed to the 0.99999 secs of this PC) so that when re-syncing
your clock it will always adjust upwards.
You really want to look at the NTP client documentation, or even
[compton ~]$ whatis adjtimex
adjtimex (2) - tune kernel clock
adjtimex (8) - display or set the kernel time variables
[compton ~]$
>Besides, on a GHz processor, seconds are rather a coarse measure anyway.
as well as how "time" is measured - it has nothing to do with the CPU
clock frequency. "INT0" (cat /proc/interrupts) is generated by a
separate (equally crappy) oscillator.
Old guy
Andy Hassall wrote:
On Sat, 23 Jun 2007 07:28:18 -0400, Jerry Stuckle <js*******@attglobal.net>
wrote:
>Bad programming. What happens, for instance, if the clock on your
server is "corrected" back five seconds (possibly because it's running
fast)?
Well, that in turn would be bad server administration, since NTP tries to do
this by slowing the clock to maintain monotonic time - you have to be off by
minutes before it resorts to going backwards (and even then there's an option
to prevent it).
No, not at all.
First of all, servers do not have clocks with the accuracy of 1 second
in 10M years.
So they have to be adjusted. And even though NTP tries to speed up and
slow the clock - it's not perfect. And at times the clock WILL jump
forwards or backwards at least one second.
Of course, you are assuming:
1) they are running Linux or another Unix variant,
2) NTP server the system is using to set the clock is accurate (not
necessarily the case - most are (at least) second or third tier servers,
3) the network delay between the system and the NTP server is constant
and measurable...
4) The hardware allows the adjustment,
5) The adjustment is within the limits allows (typically 512 ppm, but
this can vary)...
I could continue. The point is - you can't pawn this off on the
administrator. There are a lot of things out of his control.
And programming such that you require the clock to continue incrementing
is a recipe for problems later. No there have not be3en any "unleap
seconds" yet. But that doesn't mean there can't be.
And while I agree with the astronomers that there is no reason for a
negative leap-second, programmers need to be aware it can happen!
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp. js*******@attglobal.net
==================
Jerry Stuckle wrote:
....
And while I agree with the astronomers that there is no reason for a
negative leap-second, programmers need to be aware it can happen!
Shirley the correction for a negative leap-seacond would be to put the clock
/forward/ 1 second? ie /increase/ the time?[1]
The only thing is: does the time() clock actually adjust for leap seconds?
Leap days (and DLS) are "fixed" in the conversion to localtime; would leap
seconds be "fixed" at the same time?
[1] Consider that what leap days do is cause the day to be fast if you don't
correct; the "correction" causes 1 Mar becomes 29 Feb, 2 Mar becomes 1 Mar,
etc - the "correction" is to take the clock /backward/ by 86,400[2] seconds
by inserting an extra 86,400 seconds. Similarly leap-seconds: they insert a
second to take the clock backwards: the [physical] day is 86,401[2] seconds
long (24:00:01); a negative leap-second would require the day to be
86,399[2] seconds long (23:59:59) - the only way this could shirley occur is
if the earth's rotation /speeded up/...or the timekeepers (atomic clocks?)
slowed down[3]?
[2] Rounded to the nearest second.
[3] Or an error was made in adding a leap second in the first place?
Or have I totally misunderstood what leap seconds (and days) do?
Robert Newson wrote:
Jerry Stuckle wrote:
...
>And while I agree with the astronomers that there is no reason for a
negative leap-second, programmers need to be aware it can happen!
Shirley the correction for a negative leap-seacond would be to put the
clock /forward/ 1 second? ie /increase/ the time?[1]
Don't call me Shirley! :-)
In the case of a leap second, yes. But you took my statement out of
context. Leap seconds are not the only reason computer clocks may need
adjustment, and sometimes that adjustment may be backwards.
The only thing is: does the time() clock actually adjust for leap
seconds? Leap days (and DLS) are "fixed" in the conversion to localtime;
would leap seconds be "fixed" at the same time?
I don't know, but I would hope so. The problem is that leap seconds are
not fixed. They are added when necessary.
[1] Consider that what leap days do is cause the day to be fast if you
don't correct; the "correction" causes 1 Mar becomes 29 Feb, 2 Mar
becomes 1 Mar, etc - the "correction" is to take the clock /backward/ by
86,400[2] seconds by inserting an extra 86,400 seconds. Similarly
leap-seconds: they insert a second to take the clock backwards: the
[physical] day is 86,401[2] seconds long (24:00:01); a negative
leap-second would require the day to be 86,399[2] seconds long
(23:59:59) - the only way this could shirley occur is if the earth's
rotation /speeded up/...or the timekeepers (atomic clocks?) slowed down[3]?
[2] Rounded to the nearest second.
[3] Or an error was made in adding a leap second in the first place?
Or have I totally misunderstood what leap seconds (and days) do?
In the case of leap seconds. But read the rest of my message.
Also, leap seconds are added because the earth's rotation is slowing
down due to the drag from the moon's gravity. But there is nothing to
say it couldn't speed up. Of course to do that would probably require
something like a glancing blow from a large asteroid - in which case I
doubt we would be worrying about a few seconds on a computer clock :-)
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp. js*******@attglobal.net
==================
"Jerry Stuckle" <js*******@attglobal.netwrote in message
news:BP******************************@comcast.com. ..
>
So they have to be adjusted. And even though NTP tries to speed up and
slow the clock - it's not perfect. And at times the clock WILL jump
forwards or backwards at least one second.
My documentation for NTP proper says it won't do this.
What kind of events are you speaking of that might cause discontinuities?
--
David T. Ashley (dt*@e3ft.com) http://www.e3ft.com (Consulting Home Page) http://www.dtashley.com (Personal Home Page) http://gpl.e3ft.com (GPL Publications and Projects)
David T. Ashley wrote:
"Jerry Stuckle" <js*******@attglobal.netwrote in message
news:BP******************************@comcast.com. ..
>So they have to be adjusted. And even though NTP tries to speed up and
slow the clock - it's not perfect. And at times the clock WILL jump
forwards or backwards at least one second.
My documentation for NTP proper says it won't do this.
What kind of events are you speaking of that might cause discontinuities?
It depends on a lot of things. Many systems do not have the necessary
hardware adjust clock speed. So just like any clock, if it's running
fast, it must be set back sooner or later.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp. js*******@attglobal.net
==================
"Jerry Stuckle" <js*******@attglobal.netwrote in message
news:Yd******************************@comcast.com. ..
David T. Ashley wrote:
>"Jerry Stuckle" <js*******@attglobal.netwrote in message
news:BP******************************@comcast.com ...
>>So they have to be adjusted. And even though NTP tries to speed up and
slow the clock - it's not perfect. And at times the clock WILL jump
forwards or backwards at least one second.
My documentation for NTP proper says it won't do this.
What kind of events are you speaking of that might cause discontinuities?
It depends on a lot of things. Many systems do not have the necessary
hardware adjust clock speed. So just like any clock, if it's running
fast, it must be set back sooner or later.
Interesting. I had assumed that adjtimex() was available on just about
every system that would run PHP.
Also, I'm not sure that adjusting time has much to do with hardware. My
understanding of it was that every system has the capability for RTI (some
sort of real-time interrupt at a periodic rate--perhaps adjustable, perhaps
not), but maybe something around 100Hz is typical.
In any case, my understanding of Linux timekeeping was that on every
timetick, an integer was added to the internal time. The integer would be
fairly large, so that the timekeeping precision is several orders of
magnitude finer than the RTI rate. It would be this integer adjusted to
change the effective rate of the clock, not hardware.
For example, let's assume that the RTI rate is 100Hz, and we maintain time
as a 64-bit integer, with the radix point after the first 32 bits. Then, on
each tick, we add 42,949,673 to the integer. Every 100 ticks, the upper 32
bits will be incremented. Time adjustment is possible to about 1 part in 43
million. And the system is very cheap (integer arithmetic is cheap).
For example, if we want the clock to run a bit slower, we add 42,949,672
each time rather than 42,949,673.
What did I miss?
Is hardware really involved?
Can you point me to documentation about any system where the rate can't be
adjusted under Linux?
Thanks, Dave.
--
David T. Ashley (dt*@e3ft.com) http://www.e3ft.com (Consulting Home Page) http://www.dtashley.com (Personal Home Page) http://gpl.e3ft.com (GPL Publications and Projects)
..oO(Jerry Stuckle)
>It depends on a lot of things. Many systems do not have the necessary
hardware adjust clock speed.
It can all be done and corrected with software.
>So just like any clock, if it's running
fast, it must be set back sooner or later.
Not necessarily. On my local server:
kira:~# date; hwclock
So 24. Jun 18:24:39 CEST 2007
So 24 Jun 2007 18:24:09 CEST -0.758366 Sekunden
The system clock is synchronized with an NTP server, while the hardware
RTC is half a minute behind. It simply doesn't matter. The RTC is only
used to maintain the time when the system is down, the system clock is
controlled by software and is always as exact as possible.
If there would be a real difference between the system clock and the
"real time", my local NTP daemon (chrony) would slightly speed up or
slow down the system clock, so after a short period of time it would be
in sync again without any gaps or "time jumps".
Micha
On Sat, 23 Jun 2007 10:44:14 -0400 David T. Ashley said
"Sig" <iv*****@example.comwrote in message
news:MPG.20e65d5b8466b279989681@islay...
On Sat, 23 Jun 2007 01:04:46 -0400 David T. Ashley said
Is it true on my system that the Unix time may skip up or down by one
second
at midnight when there is a leap second?
By "Unix time" I mean the integer returned by time() and similar
functions.
I'm concerned about the "down" case. Some of the software I've written
assumes monotonically-increasing time.
I don't think you have to worry.
(1) NIST says "Based on what we know about the earth's rotation, it seems
unlikely that we will ever have a negative leap second."
<http://tf.nist.gov/general/leaps.htm#Anchor-52904>
(2) If it did happen, the time would repeat, not go backwards.
If I'm understanding your comment correctly, and if I'm not mixed up myself,
I believe you have the sign wrong in the way you're thinking about leap
seconds. An ordinary (positive) leap second is where you insert an extra
second and "time stands still" for a second (this is akin to February 29).
I believe these will get more frequent as the earth's rotation is slowing
down.
An ordinary leap second ("time stands still") actually in effect gives the
earth's rotation time to "catch up" to the kept time.
A negative leap second would result in the Unix time skipping a second
(jumping forward).
Of course, "time standing still" can't happen on a computer system, so you
have to re-use a Unix time value (i.e. Unix time goes backwards).
So, I believe but am not sure that due to a sign mixup, the case that you
have presented as impossible is actually the normal and expected case.
According to the entry on Wikipedia,
http://en.wikipedia.org/wiki/Unix_time
Unix time will re-use certain integers when a leap second occurs. That
surprised me, but it may very well be true.
My application is generating unique identifiers in PHP (as part of web
database scripts). The current scheme I use is:
You're right, I was over hasty (and backwards) in my interpretation of NIST's
positive and negative.
However, ignoring the issue of local clock correction, brought up elsewhere in
this thread, my comment on monotonicity stands. The seconds count will repeat,
rather than go backwards.
-- http://koiclubsandiego.org/comment/?r=8
"Sig" <iv*****@example.comwrote in message
news:MPG.20e8457c18537bc9989682@islay...
>
However, ignoring the issue of local clock correction, brought up
elsewhere in
this thread, my comment on monotonicity stands. The seconds count will
repeat,
rather than go backwards.
Fair enough. However, for my application (where I use the microtime as
well), time repeats rather than being monotonic. For my application, it
would be possible that I get a duplicate (seconds, microtime) pair.
(seconds) is monotonic (I agree with you).
(seconds.microtime) is not monotonic.
--
David T. Ashley (dt*@e3ft.com) http://www.e3ft.com (Consulting Home Page) http://www.dtashley.com (Personal Home Page) http://gpl.e3ft.com (GPL Publications and Projects)
On Sun, 24 Jun 2007 11:19:21 -0400, David T. Ashley wrote:
"Jerry Stuckle" <js*******@attglobal.netwrote in message
news:BP******************************@comcast.com. ..
>>
So they have to be adjusted. And even though NTP tries to speed up and
slow the clock - it's not perfect. And at times the clock WILL jump
forwards or backwards at least one second.
My documentation for NTP proper says it won't do this.
What kind of events are you speaking of that might cause discontinuities?
If you'd like to elaborate, I be interested in why you have the
requirement that time be monotonically increasing. In the real world,
things happen, and no software is perfect or bug-free.
Jerry Stuckle wrote:
....
Also, leap seconds are added because the earth's rotation is slowing
down due to the drag from the moon's gravity. But there is nothing to
say it couldn't speed up. Of course to do that would probably require
something like a glancing blow from a large asteroid - in which case I
doubt we would be worrying about a few seconds on a computer clock :-)
Something similar did occur to me - that if a negative leap second had to be
added, the cause of the requirement would be such that the actual clock
adjustment would be the least of anyone's worry...unfortunately, I seem to
have cut that bit from my reply. ^_^
>So they have to be adjusted. And even though NTP tries to speed up and
>slow the clock - it's not perfect. And at times the clock WILL jump
forwards or backwards at least one second.
My documentation for NTP proper says it won't do this.
What does happen when the clocks are sync'd, the cluster of systems loses
outside network connectivity to all of its reference clocks, and several
days later, connectivity comes back? adjtime is not perfect and the clocks
will drift without a reference. Eventually that becomes several seconds.
I have seen NTP (running on the system that's supposed to be the
on-site reference, driven from outside references) manage to declare
two reference clocks (stratum 2) and a number of clocks of machines
it locally serves *ALL* falsetickers, and run off of its local clock
(stratum 12) and stay that way for a couple of days until manual
intervention.
>What kind of events are you speaking of that might cause discontinuities?
>>So they have to be adjusted. And even though NTP tries to speed up and
>>slow the clock - it's not perfect. And at times the clock WILL jump
forwards or backwards at least one second.
My documentation for NTP proper says it won't do this.
What kind of events are you speaking of that might cause discontinuities?
It depends on a lot of things. Many systems do not have the necessary
hardware adjust clock speed. So just like any clock, if it's running
fast, it must be set back sooner or later.
You can also correct the conversion of the clock (which on many
systems is simply a counter driven by a reference frequency) to a
time. The reference frequency then becomes a variable.
David T. Ashley wrote:
"Jerry Stuckle" <js*******@attglobal.netwrote in message
news:Yd******************************@comcast.com. ..
>David T. Ashley wrote:
>>"Jerry Stuckle" <js*******@attglobal.netwrote in message
news:BP******************************@comcast.co m...
So they have to be adjusted. And even though NTP tries to speed up and
slow the clock - it's not perfect. And at times the clock WILL jump
forwards or backwards at least one second.
My documentation for NTP proper says it won't do this.
What kind of events are you speaking of that might cause discontinuities?
It depends on a lot of things. Many systems do not have the necessary
hardware adjust clock speed. So just like any clock, if it's running
fast, it must be set back sooner or later.
Interesting. I had assumed that adjtimex() was available on just about
every system that would run PHP.
Also, I'm not sure that adjusting time has much to do with hardware. My
understanding of it was that every system has the capability for RTI (some
sort of real-time interrupt at a periodic rate--perhaps adjustable, perhaps
not), but maybe something around 100Hz is typical.
In any case, my understanding of Linux timekeeping was that on every
timetick, an integer was added to the internal time. The integer would be
fairly large, so that the timekeeping precision is several orders of
magnitude finer than the RTI rate. It would be this integer adjusted to
change the effective rate of the clock, not hardware.
For example, let's assume that the RTI rate is 100Hz, and we maintain time
as a 64-bit integer, with the radix point after the first 32 bits. Then, on
each tick, we add 42,949,673 to the integer. Every 100 ticks, the upper 32
bits will be incremented. Time adjustment is possible to about 1 part in 43
million. And the system is very cheap (integer arithmetic is cheap).
For example, if we want the clock to run a bit slower, we add 42,949,672
each time rather than 42,949,673.
What did I miss?
Is hardware really involved?
Can you point me to documentation about any system where the rate can't be
adjusted under Linux?
Thanks, Dave.
Dave (and others who responded)
That is true, it depends on the clock frequency. However, the system
clock runs even when the system is turned off - it's battery operated
and that's why you don't have to reset the clock every time you start up.
Yes, some Linux versions have the ability to "override" the system clock
and display a different time than the system has. But that doesn't mean
the system clock is accurate, or the software clock is accurate after a
restart.
And it doesn't mean the time the program sees will never need to be
reset either way.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp. js*******@attglobal.net
==================
Jerry Stuckle wrote:
David T. Ashley wrote:
>"Jerry Stuckle" <js*******@attglobal.netwrote in message
news:Yd******************************@comcast.com ...
>>David T. Ashley wrote:
"Jerry Stuckle" <js*******@attglobal.netwrote in message
news:BP******************************@comcast.c om...
So they have to be adjusted. And even though NTP tries to speed up
and slow the clock - it's not perfect. And at times the clock WILL
jump forwards or backwards at least one second.
My documentation for NTP proper says it won't do this.
What kind of events are you speaking of that might cause
discontinuities?
It depends on a lot of things. Many systems do not have the
necessary hardware adjust clock speed. So just like any clock, if
it's running fast, it must be set back sooner or later.
Interesting. I had assumed that adjtimex() was available on just
about every system that would run PHP.
Also, I'm not sure that adjusting time has much to do with hardware.
My understanding of it was that every system has the capability for
RTI (some sort of real-time interrupt at a periodic rate--perhaps
adjustable, perhaps not), but maybe something around 100Hz is typical.
In any case, my understanding of Linux timekeeping was that on every
timetick, an integer was added to the internal time. The integer
would be fairly large, so that the timekeeping precision is several
orders of magnitude finer than the RTI rate. It would be this integer
adjusted to change the effective rate of the clock, not hardware.
For example, let's assume that the RTI rate is 100Hz, and we maintain
time as a 64-bit integer, with the radix point after the first 32
bits. Then, on each tick, we add 42,949,673 to the integer. Every
100 ticks, the upper 32 bits will be incremented. Time adjustment is
possible to about 1 part in 43 million. And the system is very cheap
(integer arithmetic is cheap).
For example, if we want the clock to run a bit slower, we add
42,949,672 each time rather than 42,949,673.
What did I miss?
Is hardware really involved?
Can you point me to documentation about any system where the rate
can't be adjusted under Linux?
Thanks, Dave.
Dave (and others who responded)
That is true, it depends on the clock frequency. However, the system
clock runs even when the system is turned off - it's battery operated
and that's why you don't have to reset the clock every time you start up.
Not on any hardware I've ever encountered (a non-universal
sample, I freely admit). There's usually a periodic interrupt
that fires at some nominal rate while power is on and the system
is running, but this interruptor doesn't run while the system
is off (and certainly not when power is removed) -- after all,
who would service the interrupt? But there's a secondary ToD
"wristwatch" chip that runs all the time on a small battery.
This ToD chip furnishes the t=0 value during boot, and may be
rewritten during clean shutdown and perhaps at other times.
But once it's supplied t=0="2007-06-24 21:34:36" at boot time,
the ToD chip is not responsible for cyclic interrupts thereafter.
Perhaps there's a system where both functions are rolled
into one device, but I haven't run into it.
--
Eric Sosman es*****@acm-dot-org.invalid
Eric Sosman wrote:
Jerry Stuckle wrote:
>David T. Ashley wrote:
>>"Jerry Stuckle" <js*******@attglobal.netwrote in message
news:Yd******************************@comcast.co m...
David T. Ashley wrote:
"Jerry Stuckle" <js*******@attglobal.netwrote in message
news:BP******************************@comcast. com...
>So they have to be adjusted. And even though NTP tries to speed
>up and slow the clock - it's not perfect. And at times the clock
>WILL jump forwards or backwards at least one second.
My documentation for NTP proper says it won't do this.
>
What kind of events are you speaking of that might cause
discontinuities?
>
It depends on a lot of things. Many systems do not have the
necessary hardware adjust clock speed. So just like any clock, if
it's running fast, it must be set back sooner or later.
Interesting. I had assumed that adjtimex() was available on just
about every system that would run PHP.
Also, I'm not sure that adjusting time has much to do with hardware.
My understanding of it was that every system has the capability for
RTI (some sort of real-time interrupt at a periodic rate--perhaps
adjustable, perhaps not), but maybe something around 100Hz is typical.
In any case, my understanding of Linux timekeeping was that on every
timetick, an integer was added to the internal time. The integer
would be fairly large, so that the timekeeping precision is several
orders of magnitude finer than the RTI rate. It would be this
integer adjusted to change the effective rate of the clock, not
hardware.
For example, let's assume that the RTI rate is 100Hz, and we maintain
time as a 64-bit integer, with the radix point after the first 32
bits. Then, on each tick, we add 42,949,673 to the integer. Every
100 ticks, the upper 32 bits will be incremented. Time adjustment is
possible to about 1 part in 43 million. And the system is very cheap
(integer arithmetic is cheap).
For example, if we want the clock to run a bit slower, we add
42,949,672 each time rather than 42,949,673.
What did I miss?
Is hardware really involved?
Can you point me to documentation about any system where the rate
can't be adjusted under Linux?
Thanks, Dave.
Dave (and others who responded)
That is true, it depends on the clock frequency. However, the system
clock runs even when the system is turned off - it's battery operated
and that's why you don't have to reset the clock every time you start up.
Not on any hardware I've ever encountered (a non-universal
sample, I freely admit). There's usually a periodic interrupt
that fires at some nominal rate while power is on and the system
is running, but this interruptor doesn't run while the system
is off (and certainly not when power is removed) -- after all,
who would service the interrupt? But there's a secondary ToD
"wristwatch" chip that runs all the time on a small battery.
This ToD chip furnishes the t=0 value during boot, and may be
rewritten during clean shutdown and perhaps at other times.
But once it's supplied t=0="2007-06-24 21:34:36" at boot time,
the ToD chip is not responsible for cyclic interrupts thereafter.
OK, I'm not making myself clear. Yes, it is a different chip. But it's
also tied closely into the system. Often times they are both run by the
same interrupt, or, more often, the ToD clock chip actually generates
the interrupts for the system.
But the fact remains - this time can be off - and can result in a
negative adjustment to the software clock.
Perhaps there's a system where both functions are rolled
into one device, but I haven't run into it.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp. js*******@attglobal.net
==================
On Sun, 24 Jun 2007, in the Usenet newsgroup comp.os.linux, in article
<Yd******************************@comcast.com>, Jerry Stuckle wrote:
>David T. Ashley wrote:
>"Jerry Stuckle" <js*******@attglobal.netwrote
>>So they have to be adjusted. And even though NTP tries to speed up and
slow the clock - it's not perfect. And at times the clock WILL jump
forwards or backwards at least one second.
The only time the clock will be jumping is a boot time, before any
applications are running, as kernel time jumps from "zero" to what ever
the BIOS is claiming. There is a mechanism in NTP where you can also
SET the time, but this should only be done at boot time.
>What kind of events are you speaking of that might cause discontinuities?
It depends on a lot of things. Many systems do not have the necessary
hardware adjust clock speed.
When was the last time you saw a hardware adjustment for clock speed?
Not to many of us are using IBM Type 1 motherboards from 1985. The
Pentium class motherboards often don't even have a separate oscillator
module. with the interrupt source being the oscillator that is part of
the RTC.
>So just like any clock, if it's running fast, it must be set back
sooner or later.
This kernel is compiled to run the IRQ0 interrupt at 100 "ticks" per
second (others use 1000 "ticks"), and that means the the divider is
normally running at 18432:1. To _drift_ the clock into correspondence
with "real" time, that division ratio is altered. As the crap crystal
oscillator used as a timing source is accurate to +/-100 ppm, the
division ration is periodically altered over the range of 18430 to
18434 to make it read something approaching the desired time. No big
magic deal - and no "major" steps. It's just that the 1/100 of a
second may vary by up to 54 microseconds. If your kernel is compiled
for a 1000 Hertz interrupt, the kernel is already doing this shuffle
step routine, as the divider is only programed to integers, and not the
1843.2:1 required with a perfectly set oscillator.
Old guy
On Jun 25, 6:59 pm, ibupro...@painkiller.example.tld (Moe Trin) wrote:
The main
point is that there are some situations where _changing_ the clock
setting is a Class 1 felony. To keep the system in time, you are
allowed to _drift_ the clock, but as in the world, time never goes
backwards, nor stand still.
Say somehow the clock is more than three seconds fast, so the system
is out of the range which is tolerated according to SEC guidelines for
trading. But the clock also runs a real-time process control system
where changing the frequency by 1 PPM will throw off synchronization.
What to do?
200 years ago navigators understood that the ship's chronometer would
not stay in agreement with the earth, but resetting the chronometer
made it unstable, so they kept logs of the difference between
chronometer and clock. 50 years ago there was still no such thing as
a clock which did not need to be reset, and the concept was
unthinkable. At some level of precision (which depends on how much
money was spent on the clock and engineering the systems around it)
that remains true.
Moe Trin wrote:
On Sun, 24 Jun 2007, in the Usenet newsgroup comp.os.linux, in article
<Yd******************************@comcast.com>, Jerry Stuckle wrote:
>David T. Ashley wrote:
>>"Jerry Stuckle" <js*******@attglobal.netwrote
>>>So they have to be adjusted. And even though NTP tries to speed up and
slow the clock - it's not perfect. And at times the clock WILL jump
forwards or backwards at least one second.
The only time the clock will be jumping is a boot time, before any
applications are running, as kernel time jumps from "zero" to what ever
the BIOS is claiming. There is a mechanism in NTP where you can also
SET the time, but this should only be done at boot time.
The only time when the system sets it automatically, you mean.
>>What kind of events are you speaking of that might cause discontinuities?
It depends on a lot of things. Many systems do not have the necessary
hardware adjust clock speed.
When was the last time you saw a hardware adjustment for clock speed?
Not to many of us are using IBM Type 1 motherboards from 1985. The
Pentium class motherboards often don't even have a separate oscillator
module. with the interrupt source being the oscillator that is part of
the RTC.
True.
>So just like any clock, if it's running fast, it must be set back
sooner or later.
This kernel is compiled to run the IRQ0 interrupt at 100 "ticks" per
second (others use 1000 "ticks"), and that means the the divider is
normally running at 18432:1. To _drift_ the clock into correspondence
with "real" time, that division ratio is altered. As the crap crystal
oscillator used as a timing source is accurate to +/-100 ppm, the
division ration is periodically altered over the range of 18430 to
18434 to make it read something approaching the desired time. No big
magic deal - and no "major" steps. It's just that the 1/100 of a
second may vary by up to 54 microseconds. If your kernel is compiled
for a 1000 Hertz interrupt, the kernel is already doing this shuffle
step routine, as the divider is only programed to integers, and not the
1843.2:1 r quired with a perfectly set oscillator.
Old guy
First of all, uncompensated clocks may or may not be 100ppm. I've got
one server, for instance, which is off more than 500 ppm. Several
others run in the 200-400ppm range.
You've come up with a lot of arguments. So you are saying you can
guarantee - WITHOUT QUALIFICATION - that the clock will NEVER be set
back while things are running?
I didn't think so.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp. js*******@attglobal.net
==================
Robert Newson wrote:
David T. Ashley wrote:
....
>
Daylight saving (though how calling one time another saves daylight -
there will be exactly the same amount of daylight in the day regardless
of what you call the hours - I'm still trying to work out)
....
When a sample of Iowa farmers were asked about the effect of
increasing the amount of daylight savings time this year, a fair
number said that it would make the summer hotter because there
would be more sunlight to warm the earth. They were evenly
divided if this was a good thing or not.
bill
bill wrote:
Robert Newson wrote:
>David T. Ashley wrote:
...
>>
Daylight saving (though how calling one time another saves daylight -
there will be exactly the same amount of daylight in the day
regardless of what you call the hours - I'm still trying to work out)
...
When a sample of Iowa farmers were asked about the effect of increasing
the amount of daylight savings time this year, a fair number said that
it would make the summer hotter because there would be more sunlight to
warm the earth. They were evenly divided if this was a good thing or not.
bill
Another urban legend.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp. js*******@attglobal.net
==================
On 27.06.2007 15:33 Jerry Stuckle wrote:
bill wrote:
>Robert Newson wrote:
>>David T. Ashley wrote:
...
>>>
Daylight saving (though how calling one time another saves daylight -
there will be exactly the same amount of daylight in the day
regardless of what you call the hours - I'm still trying to work out)
...
When a sample of Iowa farmers were asked about the effect of
increasing the amount of daylight savings time this year, a fair
number said that it would make the summer hotter because there would
be more sunlight to warm the earth. They were evenly divided if this
was a good thing or not.
bill
Another urban legend.
That was an example of so-called "joke", Jerry. ;))
--
gosha bine
extended php parser ~ http://code.google.com/p/pihipi
blok ~ http://www.tagarga.com/blok
gosha bine wrote:
On 27.06.2007 15:33 Jerry Stuckle wrote:
>bill wrote:
>>Robert Newson wrote:
David T. Ashley wrote:
...
Daylight saving (though how calling one time another saves daylight
- there will be exactly the same amount of daylight in the day
regardless of what you call the hours - I'm still trying to work out)
...
When a sample of Iowa farmers were asked about the effect of
increasing the amount of daylight savings time this year, a fair
number said that it would make the summer hotter because there would
be more sunlight to warm the earth. They were evenly divided if this
was a good thing or not.
bill
Another urban legend.
That was an example of so-called "joke", Jerry. ;))
Sorry, but that can be pretty sensitive to those of us who grew up in
Iowa - and have had people believe it as a fact, not a joke.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp. js*******@attglobal.net
==================
On Tue, 26 Jun 2007 15:05:57 -0500, Moe Trin wrote:
On Mon, 25 Jun 2007, in the Usenet newsgroup alt.comp.linux, in article
<11**********************@e16g2000pri.googlegroups .com>, sl******@gmail.com
wrote:
>>Say somehow the clock is more than three seconds fast, so the system
is out of the range which is tolerated according to SEC guidelines for
trading. But the clock also runs a real-time process control system
where changing the frequency by 1 PPM will throw off synchronization.
Poorly contrived example. If someone was so inept as to be running a
system used for SEC regulated trading, _AND_ using the same system as a
process controller, the problem is not going to be solved by somehow
offsetting the date/time. The process will be solved by getting the
process controller off the system with this gross oscillator.
I could be wrong, but I don't recall that the OP said anything about SEC
regulated trading. I'm not disputing what SEC requires, merely asking for
clarification as to his requirements.
Jerry Stuckle wrote:
gosha bine wrote:
>On 27.06.2007 15:33 Jerry Stuckle wrote:
>>bill wrote:
Robert Newson wrote:
David T. Ashley wrote:
...
>
Daylight saving (though how calling one time another saves daylight
- there will be exactly the same amount of daylight in the day
regardless of what you call the hours - I'm still trying to work out)
...
When a sample of Iowa farmers were asked about the effect of
increasing the amount of daylight savings time this year, a fair
number said that it would make the summer hotter because there would
be more sunlight to warm the earth. They were evenly divided if
this was a good thing or not.
bill
Another urban legend.
That was an example of so-called "joke", Jerry. ;))
Sorry, but that can be pretty sensitive to those of us who grew up in
Iowa - and have had people believe it as a fact, not a joke.
Apologies to all who grew up in Iowa, it was really about
Illinois farmers.
bill
"David T. Ashley" <dt*@e3ft.comwrites:
>I have Red Hat Enterprise Linux 4.
>I was just reading up about UTC and leap seconds.
>Is it true on my system that the Unix time may skip up or down by one second
at midnight when there is a leap second?
It might. If you are running ntp.
>By "Unix time" I mean the integer returned by time() and similar functions.
>I'm concerned about the "down" case. Some of the software I've written
assumes monotonically-increasing time.
The time is ALWAYS monotonically increasing.
Sometime it may be very slow.
>Thanks.
--
David T. Ashley (dt*@e3ft.com)
http://www.e3ft.com (Consulting Home Page)
http://www.dtashley.com (Personal Home Page)
http://gpl.e3ft.com (GPL Publications and Projects)
Jerry Stuckle <js*******@attglobal.netwrites:
>Robert Newson wrote:
>Jerry Stuckle wrote:
...
>>And while I agree with the astronomers that there is no reason for a
negative leap-second, programmers need to be aware it can happen!
Shirley the correction for a negative leap-seacond would be to put the
clock /forward/ 1 second? ie /increase/ the time?[1]
>Don't call me Shirley! :-)
>In the case of a leap second, yes. But you took my statement out of
context. Leap seconds are not the only reason computer clocks may need
adjustment, and sometimes that adjustment may be backwards.
>The only thing is: does the time() clock actually adjust for leap
seconds? Leap days (and DLS) are "fixed" in the conversion to localtime;
would leap seconds be "fixed" at the same time?
>I don't know, but I would hope so. The problem is that leap seconds are
not fixed. They are added when necessary.
>[1] Consider that what leap days do is cause the day to be fast if you
don't correct; the "correction" causes 1 Mar becomes 29 Feb, 2 Mar
becomes 1 Mar, etc - the "correction" is to take the clock /backward/ by
86,400[2] seconds by inserting an extra 86,400 seconds. Similarly
leap-seconds: they insert a second to take the clock backwards: the
[physical] day is 86,401[2] seconds long (24:00:01); a negative
leap-second would require the day to be 86,399[2] seconds long
(23:59:59) - the only way this could shirley occur is if the earth's
rotation /speeded up/...or the timekeepers (atomic clocks?) slowed down[3]?
[2] Rounded to the nearest second.
[3] Or an error was made in adding a leap second in the first place?
Or have I totally misunderstood what leap seconds (and days) do?
>In the case of leap seconds. But read the rest of my message.
>Also, leap seconds are added because the earth's rotation is slowing
down due to the drag from the moon's gravity. But there is nothing to
say it couldn't speed up. Of course to do that would probably require
something like a glancing blow from a large asteroid - in which case I
doubt we would be worrying about a few seconds on a computer clock :-)
No. Earthquakes reaarange the mass distribution of the earth, heating of
the atmosphere rearranges the mass distribution of the earth, etc. Ie there
are lots of things other than asteroids that could speed up or slow down
the rotation of the earth to parts per 10^8
>--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================
ib*******@painkiller.example.tld (Moe Trin) writes:
>On Wed, 27 Jun 2007, in the Usenet newsgroup comp.os.linux, in article
<13*************@corp.supernews.com>, Gordon Burditt wrote:
....
>I'd change network providers too. In the thirty-four years I've been
in networking, the longest we've been disconnected is six hours - the
classic 'backhoe fade' thanks to the city water department. But if
you are dependent on network connectivity, haven't you at least looked
into disaster scenarios? Or do disasters only happen to others? I know
that your bank is going to be in really deep sh!t if they're off line
that long - both from the government regulators AND their ex-customers.
Look, if you are really that desperate for accurate times, get a gps
receiver with pps capability. That will keep your system accurate to
microseconds . And it will not go off when your network disconnects.
And they are cheap ( the one I bought was less than $100)
Use ntp to sync to it, not to th enetwork ( which is certainly not good to
even msec, never mind microseconds).
Then slave your other computers to that one as a stratum 1 server.
>>NTP does correct for some of the error. Then again, the clock error
depends on temperature by quite a lot.
>Please remember than companies that are subject to these legal
requirements (about not fscking with the clock) are also not dependent
on a single PC in an uncontrolled location. Thus, there are three time
servers here, each monitoring _separate_ time sources, and averaging
that to 'tweak' their own concept of correct time, and we're not even
subject to those regulations - they are only serving time to 2500+ users
in this facility, and acting as a stratum 4 reference to other time
servers in other company locations.
Why not get a gps clock with the network as backup? This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics | |
by: Charles Hixson |
last post by:
This is a concept, not a finished program, and an extract from a class
at that...so forgive any illegalities, but:
import datetime;
def calcNodeId(self):
t = datetime.utcnow()
val ...
|
by: Tom |
last post by:
A field in a data set I want to import into Access is in Unix time (seconds from
a certain time on a certain date). Does anyone know the precise date and the
precise time on that date that Unix is...
|
by: Huey |
last post by:
Hi All,
I need to compute the current time value in seconds: the current time
is 12/16/2003, and it's time value in integer should around 1071560616
seconds since 1/1/1970. It is easy to get...
|
by: George |
last post by:
In Time.h there is a structure defined for time settings. I'm
building an embedded system that has a Real Time Clock but it's not PC
compatible.
My question is:
I don't some elements of the...
|
by: marc |
last post by:
hi
im trying to convert Date() into a unix timestamp so i can stick the
result into a mysql db, please help!
| | |
by: Grey Alien |
last post by:
I need to convert timestamps that are given as the number of seconds
that have elapsed since midnight UTC of January 1, 1970, (not counting
leap seconds).
It seems all of the std C functions...
|
by: usenet |
last post by:
Is the epoch time the number of seconds elapsed since January 1st 1970
in my timezone or as per UTC? I mean, if A's program makes a call to
time() in Melboune and B's program makes a call to...
|
by: Andrew Chalk |
last post by:
Network time uses 1900 as its base. The C time library uses 1970. I want to
convert a network time value to a C library time. I.e. I have to subtract
the number of seconds from 1900 to 1970. Is...
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers,...
|
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...
| | |
by: Hystou |
last post by:
Overview:
Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows...
|
by: tracyyun |
last post by:
Dear forum friends,
With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each...
|
by: isladogs |
last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM).
In this session, we are pleased to welcome a new...
|
by: conductexam |
last post by:
I have .net C# application in which I am extracting data from word file and save it in database particularly. To store word all data as it is I am converting the whole word file firstly in HTML and...
|
by: TSSRALBI |
last post by:
Hello
I'm a network technician in training and I need your help.
I am currently learning how to create and manage the different types of VPNs and I have a question about LAN-to-LAN VPNs.
The...
|
by: muto222 |
last post by:
How can i add a mobile payment intergratation into php mysql website.
| |
