How do I interpret Perfmon data? - networking

I used PerfMon on Windows XP for checking network load of an application that I have written.
In the below example you see five columns:
Date Time, Bandwidth, [x] Bytes per seconds sent, [x] Bytes per second
received, [x] Total Bytes per second
[x] == The network interface that I checked the load against
Here's the data.
02/18/2014 15:30:50.894,"1000000000","922.92007218169454","826.92838536756381","1749.8484575492582"
02/18/2014 15:30:51.894,"1000000000","994.06970480770792","774.05427718427154","1768.1239819919795"
02/18/2014 15:30:52.894,"1000000000","1446.0226222234514","1319.0206353476713","2765.0432575711229"
02/18/2014 15:30:53.894,"1000000000","2652.0592714274339","1207.0269760983833","3859.0862475258173"
Date, Time and bandwidth (10^9 bit = 1Gbit (lan connection)) are obviously correct.
The other 3 columns are hard to interpret! It says the unit is bytes per second for each but how can the system resolve 14 respectively 13 digits after the decimal dot if these were really bytes?
What is 0.0000000000000001 byte?
Indeed the values are plausible until reaching the dot.

The timer's resolution is higher than shown. You might send 923076 bytes in 100003 microseconds, so the trace shows 100 milliseconds and ignores the microseconds in the time column, but calculates 923076/100003 for the bytes per seconds column. Note i made up the numbers, doesn't make much sense to find a pair that gives your 922.9200... exactly.

Related

Is it possible to encode date AND time (with some caveats) into 12 bits?

I have at my disposal 16 bits. Of them, 4 bits are the header and cannot be touched. This leaves us with 12 bits. I would like to encode date and time data into them. These are essentially logs being sent over LPWAN.
Obviously, it's impossible to encode proper generic date and time into it. Since the unix timestamp uses 32 bits, and projects like Compact Time Format use 5 bytes.
Let's say we don't really need the year, because this information is available elsewhere. Let's also say the time resolution of seconds doesn't have to be super accurate, so we can split the seconds into 30 second intervals. If we were to simply encode the data as is then:
4 bits month (0-11)
5 bits day (0-31)
5 bits hour (0-23)
6 bits minute (0-59)
1 bit second (0,30)
-----------------------------
21 bits
21 bits is much better than 32. But it's still not 12. I could subtract one bit from the minutes (rounding to the nearest even minute), and remove the seconds but that still leaves us with 19 bits. Which is still far from 12.
Just wondering if it's possible, and if anyone has any ideas.
12 bits can hold 2^12 = 4096 values, which feels pretty tight for a task. Not sure much can be done in terms of compressing a date time into a 4096 number. It is too little space to represent this data.
There are some workarounds, none of them able to achieve what you want, but maybe something you could use anyway:
Split date and time. Alternate with some algorithm between sending date/time, one bit can be used to indicate what data is being sent. This leaves 11 bits to encode either date or time. You could go a bit further and split time like this as well. Receiving side can then reconstruct a full date time having access to the previously received data.
You could have a schema where one date packet is sent as a starting point, and subsequent packets are incremented in N-second intervals from the start of the epoch
Remove date time from data completely, saving 12 bits, but send it periodically as a stand-alone heartbeat/datetime packet.
You could try compressing the whole data packet which could allow using more bits to represent date time and still fit into a smaller overall packet size
If data is sent at reasonable fixed intervals, you could use a circular counter of an interval of N seconds, this may work if you have few devices and you can keep track of when they start transmitting. For example a satellite was launched on XYZ date time, it send counter every 30 seconds, we received counter value of 100, to calculate date we use simple math XYZ + 30*100 seconds
No. Unless you'd be happy with representing less than a span of a day and a half. You can just count 4096 30-second intervals, and find that that will cover 34 hours and eight minutes. 4096 two-minute intervals is just four times that, or five days, 16 hours, and 32 minutes. Still a small fraction of a year.
If you can assure that the difference between successive log entries is small, then you can stuff that in 12 bits. You will need a special entry to give an initial date, and maybe you could insert such an entry when the difference betweem successive entries is too large.
#oleksii has some other good suggestions as well.

AX.25 protocol interfering with sending data packet

