7 ms·

This is maybe a very dumb question but was it so expensive to add several bits (and extend its lifespan exponentially) to what is basically a counter?

kixpanganiban 4y ago
It's probably less about adding a few bits to the counter, and more about replacing the existing counters that are already deployed everywhere in the world. Industrial applications usually go by "if it ain't broke, don't fix it" and stick with decades-old machines as long as they still get the job done.
- awestroke 4y ago
  The question is if it would have been that expensive to make it more than 10 bits to begin with
  - kixpanganiban 4y ago
    We as a human race have been terrible at anticipating how fast numbers grow. A similar story is that with databases, we used to think that 32bit primary keys were plenty big enough to store all the numbers we'll ever need. In all likelihood, people who manufactured these timers in the past thought that their equipment would never outlive the need for 10 bits.
    - swores 4y ago
      There's a difference between not anticipating use of products changing in scale to the point that database PKs might need to be longer (which I would assume, albeit as an uneducated guess, has seen closer to exponential than linear growth in terms of maximum length required for unique IDs in databases), vs. anticipating "this timer will definitely hit a limit in 2022, unless the physics of time as we know it somehow changes before then". Sure it's still a relatively easy mistake to either wrongly assume that all of whatever you're creating will be in landfill by 2022 if you were making it long enough ago that all devices would be dead by now for other reasons (or to unethically do that intentionally, to cause customers to repurchase products this year - seems pretty unlikely but perhaps...), or to just forget to think about it, or think about it and assume it's fine for now and can be checked later before then forgetting. But "We as a human race have been terrible at anticipating how fast numbers grow" - we're talking about a number that's growing exactly in sync with time, and with an entirely simple way of checking when the limit will be hit, so I think it's just sloppy/lazy or expecting less longevity of use for their product, more than a flaw of humanity.
      - wolrah 4y ago
        100% agreed. When it comes to any kind of incrementing counter, IMO the limit should always be multiple orders of magnitude greater than the expected lifespan of the system. Taking OP at face value, these devices' counter has a zero point on February 1, 2003 so if we don't know what happens when they roll over they must have been designed after that point. In the world of the 2000s even 16 bit processing is old school, so there's no good reason this couldn't have been a 16 bit counter instead. If that had been the case the rollover wouldn't be until the year 3259. IMO this is the correct way to handle situations where you think you don't need any more, round up from your reasonable limit to the next major "bit border". If you have a 10 bit counter, round up to 16. If you need 16, then make it 24 or 32. The limit shouldn't just be "above where we expect it to reach in its lifespan" but "if you hit this the device belongs in a museum". Designing a device with a 10 bit week counter in the 2000s is bad design, prioritizing either laziness or cost over quality.
    - avgcorrection 4y ago
      Numbers grow unpredictably—it’s true. People in the 1970’s didn’t anticipate that we’d get to the time Sep 2022. :) How time flies.
      - cesarb 4y ago
        > People in the 1970’s didn’t anticipate that we’d get to the time Sep 2022. No, they just didn't anticipate that a GPS receiver would not know which decade it is (knowing the decade is enough to disambiguate a 10-bit week number) even though it knew the correct date a few moments ago. That is, they didn't anticipate counter rollover bugs caused by hard-coding of the starting point of the counter, instead of calculating it based on the last seen date.
        nullc 4y ago
        last seen date means a single spoofed signal yields future dates forever. Give some credit to the engineers who built these receivers and their firmware. They're extremely complex and nuanced. You can be absolutely sure that they carefully considered their options here and chose a tradeoff that made sense given the constrains they were designing for. I'm confident they anticipated them, but they just concluded that the fixes beyond using the mfgr date as a base point were worse than the disease. It's easy to criticize from the future when we know what happened, e.g. e.g. that there was an almost 20 year delay in deployment of the modernized GPS signals and many people kept using these devices far longer than anticipated.
      - fsckboy 4y ago
        most of the people in the 1970’s didn’t get to the time Sep 2022!
    - amelius 4y ago
      > We as a human race have been terrible at anticipating how fast numbers grow. But in this case it was easy ... it's a timer!
