For a brief period, the Windows kernel tried to deal with gamma rays

Re:For a brief period, the Windows kernel tried to deal with... by tjoff on Tuesday November 20, 2018 @02:55PM (#18497092)

Bit flips in network surely is many orders of magnitude worse than in cache/memory bit flips? And I doubt it has to do with gamma rays.

Those with poor or long distance DSL do see a big increase in errors.

And while hopefully getting rarer now home routers could easily overheat and introduce errors as soon as they saw more than usual traffic.

We recently had issues with the power supply for our router and it also caused issued.

[ Parent | on HN ]

Re:For a brief period, the Windows kernel tried to deal with... by groestl on Tuesday November 20, 2018 @04:11PM (#18497765)

> Bit flips in network surely is many orders of magnitude worse

Yes, but because it's so prevalent that people expect it, they've added checksums on multiple levels, so the network actually performs better. In this particular instance (DNS queries), it's very unlikely that the data was corrupted in transit: "We believe that UDP checksums are effective at preventing 'bitsquat' attacks and other types of errors that occur after a DNS query leaves a DNS resolver and enters the network."

[ Parent | on HN ]

Re:For a brief period, the Windows kernel tried to deal with... by tjoff on Tuesday November 20, 2018 @04:19PM (#18497846)

That doesn't take into consideration of flaky home-routers (note that they do recalculate the checksum). So the checksum might be processed on bad data.

For a bad connection it will also be quite common that the checksum will happen to be valid. TCP/UDP checksums are quite bad.

[ Parent | on HN ]

Re:For a brief period, the Windows kernel tried to deal with... by dfox on Tuesday November 20, 2018 @06:45PM (#18498954)

One thing to keep in mind is that the network protocols usually use quite weak and similar checksums. To the extent that there are layer combinations that reliably produce errors that are not detectable by TCP checksum.

[ Parent | on HN ]

Re:For a brief period, the Windows kernel tried to deal with... by acdha on Tuesday November 20, 2018 @09:16PM (#18499714)

Has anyone published results on the impact of large scale TLS deployment on reliability? I’ve seen some older papers on errors which TCP missed but it seems like making a hard fail would be a nice win as the crypto overhead keeps getting cheaper.

[ Parent | on HN ]

Re:For a brief period, the Windows kernel tried to deal with... by spullara on Tuesday November 20, 2018 @04:47PM (#18498091)

I saw them at multiple places in the stack. Usually the Host header showed my domain which rules out the network. Rarely would the Host header be the original domain though that doesn't narrow it down to the network.

[ Parent | on HN ]

Re:For a brief period, the Windows kernel tried to deal with... by mattnewton on Tuesday November 20, 2018 @04:06PM (#18497727)

The end of gp’s Article points to some work by a verisign engineer that put the network probability very low. So my interpretation was these but flips were happening on device before the network stack was dispatched at a url.

[ Parent | on HN ]

Re:For a brief period, the Windows kernel tried to deal with... by jhallenworld on Wednesday November 21, 2018 @12:33AM (#18500369)

So Ethernet is protected by CRC which is quite good, but it is stripped at both ends and I would not trust the routing chips at all. Some core routers used low reliability FPGAs for example..

[ Parent | on HN ]

Re:For a brief period, the Windows kernel tried to deal with... by kingosticks on Wednesday November 21, 2018 @05:47PM (#18506711)

If you require data integrity you cannot rely on ethernet's FCS. Personally I trust the core router far more than I trust the cheaper stuff around it, particularly the stuff my ISP gave me for 'free'.

[ Parent | on HN ]