rchandra
Stargate S G-1 And Atlantis Fan
Premium
join:2000-11-09
14225-2105
clubs:
| reply to RothPC1
Re: Yeah, right. It IS a good deal...
Look, I don't mean to sound harsh, but what you wrote about has nothing whatsoever to do with synchronicity. The opposite of an asynchronous (async) comm protocol is a synchronous protocol.
Asychronous means a start bit, the payload bits, and a stop bit. There is no requirement to send data all the time. Async lines are always clocked individually in each transmitter and receiver, and each of those clocks must be maintained within a certain frequency tolerance in order to communicate properly. The purpose of the start bit is to inform the receiving end when precisely to start looking for data on the line. It "knows" the start bit should be some certain time in duration, and after that time expires, it can start assembling the datum that's being communicated. Each bit in the data stream likewise is some fixed duration, and the clock internal to the receiver determines when each of the datum bits should be on the line. This is typically accomplished with a shift register. In part, the purpose of the stop bit is to give the receiver time to transfer the assembled contents of the shift register somewhere to prepare to receive the next datum.
Sync lines on the other hand (such as the T-1 you mention) eliminate the start and stop bits, and use various protocols (NRZ and NRZI to name two) to maintain clocking. (T-1's typically use bipolar signalling with 8 zero substitution, or B8ZS. Sync lines with too many consecutive zeroes will lose sync.) There are data, even if it's all zeroes or all SYN octets, traversing the line all the time. The receiving clocking can be derived from the bit patterns on the line. The next protocol layer up, such as frame relay or ATM, is what transports the data. I would be extremely surprised if a more learned person than I were to tell me that any DSL were async. (Heck, I've been wrong many times before, but I don't think so on this one.)
What you have not apparently been exposed to is traffic control/traffic shaping. Traffic shaping is the process of only allowing data to be transmitted at a configured rate. Traffic control is selecting datagrams from the data stream based on some criteria and reordering the transmission queue (or buffer if you like) from a configured policy. Taking your example, if you arrange for your "normal traffic" queue to be traffic shaped to slightly less than the link's capacity, and classify all your bulk traffic to be in that queue, you will then have a small amount of reserve link capacity that you can use to send the TCP ACK packets for your download. You simply select ACK packets, put them in this "reserve" queue, and ensure these smaller, "more important" packets in this reserve queue get sent ahead of your bulk traffic. This is the basic concept of how WonderShaper works using Linux traffic control (tc).
In other words, you don't have to settle for a strict queue for your IP networking. With the rise of the use of VoIP and other time-critical prototols, even home use router appliances are shipping with QoS (quality of service) or differentiated services (DiffServ) features. Things like the Sipura SPA-2000 that I have for VoIP can set these fields in the IP header to request the packets they transmit be treated with priority. As long as the slowest router in the path (most probably your own) honors that request, those packets will go out your DSL or cable modem before ones without any special QoS/DiffServ options set. Likewise, if ever there were to be an inbound queue, those packets would be transmitted on your LAN before ones without.
See lartc.org for more details on traffic shaping. I believe that's also where I read about the contributed WonderShaper script.
--
English is a difficult enough language to interpret correctly when its rules are followed, let alone when a writer chooses not to follow those rules. Blog is here
Jeopardy! replies REALLY suck! |