I am very sorry to not be able to provide code for this question but it is more of a logical situation. My termination sequence for the AX.25 protocol is "111111" which is six 1s. So if this sequence of 1s is found inside my data packet, it will denote the end of the packet file and send it without correctly sending the rest of the packet. I will do my best to explain my conclusions and test results such that you can understand my dilemma.
***Programming in Arduino******
byte 1 contains 8 bits. Look below and attempt to picture a byte in a rectangular box. right next to it is byte 2 which also contains 8 bits.
Situation 1:
||_1_0_1_1_1_0_1_0_ ||_1_1_1_1_1_1_0_0_||
Attempted Solution 1: you could simply change 1 into 0 and keep track of it.
Situation 2:
||_1_0_1_1_1_0_1_1_ ||_1_1_1_1_0_0_1_0_||
Attempted Solution 2: attempted solution 1 breaks apart. and I am stuck here.
Individually the bytes are safe from activating AX.25 termination sequence but combined bytes results in a problem.
Here is a list of possible cases:
1) six 1s = termination sequence activated for end of packet
2) six 1s inside actual data of packet = premature termination
3) if 1s are changed to 0s than a sequence of six 0s can be a problem in reverting changes back
4) can only read 1 byte at a time (EEPROM) due to memory limitations
5) if six 1s occur between two bytes will also prematurely activate termination sequence.
Thank you in advance for any kind of help.
The solution mandated by the ax.25 protocol is bit stuffing.
Conceptually, any time the receiver sees five sequential one bits and a zero bit, it assumes that the zero bit has been stuffed by the sender (to break up erroneous frame sequences in the data), and removes it before emitting the received data. The only sequence of six 1-bits that can have been sent un-stuffed is the framing sequence; all data will have been sent stuffed. The receiver must always de-stuff.
To stuff or unstuff will generally require a couple of bytes of working ram (or a couple of bytes of registers), although there might be creative ways around that.
To quote the official TAPR protocol standard:
"In order to ensure that the flag bit sequence mentioned above does not appear accidentally anywhere else in a frame, the sending station monitors the bit sequence for a group of five or more contiguous “1” bits. Any time five contiguous “1” bits are sent, the sending station inserts a “0” bit after the fifth “1” bit. During frame reception, any time five contiguous “1” bits are received, a “0” bit immediately following five “1” bits is discarded."
A google search for AX.25 bit stuffing should return as much detail as you might need.

Sliding window protocol, calculation of sequence number bits