lrem 4y ago
No. But which way did incentives align?
Matumio 4y ago
I remember how we once ran into trouble with a large timestamp counter in a FPGA implementation. (Was it just 64 bits, or 112 bits? Probably the full PTP timestamp, including fractional nanoseconds for precise drift corrections.) The extra bits of storage are cheap. The problem is the addition circuitry. With a small counter, you can do addition in a single clock cycle, very easy to implement. With a large counter, addition of the highest bit has to wait for completion of the previous one, etc. so if this takes longer than one clock cycle you have to implement a different, pipelined addition algorithm. (Or run everything at lower clock frequency.)
- pbhjpbhj 4y ago
  Naive question. Do processors ever have sub-elements that run at a higher clock. I can imagine trying to hack this sort of thing by putting some sort of subprocessor structure that does addition for a particular set of registers at twice normal speed (double length registers?? I'm clearly spitballing). I guess it can't because of memory bandwidth constraints?
  - rcxdude 4y ago
    Normally you'll do the opposite: you'll have sub-parts which run at a lower clock rate. The 'core clock' is generally the fastest clock in the system, at least outside of specific high-speed transceivers. The most common approach is to pipeline the operation, which increases latency of the operation but still gives you the same throughput so long as the output does not need to feed back into the input within the operation time.
    - CuriousCosmic 4y ago
      To add onto this you can easily increase the clock for specific clock domains using a PLL (Phase locked loop) as a clock multiplier. This comes with all kinds of caveats and complications(PLL clock multiplication is "fuzzy" and subject to phase drift and variations in actual frequency while normal clock division is essentially as close to exact as you can really get). Because of this, like mentioned it's preferable to use clock division instead of clock multiplication where possible.
cesarb 4y ago
> was it so expensive to add several bits If this is the GPS week number, there is very limited space for it in the GPS navigation message; every extra bit used for the counter means one less bit for everything else. From what I've read, the navigation message is transmitted at only 50 bits per second, and the time including the week number repeats every 6 seconds, so they had only 300 bits to play with. Given that a 10-bit week number already allows for nearly 20 years, a receiver only needs to know which decade it is today for that value not to be ambiguous, and that should be easy for a receiver with a few bits of local storage unless it's been powered off for more than a decade.
- nullc 4y ago
  > and that should be easy for a receiver with a few bits of local storage unless unless it gets a single spoofed or corrupted signal, then it's stuck in the future. Of course you can implement countermeasures, like requiring months of observation to advance the flag, but that makes it much less easy (and harder to test). > it's been powered off for more than a decade. That's also a concern. You don't want a receiver to get hit by lightning then get swapped out with a spare on the shelf and suddenly get the wrong date. Now you need a provisioning step that requires remote access to a normally completely embedded component. Again, not insurmountable-- but it's getting away from easy.

kixpanganiban 4y ago

It's probably less about adding a few bits to the counter, and more about replacing the existing counters that are already deployed everywhere in the world. Industrial applications usually go by "if it ain't broke, don't fix it" and stick with decades-old machines as long as they still get the job done.

awestroke 4y ago
The question is if it would have been that expensive to make it more than 10 bits to begin with
- kixpanganiban 4y ago
  We as a human race have been terrible at anticipating how fast numbers grow. A similar story is that with databases, we used to think that 32bit primary keys were plenty big enough to store all the numbers we'll ever need. In all likelihood, people who manufactured these timers in the past thought that their equipment would never outlive the need for 10 bits.
  - swores 4y ago
    There's a difference between not anticipating use of products changing in scale to the point that database PKs might need to be longer (which I would assume, albeit as an uneducated guess, has seen closer to exponential than linear growth in terms of maximum length required for unique IDs in databases), vs. anticipating "this timer will definitely hit a limit in 2022, unless the physics of time as we know it somehow changes before then". Sure it's still a relatively easy mistake to either wrongly assume that all of whatever you're creating will be in landfill by 2022 if you were making it long enough ago that all devices would be dead by now for other reasons (or to unethically do that intentionally, to cause customers to repurchase products this year - seems pretty unlikely but perhaps...), or to just forget to think about it, or think about it and assume it's fine for now and can be checked later before then forgetting. But "We as a human race have been terrible at anticipating how fast numbers grow" - we're talking about a number that's growing exactly in sync with time, and with an entirely simple way of checking when the limit will be hit, so I think it's just sloppy/lazy or expecting less longevity of use for their product, more than a flaw of humanity.
    - wolrah 4y ago
      100% agreed. When it comes to any kind of incrementing counter, IMO the limit should always be multiple orders of magnitude greater than the expected lifespan of the system. Taking OP at face value, these devices' counter has a zero point on February 1, 2003 so if we don't know what happens when they roll over they must have been designed after that point. In the world of the 2000s even 16 bit processing is old school, so there's no good reason this couldn't have been a 16 bit counter instead. If that had been the case the rollover wouldn't be until the year 3259. IMO this is the correct way to handle situations where you think you don't need any more, round up from your reasonable limit to the next major "bit border". If you have a 10 bit counter, round up to 16. If you need 16, then make it 24 or 32. The limit shouldn't just be "above where we expect it to reach in its lifespan" but "if you hit this the device belongs in a museum". Designing a device with a 10 bit week counter in the 2000s is bad design, prioritizing either laziness or cost over quality.
  - avgcorrection 4y ago
    Numbers grow unpredictably—it’s true. People in the 1970’s didn’t anticipate that we’d get to the time Sep 2022. :) How time flies.
    - cesarb 4y ago
      > People in the 1970’s didn’t anticipate that we’d get to the time Sep 2022. No, they just didn't anticipate that a GPS receiver would not know which decade it is (knowing the decade is enough to disambiguate a 10-bit week number) even though it knew the correct date a few moments ago. That is, they didn't anticipate counter rollover bugs caused by hard-coding of the starting point of the counter, instead of calculating it based on the last seen date.
      - nullc 4y ago
        last seen date means a single spoofed signal yields future dates forever. Give some credit to the engineers who built these receivers and their firmware. They're extremely complex and nuanced. You can be absolutely sure that they carefully considered their options here and chose a tradeoff that made sense given the constrains they were designing for. I'm confident they anticipated them, but they just concluded that the fixes beyond using the mfgr date as a base point were worse than the disease. It's easy to criticize from the future when we know what happened, e.g. e.g. that there was an almost 20 year delay in deployment of the modernized GPS signals and many people kept using these devices far longer than anticipated.
    - fsckboy 4y ago
      most of the people in the 1970’s didn’t get to the time Sep 2022!
  - amelius 4y ago
    > We as a human race have been terrible at anticipating how fast numbers grow. But in this case it was easy ... it's a timer!

