Consider two hosts A and B on a wired network. Both the hosts send data packets to each other. In a real world scenario, the delays experienced in the direction A->B can be different from B->A. One primary reason could different routes in which packets are made to travel. For example, A->B might take longer time than B->A, possibly because it travels through a different set of routers or a longer route. Now lets assume that the packets from A->B and B->A take the same route for delivery. Can there still be potential causes for different delays between the packets in two directions? If yes, it would be great if someone can elaborate.
They will never be identical. There are lots of factors that will effect the delay. I might not cover all the possible cases, but at-least i will try to recite what i vaguely remember.
First of all, they won't take same path. In case other direction takes same path, the counter direction traffic conditions could be different at routers in the core network. The routers could have different queuing policy.
The delays depend on the packet size (larger the packet size, larger the one way delay) as the routers treat packets with different sizes differently.
Don't forget the time and day. Holidays, working times and rush hours matter.
Depends on the measurement layer:- Assuming they have crossed all these things and the packets came to your machine, the time it takes for the packet to reach from the Ethernet card to the transport layer (TCP/UDP) or Application layer will not be the same for two different machines. It depends on your machine configuration, load on the machine, what OS, kernel etc.,
Practically they can't be same. You can consider them only for approximations and theory.
Related
This may be a very rookie question. Say I have a network card with bandwidth limit 100MB/s, so is it possible that in/out bandwidth reach that limit at the same time? Or I'll have this inequality at any point of time: in bandwidth + out bandwidth <= 100MB/s
First, your network card is probably 100Mb/sec not 100MB/sec. Ethernet is the most common wired network type by far, and it commonly comes in 10, 100, 1000 mega bits per second. A 100 megaBIT/sec ethernet interface is roughly capable of 12.5 MegaBYTES per second.
If you're plugged into an ethernet switch, you're most likely going to be connecting in Full Duplex mode. This allows both ends to speak to each other simultaneously without affecting the performance of each other.
You'll never quite reach the full advertised speed though, a Gigabit network interface (1000Mb/sec) will usually be able to transfer in the high 900's each direction without problem. There are a few things that cause overhead that prevent you from reaching the full speed. Also, many lower end network cards or computers struggle to reach the full speed, so you won't always be able to reach this.
If you're plugged into an ethernet hub, only one end can be talking at a time. There, in + out can't go higher than the link speed, and is typically far lower because of collisions. It's really unlikely you can find a hub anymore unless you're really trying to, switches are pretty much the only thing you can buy now outside of exotic applications.
TL;DR: You're almost always using full duplex mode, which allows up to (but usually less than) the advertised link speed in both directions simultaneously.
I have a voice-chat service which is experiencing variations in the delay between packets. I was wondering what the proper response to this is, and how to compensate for it?
For example, should I adjust my audio buffers in some way?
Thanks
You don't say if this is an application you are developing yourself or one which you are simply using - you will obviously have more control over the former so that may be important.
Either way, it may be that your network is simply not good enough to support VoIP, in which case you really need to concentrate on improving the network or using a different one.
VoIP typically requires an end to end delay of less than 200ms (milli seconds) before the users perceive an issue.
Jitter is also important - in simple terms it is the variance in end to end packet delay. For example the delay between packet 1 and packet 2 may be 20ms but the delay between packet 2 and packet 3 may be 30 ms. Having a jitter buffer of 40ms would mean your application would wait up to 40ms between packets so would not 'lose' any of these packets.
Any packet not received within the jitter buffer window is usually ignored and hence there is a relationship between jitter and the effective packet loss value for your connection. Packet loss typically impacts users perception of voip quality also - different codes have different tolerance - a common target might be that it should be lower than 1%-5%. Packet loss concealment techniques can help if it just an intermittent problem.
Jitter buffers will either be static or dynamic (adaptive) - in either case, the bigger they get the greater the chance they will introduce delay into the call and you get back to the delay issue above. A typical jitter buffer might be between 20 and 50ms, either set statically or adapting automatically based on network conditions.
Good references for further information are:
- http://www.voiptroubleshooter.com/indepth/jittersources.html
- http://www.cisco.com/en/US/tech/tk652/tk698/technologies_tech_note09186a00800945df.shtml
It is also worth trying some of the common internet connection online speed tests available as many will have specific VoIP test that will give you an idea if your local connection is good enough for VoIP (although bear in mind that these tests only indicate the conditions at the exact time you are running your test).
considering that metric is delay in distance vector routing algorithm,
is it possible that delay from router A to B is different from router B to A.
if yes, under which conditions??
thanks.
The algorithm assumes the graph is bidirectional. Of course, it's possible for the delays to be different in each direction in practice: for example, if B is transmitting heavily to A, then traffic from A to B is likely to be faster than from B to A, since traffic from B will have to get in line at the end of a queue.
Delay and metric are two different things.
Delay is the time it takes for a packet to traverse the network. If a link is heavily utilized in one direction and there is some kind of buffering device (such as a switch) on the link you might have different delays in the network traffic depending on direction.
Metrics are values associated with entries in a routing table that indicates "costs" of different routes. If A and B have static routing entries they can definitely be configured with different metrics for each direction of the same link.
Are you assuming both hypothetical circumstances run at the exact same time? If not I suppose there could be a spike on the traffic for one of the routers at any given time that bogs down your 'wanted' traffic.
Certainly this is possible, but to give you more details you probably need to be more specific with the question.
With regards to your specific question about Metrics and Distance Vector routing algorithms, yes, A can be configured to think that B is further away than B thinks A is, although as mentioned by one of the other answers, that doesn't necessarily mean the delay is different although it may in fact be.
In practice though, there are lots of questions to consider:
Is router A adjacent to router B? If not, then you certainly could have different delays because inbound packets may take a different path than outbound packets.
If they are adjacent, what kind of connectivity do they have? Are they the same kind of router? Imagine a router at the end of an aysymmetric DSL line. Of course the propagation delay wouldn't be aysymmetric, but delay could be higher in one direction as a result of traffic congestion. (This scenario also gives a concrete example of why you might want A to think the link to B has a higher cost than B thinks the link to A has.)
In practice, the definition of delay makes a big difference too. Are you thinking of just the computed cost? Or just propagation delay? Or just the link cost? If router B is sending more traffic than router A, it may take longer for responding packets from B to A to be processed by B than A takes when sending the packets (the same may apply for intermediary switches, especially in the case of things like multicast packets--some routers and/or switches take longer to process multicast and other "special" packets). So in this scenario the actual delay may be different, but the cost the DVP is using thinks it is the same.
Hope this answer helps. Good luck,
--jed
I wish I could play music or video on one computer, and have a second computer playing the same media, synchronized. As in, I can hear both computers' speakers at the same time, and it doesn't sound funny.
I want to do this over Wi-Fi, which is slightly unreliable.
Algorithmically, what's the best approach to this problem?
EDIT 1
Whether both computers "play" the same media, or one "plays" the media and streams it to the other, doesn't matter to me.
I am certain this is a tractable problem because I once saw a demo of Wi-Fi speakers. That was 5+ years ago, so I'm figure the technology should make it easier today.
(I myself was looking for an application which did this, hoping I wouldn't have to write one myself, when I stumbled upon this question.)
overview
You introduce a bit of buffer latency and use a network time-synchronization protocol to align the streams. That is, you split the stream up into packets, and timestamp each packet with "play later at time T", where T is for example 50-100ms in the future (or more if the network is glitchy). You send (or multicast) the packets on the local network, to all computers in the chorus. The computers will all play the sound at the same time because the application clock is synced.
Note that there may be other factors like OS/driver/soundcard latency which may have to be factored into the time-synchronization protocol. If you are not too discerning, the synchronization protocol may be as simple as one computer beeping every second -- plus you hitting a key on the other computer in beat. This has the advantage of accounting for any other source of lag at the OS/driver/soundcard layers, but has the disadvantage that manual intervention is needed if the clocks become desynchronized.
hybrid manual-network sync
One way to account for other sources of latency, without constant manual intervention, is to combine this approach with a standard network-clock synchronization protocol; the first time you run the protocol on new machines:
synchronize the machines with manual beat-style intervention
synchronize the machines with a network-clock sync protocol
for each machine in the chorus, take the difference of the two synchronizations; this is the OS/driver/soundcard latency of each machine, which they each keep track of
Now whenever the network backbone changes, all one needs to do is resync using the network-clock sync protocol (#2), and subtract out the OS/driver/soundcard latencies, obviating the need for manual intervention (unless you change the OS/drivers/soundcards).
nature-mimicking firefly sync
If you are doing this in a quiet room and all machines have microphones, you do not even need manual intervention (#1), because you can have them all follow a "firefly-style" synchronizing algorithm. Many species of fireflies in nature will all blink in unison. http://tinkerlog.com/2007/05/11/synchronizing-fireflies/ describes the algorithm these fireflies use: "If a firefly receives a flash of a neighbour firefly, it flashes slightly earlier." Flashes correspond to beeps or buzzes (through the soundcard, not the mobo piezo buzzer!), and seeing corresponds to listening through the microphone.
This may be a bit awkward over very large room distances due to the speed of sound, but I doubt it'll be an issue (if so, decrease rate of beeping).
The synchronization is relative to the position of the listener relative to each speaker. I don't think the reliability of the network would have as much to do with this synchronization as it would the content of the audio stream. In order to synchronize you need to find the distance between each speaker and the listener. Find the difference between each of those values and the value for the farthest speaker. For each 1.1 feet of difference, delay each of the close speakers by 1ms. This will ensure that the audio stream reaches the listener at the same time. This all assumes an open area, as any in proximity to your scenario will generate reflections of the audio waves and create destructive interference. Objects within the area may also transmit sound at a slower speed resulting in delayed sound of their own.
I'm assigned to a project where my code is supposed to perform uploads and downloads of some files on the same FTP or HTTP server simultaneously. The speed is measured and some conclusions are being made out of this.
Now, the problem is that on high-speed connections we're getting pretty much expected results in terms of throughput, but on slow connections (think ideal CDMA 1xRTT link) either download or upload wins at the expense of the opposite direction. I have a "higher body" who's convinced that CDMA 1xRTT connection is symmetric and thus we should be able to perform data transfer with equivalent speeds (~100 kbps in each direction) on this link.
My measurements show that without heavy tweaking the code in terms of buffer sizes and data link throttling it's not possible to have same speeds in forementioned conditions. I tried both my multithreaded code and also created a simple batch file that automates Windows' ftp.exe to perform data transfer -- same result.
So, the question is: is it really possible to perform data transfer on a slow symmetrical link with equivalent speeds? Is a "higher body" right in their expectations? If yes, do you have any suggestions on what should I do with my code in order to achieve such throughput?
PS.
I completely re-wrote the question, so it would be obvious it belongs to this site.
CDMA 1x consists of up to 15 channels of 9.6kbps traffic. This results in a total throughput of 144kbps.
Two channels are used for command and control signals (talking to base stations, associating/disassociating, SMS traffic, ring signals, etc).
That leaves you with up to 124.8kbps.
--> Each channel is one way. <--
They are dynamically switched and allocated depending on the need.
Generally you'll get more download than upload because that's the typical cell phone modem usage. But you'll never get more than 120kbps total aggregate bandwidth.
In practise, due to overhead of 1xRTT encoding, error correction, resends, etc, you'll typically experience between 60kbps and 90kbps even if you have all the channels possible.
This means that you can probably only get 30kbps-60kbps of upload and download simultaneously.
Further, due to switching the channels dynamically (and the fact that the base station controls this more than your modem - they need to manage base station channels carefully to keep channels free for voice calls) you'll lose time when it switches channels - it's not an instantaneous process.
So - 1xRTT can, in theory, give you 124kbps one way, but due to overhead, switching times, base station capacity, or the phone company simply limiting such connections for other reasons, you can't depend on a symmetrical link.
NOTE:
This will vary to some degree based on the provider and the modem. For instance, some modems have 16 channels, and some providers support 16 channels. In some cases those modems and providers work well together and can provide a full 144kbps aggregate raw bandwidth to the application, with only one dedicated channel (which has to work pretty hard) to deal with control, switching, and other issues. Even then, though, with the overhead of the modem communications, then the overhead of PPP, then the overhead of IP, then the overhead of TCP, you're still looking at maybe 100-120kbps total bandwidth, both up and down.
Lastly, no provider yet supports transparent transfer of IP traffic. In other words if you're modem is moving, the modem will switch to a new base station, but you'll completely drop the PPP session and have to restart it, as well as all the TCP sessions and such. You typically won't get the same IP address, and so your TCP sessions will not recover gracefully.
The "fun" aspect to this twist is that this can happen even if you aren't moving. If one base station gets loaded down, you may be transferred to another base station if you are close enough - there are other things that may make your modem transfer even without you moving. So make sure you take this into account, since you seem to be keen on maintaining a full duplex, symmetric channel open. It's tough to write stuff that will recover gracefully, nevermind anticipate it and do it quickly. You would do well to work very closely with a modem manufacturer (such as Kyocera) on this - otherwise you won't get the documentation on how to control the modem chipset at the low level that you need.
-Adam
I think the whole drama with high equal speeds on both directions is because my higher body thinks that they have 144 kbps on uplink AND 144 kbps on DOWNLINK (== TWO pipes). Whereas in reality we have 144 kbps of ONE pipe which is switching directions when I transfer files.
Comment me if I right or wrong, please.