I am preparing for my exams and was solving problems regarding Sliding Window Protocol and I came across these questions..
A 1000km long cable operates a 1MBPS. Propagation delay is 10 microsec/km. If frame size is 1kB, then how many bits are required for sequence number?
A) 3 B) 4 C) 5 D) 6
I got the ans as C option as follows,
propagation time is 10 microsec/km
so, for 1000 km it is 10*1000 microsec, ie 10 milisec
then RTT will be 20 milisec
in 10^3 milisec 8*10^6 bits
so, in 20 milisec X bits;
X = 20*(8*10^6)/10^3 = 160*10^3 bits
now, 1 frame is of size 1kB ie 8000 bits
so total number of frames will be 20. this will be a window size.
hence, to represent 20 frames uniquely we need 5 bits.
the ans was correct as per the answer key.. and then I came across this one..
Frames of 1000 bits are sent over a 10^6 bps duplex link between two hosts. The propagation time is
25ms. Frames are to be transmitted into this link to maximally pack them in transit (within the link).
What is the minimum number of bits (l) that will be required to represent the sequence numbers distinctly?
Assume that no time gap needs to be given between transmission of two frames.
(A) l=2 (B) l=3 (C) l=4 (D) l=5
as per the earlier one I solved this one like follows,
propagation time is 25 ms
then RTT will be 50 ms
in 10^3 ms 10^6 bits
so, in 50 ms X bits;
X = 50*(10^6)/10^3 = 50*10^3 bits
now, 1 frame is of size 1kb ie 1000 bits
so total number of frames will be 50. this will be a window size.
hence, to represent 50 frames uniquely we need 6 bits.
and 6 is not even in the option. Answer key is using same solution but taking propagation time not RTT for calculation. and their answer is 5 bits. I am totally confused, which one is correct?
I don't see what RTT has to do with it. The frames are only being sent in one direction.
Round-Trip-Time means that you have to take into account the ACK (acknowledgement message) you must receive that tells you the frames you are sending are being received by on the other side of the link. This 'time' window is the period where you get to send the remaining frames that the window allows you to send before you anticipate an ACK.
Ideally you want to be able to transmit continuously, i.e not having to stop at the window frame limit to wait for an ACK (which is essentially turns into a stop-and-wait situation if you have to stop and wait for the ack. The solution to this question is: the minimum number of frames that will be transmitted from the moment the first frame is transmitted to the moment you get an ack. (also known as the size for a large window)
Your calculations look to be correct in both cases and it would be safe to assume the answer choices for the second question are wrong .
Here its duplex channel so YOUR RTT= Tp hence they have considered Tp
Now you will get X = 25*10³
So total bits of window will be 5..

What is the difference between baud rate and bit rate?

I am really having hard time understanding the difference. Some say they are same, while others say there is a slight difference. What's the difference, exactly? I would like it if you explained with some analogy.
Bits per second is straightforward. It is exactly what it sounds like. If I have 1000 bits and am sending them at 1000 bps, it will take exactly one second to transmit them.
Baud is symbols per second. If these symbols — the indivisible elements of your data encoding — are not bits, the baud rate will be lower than the bit rate by the factor of bits per symbol. That is, if there are 4 bits per symbol, the baud rate will be ¼ that of the bit rate.
This confusion arose because the early analog telephone modems weren't very complicated, so bps was equal to baud. That is, each symbol encoded one bit. Later, to make modems faster, communications engineers invented increasingly clever ways to send more bits per symbol.¹
Analogy
System 1, bits: Imagine a communication system with a telescope on the near side of a valley and a guy on the far side holding up one hand or the other. Call his left hand "0" and his right hand "1," and you have a system for communicating one binary digit — one bit — at a time.
System 2, baud: Now imagine that the guy on the far side of the valley is holding up playing cards instead of his bare hands. He is using a subset of the cards, ace through 8 in each suit, for a total of 32 cards. Each card — each symbol — encodes 5 bits: 00000 through 11111 in binary.²
Analysis
The System 2 guy can convey 5 bits of information per card in the same time it takes the System 1 guy to convey one bit by revealing one of his bare hands.
You see how the analogy seems to break down: finding a particular card in a deck and showing it takes longer than simply deciding to show your left or right hand. But, that just provides an opportunity to extend the analogy profitably.
A communications system with many bits per symbol faces a similar difficulty, because the encoding schemes required to send multiple bits per symbol are much more complicated than those that send only one bit at a time. To extend the analogy, then, the guy showing playing cards could have several people behind him sharing the work of finding the next card in the deck, handing him cards as fast as he can show them. The helpers are analogous to the more powerful processors required to produce the many-bits-per-baud encoding schemes.
That is to say, by using more processing power, System 2 can send data 5 times faster than the more primitive System 1.
Historical Vignette
What shall we do with our 5-bit code? It seems natural to an English speaker to use 26 of the 32 available code points for the English alphabet. We can use the remaining 6 code points for a space character and a small set of control codes and symbols.
Or, we could just use Baudot code, a 5-bit code invented by Émile Baudot, after whom the unit "baud" was coined.³
Footnotes and Digressions:
For example, the V.34 standard defined a 3,429 baud mode at 8.4 bits per symbol to achieve 28.8 kbit/sec throughput.
That standard only talks about the POTS side of the modem. The RS-232 side remains a 1 bit per symbol system, so you could also correctly call it a 28.8k baud modem. Confusing, but technically correct.
I've purposely kept things simple here.
One thing you might think about is whether the absence of a playing card conveys information. If it does, that implies the existence of some clock or latch signal, so that you can tell the information-carrying absence of a card from the gap between the display of two cards.
Also, what do you do with the cards left over in a poker deck, 9 through King, and the Jokers? One idea would be to use them as special flags to carry metadata. For example, you'll need a way to indicate a short trailing block. If you need to send 128 bits of information, you're going to need to show 26 cards. The first 25 cards convey 5×25=125 bits, with the 26th card conveying the trailing 3 bits. You need some way to signal that the last two bits in the symbol should be disregarded.
This is why the early analog telephone modems were specified in terms of baud instead of bps: communications engineers had been using that terminology since the telegraph days. They weren't trying to confuse bps and baud; it was simply a fact, in their minds, that these modems were transmitting one bit per symbol.
I don't understand why everyone is making this complicated (answers).
I'll just leave this here.
So above would be:
Signal Unit: 4 bits
Baud Rate [Signal Units per second]: 1000 Bd (baud)
Bit Rate [Baud Rate * Signal Unit]: 4000 bps (bits per second)
Bit rate and Baud rate, these two terms are often used in data
communication. Bit rate is simply the number of bits (i.e., 0’s and
1’s) transmitted per unit time. While Baud rate is the number of
signal units transmitted per unit time that is needed to represent
those bits.
Bit rate:-
Bit rate is nothing but number of bits transmitted per second.For example if Bit rate is 1000bps then 1000 bits are i.e. 0s or 1s transmitted per second.
Baud rate:-
It means number of time signal changes its state.When the signal is binary then baud rate and bit rate are same.
According to What’s The Difference Between Bit Rate And Baud Rate?:
Bit Rate
The speed of the data is expressed in bits per second (bits/s or bps).
The data rate R is a function of the duration of the bit or bit time
(TB) (Fig. 1, again):
R = 1/TB
Rate is also called channel capacity C. If the bit time is 10 ns, the
data rate equals:
R = 1/10 x 10–9 = 100 million bits/s
This is usually expressed as 100 Mbits/s.
Baud Rate
The term “baud” originates from the French engineer Emile Baudot, who
invented the 5-bit teletype code. Baud rate refers to the number of
signal or symbol changes that occur per second. A symbol is one of
several voltage, frequency, or phase changes.
NRZ binary has two symbols, one for each bit 0 or 1, that represent
voltage levels. In this case, the baud or symbol rate is the same as
the bit rate. However, it’s possible to have more than two symbols per
transmission interval, whereby each symbol represents multiple bits.
With more than two symbols, data is transmitted using modulation
techniques.
When the transmission medium can’t handle the baseband data,
modulation enters the picture. Of course, this is true of wireless.
Baseband binary signals can’t be transmitted directly; rather, the
data is modulated on to a radio carrier for transmission. Some cable
connections even use modulation to increase the data rate, which is
referred to as “broadband transmission.”
By using multiple symbols, multiple bits can be transmitted per
symbol. For example, if the symbol rate is 4800 baud and each symbol
represents two bits, that translates into an overall bit rate of 9600
bits/s. Normally the number of symbols is some power of two. If N is
the number of bits per symbol, then the number of required symbols is
S = 2^N. Thus, the gross bit rate is:
R = baud rate x log2S = baud rate x 3.32 log10S
If the baud rate is 4800 and there are two bits per symbol, the number
of symbols is 2^2 = 4. The bit rate is:
R = 4800 x 3.32 log(4) = 4800 x 2 = 9600 bits/s
If there’s only one bit per symbol, as is the case with binary NRZ,
the bit and baud rates remain the same.
First something I think necessary to know:
It is symbol that is transferred on a physical channel. Not bit. Symbol is the physical signals that is transferred over the physical medium to convey the data bits. A symbol can be one of several voltage, frequency, or phase changes. Symbol is decided by the physical nature of the medium. While bit is a logical concept.
If you want to transfer data bits, you must do it by sending symbols over the medium. Baud rate describes how fast symbols change over a medium. I.e. it describes the rate of physical state changes over the medium.
If we use only 2 symbols to transfer binary data, which means one symbol for 0 and another symbol for 1, that will lead to baud rate = bit rate. And this is how it works in the old days.
If we are lucky enough to find a way to encode more bits into a symbol, we can achieve higher bit rate with the same baud rate. And this is when the baud rate < bit rate. This doesn't mean the transfer speed is slowed down. It actually means the transfer efficiency/speed is increased.
And the communicating parties have to agree on how bits are represented by each physical symbol. This is where the modulation protocols come in.
But the ability of sending multiple bits per symbol doesn't come free. The transmitter and receiver will be complex depending on the modulation methods. And more processing power is required.
Finally, I'd like to make an analogy:
Suppose I stand on the roof of my house and you stand on your roof. There's a rope between you and me. I want to send some apples to you through a basket down the rope.
The basket is the symbol. The apple is the data bits.
If the basket is small (a physical limitation of the symbol), I may only send one apple per basket. This is when baud/basket rate = bit/apple rate.
If the basket is big, I can send more apples per basket. This is when baud rate < bit rate. I can send all the apples with less baskets. But it takes me more effort (processing power) to put more apples into the basket than put just one apple. If the basket rate remains the same, the more apples I put in one basket, the less time it takes.
Here are some related threads:
How can I be sure that a multi-bit-per-symbol encoding schema exists?
What is difference between the terms bit rate,baud rate and data rate?
bit rate : no of bits(0 or 1 for binary signal) transmitted per second.
baud rate : no of symbols per second.
A symbol consists of 'n' number of bits.
Baud rate = (bit rate)/n
So baud rate is always less than or equal to bit rate.It is equal when signal is binary.
Baud rate is mostly used in telecommunication and electronics, representing symbol per second or pulses per second, whereas bit rate is simply bit per second. To be simple, the major difference is that symbol may contain more than 1 bit, say n bits, which makes baud rate n times smaller than bit rate.
Suppose a situation where we need to represent a serial-communication signal, we will use 8-bit as one symbol to represent the info. If the symbol rate is 4800 baud, then that translates into an overall bit rate of 38400 bits/s. This could also be true for wireless communication area where you will need multiple bits for purpose of modulation to achieve broadband transmission, instead of simple baseline transmission.
Hope this helps.
Bit per second is what is means - rate of data transmission of ones and zeros per second are used.This is called bit per second(bit/s. However, it should not be confused with bytes per second, abbreviated as bytes/s, Bps, or B/s.
Raw throughput values are normally given in bits per second, but many software applications report transfer rates in bytes per second.
So, the standard unit for bit throughput is the bit per second, which is commonly abbreviated bit/s, bps, or b/s.
Baud is a unit of measure of changes , or transitions , that occurs in a signal in each second.
For example if the signal changes from one value to a zero value(or vice versa) one hundred times per second, that is a rate of 100 baud.
The other one measures data(the throughput of channel), and the other ones measures transitions(called signalling rates).
For example if you look at modern modems they use advanced modulation techniques that encoded more than one bit of data into each transition.
Thanks.
The bit rate is a measure of the number of bits that are transmitted per unit of time.
The baud rate, which is also known as symbol rate, measures the number of symbols that are transmitted per unit of time.
A symbol typically consists of a fixed number of bits depending on what the symbol is defined as(for example 8bit or 9bit data). The baud rate is measured in symbols per second.
Take an example, where an ascii character 'R' is transmitted over a serial channel every one second.
The binary equivalent is 01010010.
So in this case, the baud rate is 1(one symbol transmitted per second) and the bit rate is 8 (eight bits are transmitted per second).
This topic is confusing because there are 3 terms in use when people think there are just 2, namely:
"bit rate": units are bits per second
"baud": units are symbols per second
"Baud rate": units are bits per second
"Baud rate" is really a marketing term rather than an engineering term. "Baud rate" was used by modem manufactures in a similar way to megapixels is used for digital cameras. So the higher the "Baud rate" the better the modem was perceived to be.
The engineering unit "baud" is already a rate (symbols per second) which distinguishes it from the "Baud rate" term. However, you can see from the answers that people are confusing these 2 terms together such as baud/sec which is wrong.
From an engineering point of view, I recommend people use the term "bit rate" for "RS-232" and consign to history the term "Baud rate". Use the term "baud" for modulation schemes but avoid it for "RS-232".
In other words, "bit rate" and "Baud rate" are the same thing which means how many bits are transmitted along a wire in one second. Note that bits per second (bps) is the low-level line rate and not the information data rate because asynchronous "RS-232" has start and stop bits that frame the 8 data bits of information so bps includes all bits transmitted.
Bit rate is a measure of the number of data bits (that's 0's and 1's) transmitted in one second. A figure of 2400 bits per second means 2400 zeros or ones can be transmitted in one second, hence the abbreviation 'bps'.
Baud rate by definition means the number of times a signal in a communications channel changes state. For example, a 2400 baud rate means that the channel can change states up to 2400 times per second. When I say 'change state' I mean that it can change from 0 to 1 up to 2400 times per second. If you think about this, it's pretty much similar to the bit rate, which in the above example was 2400 bps.
Whether you can transmit 2400 zeros or ones in one second (bit rate), or change the state of a digital signal up to 2400 times per second (baud rate), it the same thing.
Serial Data Speed:
Data rate (bps) = 1/Tb
Tb is the time duration of 1 bit
If the bit duration is 2ms then data rate is 1/2x10-3 , which is about 500 bps.
Baud rate:
Baud rate is defined as no. of signalling elements(symbols) in a given unit of time (say 1 sec) or it means number of time signal changes its state.When the signal is binary then baud rate and bit rate are same.
Bit rate:- Bit rate is nothing but number of bits transmitted per second.For example if Bit rate is 1000 bps then 1000 bits are i.e. 0s or 1s transmitted per second.
There are few other terms similar to this (i.e serial speed, bit rate, baud rate, USB transfer rate),and i guess(?) the values that are printed on serial monitor relates to serial speed, baud rate and USB transfer rate. Bit rate isn't an another term, please correct me if i am wrong, because serial monitor prints some values at an interval of time and value is definitely a set of bits. so if one value is printed i can say no of bits present in the respective value which gets printed on serial monitor per unit time will be the bit rate.
Replies here are misleading. Saying true, but no one tell that for UART a symbol is not a single character but a single bit and this way the question was tagged.
For example 115200/8n1 is 11520 bytes per second as a single ASCII character is a 1 start bit plus 8 data bit plus 1 stop bit.
As correctly pointed out in the other replies, the bitrate is the amount of logical (or "abstract high level") information transferred in a given time, while baud rate is the number of symbols (more or less "signal changes") in the physical line in a given time.
While it is easy to understand that if a transmitted symbol carries 4 bits of information, then the bitrate is four time the baud rate, things get blurred in case of, for example, a RS-232 serial line.
The classic serial line works on bytes (well, "frames"), not bits. There is no way to transmit fewer that 8 bits (i.e. a byte), because the serial line defines a "frame" (I assume frames with 8 data bits, no parity, 1 start bit and 1 stop bit); and this is usually OK, because devices (computers) work probably on bytes, not single bits.
Given that, when a device sends a byte, i.e. 8 bits, the physical lines transmits 10 symbols, because to the original data composed of 8 bits, 2 more are added (start and stop bits, they are needed for synchronization). Some confusion can arise because the symbols transmitted on the physical line are also called "bits", but they are really symbols (MARK and SPACE, actually).
So in that classic RS-232 (in case of "8N1" frame) the bitrate is actually 8/10 of the baudrate. If we add the parity bit, the ratio lowers further and becomes 8/11.
The number of bits or symbols per second translates directly to the duration of them (bits or symbols). What does it mean for an engineer designing a system? It means that if he is designing a line filter to protect the line or reduce the noise, he should take the duration (or frequency) of the symbols transmitted on that line. For a baudrate of 1000 baud, he knows that the frequency of the signal is 1 KHz, and that a symbol has a duration of 1 ms. Fine. But if he has to calculate how much time is needed to transfer a file from a device to another, say a file of 1000 bytes, he must consider the bitrate, not the baudrate! Because the devices, at higher level, do not even see the start and stop bits, they are only a burden which slow down the communication (but they are useful for error checking).
To take it to the extreme case, imagine that a serial frame is just a bit long. For every bit transmitted by a device, three symbols would travel in the physical line. And if a parity were added, then four symbol would travel: the bitrate would be 1/4 of the baudrate. And if we add a second stop bit, the bitrate goes down to 1/5 of the baudrate!

Calculation of data delta

I'm writing a server that sends a "coordinates buffer" of game objects to clients every 300ms. But I don't want to send the full data each time. For example, suppose I have an array with elements that change over time:
0 0 100 50 -100 -50 at time t
0 10 100 51 -101 -50 at time t + 300ms
You can see that only the 2nd, 4th, and 5th elements have changed.
What is the right way to send not all the elements, but only the delta? Ideally I'd like a function that returns the complete data the first time and empty data when there are no changes.
Thanks.
Are you looking to optimize for efficiency, or is this a learning exercise? Some thoughts:
Unless there's a lot of data, it's probably easiest, and not terribly inefficient, to send all the data each time.
If you send deltas for all of the data points each time, you won't save much by sending zeroes for unchanged points instead of re-sending the previous vales.
If you send data for only those points that change, you'll need to provide an index for each value. For example, if point 3 increases by 5 and point 8 decreases by 2, then you might send 3 5 8 -2. But now, since you're sending two values for each point that changes, you'll only win if fewer than half the points change.
If the values change relatively slowly, as compared to the rate at which you transmit updates, you might increase efficiency by transmitting the delta for each data point, but using only a few bits. For example, with 4 bits you can transmit values from -8 to +7. That would work as long as the deltas are never larger than that, or if it's ok to transmit several deltas before they "catch up" to the actual values.
It may not be worthwhile to have 2 different mechanisms: one to send the initial values, and another to send deltas. If you can tolerate the lag, it may make more sense to assume some constant initial value for every point, and then transmit only deltas.
There are lots of options. If most data isn't changing, just send (index,value) pairs of the changed elements. If most values change but the changes are small, compute deltas and gzip (or run length encode, or lots of other possibilities) the result.

Resources