Hi, I'm looking for ballpark figures on the following. Any ideas would be appreciated: In terms of lines of code and CPU load, how much processing is needed to account for deficiencies in the network? In other words, if you could assume very high QoS, predictable latency, etc., how much could you pare down your code or how much processing could you save? I realize it's a bit of an open ended question, but I'm trying to generate some rough stats of the "cost" of networking on networks with very little real QoS. Any thoughts at all would be helpful.

What does "very high" QoS mean? If it's 100%, you can save some code and processing time, but not a whole lot. As soon as you go to 99.9999% reliability, then you still have to be prepared for that unreliable event, and the amount of code and CPU spent is the same as, say, an Internet with 99% average packet reliability.

The amount of code is perhaps in the few thousands of lines of code (depends on protocol and application -- could be less). The amount of processing spent specifically on the unreliability of the network is probably not really measurable; it is (or should be) pretty small.

I doubt you could ever assume that data sent across the network would arrive intact, so as hplus says you have to be prepared for the loss. Even on a lan collisions occur or there can be interference or just a piece of hardware having an off day.


Code size is a piece of string variable as is the processing power required.

The 'advantage' to receiveing data as expected could reasonable hope to avoid extrapolation the missing data, which would hopefully be reasonable cheap to do anyway depending on the data and application.

<Very offtopic>

CrazedGenius, would you have a working e-mail address somewhere? Your profile one and the one in your real-time rendering book both do not work :(.

</offtopic>

Sorry for bumping this topic for this. :)