I have two 2600 routers connected to two different ISPs with different line speeds one is using frame relay with 1mbps connection, the other is using leased line 256kbps connection with hdlc encapsulation.
router to router latency with no utilization for the frame-relay is about 1ms average router to router latency with no utilization for the leased line connection is about 15-22ms average
when we saturate the links to 96%-100% for both connections, the frame relay router to router latency basically stays the same but the leased line connection's router to router latency jumps to a whopping 900ms average....
my question is they are both maxed out in the utilization (100%) but why one stays basically stays consistent in the router to router latency and the other does not? does it really have to do with the line speed even though both are at 100 % percent util?
You have a lot of variables here but here goes ... 1) Frame Relay is a superior protocol, specifically designed for high-speed switching at layer 2. 2) When you use HDLC over a lease-line, frames are being encapsulated - more tear down at remote end, etc. 3) There is more error checking over the leased line. ... if you had 2 crappy lines, one to each of the ISP's, then the leased line might be a better solution.
Is it possible that the frame relay circuit is full duplex but the leased line is half?
On half-duplex circuits, as utilization increases, the "cost" of turning around the line to send an ACK increases greatly... and if one of the sources happens to be sending pure UDP then there might not be a convenient time to turn the line around.
Insufficient information to make an informed guess, but my initial reaction is that you are not measuring what you think you are measuring. A few key questions:
1- How are you measuring latency?
2- From what router to what router?
3- How are you loading down the links?
4- How are you measuring the loading?
Assuming the answer to #1 is "pinging the other end of the link" your measurements are inconsistent. You can't ping the other end of a frame relay link because frame relay is a layer two protocol. And your no load measurements for the 256Kbps link are very high. Round trip serialization delay for a 64 byte ping packet at 256Kbps is only 4 ms, so you're looking at 10-20 ms of processing delay in the routers.
A quick look at queueing theory tells me that you are filling the 256K link to 98%. On the frame link, I suspect you are pinging yourself rather than the other end of the link. If you were actually seeing queueing delays at full loading, you're "fully loaded" frame link is still only at less than 66% load (best case ping at 64 bytes would be 0.6ms, and you're seeing less than 2ms at full load).
KarateD, you need to hit the books and learn a bit about how frame relay actually works. The above may be what the marketing weenies want you to believe, but it has no basis in fact. To begin with, frame relay frames are also encapsulated in HDLC framing, so if anything, there is more overhead to frame relay, not less. The error checking is identical between a frame relay access link and a Cisco default HDLC point-to-point link. Both use a 16 bit CRC and discard errored frames.
... but apparently you have enough to be an arrogant F#. The guy was just asking for some help explaining this, and you "first reaction" is to be insulting.F# ...
As I wrote earlier, "There are a lot of variables here ..." - including the Frame Relay encapsulation type, the routers at each end, duplex, quality of the line itself, ...
Not if you have the goods to back it up. Let's see, Vincent, literally, wrote the book on fault tolerant network design. He's a Ph.D. He's a real Prof Engineer. I've personally seen some of his work in action. They are quite elegant (and complex). It took me a bit to absorb what he was trying to accomplish and then later support it (I was responsible for moving the data center where he did some work)
He was also replying to your comments so he didn't address the original posters comments in his reply to your post. So your first sentence is completely off the mark. And I didn't think he was insulting in the least.
Finally, one advice I can give you is "best way out of a hole is to stop digging." For example, why would duplex matter for FR/P2P links?
Hang around the group for a bit and try to learn from those who know what they are saying. Don't get some damn defensive for cryin out loud.
I was the one who asked whether the duplexes are the same for both devices. If I recall correctly, some P2P links are implemented as 2-wire half-duplex. When you have asymmetric data volumes, full duplex can potentially keep streaming because the ACKs can flow back while data is being sent; but with half duplex the line turn-arounds have significant impact on the queuing theory.
I have been reading, and perhaps contributing to this group for a number of years and for me Vincent is probably the most valuable contributor in terms of the amount that it is possible to learn. I see no sign of arrogance at all.
His writing is always of the highest quality with carefully constructed sentences and he always avoids personal comments of any kind.
My first cut would most certainly be to believe every last word, letter, full stop that he writes.
Clearly from time to time there will be differences in preferences for this or that however he is most likely exactly correct.
Anyway, have a nice holiday, In the UK we are off 'til Wednesday:-)
Need to do CCDA for employer's cisco relationship so off to buy myself a christmas present.
-you are correct, by pinging the other end of the link using my router at default of 100 bytes
the other side of the link
and two workstations connected to that switch (default vlan1 also). I put in global IPs for the workstations provided by my ISPs and created a route-map policy so the workstation with the appropriate IP passes by the correct serial interface to the correct provider.
Isnt HDLC a layer two protocol too like frame relay?
Close enough to my original assumption of 64 byte ping packets...
This is one place where the inconsistent results could come from... (i.e., you are not pinging what you think you are). However, there is an alternate explanation, see below.
OK.
OK. So the pings are going to the ISP's router while the loading traffic is going through the ISP's router.
Yes, but HDLC only gets you to the "other end of the physical link" whereas frame relay (which uses HDLC) gets you to the "other end of the virtual circuit" which could be an arbitrary number of hops. However, this is probably a moot point, my suspicion is that your ISP terminates your physical frame link and your logical frame link on the same router so there is no meaningful difference between the two links from a protocol viewpoint, only the data rates and the router at the other end are different.
Two conclusions (really questions for you), as there are two independent inconsistencies in the performance you are seeing:
1 - You are not seeing any impact of loading on the response time of the frame relay link. This implies to me that the link is configured to use "fair queueing" or the equivalent, so that the traffic hog and your test traffic are being independently queued. This is exactly what "fair queueing" is intended to accomplish. It is also the default on serial links on Cisco routers.
2 - You are seeing abysmal performance on your 256Kbps link. The use of an underpowered, brain dead router is implied by the lack of "fair queueing", your response time degradation looks like simple FIFO queueing. But even an antique sloth router like a 25xx only requires 3-4 ms to forward a packet, nowhere near the 10-15 ms unaccounted for delays you are seeing at no load. This could be because the router is overloaded and unable to respond to your traffic, or it could be that you are paying for 256 Kbps and only using 64 Kbps. Check what bandwidth you can get with an unopposed FTP or BitTorrent.
DISCLAIMER: You get what you pay for. The conclusions above are based on the limited information provided, much conjecture, and minimal effort. While they are the most likely explanation of the behaviors you are reporting, they are not the only explanation and further testing would be required to verify or disprove each hypothesis.
Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.