lrem 4y ago

No. But which way did incentives align?

Matumio 4y ago

I remember how we once ran into trouble with a large timestamp counter in a FPGA implementation. (Was it just 64 bits, or 112 bits? Probably the full PTP timestamp, including fractional nanoseconds for precise drift corrections.) The extra bits of storage are cheap. The problem is the addition circuitry. With a small counter, you can do addition in a single clock cycle, very easy to implement. With a large counter, addition of the highest bit has to wait for completion of the previous one, etc. so if this takes longer than one clock cycle you have to implement a different, pipelined addition algorithm. (Or run everything at lower clock frequency.)

pbhjpbhj 4y ago
Naive question. Do processors ever have sub-elements that run at a higher clock. I can imagine trying to hack this sort of thing by putting some sort of subprocessor structure that does addition for a particular set of registers at twice normal speed (double length registers?? I'm clearly spitballing). I guess it can't because of memory bandwidth constraints?
- rcxdude 4y ago
  Normally you'll do the opposite: you'll have sub-parts which run at a lower clock rate. The 'core clock' is generally the fastest clock in the system, at least outside of specific high-speed transceivers. The most common approach is to pipeline the operation, which increases latency of the operation but still gives you the same throughput so long as the output does not need to feed back into the input within the operation time.
  - CuriousCosmic 4y ago
    To add onto this you can easily increase the clock for specific clock domains using a PLL (Phase locked loop) as a clock multiplier. This comes with all kinds of caveats and complications(PLL clock multiplication is "fuzzy" and subject to phase drift and variations in actual frequency while normal clock division is essentially as close to exact as you can really get). Because of this, like mentioned it's preferable to use clock division instead of clock multiplication where possible.

cesarb 4y ago

> was it so expensive to add several bits If this is the GPS week number, there is very limited space for it in the GPS navigation message; every extra bit used for the counter means one less bit for everything else. From what I've read, the navigation message is transmitted at only 50 bits per second, and the time including the week number repeats every 6 seconds, so they had only 300 bits to play with. Given that a 10-bit week number already allows for nearly 20 years, a receiver only needs to know which decade it is today for that value not to be ambiguous, and that should be easy for a receiver with a few bits of local storage unless it's been powered off for more than a decade.

nullc 4y ago
> and that should be easy for a receiver with a few bits of local storage unless unless it gets a single spoofed or corrupted signal, then it's stuck in the future. Of course you can implement countermeasures, like requiring months of observation to advance the flag, but that makes it much less easy (and harder to test). > it's been powered off for more than a decade. That's also a concern. You don't want a receiver to get hit by lightning then get swapped out with a spare on the shelf and suddenly get the wrong date. Now you need a provisioning step that requires remote access to a normally completely embedded component. Again, not insurmountable-- but it's getting away from easy.