[time-nuts] GPS Outage

jimlux jimlux at earthlink.net
Tue Mar 1 09:24:32 EST 2016


On 2/29/16 10:56 PM, Magnus Danielson wrote:
>
>
> On 02/29/2016 11:31 AM, Martin Burnicki wrote:
>> Hal,
>>
>> Hal Murray wrote:
>>>
>>> martin.burnicki at burnicki.net said:
>>>>> Strange that at least 3 independant firmware trees/development
>>>>> teams should
>>>>> chose the same magic wk860.
>>>
>>>> I don't find it strange. If the next firmware version is based on the
>>>> previous version and none of the developers has stumbled across this
>>>> potential problem earlier ...
>>>
>>> That sounds like poor software engineering.  Or poor engineering
>>> management.
>>>
>>> The wk860 is supposed to represent the build time of the software ...
>>
>> Do you *know* this, or are you just *assuming* this? ;-)
>>
>>> so it will
>>> work for 20 years from when it was built rather than 20 years from
>>> when the
>>> 10 bit week counter last rolled over or 20 years from when the
>>> constant was
>>> last updated.
>>
>> There are also approaches where the proper extension of a week number
>> doesn't just work within a single 1024 week cycle with some hardcoded
>> limit, like this simple example:
>>
>> if ( wn < 860 )
>>    wn += 1024;
>>
>> There may always be pieces of code which generate a faulty result under
>> certain conditions, and no stumbles across this even in reviews until it
>> really happens.
>>
>> I'm not aware of *any* project where each single line of code is checked
>> once again whenever a new release is rolled out.
>
> Rather, in all projects I've seen there is a tendency to trust existing
> code and only extend it. Re-validating it is usually regarded as money
> in the sea. That old code can have incorrect assumptions that you
> eventually expose as you change its environment is a re-occurring
> learning experience.


Ariane 5...




  Modern approaches to testing helps, and working on
> the backlog of testing can help to disclose such problems, but only if
> the test-code writer has the mindset that covers the problem at hand.
> It's easy to make bold statements, reality is much more humbling
> experience in the long run. Good test-benches will aid you as you want
> to make larger clean-ups of old code. Larger clean-ups helps to expose
> old bugs as you actually look at the code as a designer again. It is
> also humbling to see what errors a younger yourself did and how you now
> don't do such design anymore as you have been bitten badly by the bug.
>





More information about the time-nuts mailing list