Can someone explain to me how to get the answer I am so lost.
Q1. A multiplexer combines four 100-kbps channels using a time slot of 2 bits.
What is the frame rate and the bit rate?
The answer is 50,000 Frame per sec and 400 kbps.
bit rate = no. of channels * Input bit rate
So, bit rate = 4 * 100kbps = 400kbps
Frame rate = Input bit rate (convert it into bit) / time slot bit(s)
So, Frame rate = 100000bps / 2b = 50000 frames per second (Frames/s)
4 * 100kbps = 400kbps
100kbps / 2b = 100000bps / 2b = 50000fps
Frame rate is the number of frames per second.
If we have 400000 bits per second transmission
Since each frame carries 8 bits, the frame rate would be:
400000/8 = 5000 per second.
Related
I use graphite 0.9.15.
I have metrics with few data (many nulls) over the last 6 hours, I can draw them when querying the last 6 hours, but if I ask for more (like 7 hours), I have no data. I tried to change the consolidation function with consolidateBy to max, but I have still no data. What should I do to plot my data over more than 6 hours?
I configured the storage aggregation with a xFilesFactor of 0 and the aggregationMethod to max, but my data are too young to be aggregated.
It looks like something is wrong with your storage-schemas.conf. E.g. you have only 6 hours of data there - "retentions = 1m:6h"
Or aggregation scheme also can be wrong - if your lowest retention is 10 seconds, and you sending data e.g. every 60 seconds then you will get one data point, and then five empty points - 80% of data is empty. Default xFilesFactor is 0.5, so it will discard your data if you have more than 50% of empty points.
Usually, your lowest retention should match with your metrics rate - or you need to set up proper aggregation for different metrics by regex.
I'm having some difficulty calculating the total time it takes a packet to get from A to B, the question is:
"We have 200 bytes of data to send from A to B, with a distance of 200km between them. Calculate the total transmission time, assuming the speed of the signal is 200,000 km/s and that the data rate is 1Mbps and that a header of 40 bytes has to be added to the data before it is sent."
My understanding is that at some point you need to factor in propagation and the speed of light (??) but I'm unsure if it's needed in this case. Is there a formula which can be used to work these types of question out?
So we have a total of 200 bytes of payload + 40 bytes of header = 240 bytes. The data can be put on the wire at a rate of 1 Mbps which equals 1,000,000 bits per second (unless the question actually means Mibps which is 1,048,576 bits per second; we'll work on the assumption that Mbps is correct and it's 1,000,000).
240 bytes is equal to 1920 bits (240 * 8), so it takes
1920 bits / 1,000,000 bits per second = 0.00192 seconds
to get the data on the wire.
Now, for the data to be transmitted, it has to travel 200 km at a rate of 200,000 km/s.
200km / 200,000(km/s) = 0.001 seconds.
Now, to take the data from the wire and read into computer in location B takes the same amount of time as putting the data on the wire = 0.00192 seconds.
So the total amount of time is equal to
0.00192 + 0.001 + 0.00192 = 0.00484 seconds = 4.84 milliseconds.
I am trying to understand how to calculate the throughput for a sliding window data transmission, by solving some numerical examples. Below is the example followed by my analysis.
Example
Host A is sending data to Host B over a full duplex link. A and B are using sliding window protocol, with send and receive window sizes of 5 each. Data packets sent only from A to B, are 1000 bytes each in size, and transmission time for one such packet is 50 us. Propagation delay is 200 us. Assume Ack packets need negligible transmission time. What is the maximum achievable throughput in Mbps?
A. 7.69 B. 11.11 C. 12.33 D. 15.00
Analysis
Round trip-time is 2 * 200 us = 400 us. ... A
Time required to fill the sending window = window size (5) * transmission time of 1 packet (50 us) = 250 us. ... B
Since B < A, sender has to wait for ack to 1st packet before sending the 6th packet. This ack appears at 450 us. (round-trip time is 400 us.)
Between 250 us and 450 us, the sender is idle, that is no new data is being sent over the line.
Assuming sender has an unlimited supply of data frames, the above cycle would repeat.
Thus, in every 450 us, sender sends 5 packets = 5 * 1000 * 8 = 40000 bits of data.
Hence, throughput = 40000 bits / 450 us = 84.7710 megabits per second. (84.7710 Mbps)
However, this is not one of the given options, not even close! Is there any mistake in my analysis above?
As I stated in my comment, your analysis and calculation method is correct. However, I'd check my calculator if I were you because 40000 bits / 450 us = 88.88...Mbps, not 84.7710 Mbps.
I do not think it is mere coincidence that 88.88 is just 11.11*8, so it's a fair assumption that the question was actually asking to get megabytes per second instead of megabits per second.
Throughput = Window /RTT
Here Window size = 5*1000 bytes = 5000 bytes.
RTT = 50us + 2*200 us=> 450us.
Therefore Throughput= 5000 bytes/450 us = 11.11Mpbs
I got this math problem. I am trying to calculate the max amount of samples when the response time is zero. My test has 3 samples (HTTP Request). The total test wait time is 11 seconds. The test is run for 15 minutes and 25 seconds. The ramp up is 25 seconds, this means that for every second 2 users are created till we reach 50.
Normally you have to wait for the server to respond, but I am trying to calculate the max amount of samples (this means response time is zero.) How do i do this. I can't simply do ((15 * 60 + 25) / 11) * 50. Because of the ramp up.
Any ideas?
EDIT:
Maybe I should translate this problem into something generic and not specific to JMeter So consider this (maybe it will make sense to me aswel ;)).
50 people are walking laps around the park. Each lap takes exactly 11 seconds to run. We got 15 minutes and 25 seconds to walk as many as possible laps. We cannot start all at the sametime but we can start 2 every second (25seconds till we are all running). How many laps can we run?
What i end up doing was manually adding it all up...
Since it takes 25s to get up to full speed, only 2 people can walk for 900s and 2 people can walk for 901s and 2 people can walk for 902s all the way to total of 50 people..
Adding that number together should give me my number i think.
If I am doing something wrong or based on wrong conclusion I like to hear your opinion ;). Or if somebody can see a formula.
Thanks in advance
I have no idea about jmeter, but I do understand your question about people running round the park :-).
If you want an exact answer to that question which ignores partial laps round the park, you'll need to do (in C/java terminology) a for loop to work it out. This is because to ignore partial laps it's necessary to round down the number of possible laps, and there isn't a simple formula that's going to take the rounding down into account. Doing that in Excel, I calculate that 4012 complete laps are possible by the 50 people.
However, if you're happy to include partial laps, you just need to work out the total number of seconds available (taking account of the ramp up), then divide by the number of people starting each second, and finally divide by how many seconds it takes to run the lap. The total number of seconds available is an arithmetic progression.
To write down the formula that includes partial laps, some notation is needed:
T = Total number of seconds (i.e. 900, given that there are 15 minutes)
P = number of People (i.e. 50)
S = number of people who can start at the Same time (i.e. 2)
L = time in seconds for a Lap (i.e. 11)
Then the formula for the total number of laps, including partial laps is
Number of Laps = P * (2 * T - (P/S - 1)) / (2*L)
which in this case equals 4036.36.
Assume we're given:
T = total seconds = 925
W = walkers = 50
N = number of walkers that can start together = 2
S = stagger (seconds between starting groups) = 1
L = lap time = 11
G = number of starting groups = ceiling(W/N) = 25
Where all are positive, W and N are integers, and T >= S*(G-1) (i.e. all walkers have a chance to start). I am assuming the first group start walking at time 0, not S seconds later.
We can break up the time into the ramp period:
Ramp laps = summation(integer i, 0 <= i < G, N*S*(G-i-1)/L)
= N*S*G*(G-1)/(2*L)
and the steady state period (once all the walkers have started):
Steady state laps = W * (T - S*(G-1))/L
Adding these two together and simplifying a little, we get:
Laps = ( N*S*G*(G-1)/2 + W*(T-S*(G-1)) ) / L
This works out to be 4150 laps.
There is a closed form solution if you're only interested in full laps. If that's the case, just let me know.
I'm writing something that reads bytes (just a List<int>) from a remote random number generation source that is extremely slow. For that and my personal requirements, I want to retrieve as few bytes from the source as possible.
Now I am trying to implement a method which signature looks like:
int getRandomInteger(int min, int max)
I have two theories how I can fetch bytes from my random source, and convert them to an integer.
Approach #1 is naivé . Fetch (max - min) / 256 number of bytes and add them up. It works, but it's going to fetch a lot of bytes from the slow random number generator source I have. For example, if I want to get a random integer between a million and a zero, it's going to fetch almost 4000 bytes... that's unacceptable.
Approach #2 sounds ideal to me, but I'm unable come up with the algorithm. it goes like this:
Lets take min: 0, max: 1000 as an example.
Calculate ceil(rangeSize / 256) which in this case is ceil(1000 / 256) = 4. Now fetch one (1) byte from the source.
Scale this one byte from the 0-255 range to 0-3 range (or 1-4) and let it determine which group we use. E.g. if the byte was 250, we would choose the 4th group (which represents the last 250 numbers, 750-1000 in our range).
Now fetch another byte and scale from 0-255 to 0-250 and let that determine the position within the group we have. So if this second byte is e.g. 120, then our final integer is 750 + 120 = 870.
In that scenario we only needed to fetch 2 bytes in total. However, it's much more complex as if our range is 0-1000000 we need several "groups".
How do I implement something like this? I'm okay with Java/C#/JavaScript code or pseudo code.
I'd also like to keep the result from not losing entropy/randomness. So, I'm slightly worried of scaling integers.
Unfortunately your Approach #1 is broken. For example if min is 0 and max 510, you'd add 2 bytes. There is only one way to get a 0 result: both bytes zero. The chance of this is (1/256)^2. However there are many ways to get other values, say 100 = 100+0, 99+1, 98+2... So the chance of a 100 is much larger: 101(1/256)^2.
The more-or-less standard way to do what you want is to:
Let R = max - min + 1 -- the number of possible random output values
Let N = 2^k >= mR, m>=1 -- a power of 2 at least as big as some multiple of R that you choose.
loop
b = a random integer in 0..N-1 formed from k random bits
while b >= mR -- reject b values that would bias the output
return min + floor(b/m)
This is called the method of rejection. It throws away randomly selected binary numbers that would bias the output. If min-max+1 happens to be a power of 2, then you'll have zero rejections.
If you have m=1 and min-max+1 is just one more than a biggish power of 2, then rejections will be near half. In this case you'd definitely want bigger m.
In general, bigger m values lead to fewer rejections, but of course they require slighly more bits per number. There is a probabilitistically optimal algorithm to pick m.
Some of the other solutions presented here have problems, but I'm sorry right now I don't have time to comment. Maybe in a couple of days if there is interest.
3 bytes (together) give you random integer in range 0..16777215. You can use 20 bits from this value to get range 0..1048575 and throw away values > 1000000
range 1 to r
256^a >= r
first find 'a'
get 'a' number of bytes into array A[]
num=0
for i=0 to len(A)-1
num+=(A[i]^(8*i))
next
random number = num mod range
Your random source gives you 8 random bits per call. For an integer in the range [min,max] you would need ceil(log2(max-min+1)) bits.
Assume that you can get random bytes from the source using some function:
bool RandomBuf(BYTE* pBuf , size_t nLen); // fill buffer with nLen random bytes
Now you can use the following function to generate a random value in a given range:
// --------------------------------------------------------------------------
// produce a uniformly-distributed integral value in range [nMin, nMax]
// T is char/BYTE/short/WORD/int/UINT/LONGLONG/ULONGLONG
template <class T> T RandU(T nMin, T nMax)
{
static_assert(std::numeric_limits<T>::is_integer, "RandU: integral type expected");
if (nMin>nMax)
std::swap(nMin, nMax);
if (0 == (T)(nMax-nMin+1)) // all range of type T
{
T nR;
return RandomBuf((BYTE*)&nR, sizeof(T)) ? *(T*)&nR : nMin;
}
ULONGLONG nRange = (ULONGLONG)nMax-(ULONGLONG)nMin+1 ; // number of discrete values
UINT nRangeBits= (UINT)ceil(log((double)nRange) / log(2.)); // bits for storing nRange discrete values
ULONGLONG nR ;
do
{
if (!RandomBuf((BYTE*)&nR, sizeof(nR)))
return nMin;
nR= nR>>((sizeof(nR)<<3) - nRangeBits); // keep nRangeBits random bits
}
while (nR >= nRange); // ensure value in range [0..nRange-1]
return nMin + (T)nR; // [nMin..nMax]
}
Since you are always getting a multiple of 8 bits, you can save extra bits between calls (for example you may need only 9 bits out of 16 bits). It requires some bit-manipulations, and it is up to you do decide if it is worth the effort.
You can save even more, if you'll use 'half bits': Let's assume that you want to generate numbers in the range [1..5]. You'll need log2(5)=2.32 bits for each random value. Using 32 random bits you can actually generate floor(32/2.32)= 13 random values in this range, though it requires some additional effort.