how-to block ads
|
RothPC1
@il.frontier
| reply to rchandra
Re: Yeah, right. It IS a good deal...
Ok, RChandra. You're right about the "a" but it still is not synchronous.
Synchronous, if you think about a T1, is the following.
A T1 is both up and down at 1.5Mbit
I can download at FULL capacity of 1.5 and also upload at the exact same rate at FULL capacity.
aDSL, if you use the FULL 256Kbit of my DSL provider or others that I've used at friends, You will not have hardly ANY download speed (as in = 8KByte average MAX when utilizing full Upload)
So, either way. Same difference.
(Frowns about his ISP)
RothPC | |
RothPC1
@il.frontier
| Also, not to mention, Rchandra.
It Does matter where you authenticate. Took them over 9 months to get a DSLAM local to me, in Chicago.
Until that time, My Ping times were in the averages of 1800ms
Terrible, huh?
When they got the one in Chicago, which is still about 4 hours from me, It dropped instantaneously to about 140ms which is still rediculously high. But I can deal with it.
Anyways, *Frowns*, It could just be my ISP *Knows it is but don't want to admit it*
And yea, you are right about most of it.
FYI, RChandra: You are more knowledgeable than 99% of the IT staff at my ISP *laughs hard* | |
rchandra
Stargate S G-1 And Atlantis Fan
Premium
join:2000-11-09
14225-2105
clubs:
| reply to RothPC1
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! | |
rchandra
Stargate S G-1 And Atlantis Fan
Premium
join:2000-11-09
14225-2105
clubs:
| reply to RothPC1
Good God...please...understand that one, PPP is inherent to PPPoA, and two, authentication is part of PPP. You don't use a separate PVC or something for authentication, and another for your data; it all goes to/comes from the same place. It's just that auth packets have a different type identifier than IP packets. I think that technically, it's possible to send ATM cells to different places (e.g., along a different VPI/VCI), but that it's extraordinarily unlikely to make such distinctions based on PPP packet type. Heck, I've been wrong before, but I don't think so on this one.
--
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! | |
|
