OR Cable Modem Services
OR Cable Modem ServicesInbound UDP flooding data rate is 6.6 Mbs through Linksys and 9.9 Mbs without Linksys. TCP is about 4.0 Mbs through linksys to UT using Java bandwidth tester and with a recvwindow of 64KB. However, if linksys is removed and PC (Win98) is hooked directly to cable modem, then TCP java test to UT gets 4.5 Mbs. (Given a RTT of 95 ms and a 64KB window, the bandwidth is limited by the window to 5.4 Mbs, so 4.5 Mbs is about what should be expected after a 10s test.) The Linksys appears to be reducing bandwidth. In February, inbound data rates were 3.2 Mbits/s (for UDP flooding) and outbound rates remain restricted to 128 Kbs. The hop count to ORNL is still near 20, and the RTT around 150 ms. Thus to obtain 3.2 Mbs the client and server TCP window size needs to be 3.7*.150 = .480 Mbits, or about 60 KBytes. With only a 32 KB window, the max throughput you will get is 1.7 Mbits/sec. (Though, even with a large buffer, I still get only about 2 Mbs with TCP.) The packets are not wildly out of order as they were before. The following plot from Wedndesday, March 6, shows how the lost-packet rate has improved since our test on February 8 (see plot). The plotted data is percent loss per minute, calculated from 1-second ICMP ping's between an Oak Ridge @home PC and an ORNL machine.
Older (January 1, 2001) performance shows 128 Kbs out from the home and about 700 Kbs in. Detailed analysis shows that there might be as much as 6+Mbs inbound through (parallel?) T1's, but the load balancing across the links causes enough packet reordering that TCP thinks there are losses. This plot shows how out of order UDP datagrams can be on my @home link. This plot would normally be a straight line at y=0. (Note, the load-balanced paths aren't necessarily in the last hop, but could be somewhere else in the path.) Rumor is they plan to upgrade to a DS3 (45 Mbs) Feb 12, and to re-establish the direct link to ORNL. (It's more than 16 hops right now, RTT of 130 ms. Also, the forward and reverse paths to ORNL are not the same, see table of traceroutes to/from my @Home box from/to ORNL.) I have a bandwidth testing page with information on TCP tuning and tracing routes. (Note, traceroute/tracert probably won't work from behind a firewall, e.g. Linksys.)
The following plot shows how the lost-packet rate increases during "prime time" on Wednesday, February 8, 2001. The plotted data is percent loss per minute, calculated from 1-second ICMP ping's between an Oak Ridge @home PC and an ORNL machine. The losses could be occurring anywhere along the many hops and not necessarily within @home's nets.
TCP packet loss results in lower bandwidth and in poor interactive response times. Packet loss degrades bandwidth more with longer round-trip times (RTT). The following plot from a network simulation (ns-2) roughly shows how packet loss degrades TCP bandwidth for a 2 Mbs link for both a long delay (100 ms RTT) link and moderate delay (10 ms RTT) link. With just a 2% loss (p=0.02), bandwidth is halved. With a 20% loss (p=0.2) our 2 Mbs link is slower than a 28.8k dialup!
Poor interactive response is noticable if you are telnet'd to a remote host and the echo delay for your typing is delayed. The following graph shows the echo delay to ORNL for 100 one-character samples during prime time and during the early morning. Notice that during prime time, character echo is generally slower with occasional delays over 1 second.
Your throughput is going to be no better than the slowest link along the route to/from your destination. TCP throughput can be restricted by a small "window size". For TCP, windowsize = bandwidth*roundtriptime You may be able to adjust the windowsize from an appliation or through your OS. Too big a windowsize can actually reduce bandwidth. Visit the bandwidth testing page or dslreports tuning tweaks page
Security
Though Ethernets are normally "party-lines" and subject to eavesdropping, the OR CATV configuration permits your cable modem to see only traffic destined to your home computer and no one else's traffic. However, as with any ISP, your network packets travel through many sites, so you should assume someone could be reading your packets along the way. There are various products (ssh, pptp, pgp) that one might use to insure privacy. Or for security you might consider firewall software (zonealarm or network ice) , or a firewall box. The Linksys BEFSR41 is both NAT and firewall and works with ORNL's VPN. Also CERT's info on nome network security.
ISPchannel's FAQ
