Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[JGO]

In hardware design it is taken as read that too much BITE reduces reliability, since all  hardware has similar reliability so the probability of a false diagnosis increases with the proportion of test equipment. ( Using more reliable test equipment is rubber gloves for a leaky fountain pen; it would be better used for the prime purpose of reducing faults rather than better diagnosis).

Similar considerations must apply to software; has anyone a figure for the useful proportion ?



 

[roseway]

I'm not sure that it's possible to quantify it for software. Any reasonably complex program will be littered with small tests, for example to check that values don't go out of range and to trap errors which can occur as a result of unexpected events. I don't know where you would draw the line between these necessary error avoidance measures and BITE.

[boost]

How bizarre!

[JGO]

Roseway

" I don't know where you would draw the line between these necessary error avoidance measures and BITE."

- yes  a good point.

  Off the cuff I'd say if the user doesn't see error avoidance etc  it isn't a fault, but in  cases  say where the presence of external test software shows up a fault in a router which is not harmful nor normally visible,  it reduces user confidence unnecessarily.   OK some cars beep if the driver applies the handbrake with the engine running, useful warning but at traffic lights on a steep hill not a fault.   

[roseway]

Are you suggesting that monitoring programs provide too much information, and this is more likely to confuse users than to be helpful to them? If so, we're back at the question of where to draw the line, because some of the information can be confusing or worrying to a non-technical user, but very helpful to a more knowledgeable user.

I guess a better example of what you're saying would be where the monitoring program has a bug which results in completely wrong results being reported. But I don't think this means that the results shouldn't be reported at all - it just means that the programmers need to fix the bugs.

[renluop]

Prime example of B.I.T.E

Putting on coat now!

[kitz]

say where the presence of external test software shows up a fault in a router which is not harmful nor normally visible,  it reduces user confidence unnecessarily

Sorry if Im being a bit slow, but I cant quite think what you're attempting to say.   What type of hardware fault in the router would you mean....  or do you mean to say about line diagnostics.   If you mean line data then Id have to agree with eric that the information available is "very helpful to a more knowledgeable user."

The danger is that some users get hooked and overly concerned about certain things that are within the realms of normality.   The sad fact is that although this information can be very useful, there will be some who take it to the extreme.   We've seen it happen many times before which has caused certain router manufacturers not making such information available anymore (eg Thomson/Speedtouch) and ISPs deliberately locking down routers. 

Ive seen a document somewhere (cant recall now what it was exactly and where it was) but BT was citing DMTtool by name as a reason why there were problems when the EU's starting tweaking their SNRm and causing instability issues.      Its no big secret that it was the likes of BT that had the [purchasing] power to get Thomson to totally remove certain info from their routers.

[boost]

I can't quite get my head around this at all tbh.

I came to the conclusion it must be a common engineering thing which relates specifically to moving parts although I couldn't really think of an example where too much diags would be bad but this is probably my curent 'DSLstats' mindset of log everything in case something bad happens so I can scrutinise the history.