Live data from Hacker News

Nanosecond timestamp collisions are common

evanjones.ca

231–240 of 291 posts

Re: Nanosecond timestamp collisions are common

#231

Earlier quoted context omitted.

The logistics of combining fields in indexes and identifiers is relatively complex, while the logistics of indexing a single field is comparatively trivial. This is also why you don't ship timestamps using separate fields for second/minute/hour/day/month/year, but a single ISO-string or UNIX timestamp as representation: it makes querying and interpreting the value more consistent.

Create a new column with an MD5 hash of the other columns. Easy. /s

This is how it works, except it's not MD5 but a less-costly hash function

Re: Nanosecond timestamp collisions are common

#232
post #225

Earlier quoted context omitted.

> location of birth may change My British passport says I was born in Birr; my Irish passport says I was born in Galway. These are both correct, because they are answering different questions. (I was born in the town of Ballinasloe in County Galway, but my mother's place of residence at the time of my birth was the town of Birr in County Offaly.)

So British place of birth means "mother's residence" and not place of birth?

Official guidances here: https://assets.publishing.service.gov.uk/government/uploads/...

Could maybe be just a mistake when doing the UK registration ? It's an easy fix if wanted.

Re: Nanosecond timestamp collisions are common

#233
post #167
post #166

Earlier quoted context omitted.

You’re complaining that the infrastructure details are bleeding into the intrastructure implementation?

Infrastructure details are bleeding into non-infrastructure implementation. Your database content is not an infrastructure implementation.

the content is not, but it can use a database function, such as CURRENT_TIMESTAMP or RANDOM() can it not?

Re: Nanosecond timestamp collisions are common

#234
Let me tell you about the time the performance guy figured out one of the big cycle eaters was that every CPU in the SMP system was trying to read the time of day from the same place in memory so they "fixed" that by giving every CPU its only copy of the current time ...

Re: Nanosecond timestamp collisions are common

#235
post #107
post #73

Earlier quoted context omitted.

For devices clocked above 1Ghz it's perfectly possible for the clock to increment every ns, although that doesn't make it accurate to that level, and multi core systems may have clocks that are not synchronised to that level. ARMv8 guarantees that it's clock increments at at least 1Ghz, for intel and earlier ARM it's more complicated

Cycle counting is one thing, but it gets tricky when you have frequency scaling in play. Another problem that even without freq scaling, cpu clocks are not designed to be super accurate/exact, and the true frequency might vary significantly even if the nominal freq is fixed

I think on newer x86 chips the ‘cycle’ counter increments at a ~constant rate, rather than changing with variable cpu frequencies. There’s a cpuid flag for this and I think Linux exposes it in procfs somewhere too. Older chips do have the problem you describe, as well as problems with cycle counts diverging (or never being close) between cores/sockets. It still isn’t exact in the way you describe. The most reasonable thing you can do is regularly calibrate based on an actual clock (whose rate also gets calibrated based on ntp…) to have a cyclesns conversion factor.

Re: Nanosecond timestamp collisions are common

#236

At some point doesn’t this come down to the ISA? A CPU running at 3GHz gets 3 clock cycles per nanosecond. I bet there is a fair amount of optimization in the compiler that leads to back to back assembly calls of reading the clock register. If subsequent time.Now() calls happen within 3 clock cycles of each other, can you really fairly expect unique nanosecond precision…

It takes like 20 cycles to read the cycle count register on modern chips. Even if collisions are somewhat unlikely, it’s still much worse to get several a day than ‘almost never going to happen’.

Re: Nanosecond timestamp collisions are common

#237

I’ve met too many people who are surprised by millisecond or microsecond timestamp collisions. My most memorable and least favorite variety of this is when people try to assemble a timestamp from two system calls, one for the most significant digits and a second for the least. If the smallest digits roll over from 99x to 00x after you read the large digits, due to process preemption, you can create a time stamp for a…

My most memorable example was some support discussion that went something like “we think you have a race condition, ”

“It can’t be a race condition as those two events happened in the exact same time”

Re: Nanosecond timestamp collisions are common

#238

Earlier quoted context omitted.

UUID7 was first drafted a bit over a year ago: https://datatracker.ietf.org/doc/html/draft-peabody-dispatch...

That's kinda what I figured. So you can see my confusion.

Perhaps one of many on this list[1]? ULID is listed as having 1.21e+24 unique per millisecond. I have no idea though about what may match up with your timeline(s).

[1] https://github.com/swyxio/brain/blob/master/R%20-%20Dev%20No...

Re: Nanosecond timestamp collisions are common

#239
post #24
post #21

If you want unique identifiers, use version 4 (random) UUIDs. Problem solved. The probability of a collision is roughly the same as the probability of a fully grown dinosaur spontaneously manifesting in your bedroom due to quantum fluctuations.

the dinosaur is now on my bed, what next?

[deleted]

Re: Nanosecond timestamp collisions are common

#240
post #232
post #225

Earlier quoted context omitted.

So British place of birth means "mother's residence" and not place of birth?

Official guidances here: https://assets.publishing.service.gov.uk/government/uploads/... Could maybe be just a mistake when doing the UK registration ? It's an easy fix if wanted.

> Could maybe be just a mistake when doing the UK registration ? It's an easy fix if wanted.

Changes! lol

Post reply on HN