Spans of time that cause trouble with computers or are significant to computers.

Issues related to very large spans of time will be collected elsewhere.

Also see Troublesome Dates.

40 ms

+tcp_default_delack_min:	- INTEGER
+	Sets the default minimum time (in miliseconds) to delay before sending an ACK.
+	Default: 40ms

200 ms

+tcp_default_delack_max: - INTEGER
+	Sets the maximum time (in miliseconds) to delay before sending an ACK.
+	Default: 200ms

As currently implemented, there is a 200 millisecond ceiling on the time for which output is corked by TCP_CORK

10 seconds

Wi-Fi latency spike every 10 seconds

QT_BEARER_POLL_TIMEOUT has default value of 10 seconds

int interval = qEnvironmentVariableIntValue("QT_BEARER_POLL_TIMEOUT", &ok);
  if (!ok)
    interval = 10000;//default 10 seconds

20 seconds

Doing DNS lookup over TLS on Android has a 20 second “idle timeout”:

static constexpr std::chrono::seconds kIdleTimeout = std::chrono::seconds(20);

25 seconds

https://www.wireguard.com/quickstart/#nat-and-firewall-traversal-persistence

30 seconds

Maximum Segment Lifetime, most of the Linux systems define the MSL 30s

75 seconds

Under some old versions of Ultrix, select() wouldn’t notice failure before the 75-second timeout.

keepinit      Timeout,  in  milliseconds, for new, non-established
        TCP connections.  The default is 75000 msec.

2 minutes

TIME_WAIT state for TCP

5 minutes

Linux jiffies wrap 5 minutes after boot time

~7 minutes

the clock in a version 2 UUID will “tick” only once every 429.49 seconds, a little more than 7 minutes, as opposed to every 100 nanoseconds for version 1

~11 minutes

9 * 75 Second == 675 Second == 11.25 Minute

tcp_keepalive_probes - INTEGER

How many keepalive probes TCP sends out, until it decides that the connection is broken. Default value: 9.

tcp_keepalive_intvl - INTEGER

How frequently the probes are sent out. Multiplied by tcp_keepalive_probes it is time to kill not responding connection, after probes started. Default value: 75sec i.e. connection will be aborted after ~11 minutes of retries.

~17 minutes

1 Mega Milli Second == 16.66 Minute

~53 minutes

1 Micro Century == 52.6 Minute

2 hours

tcp_keepalive_time - INTEGER

How often TCP sends out keepalive messages when keepalive is enabled. Default: 2hours.

~2.77 hours

10000 seconds

~4.5 hours

2^31 / (6 * 22050 Hz) == 4.5 Hour

~11 hours

29 hours

Why does the IIS worker process recycle every 29 hours and not every 24 hours?

https://serverfault.com/questions/348493/why-does-the-iis-worker-process-recycle-every-29-hours-and-not-every-24-hours/348502#348502

~3.23 days

2^24 frames running at 60 FPS

~4 days

100 Hour == 4.17 Day

~4-5 days

Retries continue until the message is transmitted or the sender gives up; the give-up time generally needs to be at least 4-5 days.

~6.2 days

2^29 Milli Second == 149.131 Hour == 6.2 Day

~6.47 days

2^24 frames running at 30 FPS

~11.5 days

1 million seconds

1 billion milli-seconds

~19.4 days

2^24 deci seconds

A 24-bit register, with clock ticks every 0.1 second, would overflow in less than 20 days

22 days

says 21 days: https://itwire.com/business-it-news/security/boeing-787-needs-a-reboot-every-21-days.html

unclear what the cause is

~24.9 days

2^31 milliseconds is about 24.9 days

probably means Integer.MAX_VALUE here, since Long.MAX_VALUE is not prime

40 days

Now, for a different real world example, Microsoft IIS (3.x, I think it was) had a bug where the date/time fields in W3C format log files would stop incrementing after only 40 days. Wonder what size counters they were using?

unclear

41.666 days

1000 hours

Pokemon playtime counter maxes out at 999:59 hours.

47 days

https://news.ycombinator.com/item?id=43694477

47 days = 1 maximal month (31 days) + 1/2 30-day month (15 days) + 1 day wiggle room

https://www.digicert.com/blog/tls-certificate-lifetimes-will-officially-reduce-to-47-days

~49.7 days

2^32 milliseconds

~51 days

42 bit counter @ 1 Mhz = 50.9033 Day

2^32 @ 1024 MHz = 50.9033 Day

This is a great article:

A Reverse Engineer’s Perspective on the Boeing 787 ‘51 days’ Airworthiness Directive

and proposes

0x800000000000 @ 32 MHz = 50.9033 Day

~70 days

1700 Hour

https://learn.microsoft.com/en-us/troubleshoot/windows-server/backup-and-storage/intel-ssd-d3-s4510-s4610-series-1-dot-92-3-dot-84-tb-drives-unresponsive

could be: 102400 minutes

2^10 centi minutes

