3 ms·

Given enough of these fault analysis articles, I wonder if it’s possible to compile them into some kind of decision tree-like interface where you can describe y

Given enough of these fault analysis articles, I wonder if it’s possible to compile them into some kind of decision tree-like interface where you can describe your problems and have it guide possible failure scenarios (plus diagnose steps). Would be cool to collect all of this knowledge beyond google, as this is the type of stuff where Google often breaks down.

physicsgraph 6y ago
I agree with your suggestion conceptually, but the starting point of a decision tree strongly depends on many factors: which version of the software is being used, how the software was compiled, running with what OS, which what patches, on what hardware, under what environmental conditions, in support of what application usage patterns, and what load, etc. Merely capturing the (potentially) relevant input conditions becomes challenging, never mind the process of eliminating irrelevant variables. And that's all premised on the concept that a problem is recurring (rather than some fluke that no one else has encountered). I think that's why Stack Overflow websites focused on shallow conditions flourish -- the deep dives are usually specific to a given situation.
toast0 6y ago
1) run tcpdump on both sides and compare 2) If both sides have the same tcpdump, it's not a network problem. Find the software problem. truss or strace can help 3) If the sides differ; figure out if the network is broken, or the os/network card is lying. 4) If the network is broken, fix it ;) 5) if the os/network card is lying, turn off the lying (mostly offloads, like segmentation, large receive, and checksum) and go back to step 1 This is basically common pattern debugging. I'm not getting the results that I expect; find a way to observe when/where the data in progress changes from what I expect to something else; along the way, being as explicit as needed about what data is expected. The closer you can narrow down where the failure occurs, the more likely you are to be able to find the failure, or a person responsible for fixing the failure who you can give your investigation results to and they can fix the failure.

physicsgraph 6y ago

I agree with your suggestion conceptually, but the starting point of a decision tree strongly depends on many factors: which version of the software is being used, how the software was compiled, running with what OS, which what patches, on what hardware, under what environmental conditions, in support of what application usage patterns, and what load, etc. Merely capturing the (potentially) relevant input conditions becomes challenging, never mind the process of eliminating irrelevant variables. And that's all premised on the concept that a problem is recurring (rather than some fluke that no one else has encountered). I think that's why Stack Overflow websites focused on shallow conditions flourish -- the deep dives are usually specific to a given situation.

toast0 6y ago

1) run tcpdump on both sides and compare 2) If both sides have the same tcpdump, it's not a network problem. Find the software problem. truss or strace can help 3) If the sides differ; figure out if the network is broken, or the os/network card is lying. 4) If the network is broken, fix it ;) 5) if the os/network card is lying, turn off the lying (mostly offloads, like segmentation, large receive, and checksum) and go back to step 1 This is basically common pattern debugging. I'm not getting the results that I expect; find a way to observe when/where the data in progress changes from what I expect to something else; along the way, being as explicit as needed about what data is expected. The closer you can narrow down where the failure occurs, the more likely you are to be able to find the failure, or a person responsible for fixing the failure who you can give your investigation results to and they can fix the failure.