~194 days

2^24 seconds

208.5 days

0xffffffffffffffff >> 10 Nano Second == 208.5 Days

In[1]:= BitShiftRight[16^^ffffffffffffffff, 10]/10^9/60/60/24 // N

Out[1]= 208.5

213.504 days

2^64 picoseconds = 5124.1 hours = 213.504 days

It’s what you get when you have a 64 bit unsigned counter running at 1 THz.

In[204]:= 
2^64*Second/(1000000 Mega) Minute/(60 Second) Hour/(60 Minute) // N

Out[204]= 5124.1 Hour

~216 days

“5184 hours” (suspiciously close to 2^64 picoseconds, but that is actually 5124.1 hours)

really close to 5124.1 + 60 ? But why would you need to add 60 hours?

In[226]:= 2^32*Second/230 Minute/(60 Second) Hour/(60 Minute) // N

Out[226]= 5187.16 Hour

In[200]:= 
2^53*Second/(482.5 Mega) Minute/(60 Second) Hour/(60 Minute) // N

Out[200]= 5185.49 Hour

“exactly 5200 hours”

https://www.reddit.com/r/hardware/comments/o40ew/crucial_m4_ssd_drives_start_to_fail_after_exactly/

https://icrontic.com/article/crucial-m4-5200-hour-error

https://web.archive.org/web/20190304081549/https://forums.crucial.com/t5/SSD-Archive-Read-Only/0x00000f4-error-on-M4-64GB/m-p/79094/highlight/true

~248 days

2^31 centi-seconds

2^31 ticks @ 100 Hz

~497 days

497 is the approximate number of days a counter will last if it is 32 bits, unsigned, starts from zero, and ticks at 100 Hz.

1.28 years

466 days

0xF0000000 * 10 Milli Second = 466.034 Day

~1.36 years

2^32 * 10 Milli Second == 497 Day

~2.27 years

828 days

2^32 / (60Hz * 60sec * 60min * 24hr) = 828.5 days

2^32 frames running at 60 fps

~2.7 years

994 Day

2^32 * 2 * Centi Second == 994 Day

~3.7 years

32768 Hour

~4.5 years

39768.2 hours

2^32 frames running at 30 fps

~4.5 years

2^57 Nano Second == 40032 Hour

HPE releases urgent fix to stop enterprise SSDs conking out at 40K hours - https://news.ycombinator.com/item?id=22706968 - March 2020 (0 comments)

HPE SSD flaw will brick hardware after 40k hours - https://news.ycombinator.com/item?id=22697758 - March 2020 (0 comments)

Some HP Enterprise SSD will brick after 40000 hours without update - https://news.ycombinator.com/item?id=22697001 - March 2020 (1 comment)

HPE Warns of New Firmware Flaw That Bricks SSDs After 40k Hours of Use - https://news.ycombinator.com/item?id=22692611 - March 2020 (0 comments)

HPE Warns of New Bug That Kills SSD Drives After 40k Hours - https://news.ycombinator.com/item?id=22680420 - March 2020 (0 comments)

(there’s also https://news.ycombinator.com/item?id=32035934, but that was submitted today)

current theory:

2^53 * 62.5 MHz == 40032 hours

2^57 * 1 GHz == 40032 hours

2^63 * 64 GHz == 40032 hours

2^64 * 128 GHz == 40032 hours

~7.4 years

2^16 Hour == 2730.67 Day == 7.48 Year

~13.6 years

429496729.6 Second == 2^32 Deci Second

ALSO

5,000 days

In[1]:= 5000 * 24 * 60 * 60

Out[1]= 432000000

~15.84 years

500,000,000 seconds (15 years, 308 days, 53 minutes and 20 seconds)

~19.6 years

1024 Week == 10321920 Minute

~31.7 years

1 billion seconds

~34 years

0x40000000 seconds = 1073741824 seconds = 34.0481 years

Something to do with NTP

This requires the computer clock to be set within 34 years of the current time.

~36 years

It sound like that could equate to “Sat May 13 02:27:28 BST 2006”, or 1147483648 seconds since epoch, which makes it exactly 1,000,000,000 seconds until expiry of 32 bit time. Coincidence? Seems too strange as to a computer that is not a nice round number.

~68 years

2^31 seconds

In[1]:= 2^31 / 60 / 60 / 24 / 365 // N

Out[1]= 68.0963

~89.8 years

2831155200 seconds

~110 years

~136 years

2^32 seconds

In[1]:= 2^32 / 60 / 60 / 24 / 365 // N

Out[1]= 136.193

~157 years

2^13 weeks

~272 years

2^33 seconds

~292 years

2^63 Nano Second

https://docs.oracle.com/javase/8/docs/api/java/lang/System.html#currentTimeMillis–

Differences in successive calls that span greater than approximately 292 years (2^63 nanoseconds) will not correctly compute elapsed time due to numerical overflow.

~1260.31 years

2^16 weeks